Kubernetes 1.14.2 repairs interrupted controller progress

A controller can have a correct desired state and still fail to make progress if its observation or cleanup machinery stops working. The Kubernetes 1.14.2 release published on May 16 includes fixes for both situations. An etcd watch error could leave informers stuck. A separate DaemonSet bug could stop processing for five minutes after a node disappeared. These are useful reasons to read a maintenance release through the behavior it restores.

I value level-triggered reconciliation because a controller can resume work from the current state. That model still depends on the implementation recovering from problems in its watches and coordinating with other controllers. The fixes in this release address those dependencies directly. Their significance lies in restoring progress when an otherwise ordinary cluster transition exposes an error path.

A watch must fail in a recoverable way

The watch fix in pull request 76675 handles a delete event whose previous key-value data is missing. The author describes ending the watch in that situation. Its release note identifies stuck informers when an etcd watch receives update or delete events with missing data as the user-visible problem.

Ending a watch may sound like giving up on observation, but the recorded problem is a watch that leaves its consumer stuck. The fix makes an unusable event an explicit reason to end that attempt. This is a distinction between an ordinary interruption the surrounding system can handle and a condition that prevents further observation from progressing. The pull request describes a narrow correction to that failure behavior, not a new watch API for applications.

The scope should remain equally narrow when interpreting the patch. It addresses events with missing data. Nothing in the release note establishes that every possible informer failure has the same cause or that every quiet controller is affected by this bug. For an installation using the affected release branch, however, it removes a documented way for the observation machinery to become stuck.

This is the sort of maintenance that matters to an extensible controller system. Resource definitions express what should exist, but controllers must obtain usable observations to act on that declaration. A failure that prevents those observations from advancing can make an apparently valid configuration ineffective. The release repairs one concrete path through that implementation.

DaemonSet cleanup crossed controller responsibilities

The DaemonSet correction in pull request 76060 addresses a different interruption. Its author explains that the DaemonSet controller had stopped processing some DaemonSets for five minutes after node removal. The fix changes which pods it deletes when their node no longer exists.

The corrected behavior leaves ordinary removal to the Pod garbage collector where that controller can handle it. The DaemonSet controller deletes pods for nonexistent nodes only when they have not been scheduled before the node was deleted, which the pull request identifies as the case the garbage collector cannot remove. Responsibility for cleanup therefore depends on the pod's state.

This is more specific than a general claim that DaemonSet scheduling becomes faster. The delay follows node removal and affects some DaemonSets. Understanding that trigger helps explain why a small change in deletion behavior can matter to workload progress. Two controllers have responsibilities around the same disappearing infrastructure, and an inappropriate cleanup path can interfere with processing the workload that remains.

The fix also illustrates why reconciliation needs carefully defined ownership. Several controllers may observe related objects without being interchangeable. An implementation has to decide which one performs a deletion and which exceptional cases need another owner. Here the distinction is between pods already scheduled and pods left unscheduled when their target node vanished.

Runtime observations get a related correction

The 1.14.2 changelog also records a kubelet statistics correction for CRI runtimes such as containerd and CRI-O. When a pod has a running instance, statistics for previous terminated instances no longer appear in kubelet's summary. The notes say this matches Docker integration and fixes container Prometheus metrics that do not work when multiple instances of the same pod appear in summary statistics.

That change concerns the interpretation of observed state. A running pod and its terminated predecessors should not produce the ambiguous summary described by the release note. It is separate from the informer fix, but both concern information that another component consumes. Correct workload behavior is insufficient if the reporting path supplies information in a form its consumer cannot use.

I see these corrections as a practical complement to Kubernetes' API design. Declared state needs a functioning observation path and cleanup that permits controllers to continue. This maintenance release improves those mechanics without asking users to rewrite their workload declarations. For the affected cases, the operational change is recovery of expected controller progress and statistics that represent the current running instance.