Skip to content
Databasezy Docs

Connecting from a Kubernetes cluster

Tested with: Kubernetes 1.31 · External Secrets Operator 0.10 · cert-manager 1.16 · Cilium 1.16

Your workloads talk to Databasezy over the public endpoint (or PrivateLink on Enterprise); nothing of ours runs in your cluster. The pattern is the same for every engine:

Deployment ──► env from Secret (DATABASE_URL, password)
           ──► ExternalName Service "pg-prod" ──► pg-7f3k.us-east.databasezy.com:5432
           ──► NetworkPolicy allows egress to that FQDN / CIDR only
           ──► CA bundle mounted from a ConfigMap (drivers that need it)

Minimal working example

Section titled “Minimal working example”

  1. Create the credential Secret. In production this comes from your secret manager through an ExternalSecret; for a first test, create it directly.

    shell
    kubectl create namespace app
    kubectl -n app create secret generic zb-pg-prod \
      --from-literal=host=pg-7f3k.us-east.databasezy.com \
      --from-literal=port=5432 \
      --from-literal=username=app \
      --from-literal=password='<password>' \
      --from-literal=database=app

  2. Publish the CA bundle as a ConfigMap (needed for libpq-based drivers; see CA bundle).

    shell
    zb api GET /v1/orgs/{org}/ca.pem > databasezy-ca.pem
    kubectl -n app create configmap databasezy-ca --from-file=ca.crt=databasezy-ca.pem

  3. Give the host a stable in-cluster name and allow egress to it.

    pg-prod-service.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: pg-prod
      namespace: app
    spec:
      type: ExternalName
      externalName: pg-7f3k.us-east.databasezy.com
      ports:
        - name: postgres
          port: 5432

    The NetworkPolicy page shows the matching egress rule for Cilium, Calico and vanilla policies.

  4. Reference everything from the workload.

    deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: api
      namespace: app
    spec:
      replicas: 2
      selector: { matchLabels: { app: api } }
      template:
        metadata:
          labels: { app: api }
        spec:
          containers:
            - name: api
              image: ghcr.io/acme/api:1.4.2
              env:
                - name: PGHOST
                  valueFrom: { secretKeyRef: { name: zb-pg-prod, key: host } }
                - name: PGPORT
                  valueFrom: { secretKeyRef: { name: zb-pg-prod, key: port } }
                - name: PGUSER
                  valueFrom: { secretKeyRef: { name: zb-pg-prod, key: username } }
                - name: PGPASSWORD
                  valueFrom: { secretKeyRef: { name: zb-pg-prod, key: password } }
                - name: PGDATABASE
                  valueFrom: { secretKeyRef: { name: zb-pg-prod, key: database } }
                - name: PGSSLMODE
                  value: verify-full
                - name: PGSSLROOTCERT
                  value: /etc/databasezy/ca.crt
              volumeMounts:
                - name: databasezy-ca
                  mountPath: /etc/databasezy
                  readOnly: true
              resources:
                requests: { cpu: 100m, memory: 128Mi }
                limits: { memory: 256Mi }
          volumes:
            - name: databasezy-ca
              configMap: { name: databasezy-ca }

  5. Allow the cluster’s egress IPs on the instance. With a NAT gateway that is one CIDR; with per-node public IPs, use the node CIDR or a static egress gateway (Cilium Egress Gateway, GKE Cloud NAT, EKS NAT).

    shell
    zb api PUT /v1/orgs/{org}/instances/pg-7f3k/network -d '{"allow_cidrs": ["198.51.100.0/26"]}'

    The call replaces the whole list; include any CIDRs you already allow, or use Network → Allow-list in the portal.

Pages in this section

Section titled “Pages in this section”