Kubernetes production-readiness checklist for Irish SaaS teams

Workload behaviour

Confirm startup, readiness and liveness probes represent application behaviour. Review graceful shutdown, termination time, pod disruption and dependency timeouts. A probe that only checks the process can keep an unusable instance in service.

• Resource requests and limits based on observed use
• Pod disruption budget where availability requires it
• Topology spread or anti-affinity for failure domains
• Timeout, retry and connection-pool behaviour
• Horizontal scaling signal and safe bounds

Deployment and rollback

The pipeline should identify the image by immutable digest, validate policy before deployment and record who promoted the release. Test the chosen rollout strategy with realistic traffic and dependency behaviour.

Rollback needs more than a previous manifest. Database, message and API compatibility can make an application rollback unsafe.

Security and access

Run workloads with the least privilege they require. Review service accounts, secret delivery, network policy, image provenance and admission controls. Separate developer convenience from production access.

• Non-root security context where the image supports it
• Scoped service accounts and cloud identity
• Secrets outside images and repository history
• Image scanning plus an exception process
• Audit records for privileged changes

Observability, recovery and ownership

Define the user-visible signals, supporting infrastructure metrics and alert routes. Run a restore or recovery exercise rather than relying on a successful backup job.

Record the workload owner, platform owner and escalation path. Schedule cluster and dependency upgrades before versions approach end of support.

Review the workload, not only the Kubernetes objects

Resource requests should reflect observed normal and peak behaviour, while limits need to account for runtime characteristics and the consequence of throttling or termination. Check whether horizontal or event-driven scaling uses a signal that arrives early enough to protect the service. Capacity planning must include the cluster room needed during upgrades, failures and rollouts.

Readiness, liveness and startup probes answer different questions. A readiness probe should protect users from traffic reaching an instance that cannot serve correctly. A liveness probe should not restart a slow but recoverable process and amplify an incident. Test probe behaviour when dependencies fail rather than accepting default endpoints.

Examine shutdown and disruption. The application needs enough time to stop accepting work, finish or transfer in-flight activity and release resources. Pod disruption budgets, topology spread and replica count should be considered with node maintenance and availability-zone failure, not reviewed as isolated fields.

• Observed CPU, memory, concurrency and dependency limits
• Startup, readiness, liveness and graceful shutdown behaviour
• Rollout strategy, surge capacity and rollback path
• Disruption, topology and node-maintenance tolerance
• State, queues and in-flight work during termination

Exercise failure and recovery before launch

Begin with controlled scenarios that match credible risk: a pod restart, unavailable dependency, lost node, bad configuration or failed deployment. Agree safeguards, expected signals and stop conditions. The purpose is to validate detection and recovery, not to create the most dramatic failure possible.

Observe the customer journey, application telemetry, Kubernetes events and dependency behaviour together. Confirm that the owning team receives an actionable alert and can find the relevant runbook. Record any manual access or specialist knowledge required to restore service.

Turn results into a release decision. Some findings block production because recovery is absent or data is at risk; others can be accepted with an owner and deadline. Keep the evidence with the readiness review so the decision can be revisited after the next change.

Frequently asked questions