Skip to main content

Archived runbooks

Older techniques and runbooks that I no longer use move here. They remain available for reference, research, or migration work, but they are not maintained.

warning

Read with caution. Archived content may be insecure, incompatible with current Kubernetes versions, or rely on deprecated APIs, images, or defaults. Use only in a lab and never copy-paste into production without a full review.

What belongs in the archive​

I move items to the archive when one or more of the following is true.

  • A better, simpler, or safer approach replaced it.
  • Upstream projects deprecated or removed required features.
  • Operational risk is too high compared with current alternatives.
  • The technique depends on tooling I no longer carry in the Sphere.

Lifecycle and policy​

I use four states to keep things tidy.

  • Active. In use, tested, and maintained.
  • Deprecated. Still works but has a clear replacement and a sunset plan.
  • Archived. Retired from use, retained for reference only. No updates.
  • Removed. Fully deleted when keeping it adds more confusion than value.

How to use archived runbooks safely​

If you must try an archived approach, do this first.

  • Confine it. Use a disposable lab cluster or VMs, not production.
  • Pin versions. Stick to the “Last known working versions” listed in the runbook.
  • Scan images. Pull to a private registry and scan before use.
  • Review manifests. Check API versions, security context, and network exposure.
  • Plan an exit. Identify the modern replacement and a migration path.

Standard sections for each archived runbook​

To make these easy to evaluate, each archived runbook follows the same structure.

  • Status. Archived with date and reason.
  • Superseded by. Link to the current method or explain why none exists.
  • Last known working versions. Kubernetes, CNI, CSI, OS, and key tools.
  • Why it was archived. Risks, operational pain, or upstream deprecations.