Kubernetes 1.14 brings Windows workers into the supported cluster

Running Windows and Linux applications has meant maintaining different assumptions about where those applications can be orchestrated. The Kubernetes 1.14 announcement makes Windows worker nodes a supported production option. Windows Server 2019 supplies the worker and container platform named in the announcement. An organization with both kinds of application can now choose a common Kubernetes orchestration system without treating Windows node support as a beta experiment.

That common system still has to respect the operating system of each workload. The interesting question is how much coordination can be shared while the execution environments remain different. The release's version-pinned changelog gives a concrete example. Kubeadm restricts CoreDNS to Linux nodes through node selectors because CoreDNS is officially supported only on Linux at this point. Adding supported Windows workers makes correct placement of existing system components more consequential.

I value Kubernetes for the controllers and API machinery that let it express operations as declared state. Windows support extends the set of workloads that can use that arrangement. It does not justify assuming that every node provides the same capabilities, and the changes in this release make that distinction visible.

Shared orchestration still requires operating system integration

The announcement describes improved support for pods, service types and workload controllers on Windows. It also names metrics and quotas among the areas brought closer to Linux capabilities. These are operational parts of supporting a worker, beyond merely starting a container. A supported worker must participate in the cluster's representation of workloads and expose information that the rest of the system can use.

Networking remains an explicit integration. The release names Azure-CNI, OVN-Kubernetes and Flannel as out-of-tree networking options for Windows. This is a useful example of Kubernetes' extension model in practice. The cluster shares workload and service abstractions while networking implementations perform the operating-system-specific work needed to realize them. Selecting the networking implementation is therefore part of building a mixed cluster, not a detail implied by the presence of a Windows node binary.

The changelog records Windows kube-proxy support for overlay networking and direct server return, with new configuration flags for network name, source virtual IP and enabling direct server return. It separately records network statistics for Windows nodes and containers. These changes explain why a support milestone involves multiple components. Routing traffic and accounting for what happens on a worker require implementations that fit the host environment.

Storage behavior also has concrete differences. The changelog marks a test Linux-only because individual files cannot be mounted in Windows containers. It includes fixes for SMB mount, unmount and remount behavior on Windows. These entries are narrower than a claim of universal workload compatibility. A containerized application still brings filesystem expectations that its target worker must satisfy.

For an operator, the CoreDNS placement change illustrates an immediate requirement. A mixed cluster needs explicit placement for components whose support is tied to one operating system. The shared scheduler cannot make unsupported software become portable. The benefit is maintaining the placement decision within the same orchestration model that manages the rest of the workload.

Configuration reuse enters kubectl

The other change with broad daily consequences is kustomize integration. Kubernetes 1.14 adds a kustomize subcommand and the -k option for commands including apply and get. A directory containing kustomization.yaml becomes an input that kubectl can build into resource configuration. The announcement presents this as reuse through Kubernetes-native configuration concepts.

These commands show the two distinct operations described in the announcement. The first emits configuration, while the second applies configuration from the directory to the selected cluster. The directory must already contain a valid kustomization and its referenced inputs.

kubectl kustomize ./application
kubectl --context example-cluster apply -k ./application

The distinction is useful because generating configuration can be examined separately from changing cluster state. A checked-in kustomization describes how resource configuration is assembled. The generated objects can be read before an apply operation, so the reusable input and the resulting API objects remain separately inspectable. The release does not require that a configuration author replace the Kubernetes objects with an unrelated application definition language.

Kustomize also keeps its own development repository and standalone binary. The announcement says new standalone capabilities will appear on a frequent release cadence and kubectl will update its copy before Kubernetes releases. This means that a command sharing a name across two binaries does not establish identical capability at every point in time. Configuration used by a deployment process needs to match the implementation that process invokes.

I prefer keeping the assembled resource configuration available for inspection. The command that prints it makes this a direct part of the tool, which suits an API-centered approach to operating the cluster. The integration also reduces a packaging step for users who need the version included with kubectl, while retaining a separate release path for kustomize itself.

Stable extension points have specific contracts

Kubectl's plugin mechanism also graduates to stable. The announcement describes plugins as standalone binaries with a kubectl- prefix on the user's PATH. That keeps distribution of additional commands separate from changes to kubectl itself. A developer can publish higher-level operations as an executable while users continue to enter through the same command-line tool.

This differs in a useful way from embedding kustomize. Kustomize becomes part of the bundled command set, with the release cadence described above. The plugin mechanism provides a general way to add commands whose executable remains separately installed. Both support extension, but they place version ownership in different locations. An operational procedure needs to identify which executable implements a command it depends upon.

Pod readiness gates supply another extension point, this time inside the workload lifecycle. The announcement describes external feedback on readiness, and the changelog records graduation to general availability. A pod's readiness can therefore incorporate a condition supplied outside the container's own probe mechanism. This is consistent with Kubernetes exposing a place for another controller to contribute information without requiring every integration to be built into the workload implementation.

Persistent local volumes also become generally available. The announcement identifies distributed filesystems and databases as principal use cases, explaining the performance and cost appeal of attached storage. A local persistent volume exposes locally attached storage through the persistent-volume model. The locality remains part of the infrastructure choice, so this milestone should be understood as support for that storage arrangement rather than an assertion that every backend has equivalent behavior.

Resource protection and discovery have separate upgrade effects

The release also addresses process IDs as an exhaustible Linux host resource. Its announcement explains that a pod can reach the host task limit without exhausting another resource and prevent daemons such as kubelet or the runtime from running. Per-pod PID limits move to beta. Reserving PIDs for the node's system components remains alpha, which gives the two related protections different maturity levels.

The changelog makes the reservation mechanism concrete. Kubelet accepts pid=<number> in the system-reserved and kube-reserved options, with the SupportNodePidsLimit feature gate required for that functionality. These are host resource controls with a specific purpose. A cluster that accounts for memory and CPU still needs a separate treatment of the task limit described by the release team.

The default discovery permissions change has a different upgrade qualification. Release authors highlight removal of default unauthenticated discovery access. According to the changelog, upgraded clusters preserve the prior behavior, while new clusters require an explicit opt-in to expose discovery or permission-checking APIs to unauthenticated users. That difference prevents treating a version upgrade as proof that an existing cluster acquired the new default access policy.

Health probes have another behavior change recorded in the release notes. HTTP probes stop following redirects to another hostname and instead treat such a redirect as success, producing a ProbeWarning event. A probe that relied on reaching a different endpoint through a redirect therefore needs its logic outside kubelet, such as the proxying arrangement suggested in the notes. This affects the interpretation of readiness even when the application's manifest still parses without a configuration error.

Taken together, these details define what the support milestone can mean in practice. Windows workers add a supported execution environment, and the release improves configuration authoring and several extension contracts around it. Placement of Linux-only components and the installed network implementation still describe real differences inside the cluster. Existing installations also retain discovery behavior that a fresh installation changes. Kubernetes 1.14 gives those installations more supported workloads and tools, with the operational result determined by their actual node and API configuration.