Chapter 20: Platform Lifecycle
Learning Objectives
By the end of this chapter, you will be able to:
- Say which parts of the platform may change by themselves and which only through a reviewed pull request - and why this platform lets nothing on its nodes move by itself
- Find what is out of date, and update it on your own schedule: once a month, release notes read, the patches together and every larger step in a pull request of its own
- Check that the tests verify against the versions Git pins for the cluster - and read what it really runs - and why a passing test against another version proves nothing
- Run a drain dry run, read which PodDisruptionBudgets would block it, and say what one worker, with every database instance on it, costs during maintenance
- Find the APIs the next Kubernetes version removes - in Git and in what the cluster is asked for - before the upgrade
- Explain why a stopping pod drops requests, and how a
preStopwait reduces the drops
Recall Check
Before continuing, quickly recall:
- What does a PodDisruptionBudget limit, and what does it not? (Chapter 09)
- How does Flux apply a HelmRelease, and what happens when an upgrade fails? (Chapter 03)
- Which engine verifies image signatures at admission, and how do its tests run? (Chapter 17)
If you can’t answer these, revisit the corresponding chapter before proceeding.
Context
A platform that is never updated decays quietly: security fixes do not arrive, the gap to the current versions grows, and the day an update can no longer wait, it is many releases at once - every change between them at the same time. A platform that updates itself whenever something new appears has the opposite problem: a node reboots on a Saturday night, a chart moves to a version nobody read, and nobody chose when.
This chapter takes the middle: nothing changes by itself, and everything is updated on a schedule we keep. A dashboard says what is out of date; updates go through one reviewed pull request, after the release notes; the tests run the versions the charts in Git install, and what runs is read from the cluster after every upgrade; nodes are maintained one at a time, at a time chosen and announced.
This chapter shows one widely used way to do it, not every way: pinned versions, Renovate in dashboard-only mode, and node maintenance by script. Others work too:
- automatic updates with a strong safety net - Renovate or Dependabot opening a pull request per update, merged automatically when the tests pass; it needs tests good enough to trust;
- managed control planes (GKE, EKS) - the provider upgrades Kubernetes in maintenance windows you set;
- immutable nodes - a new node from a new image replaces the old one instead of being updated in place.
The story is this platform’s own: an upgrade of its admission policy engine, put off since the first commit.
Work through each lesson section; the chapter video, once it is published, gives the concept overview.
An Update, From Notice to Running
