Designing Kubernetes workloads

A production workload is more than a Deployment and a Service.

Stateless service baseline

Use a Deployment with multiple replicas, rolling-update strategy, readiness, startup and liveness probes, resource requests, sensible limits, topology spread, Pod disruption budget, security context, dedicated service account, and controlled configuration.

Graceful behavior

When Kubernetes terminates a Pod it sends a signal and waits for a grace period. The application should stop accepting new work, finish or hand off safe work, close connections, and exit. Align load-balancer draining, readiness, signal handling, and termination grace.

Configuration

Keep environment-specific configuration outside images. ConfigMaps are not secret stores. For sensitive values, prefer Secret Manager integration or carefully governed Kubernetes Secrets with encryption, access, and rotation.

Stateful work

Kubernetes can run stateful software, but a managed database often reduces risk. If state must run in GKE, define stable identity, storage class, replication, anti-affinity, quorum, backup, upgrades, disruption, and recovery. A StatefulSet does not create database replication for you.

Batch and events

Use Jobs and CronJobs for finite work, with concurrency and history limits. For event-driven scale-to-zero use cases, evaluate Knative-based platforms or KEDA where supported and governed. Never let an uncontrolled retry create an infinite expensive workload.