Kubernetes 1.0: Keep Asking for the Desired State

Launching three copies of a program is a task with an apparent finish. Keeping three useful copies available is a task that keeps receiving new conditions.

A machine fails. A process stops. A replacement takes time to initialize. The addresses clients used yesterday no longer identify the same running instances. Repeating the original launch command is not a complete answer to all of those events.

Kubernetes reached its version 1.0 milestone on July 21, 2015. The release announcement presented a production-oriented container orchestration system while acknowledging that the broader toolset still required work.¹

The useful shift was to describe an intended state and give continuing machinery responsibility for comparing it with observed conditions. Version 1.0’s replication controller, pods and services supplied distinct parts of that arrangement.

Those parts are easier to understand when the application’s goal is kept small: a fictional preview service that needs three interchangeable workers.

Ask for three, observe two

Suppose the service receives a request and returns a preview of a document. Each worker can handle any request. For the example, requests leave no durable work stored inside an individual worker.

Set the desired replica count to three. Now imagine the control system observes two nonterminated matching pods. The arithmetic is simple: three desired minus two observed leaves one missing.

A toy reconciliation function can report that one additional pod should be created. If it observes five matching pods against the same desired count, it reports two excess pods instead.

The accompanying Python model checks both cases. It is original integer accounting, not Kubernetes code, scheduling, network traffic or a cluster benchmark.

What makes that accounting consequential is its continuing role. The requested count remains part of the system after the first attempt to satisfy it. A later observation can reveal a new difference and prompt further work.

Version 1.0’s replication-controller documentation describes maintaining a chosen number of replicas, replacing terminated or deleted pods and identifying its target population through a label selector.²

That last detail matters. The controller’s question is not simply how many pods exist somewhere in the cluster. It concerns the population selected for this responsibility. An unrelated database pod should not satisfy our preview-worker count.

If a pod’s labels change so that it leaves the selected population, the remaining count can fall below the target even though that particular pod still exists. The controller can replace the missing member of its population. This is a relationship defined by selection, not by a fixed list of cherished instance names.

A pod is a unit of placement

The tagged pod document describes a pod as the smallest deployable unit: a colocated group of closely related applications with shared resources such as networking and volumes.³

For our fictional worker, one pod might hold the preview application and a helper that handles an associated local task. The point of putting them together is their close relationship, not to gather every copy of the service into one pod.

Three service replicas should therefore not be imagined as three equivalent worker containers all squeezed into a single pod merely because they run the same program. Replication and colocation answer different questions.

The pod’s placement also has a lifetime. The period document says a pod bound to a node is not moved to another node after failure. Another pod replaces it. That distinction explains why clients should not rely on an individual worker’s identity as if it were permanent.

A replacement can run the same application image without being the same instance. It may have a different address, a different start time and none of the temporary state its predecessor held.

That is comfortable for our interchangeable preview workers. It requires more design work for an application that keeps the only copy of an important record locally. Replica maintenance is not a substitute for deciding where durable state belongs.

Modern original model, drawn in 2026. Counts illustrate control intent; the Python check does not create Kubernetes objects or measure recovery time.

Three counted pods can mean two useful workers

Now give the preview service three matching pods: A, B and C. A and B can serve requests. C is still initializing and its readiness probe has not passed.

Our model counts three nonterminated pods but only two ready ones. Desired minus counted is zero. Creating a fourth merely because readiness is low would be a different policy from maintaining the selected nonterminated population.

The version 1.0 controller document explicitly distinguishes its narrow counting responsibility from readiness and liveness diagnostics. Its text says terminated pods are excluded from the count; it does not promise that every counted replica is productively serving.²

The pod-lifecycle document makes the readiness distinction concrete. A failed readiness probe removes a pod’s address from the endpoints of matching services. A failed liveness probe can cause the kubelet to kill the container, subject to its restart policy.⁴

Those are different responses to different questions. Is the process healthy enough to remain running? Is it presently ready for requests? Restarting something and removing it from traffic are not interchangeable acts.

For a preview worker that spends time loading required material, it can be reasonable to remain alive while not yet ready. Killing it repeatedly during normal initialization might prevent it from ever finishing.

The diagnostic still needs to mean something. An open port is evidence of an open port. It need not prove that the application can complete a valid preview request. A readiness test aligned with the work clients expect supplies more useful information than an arbitrary condition chosen merely because it is easy to test.

Nor does a probe eliminate observation delays or all failures between observation and use. It gives the system a specified signal to act on. The model’s clean transition from false to true is an explanation, not a claim of instantaneous real-world recovery.

A service gives clients a steadier question

Clients should ask for the preview service rather than maintain a private inventory of worker addresses. The version 1.0 service documentation defines a logical set of pods, usually selected by labels, and an access policy for that set.⁵

Our example can select pods labeled for the preview application. A changes address after replacement; the logical service remains the place clients intend to use. Endpoint information follows changes in the selected backend population.

This separates client intent from instance turnover. The client wants a preview, not a lifelong relationship with worker A.

Combined with readiness, that separation becomes particularly useful. At first, A and B are eligible in our fictional model while C is not. After C becomes ready, all three can be eligible. If B terminates and D replaces it, D can join the usable set once its readiness condition is satisfied.

The companion check walks through those states and confirms the selected ready identifiers. It does not simulate the proxy, actual endpoints controller, protocol handling or failed requests. No balancing proportions are claimed.

The abstraction does not guarantee that requests never fail. It organizes how the system can find suitable destinations as individual workers change. Application behavior, traffic conditions and the surrounding infrastructure still determine what happens to any particular request.

Modern explanatory diagram, drawn in 2026. Invented pod identities and readiness values show distinct counts, not a captured historical cluster.

A template does not edit its previous creations

Another period-specific detail is easy to blur with later deployment tools. The version 1.0 replication-controller document states that changing its pod template does not directly change pods already created from that template.²

A template is a recipe for subsequent creation. A running pod has its own specification. Changing one should not be described as a magical rewrite of the other.

For the preview service, replacing image version one with version two therefore needs an actual update procedure. The period document discusses using separate replication controllers and adjusting their counts during a rolling change.

This is precisely where present-day familiarity can falsify an early account. Today’s common Deployment vocabulary should not be silently inserted as the mechanism available in the first stable release. The narrower primitives deserve to be explained on their own terms.

They also expose the questions an update must answer. Which old workers remain? Which new workers have become ready? Are enough useful destinations available while the population changes? Merely setting a new template does not settle those questions.

Continuing control is not continuing certainty

The 1.0 announcement’s production claim belongs to its authors and its moment. It is not a guarantee that every application becomes reliable by adopting the system.

Our original example assumes interchangeable workers and omits scheduling constraints, insufficient resources, storage, partitions and overlapping selectors. Any of those can complicate the neat desired-minus-observed calculation. The research note records the model’s limits and the documents actually inspected.

The conceptual achievement nevertheless survives those qualifications. Launching an instance, maintaining a population, deciding readiness and presenting a logical service became separate responsibilities that could cooperate.

For our preview service, a useful status report is consequently more precise than three are running. Three are requested. Three count toward that request. Two are ready. A replacement is being created, or an existing worker is still initializing.

That vocabulary can sound fussy until a request fails. Then the distinction between an instance that exists and an instance that can do the work becomes the distinction somebody needs to investigate.

Sources

Footnotes

1. Craig McLuckie, “Kubernetes V1 Released”, July 21, 2015. Contemporary release announcement. Date corroborated by Canonical’s contemporary announcement. ↩

2. Kubernetes, v1.0.0 replication-controller documentation, read in full. Planned features in the document not treated as delivered. ↩ ↩² ↩³

3. Kubernetes, v1.0.0 pod documentation, opening definition, resource sharing, lifetime and motivation sections inspected. Abstract namespace discussion includes implementation qualifications. ↩

4. Kubernetes, v1.0.0 pod lifecycle, April 14, 2015 internal update; phase, conditions, probes and restart-policy sections inspected. ↩

5. Kubernetes, v1.0.0 services, overview, definition and selected endpoint/proxy passages inspected. No later networking implementation attributed to1.0. ↩