Kubernetes Deployment Checklist: From Container Image to Production Service

Overview

Deploying an application to Kubernetes involves several connected decisions. The container must be available to the cluster, the workload needs an explicit identity and configuration, and the platform must know when the application is ready, healthy, and safe to replace. Network access, resource consumption, permissions, and rollback procedures also need to be defined before production traffic arrives.

This Kubernetes deployment checklist is designed for application teams and platform engineers. It works for a first deployment, a migration from another environment, or a review of an existing workload. Adapt the details to your cluster, runtime, compliance requirements, and delivery process rather than treating every item as a mandatory template.

Keep Kubernetes manifests in version control and make the intended state reviewable. Whether your team uses a traditional CI/CD pipeline or a GitOps workflow, the same principle applies: changes should be traceable, testable, and reversible.

Checklist by scenario

Before creating the workload

• Validate the image. Confirm that the image is built from the intended source revision, can be pulled by the cluster, and does not depend on undocumented local files or environment variables.
• Choose a namespace. Decide where the workload belongs and apply the namespace consistently across development, staging, and production. Avoid deploying production resources into a personal or shared testing namespace.
• Define ownership. Add labels and annotations that identify the application, team, environment, release, and operational owner. Consistent metadata makes filtering, cost review, and incident investigation easier.
• Review the deployment strategy. For a stateless application, a rolling update may be appropriate. Stateful systems, jobs, and applications with incompatible schema changes may need a different sequence and a documented migration plan.

When writing manifests

• Set replica expectations. Define the number of replicas deliberately instead of relying on an accidental default. Consider availability, startup time, and whether the application can safely run more than one instance.
• Separate configuration from the image. Put environment-specific values in ConfigMaps or another approved configuration system. Do not rebuild an image merely to change a URL, feature flag, or operational setting.
• Handle secrets carefully. Store credentials, tokens, certificates, and connection details through the platform’s approved secret-management process. Limit access to the smallest set of workloads and operators that need it.
• Set resource requests and limits. Requests help the scheduler place pods; limits provide a boundary for consumption. Base the initial values on observed behavior or a conservative test plan, then review them after real workloads run.
• Define health checks. Use a startup probe when initialization can take time, a readiness probe to control traffic eligibility, and a liveness probe only when a failed check should cause a restart. Each endpoint should represent a meaningful condition, not merely return success unconditionally.

When exposing the application

• Create a Service intentionally. Verify the selector matches the pod labels and that the target port matches the process listening inside the container. A running pod is not useful to clients if the Service selects nothing or points to the wrong port.
• Choose the traffic boundary. Decide whether the application needs internal cluster access, external access, or an ingress route. Document hostnames, paths, TLS handling, timeouts, and any required authentication layer.
• Test the path end to end. Check access from inside the cluster first, then test the intended external route. Confirm DNS, certificates, routing rules, response codes, and application-level dependencies.
• Consider autoscaling. If demand varies, define an autoscaling approach and confirm that the selected metrics reflect useful load. Autoscaling cannot compensate for slow dependencies, unsuitable resource settings, or an application that cannot run concurrently.

Before production traffic

• Apply security settings. Run the container as a non-root user where possible, set an appropriate security context, avoid unnecessary Linux capabilities, and use a read-only filesystem when the application supports it.
• Review permissions. Give the workload only the Kubernetes API access it needs. If it does not need to call the API, do not grant it access by habit.
• Confirm network controls. Review namespace isolation, network policies, egress requirements, and access to databases or third-party services. Test both allowed and intentionally denied paths.
• Prepare observability. Confirm that logs identify the workload and release, metrics cover useful service behavior, and traces or request identifiers are available where needed. Define the signals that will indicate a bad rollout.
• Write the rollback path. Record how to inspect rollout history, stop or reverse a change, restore configuration, and handle a database migration that cannot be reversed safely.

During and immediately after rollout

• Check that the new ReplicaSet or workload revision is created and that pods reach readiness.
• Inspect events, pod status, container logs, and probe failures rather than relying on a single successful command.
• Verify that the Service endpoints contain the expected ready pods.
• Run smoke tests against the internal and external routes, including authentication and a representative application operation.
• Watch error rate, latency, saturation, restart counts, and dependency health during the rollout window.
• Record the deployed image digest, configuration revision, and verification result in the release or deployment record.

For broader release controls, compare this process with the CI/CD deployment checklist and the post-deployment verification checklist.

What to double-check

Selectors and labels: A mismatch between a Deployment, Service, or policy selector can produce a workload that appears healthy but receives no traffic or protection. Compare selectors character by character and inspect the resulting objects in the cluster.

Probe behavior: A readiness probe should fail when the process cannot safely serve requests. It should not necessarily fail because an optional dependency is unavailable. A liveness probe should identify an unrecoverable process condition, not turn a temporary downstream failure into a restart loop.

Configuration precedence: Check which values come from the image, manifest, ConfigMap, Secret, mounted file, or command-line argument. Ambiguous precedence can make an apparently correct configuration ineffective.

Resource assumptions: Compare requests and limits with actual startup and steady-state behavior. A request that is too low can create contention; a limit that is too low can cause avoidable termination. Also verify that the cluster has enough allocatable capacity for the requested replicas.

Rollout safety: Confirm the maximum unavailable and maximum surge behavior for the workload. Consider what happens if the new version starts successfully but returns incorrect responses. Health checks alone may not detect a functional regression, so include application-level smoke tests and a clear abort threshold.

Data changes: Coordinate application releases with schema migrations, backfills, and compatibility windows. The database migration deployment guide can help structure this part of the release.

Common mistakes

• Using a floating image tag without a traceable release identifier. A deployment should make it possible to determine exactly what code is running.
• Putting credentials in images or plain manifest files. Treat secrets as operational data and apply access controls throughout their lifecycle.
• Skipping resource settings. An application may appear fine in a quiet test cluster but behave unpredictably when nodes are busy.
• Using a liveness probe as a dependency monitor. Restarting a healthy process because a database is briefly unavailable can increase the incident’s impact.
• Assuming a successful rollout means a successful release. Kubernetes can report ready pods while the application has broken routes, incorrect permissions, or unusable business behavior.
• Making manual production edits. Emergency changes may be necessary, but reconcile them back into version control so the declared state remains accurate.
• Ignoring the rollback of configuration and data. Reverting an image does not automatically revert a ConfigMap, Secret, feature flag, or database schema.

If a deployment fails, separate immediate stabilization from later diagnosis. Use a documented runbook and record what changed, what was observed, and which version was restored. The incident response checklist for failed deployments provides a useful companion process.

When to revisit

Review this Kubernetes deployment checklist before each production release that changes the image, configuration, permissions, networking, resource profile, or data contract. Revisit it after a failed rollout, a significant incident, a cluster upgrade, a change to ingress or secret management, or the introduction of autoscaling.

It is also worth scheduling a broader review before seasonal planning cycles or periods of expected demand change. Compare actual CPU and memory use with requests and limits, inspect restart and probe trends, test the rollback procedure, and remove obsolete configuration. Platform teams should update the shared deployment template when recurring review findings reveal a missing default or unsafe assumption.

To use this checklist in practice, copy it into the team’s deployment runbook, mark which items are automated in the CI/CD pipeline, and identify the owner for each remaining manual check. After every release, capture the image identifier, manifest revision, verification evidence, and any follow-up action. That small record turns a one-time Kubernetes deployment into a repeatable operating process.