Kubernetes Deployment

Kubernetes Deployment

Template files: deploy/kubernetes/base/

Prerequisites

• Kubernetes cluster with kubectl access
• A PostgreSQL or MySQL database accessible from the cluster

Deploy

Deployment is a two-phase process: server first, then agent (the agent needs a token generated by the server).

Phase 1: Server

# Apply namespace, service account, config, PVC, and server deployment
kubectl apply -f deploy/kubernetes/base/namespace.yaml
kubectl apply -f deploy/kubernetes/base/serviceaccounts.yaml
kubectl apply -f deploy/kubernetes/base/configmaps.yaml
kubectl apply -f deploy/kubernetes/base/server-pvc.yaml
kubectl apply -f deploy/kubernetes/base/server-deployment.yaml
kubectl apply -f deploy/kubernetes/base/server-service.yaml
kubectl apply -f deploy/kubernetes/base/networkpolicy.yaml

Wait for the server to become ready:

kubectl -n dbward rollout status deploy/dbward-server

Phase 2: Bootstrap tokens

# Get the admin token
kubectl -n dbward exec deploy/dbward-server -- cat /data/admin-token

# Get the agent token
kubectl -n dbward exec deploy/dbward-server -- cat /data/agent-token

Update the Secret with the real values:

kubectl -n dbward create secret generic dbward-secrets \
  --from-literal=agent-token=dbw_... \
  --from-literal=database-url=postgres://user:pass@db-host:5432/app \
  --dry-run=client -o yaml | kubectl apply -f -

Phase 3: Agent

kubectl apply -f deploy/kubernetes/base/secrets.yaml  # if not created above
kubectl apply -f deploy/kubernetes/base/agent-deployment.yaml

Access the server

The server Service is ClusterIP (internal only). To access it:

Port-forward (development / first-time setup):

kubectl -n dbward port-forward svc/dbward-server 3000:3000

Production: Create an Ingress or change the Service type to LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  name: dbward-server
  namespace: dbward
spec:
  type: LoadBalancer
  ports:
    - port: 3000
      targetPort: http
  selector:
    app.kubernetes.io/name: dbward-server

Persistence

The server uses a PersistentVolumeClaim (dbward-server-data, 1Gi RWO) mounted at /data. This stores the SQLite database, signing keys, and bootstrap tokens. The PVC must survive pod restarts.

The agent is stateless — no PVC needed.

Network Policy

The manifests include a default-deny policy with targeted exceptions:

Policy	Allows
default-deny	Block all ingress/egress by default
allow-dns	UDP/TCP 53 for all pods
server-ingress	Agent → Server:3000, Ingress controller → Server:3000
server-egress	Server → HTTPS:443 (webhooks, OIDC, S3)
agent-egress	Agent → Server:3000, Agent → Database:5432/3306

Multi-agent

The base manifests include a single agent Deployment. For multiple databases or environments with different capabilities, duplicate the agent resources:

1. Copy agent-deployment.yaml → agent-staging-deployment.yaml
2. Create a separate ConfigMap with the staging agent config
3. Update labels and names to avoid conflicts

Alternatively, use Kustomize overlays or the Helm chart.

Upgrade

# Update image tag in deployment manifests, then:
kubectl -n dbward set image deploy/dbward-server server=ghcr.io/dbward-dev/dbward-server:v0.1.3
kubectl -n dbward set image deploy/dbward-agent agent=ghcr.io/dbward-dev/dbward-agent:v0.1.3

The server applies SQLite migrations automatically on startup.

See also

• Server configuration — full server settings reference
• Agent configuration — agent settings, capabilities, resilience
• Helm deployment — deploy with Helm for easier configuration management
• Troubleshooting — common deployment issues