Getting Started with the Databases Service

This guide will walk you through the process of provisioning a new PostgreSQL database using the managed Databases service.

By following these steps, you will learn how to find the available database server, create a Database custom resource to provision your database, and connect your application to it using the automatically generated credentials.

Prerequisites

Before you begin, you will need access to a Kubernetes cluster on the platform.

Step 1: Discover the Database Instance

The platform provides one or more highly available database servers (instances) per cluster. You do not create the server; you create your individual databases on this shared server.

First, you need to find the name of the available database instance. You can do this with kubectl:

kubectl get dbin

You will see output similar to this, listing the available instance(s):

NAME                                                   PHASE     STATUS
prod1-dc4-dbaas01.netic-platform.shared.k8s.netic.dk   Running   true

Take note of this name. You will need it for the next step.

Step 2: Create Your Database

You provision a new database by creating a Database custom resource in your application's namespace. The db-operator will detect this resource and automatically create the database and a corresponding user and password.

Create a manifest file (e.g., my-database.yaml) with the following content:

apiVersion: "kinda.rocks/v1beta1"
kind: "Database"
metadata:
  name: "my-application-db"
spec:
  # This must match the name of the DbInstance from Step 1
  instance: prod1-dc4-dbaas01.netic-platform.shared.k8s.netic.dk

  # The operator will create a Secret with this name
  secretName: my-app-db-credentials

  # This prevents the database from being deleted if the manifest is removed
  deletionProtected: true

  # Backup is managed at the instance level, so this should remain false
  backup:
    enable: false

Apply this manifest to your cluster using kubectl or by committing it to your GitOps repository.

Key Configuration Fields

• spec.instance: (Required) The full name of the DbInstance you discovered in Step 1.
• spec.secretName: (Required) The name of the Kubernetes Secret that the operator will create to hold the database credentials (username, password, host, etc.).
• spec.deletionProtected: (Highly Recommended) When set to true, deleting the Database manifest from Kubernetes will not delete the actual database on the server. This is a critical safety feature to prevent accidental data loss.

Step 3: Access and Use the Database

Once the db-operator has processed your request, it will create a Secret with the name you specified in secretName.

You can inspect the secret to see the credentials:

kubectl get secret my-app-db-credentials -o yaml

The best way to use these credentials is to mount them as environment variables in your application's Deployment or StatefulSet.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-application
spec:
  # ... other deployment specs
  template:
    spec:
      containers:
      - name: app
        image: my-app-image
        envFrom:
          - secretRef:
              name: my-app-db-credentials
        # Your application can now use environment variables like
        # DBNAME, USER, PASSWORD, HOST, and PORT to connect to the database.

Advanced: Custom Connection Strings

The Secret created by the operator contains all the individual fields needed to connect to the database. If your application requires a specific connection string format (e.g., a JDBC URL), you can instruct the operator to generate it for you.

Add the spec.credentials.templates section to your Database manifest:

spec:
  # ... other fields
  credentials:
    templates:
      - name: CONNECTION_STRING # The key for the new entry in the Secret
        # A Go template for your desired connection string format
        template: "jdbc:{{ .Protocol }}://{{ .Username }}:{{ .Password }}@{{ .Hostname }}:{{ .Port }}/{{ .Database }}"

The operator will add a new key (CONNECTION_STRING) to the Secret with the fully rendered connection string.

Backup and Recovery

Database backup and recovery is managed at the instance level by the platform team. You do not need to configure anything in your manifests.

Full backups are taken nightly at 22:00 and archived for 6 months. Point-in-time recovery (PITR) is also enabled, with transaction logs archived every 5 minutes. This allows for restoration to any 5-minute interval within the last 5 days.

Please contact the platform team to initiate a database restoration.