KubernetesCXXX · Production Anti-PatternsProduction anti-patterns
Operational anti-patterns — the cluster's runbook
What you'll learn
- Identify the operational anti-patterns
- Diagnose the impact of each anti-pattern
- Distinguish the high-impact from the low-impact anti-patterns
- Apply the discipline of operational anti-pattern fix
Prerequisites
Verified against Kubernetes 1.34.x · kubeadm 1.34.x · kubectl 1.34.x · etcd 3.6.x · CoreDNS 1.11.x · containerd 1.7.x / 2.x · 2026-08-16
The operational anti-patterns are the cluster’s runbook. The diagnostic is the anti-patterns, the impact, and the systematic approach to fixing them. The discipline is the same scale-free: every anti-pattern gets a fix.
The operational anti-patterns
The operational anti-patterns are:
- No backup. The workload has no backup; the data is not recoverable.
- No etcd test. The etcd snapshot is not tested; the restoration is not rehearsed.
- Manual edits. The cluster is managed by manual edits; the cluster’s state is not reproducible.
- No monitoring. The cluster has no monitoring; the failures are not detected.
flowchart TD
A[Operational anti-patterns] --> B[No backup]
A --> C[No etcd test]
A --> D[Manual edits]
A --> E[No monitoring]
The operational anti-patterns are the cluster’s runbook.
The diagnostic
The canonical diagnostic:
# Substitute your own values before running:
NS=velero
BACKUP_JOB=etcd-snapshot
# Use Polaris to detect anti-patterns
polaris audit --format yaml
# Check the backup
kubectl get cronjob -n "$NS" --field-selector metadata.name="$BACKUP_JOB"
# Check the etcd snapshot
ls -la /var/backups/etcd/
# Check the manual edits
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.annotations}{"\n"}{end}'
# Check the monitoring
kubectl get pods -n monitoring
The diagnostic is the Polaris audit, the backup, the etcd snapshot, the manual edits, and the monitoring.
The remediation
The remediation depends on the anti-pattern:
# Option 1: Set up the backup
kubectl apply -f backup-cronjob.yaml
# Option 2: Test the etcd snapshot
etcdutl snapshot restore /var/backups/etcd/snapshot.db --data-dir /var/lib/etcd-lab
# Option 3: Use GitOps
# (e.g., ArgoCD, Flux)
# Option 4: Set up the monitoring
kubectl apply -f monitoring-stack.yaml
The remediation is the anti-pattern fix.
Production discipline
The operational anti-patterns are the cluster’s hypothesis. The discipline is to walk the 11-step methodology applied to the anti-patterns, identify the cause, apply the remediation. The cluster’s discipline is the same scale-free: every anti-pattern gets a fix.
- Detect the anti-patterns with
polaris audit. The audit names the ones the cluster actually has, and the backup CronJob, the snapshot directory, and the monitoring namespace answer for the rest. - Run the detection in CI. A detection that runs only after an incident is a report, not a prevention.
Quiz
Knowledge check · 4 questions
Q1. What is the most dangerous operational anti-pattern?
Q2. Restoring the cluster from an etcd snapshot rolls the API objects back but leaves the contents of every PersistentVolume exactly as they are now.
Q3. A production namespace was deleted by mistake and the backups turn out to be unusable. Recover what you can and close the operational gaps.
kubectl delete namespace prod was run against the wrong context at 14:20, removing 31 Deployments and 6 PVCs. The most recent Velero backup is 9 days old and its phase is PartiallyFailed. The etcd snapshot CronJob has run nightly for a year, writing to /var/backups/etcd on control-plane-01, and has never been restored anywhere.
Q4. Name three operational anti-patterns and the remediation for each.
Passing score: 75%. Answers are checked in this browser.