Kubernetes Deployment Checklist: A Production-Ready Guide from Container to Rollback

Overview

Use this Kubernetes deployment checklist before a release, after a significant configuration change, and during scheduled platform reviews. It is designed for workloads managed through declarative manifests, Helm, Kustomize, or a similar delivery process. Adapt the details to your cluster, workload type, and operational requirements.

A reliable deployment should answer five questions:

• Can the cluster run it? The image, architecture, permissions, resources, and scheduling rules are compatible with the target environment.
• Can the application start safely? Configuration, dependencies, migrations, and startup behavior are understood.
• Can Kubernetes route traffic correctly? Services, selectors, ports, readiness, and ingress behavior agree with one another.
• Can operators tell whether it is healthy? Logs, metrics, traces, alerts, and deployment events provide enough evidence.
• Can the team recover? A tested rollback or forward-fix path exists, and the previous release remains identifiable.

Keep the checklist close to the repository or delivery workflow rather than treating it as a document used only during incidents. A pull request template, deployment pipeline gate, or runbook can turn these checks into repeatable cloud-native best practices. For pipeline design, see the GitHub Actions CI/CD pipeline templates.

What to track

1. Image and manifest integrity

• Use an immutable image reference where practical, such as a digest or a release-specific tag. Avoid relying on a mutable tag when you need to reproduce a deployment.
• Confirm that the image was built from the intended commit and passed the required tests and security checks.
• Verify the target registry, pull credentials, CPU architecture, and runtime assumptions.
• Review Deployment selectors, pod labels, container ports, Service selectors, and Ingress or Gateway routes together. A single label mismatch can make healthy pods unreachable.
• Check that namespace, context, and cluster selection are explicit in the delivery process.

Registry behavior is part of deployment reliability. If your team is comparing registry options, the container registry comparison provides a useful framework for reviewing authentication, integration, and storage considerations.

2. Configuration and secrets

• Separate environment-specific configuration from the container image.
• Confirm required ConfigMaps and Secrets exist in the target namespace and contain the expected keys.
• Do not place credentials, tokens, or private keys directly in application manifests or source control.
• Document which configuration changes require a pod restart and how that restart is triggered.
• Check external dependencies such as databases, queues, object storage, identity providers, and third-party APIs.

Kubernetes Secret objects can help manage delivery, but they are not a complete secrets-management process by themselves. Define access controls, rotation ownership, audit expectations, and recovery procedures. Compare the available approaches in Secrets Management Tools Compared.

3. Health probes and lifecycle behavior

Use probes to express different operational questions:

• Startup probe: Can this container finish initialization within the permitted window?
• Readiness probe: Should this pod receive traffic right now?
• Liveness probe: Is the process stuck or unhealthy enough to justify a restart?

Probe endpoints should be inexpensive and representative of the relevant state. A readiness check may verify that essential dependencies are available, while a liveness check often should not fail merely because a downstream service is temporarily unavailable. Set initial delays, timeouts, periods, and failure thresholds based on observed startup and recovery behavior rather than copying defaults.

Also verify graceful shutdown. The application should stop accepting new work, finish or cancel in-flight work according to its contract, and exit within the pod termination window. Test this behavior during a controlled deployment rather than discovering it when nodes are drained.

4. Resources, scheduling, and scaling

• Set CPU and memory requests so the scheduler can place pods predictably.
• Set limits deliberately and understand how the runtime behaves when a limit is reached.
• Review recent usage rather than treating resource values as permanent. Track throttling, memory pressure, evictions, and restart patterns.
• Confirm that replicas, topology rules, affinity, taints, and tolerations match the availability requirement.
• If using a Horizontal Pod Autoscaler, verify its metrics, minimum and maximum replicas, scale-up behavior, and scale-down stabilization.

Autoscaling cannot compensate for an application that has no useful saturation signal. Choose metrics that relate to work, such as request rate, latency, queue depth, or resource use, and check whether scaling actually improves the user-facing result.

5. Security and observability

Review security context settings before production deployment. Where compatible with the application, run as a non-root user, use a read-only root filesystem, drop unnecessary Linux capabilities, and avoid privileged containers. Restrict service account permissions to the minimum required and review network access through the controls available in your environment.

At minimum, capture structured application logs, deployment events, request or job metrics, and enough context to connect an alert to a release. Track error rate, latency, saturation, restart counts, readiness failures, and replica availability. The cloud observability tools comparison can help structure a tool review, while OpenTelemetry Collector configuration patterns covers common telemetry pipeline considerations.

Cadence and checkpoints

Not every check belongs at the same point in the deployment lifecycle. Use a layered cadence so routine releases stay fast while deeper reliability questions are still reviewed.

Every pull request or release candidate

• Validate manifests and render environment-specific output.
• Build and scan the image, then confirm its provenance within your delivery process.
• Run unit, integration, and relevant contract tests.
• Check resource changes, probe changes, permissions, routes, and configuration differences.
• Confirm the rollback target and migration plan.

During each deployment

• Watch the rollout rather than assuming that an applied manifest equals a healthy release.
• Confirm new pods become Ready and old pods are removed according to the intended strategy.
• Check application errors, latency, saturation, logs, and dependency health during the observation window.
• Record the deployed image digest, configuration version, and operator or pipeline run.

Monthly or quarterly

• Review requests and limits against actual usage, cost allocation, and capacity pressure.
• Test rollback, restore, and access procedures in a safe environment.
• Reassess service accounts, network policies, exposed endpoints, and unused secrets.
• Review alerts for noise, missing coverage, and unclear ownership.
• Update the supported Kubernetes, ingress, storage, and observability components according to your organization’s maintenance process.

For stateful workloads, add backup and restore verification to the recurring review. A backup that has not been restored in a representative environment should not be treated as a fully verified recovery path. See the Kubernetes backup tools comparison for areas to evaluate.

How to interpret changes

Deployment signals are most useful when compared with a known-good baseline. A rise in restart count immediately after a release points toward application startup, memory, configuration, or dependency issues. Readiness failures with normal process health may indicate a route, port, dependency, or probe-design problem. Pods stuck in Pending often require a review of requests, node capacity, taints, affinity rules, or scheduling constraints.

Separate symptoms from causes. Increased latency may result from application code, database contention, network behavior, insufficient CPU, or a failing downstream service. Compare deployment events with application telemetry and cluster events before choosing a rollback.

Use rollout status and revision history to establish what changed. If the new version is clearly responsible and the previous version is known to be safe, rollback may reduce impact. If a database migration or irreversible data change is involved, a simple image rollback may not be safe; use the documented forward-fix or compatibility plan instead.

A successful rollout is not proof of a successful release. Continue checking user-facing behavior after all replicas report Ready. For a step-by-step diagnostic process when the signals disagree, use the Kubernetes deployment troubleshooting checklist.

When to revisit

Revisit this checklist before every production deployment that changes code, images, configuration, permissions, routes, probes, resources, dependencies, or data schemas. Schedule a deeper review monthly or quarterly, depending on release frequency and operational risk.

Trigger an unscheduled review after a failed rollout, unexpected restart pattern, security finding, cluster upgrade, major traffic change, incident, cost anomaly, or change in an external dependency. Also revisit the checklist when a service moves from internal use to internet-facing traffic, adopts autoscaling, becomes stateful, or gains a new availability requirement.

A practical next step

1. Copy the checklist into your repository as a pull request or release template.
2. Mark each item as automated, manually verified, or not applicable, and record the reason for exceptions.
3. Automate manifest validation, image checks, policy checks, rollout status, and basic smoke tests in the CI/CD pipeline.
4. Define one owner for deployment verification and one clear rollback decision point.
5. Set a recurring calendar review and update the checklist after every incident or meaningful platform change.

The goal is not to add ceremony to every deployment. It is to make the important assumptions visible, testable, and easy to revisit as the application and Kubernetes environment change.