Deploying to Kubernetes
Plugin: TSH Platform Engineering
Invoke: /tsh-platform-engineering:deploying-to-kubernetes, or loaded automatically when a request matches its description
Used by: devops-engineer, infrastructure-auditor
Configures Kubernetes workloads to a production standard. The premise is that Kubernetes defaults are not production defaults: a manifest with no requests, no probes and no disruption budget deploys successfully and then behaves badly under the conditions it was deployed for.
Key Areas
| Area | Coverage |
|---|---|
| Precedence | Reads the shared context file (sections 2, 3 and 5): raw manifests, Helm or Kustomize, the API versions the cluster serves, and whether a GitOps controller owns the cluster. The project's existing packaging is matched; adding a Helm chart to a Kustomize repository is a finding. |
| Workload type | Deployment for stateless apps, StatefulSet for stable identity or ordered startup, DaemonSet for node-level agents, Job for one-off tasks, CronJob for scheduled ones. A StatefulSet only when stable network identity or per-replica storage is genuinely required. |
| Resources and QoS | Requests on every container, a memory limit always, and CPU limits as a deliberate decision because throttling shows up as tail latency. Production workloads are Guaranteed or Burstable, never BestEffort. A 1:2 request-to-limit ratio is a reasonable starting point for memory. |
| Probes | Readiness on anything that serves traffic and may check dependencies. Liveness checks the process only, never its dependencies. Startup probes for slow starters. |
| Resilience | At least two replicas and a PodDisruptionBudget in production. maxUnavailable: 1 is the safe default for three or more replicas, and minAvailable equal to the replica count blocks drains. Preferred pod anti-affinity or topology spread constraints, not required rules that can leave pods Pending. |
| Scaling | HPA for CPU or memory, and for custom metrics through the Prometheus adapter. KEDA for message queues and external events and the only option that scales to zero. VPA for right-sizing requests, usually in Off mode. HPA and VPA are not pointed at the same workload on CPU or memory. |
| Packaging | Helm chart layout and values.yaml conventions (no committed image tag, name helpers, safe defaults), or Kustomize base/ and overlays/. Whichever the project already uses; Helm for distribution to other teams, Kustomize for an internal app with a few environments. |
| Ingress and networking | Controller choice (ingress-nginx, AWS Load Balancer Controller, Traefik, a Gateway API implementation, or a mesh gateway), TLS with cert-manager, ingressClassName, controller-specific annotations, default-deny network policies that need an enforcing CNI, and ClusterIP as the default service type. |
| Security context | Non-root, allowPrivilegeEscalation: false, dropped capabilities, seccompProfile set to RuntimeDefault, and readOnlyRootFilesystem: true with an emptyDir mount where the app writes. |
| Rules | Requests on every container, a readiness probe, pinned image tags, non-root in production, two replicas and a PDB in production, and server-side validation. Never put secret values in a ConfigMap, manifest or committed values file, and never kubectl apply directly against a cluster a GitOps controller owns. |
How it works
- Discover packaging, cluster API versions and whether GitOps owns the cluster, from the shared context file.
- Choose the workload type.
- Configure resources. Requests come from measured usage where available, an estimate is labelled as one, and the request-to-limit ratio is set deliberately.
- Add probes: readiness always, startup for slow starters, liveness checking the app itself.
- Add resilience: replicas, PDB, anti-affinity or topology spread.
- Add scaling if the load varies.
- Harden with a security context, and network policies where the cluster enforces them.
- Package to the project's convention.
- Validate with
kubectl apply --dry-run=serverandhelm template, andkubeconformwhere the project has it. Client-side dry-run does not catch admission failures.
References
| Reference | Load when |
|---|---|
workload-configuration.md | Writing or reviewing any workload manifest. Read before writing one: resources, QoS, all three probe types, PDB, anti-affinity and security context. |
scaling.md | The workload needs to scale, or scales badly. HPA with behavior tuning, KEDA, VPA, and a note that pod autoscaling only helps if nodes exist. |
helm-and-kustomize.md | Packaging a workload, or changing a chart or overlay. |
ingress-and-networking.md | Exposing a service outside the cluster. |
Related skills
- Implementing Observability - cluster and workload monitoring.
- Implementing CI/CD Pipelines - how the manifests get deployed.
- Managing Secrets - in-cluster secret delivery.
- Implementing Terraform Modules - provisioning the cluster itself.