Windows HostProcess Container: A New Era for Kubernetes Management

Kubernetes v1.22 introduced an exciting new alpha feature for clusters with Windows nodes: HostProcess Containers.

HostProcess Containers extend the Windows container model and enable a variety of scenarios for managing Kubernetes clusters. These containers run directly on the host and behave similarly to regular processes. With HostProcess Containers, users can package and distribute management operations and functions that require host access while maintaining the version control and deployment methods of containers. This allows Windows containers to be used for various scenarios related to device plugins, storage, and network management in Kubernetes.

A key feature is the host network mode, which allows HostProcess Containers to run in the host’s network namespace instead of their own. HostProcess Containers can also be built on existing Windows Server 2019 (or later) base images, managed via the Windows container runtime, and executed as any user available on the host or present in the domain.

Previously, privileged Linux containers were used for various key scenarios in Kubernetes, such as kube-proxy (via kubeadm), storage, and network scenarios. Supporting these scenarios on Windows previously required workarounds via proxies or other implementations. With HostProcess Containers, cluster operators no longer need to access each Windows node and configure it individually for administrative tasks and management of Windows services. Instead, they can leverage the container model to easily distribute management logic across as many clusters as needed.

How does it work?

Windows HostProcess Containers are implemented using Windows Job Objects, which represents a departure from the previous container model with server silos. Job Objects are components of the Windows operating system that allow a group of processes to be managed as a group (also known as jobs) and set resource constraints for the entire group. Job Objects are specific to the Windows operating system and are not related to the Kubernetes Job API. They do not provide process or file system isolation, allowing the privileged payload to view and modify host file systems with the appropriate permissions, as well as other host resources. The init process and all processes it starts or that are explicitly started by the user are assigned to the Job Object of this container. When the init process exits or receives a signal to terminate, all processes in the job are also signaled to terminate, the job handle is closed, and the memory is unmounted.

HostProcess Containers and Linux privileged containers enable similar scenarios but differ significantly in their implementation (hence the different naming). HostProcess Containers have their own pod security policies that do not apply to the configuration of Linux privileged containers. Accessing a Windows host is a fundamentally different process than with Linux, so the configuration and capabilities differ significantly. Below is a diagram detailing the overall architecture of Windows HostProcess Containers:

The new HostProcess Containers offer an exciting opportunity to optimize the management of Windows environments in Kubernetes. At ayedo, we are proud to support you in implementing this innovative feature and helping you make your Kubernetes environments more efficient.

Source: Kubernetes Blog