Upgrades, backups and recovery plans · Kubernetes Handbook

The mechanism

Cluster upgrades involve component compatibility, deprecated APIs, workload behavior and provider procedures. The official version-skew policy defines supported relationships; do not infer that every component can be upgraded independently to the latest version.

An etcd backup preserves important cluster state, but application data may live in external databases or persistent volumes. A complete recovery plan must identify those stores and their consistency requirements. A successful snapshot command is not a completed restore test.

This chapter is planning-only. It performs no cluster upgrade, snapshot, drain, restore or deletion. Managed services may own parts of the control plane and expose different procedures, so use the provider’s current supported process for a real environment.

Inventory + compatibility

Backup scope

Staged upgrade

Verified recovery

Worked example

This recovery worksheet distinguishes infrastructure and application evidence. Fill it with approved operational information in a private environment; keep the public handbook synthetic.

Cluster version and distribution: unknown
Component skew reviewed: not run
Deprecated API inventory: not run
etcd/control-plane recovery owner: to be assigned
Application database backup: unverified
Volume backup and consistency: unverified
Restore environment and acceptance test: proposed
Recovery time / data loss objectives: to be agreed

Practice: predict, inspect, explain

Offline exercise. Trace recovery after losing a cluster while the external database remains intact, then after losing both. Identify which configuration, credentials and data backups are needed for each scenario. Define an application transaction that must succeed after restoration.

Expected observation: control-plane restoration and business recovery are different milestones. A credible plan names the owner, artifact, procedure and acceptance evidence for every data store. Leave recovery-time claims blank until a timed, approved restore exercise exists.

Troubleshooting and trade-offs

If an upgrade plan skips versions or ignores managed-provider constraints, revise it before execution. If backups cannot be located or decrypted by the recovery process, their existence alone is insufficient. Protect backup credentials and sensitive snapshots. Do not run destructive restoration commands against an existing cluster as a learning exercise.

Interview practice

Why is an etcd snapshot insufficient for many applications?

Application data may live outside etcd, and recovery also needs compatible infrastructure, credentials and application validation.

What evidence supports a recovery-time claim?

A timed restore exercise in a defined environment with verified application acceptance, documented scope and retained results.

Completion check

Write a recovery dependency map and distinguish proposed objectives from measured restoration results.

Sources and version notes

Baseline checked 6 October 2026: the official release page lists Kubernetes 1.37.1. Verify your cluster and distribution prerequisites. All manifests are offline teaching examples; no cluster mutations or cloud resources are executed by this handbook.

YOUR NEXT STEP

Make the understanding yours.

Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.

Self-assessed reading progress. This does not certify that a lab ran or a system is secure.