Kubernetes Deployment Best Practices: A Production Readiness Checklist

Overview

Kubernetes deployment best practices are easiest to apply when they become a review process rather than a collection of one-time fixes. For every production workload, ask four questions:

1. Can the scheduler place it reliably? Resource requests, limits, affinity rules, and availability requirements should reflect how the application actually behaves.
2. Can Kubernetes tell whether it is healthy? Startup, readiness, and liveness probes must represent different states and failure modes.
3. Can the deployment change safely? The rollout strategy, replica count, disruption budget, and rollback procedure should work together.
4. Can the team operate it? Configuration, secrets, metrics, logs, alerts, ownership, and runbooks should be available before an incident.

A useful production readiness review records evidence for each answer. “The service has three replicas” is an input; “three replicas remain available while one is terminating and a new version is starting” is a tested outcome.

Use this guide alongside your application’s service-level objectives and operational requirements. A stateless HTTP API, a queue consumer, and a stateful database have different safe defaults. Kubernetes provides mechanisms, but your workload determines the correct values.

How to estimate

You can turn the checklist into a lightweight readiness estimate without pretending that a score replaces testing. Assign each category a status:

• Ready: The requirement is configured and verified in an environment that resembles production.
• Partial: The configuration exists, but its values or behavior have not been validated under realistic conditions.
• Blocked: A missing control could cause an outage, unsafe rollout, data exposure, or difficult recovery.

Review these eight categories:

1. Resources and scheduling
2. Startup, readiness, and liveness behavior
3. Rollout and rollback controls
4. Autoscaling and capacity
5. Configuration and secrets
6. Networking and traffic protection
7. Security and supply-chain controls
8. Observability and operational ownership

For a simple estimate, count the categories marked Ready and divide by eight. Treat any Blocked category as a release stop even if the percentage looks high. For example, seven Ready categories and one Blocked category should not be described as “87.5% production ready”; it is a deployment with a known critical gap.

This approach is intentionally repeatable. Run the review against the current manifest, record the evidence, fix the gaps, and run it again after load testing or a significant platform change. For progressive delivery, compare the estimated readiness of the deployment process as well as the application. Guidance on canary and blue-green choices is available in Kubernetes deployment strategies explained and the comparison of Argo Rollouts and Flagger.

Inputs and assumptions

Resources and scheduling

Set CPU and memory requests based on observed normal usage plus an explicit operating margin. Requests influence scheduling and capacity planning. Set limits deliberately: a memory limit can protect a node from an unbounded process, while an unsuitable CPU limit can constrain bursty work. Validate both with workload tests and runtime metrics rather than copying values between services.

Decide how many replicas are required for normal traffic and maintenance. If replicas must be distributed across failure domains, express that requirement with topology spread constraints or an appropriate affinity rule. Do not assume that a replica count alone guarantees availability.

Probes and lifecycle

A startup probe gives a slow-starting application time to initialize. A readiness probe controls whether the pod receives traffic. A liveness probe is for a process that is running but stuck and should be restarted. Keep liveness checks conservative; an endpoint that depends on a database or another service can create restart loops during a dependency outage.

Also review graceful termination. The application should stop accepting new work, finish or requeue in-flight work, and exit within the configured termination window. For HTTP services, confirm that the load balancer, service, and application agree on connection draining behavior.

Rollouts, disruption, and scaling

Choose a rolling, blue-green, canary, or progressive strategy according to risk and observability. Set deployment availability and surge behavior so the cluster can actually provide the temporary capacity required by the rollout. A PodDisruptionBudget can protect voluntary disruptions, but it is not a replacement for multiple replicas or a fix for application crashes.

If using a horizontal pod autoscaler, identify the metric, target, minimum, maximum, and scale-up or scale-down behavior. Confirm that the selected metric reflects user demand. CPU may be a useful proxy for one service and a poor signal for a queue consumer. Compare autoscaler decisions with request latency, error rate, queue depth, and saturation.

Configuration, networking, and security

Keep environment-specific settings outside the image and make configuration changes auditable. Store credentials in a secrets system appropriate to your environment; avoid placing secret values in manifests, images, or ordinary configuration maps. Define a network policy where your cluster and application model support it, and document which inbound and outbound connections are required.

Pin images to an auditable version or digest, scan and sign artifacts according to your supply-chain process, and run containers with the minimum permissions they need. Review the service account, Linux capabilities, filesystem write access, and namespace boundaries. These controls belong in the deployment review, not only in a separate security assessment.

Observability and ownership

Before production, identify the dashboards and alerts that show availability, latency, errors, saturation, rollout progress, and restart behavior. Include application logs with enough context to connect a failed request to a pod and release. If traces are useful for your architecture, define how context is propagated and where telemetry is collected; the OpenTelemetry setup guide covers those design choices.

Example baseline manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-api
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: orders-api
  template:
    metadata:
      labels:
        app: orders-api
    spec:
      serviceAccountName: orders-api
      containers:
        - name: api
          image: registry.example/orders-api:release-version
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 256Mi
            limits:
              memory: 512Mi
          startupProbe:
            httpGet:
              path: /startup
              port: http
            failureThreshold: 30
            periodSeconds: 2
          readinessProbe:
            httpGet:
              path: /ready
              port: http
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health
              port: http
            periodSeconds: 10
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true

This is a reviewable starting point, not a universal production template. The resource values, probe endpoints, image reference, and security settings must be tested against the actual service.

Worked examples

Example one: a stateless API

Assume an API normally runs three replicas and must remain available during a single pod replacement. The review should verify that requests are set for the normal workload, memory behavior is bounded, readiness is removed before termination, and the rolling update can create one additional pod without exhausting namespace or cluster capacity.

Next, exercise the rollback path. Deploy a deliberately incompatible test version, observe whether readiness prevents it from receiving traffic, and confirm that the deployment controller or delivery tool can return to the previous version. Record the commands, permissions, expected signals, and owner in the runbook.

Example two: a queue worker

A worker may not need an HTTP readiness endpoint, and CPU may not be the best autoscaling signal. Its checklist should focus on queue depth, message visibility timeouts, idempotency, graceful shutdown, and whether a terminating pod can finish or safely return work. A liveness check should detect a stuck consumer without restarting a process that is simply waiting for work.

Here, the estimate is Ready only when scaling has been tested against a representative backlog and the team can explain what happens when the broker is unavailable. A deployment with healthy pods but an unbounded queue is not operationally ready.

Example three: a service with expensive capacity

If a rollout temporarily adds pods, the extra capacity can affect both scheduling and cost. Review maxSurge, autoscaler limits, node capacity, and the time required for old pods to terminate. Pair this review with the Kubernetes cost optimization checklist. The goal is not to eliminate all spare capacity; it is to make temporary and idle capacity visible and intentional.

When to recalculate

Revisit this Kubernetes production checklist whenever an input changes, not only when a release is planned. Recalculate the readiness estimate after:

• A change in traffic shape, request size, latency target, or concurrency.
• A new application version, base image, runtime, dependency, or startup path.
• A change to CPU or memory requests, limits, autoscaling rules, or replica counts.
• A Kubernetes, node image, ingress, service mesh, policy, or admission-control upgrade.
• A production incident, failed rollout, unexpected eviction, or repeated restart.
• A change to secrets, service accounts, network policies, image provenance, or permissions.
• A move to a different cluster size, availability design, region, or cost model.

Make the review part of the deployment workflow where possible. A GitOps process can keep the desired configuration and review history together; compare that model with other delivery approaches in GitOps vs CI/CD. For each recalculation, retain the assumptions, test evidence, unresolved risks, and rollback owner.

The practical final check is simple: can the team explain how this workload starts, receives traffic, scales, fails, rolls back, and gets observed? If any answer depends on an untested assumption, mark that category Partial or Blocked and address it before production. Kubernetes manifests express intent; production readiness comes from validating that intent under the conditions your service must survive.