6.3 Running Kubernetes without running the control plane

What this is and why it exists

Running Kubernetes and running the control plane are two different jobs, and a managed cluster hands you only the first. This lesson is the operational half: shipping a change, watching it land, putting it back when it does not, keeping configuration readable across environments, and surviving the fact that the cluster underneath you keeps moving whether you engage with it or not.

The vocabulary

• Control plane — the components that hold cluster state and make the decisions; managed, this is the provider's problem.
• Node — a machine that runs your Pods; even in a managed cluster, mostly yours.
• Rolling update — replacing Pods a few at a time so the application stays available throughout.
• Readiness probe — the check deciding whether a Pod should receive traffic.
• Liveness probe — the check deciding whether a container should be restarted.
• Rollback — returning to the previous version of a Deployment.
• Helm chart — "a collection of files that describe a related set of Kubernetes resources", with values you can override per environment.
• Deprecation — an API version being removed in a future release, on the project's schedule rather than yours.

The mental model

Start with the line a managed offering draws. Theirs: the API server, the scheduler, the controller manager, the cluster datastore, their availability and their backups. Yours: the nodes and their operating system images, everything you deploy, the resource requests that decide whether Pods fit, the network policies, the role bindings, the cost, and every upgrade decision. A managed control plane removes the hardest thing to run well and leaves the things that break most often.

Rollouts are declarative, like everything else here. You change the image in the Deployment and apply it; the controller creates a new ReplicaSet and shifts Pods across gradually, keeping the stated number available. The mechanism that makes this safe rather than merely gradual is the readiness probe — the documentation is exact that readiness probes "determine when a container is ready to accept traffic", and that when one fails "the EndpointSlice controller removes the Pod's IP address from the EndpointSlices of all Services that match the Pod". So a new Pod receives no traffic until it says it is ready, and a rollout stalls rather than proceeding if the new Pods never become ready. A Deployment without a readiness probe rolls out broken versions at full speed and calls it a success, because "the container started" is the only evidence it has.

Keep the two probes distinct, because confusing them causes outages. A liveness probe determines "when to restart a container" — the documentation gives deadlock as the example — and when it fails the kubelet restarts the container. A readiness probe only removes the Pod from service. So a liveness probe pointed at something slow, or at a dependency, converts a temporary problem into a restart loop across every Pod at once. Readiness is the one you almost always want; liveness is for a process that can genuinely wedge, and a startup probe is what to reach for when an application is slow to initialise, since Kubernetes "does not execute liveness or readiness probes until the startup probe succeeds".

Rollback is cheap because the previous ReplicaSet is still there at zero replicas. kubectl rollout "manages the rollout of one or many resources", with status to "show the status of the rollout", history to "view rollout history" and undo to "undo a previous rollout". Knowing undo before you need it is the difference between a two-minute incident and a twenty-minute one — and the habit worth forming is to watch status after every apply rather than assuming, because an apply that returns successfully has only told you the object was accepted.

Helm exists because writing the same manifests per environment goes wrong quickly. A chart is a directory: Chart.yaml "containing information about the chart", values.yaml holding "the default configuration values for this chart", and templates/ — "a directory of templates that, when combined with values, will generate valid Kubernetes manifest files". The shape is one set of templates, one file of values per environment, and nothing duplicated. The failure to avoid is templating everything into a chart so general that nobody can read the output; a chart is worth having when several environments genuinely share a structure, and copy-paste is honestly better below that.

Then the treadmill, which is the part nobody warns beginners about. Kubernetes releases several times a year, providers support a limited window of versions, and API versions are removed on the project's schedule. That means a cluster nobody upgrades becomes a cluster that cannot be upgraded, and manifests that worked last year can be rejected outright. The way to make this ordinary rather than alarming: know your version and its end-of-support date, upgrade a non-production cluster first and on a rhythm, read the deprecation notes for each release, and check your manifests against the API versions the next release keeps. It is a maintenance cost that comes with the system, and the teams that suffer are the ones who budgeted zero for it.

Portable operations

Checked against the Kubernetes reference, in the documented form kubectl [command] [TYPE] [NAME] [flags]:

kubectl apply -f deployment.yaml
kubectl rollout status deployment/nginx-deployment
kubectl rollout history deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment
kubectl describe pod nginx-deployment-abc123

The last one is where a stuck Pod explains itself: the events at the bottom say whether it cannot be scheduled, cannot pull its image, or is failing a probe — three very different problems that look identical from a list of Pods.

What you should now be able to explain or do

Draw the line between what a managed control plane covers and what remains yours. Explain what a readiness probe does during a rollout, and what a Deployment without one does instead. Say what a liveness probe pointed at a dependency causes. Roll a change out, watch its status, and undo it. Describe a Helm chart's three parts and say when a chart is not worth it. Name four things you would do to stay ahead of cluster deprecations.

Check yourself