Kubernetes go-live checklist: 25 checks as a self-test

Have the cluster reviewed externally before go-live? The cluster audit checks configuration, versions, access, network policies and backups of your cluster and delivers a report with prioritized measures. From €1,490 net one-time, credited against the first month of operations, no penetration test (as of October 2026). View the cluster audit

A cluster that accepts deployments is not yet production ready. This checklist is a self-test with 25 checks in six areas. Each item has a pass criterion that can be measured or demonstrated, and a rating: green, yellow or red. All red items are closed before go-live. As of October 2026. It is not a penetration test.

Contents

• How the scoring works
• The 25 checks
  • A Availability
  • B Resources and scaling
  • C Operations, monitoring and alerting
  • D Backup and restore
  • E Security
  • F Processes and handover
• Order of the checks
• Check commands
• Which Kubernetes version for go-live
• When the self-test is not enough
• Our approach at WZ-IT
• Status and methodology
• Further guides

How the scoring works

Each item gets a color:

• Green: The criterion is met and documented with evidence (command output, log or report with a date).
• Yellow: The criterion is partly met, for example in one namespace instead of all, or met but not documented.
• Red: The criterion is not met or unknown. Unknown counts as not met.

A second person confirms the colors. Whoever decided the architecture reviews it with the same assumptions. The check is repeated before every minor upgrade and after major changes to access, network or storage.

The 25 checks

A Availability

B Resources and scaling

C Operations, monitoring and alerting

D Backup and restore

E Security

The criteria for E1 to E5 appear with commands and standard references in the hardening checklist.

F Processes and handover

Order of the checks

Start with the items that need a test with lead time: A1, A2, B4, D3, D4 and F2 (failure tests, load test, restore, rebuild, upgrade in staging). They decide whether the date holds. Next come the items that can be checked by command or configuration comparison: A3, A4, B1 to B3, C1, C4, D1, D2 and E1 to E5. Last come C2, C3, F1, F3 and F4. Alerts, runbooks and staffing build on the results of the first group.

Check commands

# A1: API server reachable while a control plane node is off
kubectl get --raw='/readyz?verbose'
# A2: simulate a node failure (maintenance window or staging)
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
kubectl get pods -A --field-selector=status.phase=Pending
kubectl uncordon <node>
# A3: deployments with one replica, PodDisruptionBudgets
kubectl get deploy -A -o json | jq -r '.items[] | select(.spec.replicas==1) | .metadata.namespace + "/" + .metadata.name'
kubectl get pdb -A
# A4: containers without a readinessProbe
kubectl get pods -A -o json | jq -r '.items[] | .metadata.namespace as $ns | .metadata.name as $p | .spec.containers[] | select(.readinessProbe == null) | "\($ns)/\($p)/\(.name)"'
# B1: containers without requests or memory limit
kubectl get pods -A -o json | jq -r '.items[] | .metadata.namespace as $ns | .metadata.name as $p | .spec.containers[] | select(.resources.limits.memory == null or .resources.requests.memory == null or .resources.requests.cpu == null) | "\($ns)/\($p)/\(.name)"'
# B2, B3: quotas, autoscalers, headroom (section "Allocated resources")
kubectl get resourcequota,limitrange,hpa -A
kubectl describe nodes
# B4: pods with OOMKilled
kubectl get pods -A -o json | jq -r '.items[] | select(.status.containerStatuses[]?.lastState.terminated.reason == "OOMKilled") | .metadata.namespace + "/" + .metadata.name'
# C1: compare the number of nodes with monitoring
kubectl get nodes --no-headers | wc -l
# C4 (kubeadm only, on a control plane node), E5: certificates and version
kubeadm certs check-expiration
kubectl version

Which Kubernetes version for go-live

The end of support is listed on kubernetes.io/releases. For a go-live on 28.10.2026 this gives:

When the self-test is not enough

The self-test checks what your own team can measure. It does not check whether the criteria fit the application, and it does not produce an independent report. For customer questionnaires, evidence for auditors or a second opinion before go-live, an external configuration review is the right tool. It compares the cluster with the CIS Kubernetes Benchmark and APP.4.4 and is not a penetration test.

Our approach at WZ-IT

The cluster audit checks versions and upgrade path, RBAC and service accounts, secrets, network policies, and backup and restore path, and compares the cluster with CIS and APP.4.4. The result is a report with findings by priority. We make no changes to the cluster during the audit. The cluster audit costs from €1,490 net one-time and is credited against the first month of operations.

Managed Kubernetes from €590 net per cluster per month including three worker nodes takes over operations after go-live, with monitoring, upgrades, backups with restore test and hardening. Monitoring runs 24/7, the response to P1 incidents follows the service level. The levels are on the SLA page. Open items on upgrades, certificates or etcd we also handle without a contract through Kubernetes support, €120 net per hour, without a guaranteed response time. Prices net, as of October 2026.

Status and methodology

• Status: 28.10.2026. The end-of-support dates come from kubernetes.io/releases, retrieved on 28.10.2026. The months until end of support are counted from that date.
• Sources of the criteria: Kubernetes documentation (production environment, probes, PodDisruptionBudget, resource management, Security Checklist) and the BSI modules APP.4.4 and SYS.1.6, 2023 edition. The modules name requirements such as backup of the cluster (APP.4.4 A5), health checks (A11) and resource limits (SYS.1.6.A15), but no numeric values for these items.
• Planning values: 70 % request utilization, factor 1.5 for the load test, 30 days for certificates, 6 months until end of support and 90 days for the restore evidence are our assumptions. Adjust them to criticality. The rhythm of at most 90 days follows the quarterly restore test from Kubernetes backup.
• Selection: The 25 items are our own selection. They cover the areas where clusters typically have gaps at go-live and in takeovers, see the takeover checklist.
• Scope: Self-test and configuration review. Not a penetration test.

Further guides

• Kubernetes hardening checklist - area E in depth, with CIS, BSI and NIS2
• Kubernetes backup: the four layers - area D in detail
• Taking over a Kubernetes cluster: audit checklist - the operations view for inherited clusters
• Longhorn vs. Rook-Ceph - which storage system carries the volumes

Secure the go-live with an external review? The cluster audit delivers the report, managed Kubernetes takes over operations afterwards. Cluster audit · Managed Kubernetes

Further reading: Kubernetes operations concept per APP.4.4