Tech Story: Kubernetes manifests and cluster setup

[GitAddRemote]

Tech Story

As a platform engineer, I want the Station application deployed to a Kubernetes cluster with all required services so that we have a scalable, self-healing production environment with clear separation between application and infrastructure concerns.

Context

Currently no k8s manifests exist. Station requires: NestJS backend, React frontend (nginx), PostgreSQL, Redis, and eventually a Discord bot container. All should be deployable from a single kubectl apply or Helm chart.

Acceptance Criteria

• Namespace station created for all resources
• Backend: Deployment, Service, HorizontalPodAutoscaler
• Frontend: Deployment (nginx), Service
• PostgreSQL: StatefulSet with PersistentVolumeClaim (or external managed DB — decision to be made)
• Redis: Deployment or StatefulSet with persistence
• Ingress resource routing /api → backend, / → frontend
• TLS via cert-manager + Let's Encrypt (ClusterIssuer configured)
• Secrets (JWT_SECRET, DB credentials, etc.) stored as k8s Secrets (not in manifests)
• ConfigMap for non-sensitive environment config
• readinessProbe and livenessProbe on all application pods
• Resource requests and limits set on all containers
• Manifests organised under k8s/ directory in repo root

Technical Elaboration

• Use nginx ingress controller (or Traefik — decision to be made based on host)
• cert-manager Certificate resource + ClusterIssuer for Let's Encrypt ACME
• Consider kustomize overlays for dev vs production environments
• PostgreSQL: evaluate managed DB (e.g. cloud provider) vs in-cluster StatefulSet for production
• Secrets: evaluate external secrets operator or sealed secrets vs manual kubectl create secret

Notes

• CI/CD pipeline issue (story: CI/CD pipeline for staging and production #90) should be updated or created alongside this to build/push images and apply manifests on merge to main
• Decision on managed vs in-cluster Postgres should be documented as an ADR