Kubernetes Deployment Checklist: From Container Image to Production Operations

Overview

Use this checklist before deploying a new workload, moving an existing service into Kubernetes, or changing the way a production application is operated. It is designed for teams using manually applied manifests, package-based workflows, or GitOps-oriented deployment processes. Adapt the details to your cluster, workload, compliance requirements, and delivery model.

A Kubernetes production checklist should answer five practical questions:

• Is the container image known, reproducible, and ready to run?
• Will the workload receive the configuration and permissions it actually needs?
• Can Kubernetes schedule, expose, monitor, and restart it safely?
• Can the team detect a bad release and return to a known-good version?
• Has the deployment been validated from both the platform and user perspectives?

Keep a copy of this checklist in the repository or release documentation. The exact commands and resource names will vary, but the decision points remain useful across clusters and deployment tools.

Checklist by scenario

Before building or promoting the image

• ☐ Build the image from a reviewed source revision and record the commit or release identifier.
• ☐ Use a deliberate base image and remove build tools, caches, and unnecessary files from the runtime image where practical.
• ☐ Confirm the container starts with the expected command, arguments, working directory, and user.
• ☐ Test the image locally or in an isolated environment using the same environment variables and ports expected in the cluster.
• ☐ Scan the image and its dependencies according to the team’s security process.
• ☐ Prefer an immutable image reference, such as a digest, when the release process requires exact reproducibility.
• ☐ Confirm the image registry, pull credentials, retention rules, and access permissions are suitable for the target environment.

Before applying manifests or a release package

• ☐ Check that the namespace, labels, annotations, and ownership metadata are correct.
• ☐ Review the Deployment, StatefulSet, DaemonSet, Job, or CronJob choice against the workload’s behavior.
• ☐ Verify replica settings, update strategy, revision history, and disruption behavior.
• ☐ Confirm configuration is separated from the image and that environment-specific values are explicit.
• ☐ Check that referenced ConfigMaps, Secrets, service accounts, volumes, and image pull credentials exist or are created in the intended order.
• ☐ Render templates or packages before deployment and inspect the final output rather than reviewing only source templates.
• ☐ Validate manifests against the cluster’s supported API versions and admission rules.
• ☐ Run policy, configuration, and security checks in the delivery pipeline where available.

Before exposing the workload

• ☐ Confirm the container port, Service port, target port, and protocol agree.
• ☐ Choose the correct Service type and verify whether internal or external access is required.
• ☐ Review Ingress or gateway routing, TLS configuration, hostnames, path rules, and timeout assumptions.
• ☐ Confirm NetworkPolicy behavior, especially for ingress from clients and egress to databases, queues, APIs, or DNS.
• ☐ Check that the Service selector matches the intended Pods and does not accidentally include another workload.
• ☐ Test access through the same route clients will use, not only by connecting directly to a Pod.

Before calling the release production-ready

• ☐ Define CPU and memory requests so the scheduler can make an informed placement decision.
• ☐ Set limits deliberately, understanding how they may affect throttling, termination, or workload stability.
• ☐ Add a startup probe for applications that need time to initialize.
• ☐ Add a readiness probe that reflects whether the instance can serve traffic.
• ☐ Add a liveness probe only when a failed probe identifies a condition that restarting can reasonably correct.
• ☐ Verify graceful shutdown behavior, including termination handling, connection draining, and an appropriate termination window.
• ☐ Confirm logs, metrics, traces, and deployment events are visible to the responsible team.
• ☐ Document the rollback method and identify the last known-good release before starting the rollout.

For stateful workloads

• ☐ Confirm the storage class, access mode, capacity, performance expectations, and reclaim behavior.
• ☐ Test volume attachment, mounting, permissions, and recovery behavior in a non-production environment.
• ☐ Define backup, restore, retention, and recovery ownership separately from the application deployment.
• ☐ Treat schema changes, data migrations, and application rollbacks as separate decisions.
• ☐ Review disruption, rescheduling, scaling, and node maintenance scenarios before relying on the workload in production.

For database-heavy deployments, storage choices deserve their own review. The guide to Kubernetes storage classes for stateful databases can be used alongside this release checklist.

What to double-check

Configuration and secrets

Separate values that change between environments from the application image. Check for accidental defaults, missing variables, incorrect URLs, and mismatched feature flags. Do not place credentials, tokens, or private keys in images, plain repository files, rendered logs, or command-line arguments that may be retained by automation. Use an approved secrets management workflow and verify that the Pod receives only the permissions and values it needs.

Security context and access

Review the Pod and container security context, including the runtime user, filesystem write access, privilege settings, Linux capabilities, and service account. Ask whether the workload truly needs access to the Kubernetes API or host resources. Confirm that role bindings are scoped to the appropriate namespace and that image, registry, and network permissions match the service’s actual responsibilities.

Scheduling and resilience

Check whether requests fit the capacity of the target node pools and whether the workload needs affinity, anti-affinity, taints, tolerations, or topology constraints. For more than one replica, consider whether instances could be placed on the same failure domain. Review Pod disruption behavior and autoscaling assumptions together; a setting that looks reasonable in isolation may behave differently during maintenance or a traffic increase.

Observability and rollback

Before release, identify the signals that will tell you whether the deployment is healthy: request success rate, latency, saturation, restart count, queue depth, business-level checks, or another workload-specific measure. Make sure alerts identify an actionable owner. A rollout status of “complete” does not prove that users can complete their workflows.

Also verify that the rollback target still exists, its image is available, its configuration is compatible, and any database or message changes are reversible or forward-compatible. A rollback plan that has never been tested may not be a usable rollback plan.

Common mistakes

• Using a floating image tag: The same tag can refer to different content over time, making diagnosis and rollback harder. Use a release convention that identifies the exact artifact.
• Skipping resource requests: Without realistic requests, scheduling and capacity planning become less predictable.
• Using a liveness probe as a readiness probe: A temporary dependency failure can cause unnecessary restarts instead of simply removing a Pod from service.
• Checking only Pod status: A Running Pod may still have broken routing, invalid credentials, failed dependencies, or unusable application behavior.
• Applying changes directly without a rendered review: Template values can produce unexpected names, selectors, ports, or permissions.
• Assuming Secrets solve secret governance: Kubernetes storage and access controls should be considered alongside rotation, auditability, ownership, and external secret workflows.
• Rolling back the application but not the data change: Database migrations and application versions need a coordinated compatibility plan.
• Ignoring cleanup: Old Jobs, unused ConfigMaps, abandoned Services, stale image tags, and temporary access rules add operational confusion and cost.

When to revisit

Use the checklist for every production release, but schedule a deeper review when the surrounding assumptions change. Revisit it before seasonal planning cycles, a major traffic event, a cluster upgrade, a new region or node pool, a change in deployment tooling, or a migration from manually applied manifests to a GitOps workflow. It should also be reviewed after a significant incident, a security finding, a storage change, or a change to application ownership.

At the start of each review, compare the checklist with the actual platform behavior:

1. Choose one recent release and trace it from source commit to running Pods.
2. Confirm the image, rendered manifests, configuration, permissions, and approvals are all discoverable.
3. Test the health checks, alert path, client route, and rollback procedure in an appropriate environment.
4. Remove checks that no longer reflect the platform, and add items exposed by incidents or workflow changes.
5. Assign an owner and record the review date so the checklist remains part of operations rather than a one-time document.

A Kubernetes deployment checklist is most valuable when it changes with the system it protects. Keep the core gates stable, tailor the scenario-specific items to each workload, and require evidence for the decisions that matter most: what is running, what it can access, how it is observed, and how the team will recover when a release does not behave as expected.