Alpha in v1.22: Windows HostProcess Containers
Authors: Brandon Smith (Microsoft)
Kubernetes v1.22 introduced a new alpha feature for clusters that include Windows nodes: HostProcess containers.
HostProcess containers aim to extend the Windows container model to enable a wider range of Kubernetes cluster management scenarios. HostProcess containers run directly on the host and maintain behavior and access similar to that of a regular process. With HostProcess containers, users can package and distribute management operations and functionalities that require host access while retaining versioning and deployment methods provided by containers. This allows Windows containers to be used for a variety of device plugin, storage, and networking management scenarios in Kubernetes. With this comes the enablement of host network mode—allowing HostProcess containers to be created within the host's network namespace instead of their own. HostProcess containers can also be built on top of existing Windows server 2019 (or later) base images, managed through the Windows container runtime, and run as any user that is available on or in the domain of the host machine.
Linux privileged containers are currently used for a variety of key scenarios in Kubernetes, including kube-proxy (via kubeadm), storage, and networking scenarios. Support for these scenarios in Windows previously required workarounds via proxies or other implementations. Using HostProcess containers, cluster operators no longer need to log onto and individually configure each Windows node for administrative tasks and management of Windows services. Operators can now utilize the container model to deploy management logic to as many clusters as needed with ease.
How does it work?
Windows HostProcess containers are implemented with Windows Job Objects, a break from the
previous container model using server silos. Job objects are components of the Windows OS which offer the ability to
manage a group of processes as a group (a.k.a. jobs) and assign resource constraints to the
group as a whole. Job objects are specific to the Windows OS and are not associated with the Kubernetes
HostProcess and Linux privileged containers enable similar scenarios but differ
greatly in their implementation (hence the naming difference). HostProcess containers
have their own pod security policies. Those used to configure Linux privileged
containers do not apply. Enabling privileged access to a Windows host is a
fundamentally different process than with Linux so the configuration and
capabilities of each differ significantly. Below is a diagram detailing the
overall architecture of Windows HostProcess containers: HostProcess containers can be run from within a
HostProcess Pod.
With the feature enabled on Kubernetes version 1.22, a containerd container runtime of
1.5.4 or higher, and the latest version of hcsshim, deploying a pod spec with the
correct HostProcess configuration
will enable you to run HostProcess containers. To get started with running
Windows containers see the general guidance for Windows in Kubernetes Work through Create a Windows HostProcess Pod Read about Kubernetes Pod Security Standards HostProcess containers are in active development. SIG Windows welcomes suggestions from the community.
Get involved with
to contribute!
How do I use it?
How can I learn more?
How do I get involved?