Week 26: Capstone, Part 2 — Deploy, Harden & Ship

1. Deploying to Kubernetes

The manifests below use the same shapes from Weeks 11–12, wired to the RDS instance Week 25 provisioned instead of a database Pod, applied once by hand to bootstrap the cluster before the pipeline — or ArgoCD, if that's the path you chose in Week 25 — takes over updating the image going forward.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: capstone-app
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate: { maxUnavailable: 0, maxSurge: 1 }
  selector:
    matchLabels: { app: capstone-app }
  template:
    metadata:
      labels: { app: capstone-app }
    spec:
      containers:
        - name: app
          image: PLACEHOLDER   # set by the deploy step
          ports: [{ containerPort: 8000 }]
          env:
            - name: DATABASE_URL
              valueFrom: { secretKeyRef: { name: capstone-db, key: url } }
          readinessProbe:
            httpGet: { path: /healthz, port: 8000 }
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet: { path: /healthz, port: 8000 }
            initialDelaySeconds: 15
            periodSeconds: 20
          resources:
            requests: { cpu: "100m", memory: "128Mi" }
            limits:   { cpu: "500m", memory: "256Mi" }
---
apiVersion: v1
kind: Service
metadata:
  name: capstone-app
spec:
  selector: { app: capstone-app }
  ports: [{ port: 80, targetPort: 8000 }]

replicas: 2 with maxUnavailable: 0 is what makes the rollout genuinely zero-downtime: Kubernetes must bring up a new, ready Pod (maxSurge: 1) before removing an old one, so there's never a moment with fewer than two healthy Pods — a guarantee that only holds because a readinessProbe is defined; without one, a Pod counts as ready the moment its process starts, well before it can actually serve a request against the database correctly.

  deploy:
    needs: build-scan-push
    runs-on: ubuntu-latest
    environment: production   # requires reviewer approval -- Week 7
    steps:
      - uses: actions/checkout@v4
      - run: |
          mkdir -p ~/.kube
          echo "${{ secrets.KUBECONFIG_B64 }}" | base64 -d > ~/.kube/config
      - run: |
          kubectl set image deployment/capstone-app app=${{ needs.build-scan-push.outputs.image }}
          kubectl rollout status deployment/capstone-app --timeout=120s

kubectl rollout status is what makes this trustworthy — the job doesn't report success the instant it issues the update, it waits and confirms the new Pods actually became ready. If you chose ArgoCD instead in Week 25, this step is replaced entirely by an image-tag bump to a Git repo ArgoCD watches, per Week 17 — either is a legitimate capstone choice as long as you can explain why you picked it.

2. Observability, SLOs & Security

A pipeline that deploys correctly but leaves you blind, unmeasured, and unrestricted once the app is running only solves part of the problem. Apply Weeks 13, 14 and 21 in full:

• Metrics & dashboards — deploy the kube-prometheus-stack Helm chart to scrape both cluster-level metrics and the app's own /metrics endpoint, and build one Grafana dashboard covering request rate, error rate and Pod restarts.
• An SLO — define one real availability or latency SLO for the app (Week 21) backed by a Prometheus query against those metrics, and calculate its error budget over a 7-day window.
• Logging — confirm the app logs structured JSON to stdout, which kubectl logs can consume without extra parsing.
• Secrets — every credential the pipeline or cluster uses lives in GitHub Encrypted Secrets or a Kubernetes Secret, never committed to the repo — verify with git log -p -- '*.env' '*.pem' turning up nothing.
• Network policy — a default-deny NetworkPolicy plus one explicit allow rule for the app's actual traffic pattern to the RDS instance and inbound HTTP.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny }
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: allow-app-traffic }
spec:
  podSelector: { matchLabels: { app: capstone-app } }
  policyTypes: [Ingress, Egress]
  ingress:
    - from: []
      ports: [{ protocol: TCP, port: 8000 }]
  egress:
    - to: []                                 # RDS lives outside the cluster
      ports: [{ protocol: TCP, port: 5432 }, { protocol: UDP, port: 53 }]  # + DNS, per Week 14

That trailing UDP/53 rule is Week 14's lesson paid forward directly — a default-deny egress policy blocks DNS resolution unless explicitly allowed, and a Pod that can't resolve the RDS endpoint's hostname fails in a confusing way that has nothing to do with the actual NetworkPolicy intent.

3. The Capstone Project

4. Final Checklist

Before calling the capstone — and the course — done, confirm each of these honestly: