Kubernetes Deployment

Manifests live in deployments/kubernetes/. Apply them in order or use kustomize.

Prerequisites

• Kubernetes 1.27+
• kubectl configured for your cluster
• A container registry the cluster can pull from
• A StorageClass that provides ReadWriteOnce PVCs (standard on most managed clusters)

Quick deploy

# 1. Build and push the image
docker build -t registry.example.com/vetrix:latest .
docker push registry.example.com/vetrix:latest

# 2. Edit secrets (replace placeholder values with real base64-encoded secrets)
#    NEVER commit the edited secret.yaml to version control.
$EDITOR deployments/kubernetes/secret.yaml

# 3. Apply manifests
kubectl apply -f deployments/kubernetes/namespace.yaml
kubectl apply -f deployments/kubernetes/secret.yaml
kubectl apply -f deployments/kubernetes/configmap.yaml
kubectl apply -f deployments/kubernetes/pvc.yaml
kubectl apply -f deployments/kubernetes/deployment.yaml
kubectl apply -f deployments/kubernetes/service.yaml
kubectl apply -f deployments/kubernetes/ingress.yaml

# 4. Wait for pod to be ready
kubectl -n vetrix rollout status deployment/vetrix

# 5. Create admin account
kubectl -n vetrix port-forward svc/vetrix 3000:80 &
curl -X POST http://localhost:3000/api/v1/setup \
     -H 'Content-Type: application/json' \
     -d '{"username":"admin","email":"admin@example.com","password":"CHANGE_ME"}'

Secrets management

The secret.yaml template uses stringData for readability. In production use one of:

• External Secrets Operator (recommended) — sync from AWS Secrets Manager, Vault, GCP Secret Manager
• Sealed Secrets — encrypt with kubeseal, safe to commit
• Helm with --set or values.secret.yaml (gitignored)

Never store unencrypted secrets in version control.

Scaling

Vetrix uses a ReadWriteOnce PVC for git repository storage. With RWO:

• Replicas must be 1 unless you mount a shared network filesystem (NFS, CephFS, AWS EFS, Azure Files).
• For HA deployments, provision a ReadWriteMany PVC and set replicas: 2+.
• The deployment strategy is set to Recreate by default to avoid split-brain on RWO volumes.

SSH access

The vetrix-ssh Service is of type LoadBalancer. Your cloud provider will allocate an external IP. Point your DNS A record for git.example.com at this IP:

# Get the external IP
kubectl -n vetrix get svc vetrix-ssh

Users clone via:

git clone ssh://git@git.example.com:22/alice/myrepo

Ingress (HTTPS)

Edit deployments/kubernetes/ingress.yaml to set your hostname and uncomment the cert-manager annotation:

annotations:
  cert-manager.io/cluster-issuer: "letsencrypt-prod"
  nginx.ingress.kubernetes.io/proxy-body-size: "512m"
spec:
  ingressClassName: nginx
  ...

Health probes

The Deployment configures both probes automatically:

Probe	Path	Meaning
Liveness	/api/v1/health	Restart container if it stops responding
Readiness	/api/v1/ready	Only send traffic when DB connection is healthy

Upgrading

# Update the image tag in deployment.yaml, then:
kubectl apply -f deployments/kubernetes/deployment.yaml
kubectl -n vetrix rollout status deployment/vetrix

# Roll back if needed:
kubectl -n vetrix rollout undo deployment/vetrix

Vetrix applies migrations on startup. The readiness probe ensures no traffic reaches the pod until migrations complete.

Resource tuning

Default resource requests (in deployment.yaml):

	CPU	Memory
Requests	250m	256Mi
Limits	2000m	1Gi

Adjust based on repository count, team size, and CI/CD load.