Kubernetes Deployment Checklist: From Container Image to Production Readiness

Overview

Kubernetes can schedule an application successfully while the application remains unsafe, difficult to operate, or expensive to troubleshoot. Production readiness depends on the surrounding controls: a traceable image, explicit configuration, realistic resource settings, meaningful health checks, restricted access, observable behavior, and a tested recovery path.

Use this Kubernetes production checklist as a release gate rather than a one-time setup task. Review it before an initial production deployment, then revisit it after significant application, cluster, traffic, or dependency changes. The exact manifests will vary between teams, but the questions remain broadly useful across managed and self-managed clusters.

For infrastructure managed through Terraform, keep cluster and supporting-resource changes in a controlled workflow. The guide to Terraform state management covers remote backends, locking, and team-safe coordination. Separating infrastructure changes from application releases can make it easier to identify which change caused an incident.

What to track

1. Container image and supply chain

• Build the image from a reviewed source revision and record the commit or release identifier.
• Use an immutable image reference where practical, such as a digest, rather than relying only on a mutable tag.
• Remove development tools, unnecessary shells, credentials, and build artifacts from the runtime image.
• Run the process as a non-root user unless the workload has a documented reason not to.
• Define an image scanning and patching process, including ownership for responding to findings.

The deployment should make it possible to answer a basic operational question quickly: which exact image is running in each environment? Avoid manually changing an image in a live cluster without recording the change in version control or the release system.

2. Manifests and configuration

Keep Kubernetes objects declarative and reviewable. A typical application deployment should have clearly defined labels, selectors, a namespace, a service account, container ports, update behavior, and an explicit number of replicas. Labels should identify the application, environment, and release in a consistent way so that logs, metrics, policies, and selectors continue to work as the application evolves.

Keep environment-specific values separate from the base manifest. ConfigMaps are suitable for non-sensitive configuration; Secrets are intended for sensitive values, but their use does not eliminate the need for access controls, encryption practices, rotation, and auditability. Do not place passwords, tokens, or private keys directly in a container image or committed manifest.

Review the service account attached to the workload. If the application does not need access to the Kubernetes API or cloud resources, avoid granting it those permissions. For broader IAM guidance, see Cloud IAM best practices.

3. Health probes

Kubernetes health probes are operational contracts, not simple availability flags. Configure them according to what the application can reliably report:

• Startup probe: Use it for applications that need substantial time to initialize. It can prevent liveness checks from restarting a process before startup is complete.
• Readiness probe: Use it to indicate whether the pod can receive traffic. A pod may be running but not ready because it is loading configuration, warming a cache, or waiting for a required dependency.
• Liveness probe: Use it only for conditions that indicate the process should be restarted. A dependency outage is not always a reason to restart every replica.

Set initial delays, timeouts, failure thresholds, and check intervals based on observed startup and response behavior. A probe that is too strict can create a restart loop; one that is too permissive can route traffic to a broken process.

4. Resource requests, limits, and autoscaling

Kubernetes resource requests influence scheduling, while limits constrain container usage according to the configured resource type and cluster behavior. Set requests from measured or carefully estimated workload needs rather than copying values from another service. Requests that are too low can lead to contention and poor scheduling decisions; requests that are too high can leave capacity unused and increase infrastructure cost.

Review memory and CPU separately. Memory pressure can cause termination, while CPU contention may appear as latency or reduced throughput. If you use a Horizontal Pod Autoscaler, verify that the selected metrics reflect actual demand and that the application can safely add replicas. Autoscaling cannot compensate for a database bottleneck, a fixed connection pool, or a downstream rate limit.

5. Availability and rollout settings

Define a rollout strategy that matches the service's tolerance for interruption. Rolling updates should specify how many pods can be unavailable or added during a change. Check that the replica count, readiness behavior, and disruption settings work together. A high replica count does not guarantee availability if all pods land on one failure domain or depend on the same unavailable service.

Use a PodDisruptionBudget where voluntary disruptions need protection, but do not set it so strictly that cluster maintenance becomes impractical. If the workload needs stronger placement guarantees, review topology spread constraints or affinity rules and test them against the capacity actually available in the cluster.

6. Secrets, access, and network boundaries

Limit which people, workloads, and automation identities can read or change the namespace. Review Role-Based Access Control permissions, service-account usage, and admission or policy controls where available. Network policies can reduce unnecessary communication between workloads, but they should be introduced with a tested traffic inventory so that required dependencies are not blocked unexpectedly.

Protect the delivery path as well as the cluster. CI/CD credentials should be scoped to the environments and actions they require, and production deployments should have an auditable approval or promotion process appropriate to the risk. The guide to securing GitHub Actions secrets and runners provides related controls for teams using GitHub Actions.

7. Logging, metrics, and alerting

Before release, identify the signals that show whether the service is healthy. At minimum, track request volume, error rate, latency, pod restarts, readiness failures, resource saturation, and deployment status. Capture structured application logs with enough context to connect a request or job to a release and workload instance, while avoiding secrets and unnecessary personal data.

Alerts should lead to an action. An alert for repeated restarts should point an operator toward container logs and recent rollout history; an alert for elevated latency should help distinguish application saturation from dependency or network problems. A monitoring dashboard that is never used during a deployment is less valuable than a smaller dashboard tied to clear decisions.

Cadence and checkpoints

Use different review cadences for different risks rather than waiting for an annual checklist exercise.

• Every deployment: Verify the image identifier, manifest diff, configuration changes, probe behavior, resource settings, rollout status, and release owner. Confirm that the deployment can be paused or rolled back.
• After a significant application change: Recheck startup time, readiness conditions, dependency usage, resource consumption, and autoscaling assumptions. Changes to database queries, caching, concurrency, or background work can alter the workload profile even when the Kubernetes manifest changes little.
• Monthly: Review failed probes, restart counts, pending pods, capacity pressure, noisy alerts, image vulnerabilities, unused permissions, and stale configuration. Look for recurring symptoms rather than treating each incident as isolated.
• Quarterly: Run a rollback or recovery exercise in a suitable environment, review access and network policies, validate backup and restore assumptions for stateful dependencies, and test whether dashboards still reflect the service's current architecture.
• After a cluster or platform change: Revalidate ingress behavior, storage, identity integration, autoscaling, admission policies, and observability. A managed Kubernetes upgrade or node-pool change can expose assumptions that were not visible in application testing.

Keep the checklist close to the deployment process. A pull-request template, release pipeline gate, or runbook can turn these checks into evidence rather than memory. If the team uses infrastructure automation, the related Terraform CI/CD workflow can help establish review and promotion patterns for platform changes.

How to interpret changes

Do not judge production readiness from a single metric. Interpret changes in context and compare them with the previous release, normal traffic pattern, and dependency behavior.

• Restart counts increase: Check application exits, out-of-memory events, liveness failures, node pressure, and changes to startup or shutdown behavior. Increasing restarts do not automatically mean the probe is wrong, but probe failures are an important line of investigation.
• Pods remain pending: Compare requests with available capacity, placement constraints, taints, affinity rules, and quota. A scheduling failure may reflect an intentional constraint or an unexpectedly large request.
• Readiness failures rise: Inspect dependency latency, connection pools, startup work, probe timeouts, and recent configuration changes. Removing the readiness check may hide the symptom while increasing user impact.
• CPU or memory usage changes: Compare usage with requests and limits, then examine traffic, payload size, concurrency, garbage collection, and code changes. Adjusting limits without understanding demand can move the failure elsewhere.
• Rollouts are slow or stall: Check whether new pods become ready, whether the update strategy can fit within available capacity, and whether a disruption budget or placement rule prevents progress.

When a release is unhealthy, stop the rollout before making several unrelated changes. Preserve the evidence, compare the live state with the intended manifest, and use the smallest safe recovery action. A rollback is useful only when the previous version remains compatible with configuration, data, and dependent services.

When to revisit

Revisit this Kubernetes production checklist on every release and use a monthly or quarterly review to catch gradual drift. Update it sooner when the application adds a dependency, changes its traffic pattern, adopts new secrets or identities, moves between clusters, or introduces stateful behavior.

Make rollback validation a recurring checkpoint, not a statement in a runbook. In a non-production environment, confirm that the team can identify the active version, stop a rollout, restore the previous version, and verify readiness, logs, metrics, and user-facing behavior. For stateful services, separately validate data compatibility and recovery procedures.

Finally, record exceptions. If a workload must run as root, needs elevated permissions, cannot use a standard probe, or requires unusual resource settings, document the reason, owner, and review date. At the next monthly or quarterly checkpoint, ask whether the exception is still necessary. This keeps production readiness aligned with the service as it changes instead of allowing temporary decisions to become permanent risk.