Chapter 84 -- Staying current

In one sentence

Operating systems, Linux, and Kubernetes are all actively developed, moving targets -- the specific commands and defaults in this guide are accurate as of when it was written, and staying useful over the following years means knowing which sources to check periodically, not re-reading this guide.

Why this matters

A guide like this one is a snapshot. Kubernetes and the Linux kernel both ship regularly, and they periodically deprecate APIs, graduate features, or change defaults (the cgroups v1-to-v2 transition is a good example of a change that affected how memory and CPU limits were enforced in practice). An engineer who treats what they learned once as permanently true will, within a couple of years, be confidently wrong about specific details even while being right about the underlying concepts -- and the underlying concepts (processes, memory, namespaces, the control plane/node split) are exactly what stays stable across those version changes, which is why this guide focused on them.

How it actually works

A short, durable list of places to check periodically, organized by how often they change:

   RARELY CHANGES (concepts -- revisit if you feel rusty, not on a
   schedule):
     - The core OS concepts in Parts 1-6 of this guide. Processes,
       memory, syscalls, and the boot sequence have been stable in
       their fundamentals for decades and will likely remain so.

   CHANGES OVER YEARS (check every year or two):
     - Linux kernel release notes (kernelnewbies.org/LinuxChanges) --
       skimming major version summaries tells you what's newly
       possible or newly deprecated.
     - Your distribution's release notes (Ubuntu LTS, Debian stable,
       RHEL) if you operate a specific distribution professionally.

   CHANGES OVER MONTHS (check a few times a year, or when planning
   an upgrade):
     - Kubernetes release notes and the deprecated API migration
       guide (kubernetes.io/docs/reference/using-api/deprecation-guide)
       -- checking this before cluster upgrades is a professional habit;
       skipping it is a common way to break production.
     - Docker Engine release notes, if you build images as part of
       your job.
     - The CNCF's annual "Cloud Native Landscape" survey, for a sense
       of which tools in the ecosystem are gaining or losing adoption.

   CONTINUOUS (follow loosely, don't obsess):
     - Your own company's or a major cloud provider's incident
       postmortems and engineering blog -- reading how other
       real teams break things and fix them is, chapter for chapter,
       some of the most useful continuing education available, and
       it's exactly the kind of material this guide's "Real-world
       example" sections were built from.
     - CVE feeds relevant to your stack (e.g. a mailing list or RSS
       feed for the specific Linux distribution, container runtime,
       and Kubernetes distribution you actually run).

Real-world example

The cgroups v1-to-v2 migration, referenced throughout Part 6 and Part 14 of this guide, is a concrete illustration of exactly the kind of change that rewards staying current: for years, docker stats and Kubernetes resource enforcement relied on cgroups v1's separate hierarchies per resource type; cgroups v2's unified hierarchy (merged into the mainline kernel starting around 4.5, but not the default in major distributions and container runtimes until years later, roughly 2021-2022 for most mainstream Linux distributions and container tooling) changed some memory-accounting edge cases enough that teams upgrading their base OS image sometimes saw containers get OOM-killed at different thresholds than before, purely because of the underlying cgroup version switching under them. Nothing about the concept of cgroups (Chapter 44) changed; the concrete mechanics teams needed to re-verify after an OS upgrade did. This is the recurring pattern behind essentially every "why did upgrading the base image change our container's behavior" incident: the concepts this guide taught you remain the right mental model; the specific mechanics are worth re-checking against current documentation whenever you cross a major version boundary.

Try it yourself

Subscribe to, or bookmark for periodic checking, one source from each of the "changes over months" and "continuous" categories above that's relevant to your actual stack. If you don't currently run Kubernetes professionally, substitute the release notes of whatever you do run (a specific Linux distribution, a specific database, a specific cloud provider's compute service) -- the habit matters more than the specific source.

Common mistakes

Treating a guide, book, or course as a one-time investment rather than a foundation to be periodically checked against current sources -- especially dangerous for fast-moving layers like Kubernetes.
The opposite mistake: chasing every new tool and blog post without a stable foundation underneath, which produces someone who knows many buzzwords and few fundamentals. The concepts in Parts 1-19 of this guide are the antidote to this; keep them solid and let the fast-moving specifics rotate on top of them.
Skipping a Kubernetes deprecated-API check before a version upgrade, then discovering in production that a manifest using a removed apiVersion no longer applies.
Ignoring your own organization's postmortems as a learning source because they feel like "just work," when they are, chapter for chapter, as valuable as any external resource on this list.

Check yourself

Why does this guide claim the core OS concepts (Parts 1-6) will stay useful longer than the specific Kubernetes commands in Part 17?
Name one category of source from the list above you would check before performing a Kubernetes version upgrade, and explain what bad outcome checking it helps you avoid.
What changed, mechanically, in the cgroups v1-to-v2 transition, and why did teams who upgraded their base OS image sometimes see different OOM-killing behavior as a result?