HostProcess / Privileged containers lengthen the Windows container model to allow a wider vary of Kubernetes cluster administration scenarios. HostProcess containers run at once on the host and preserve behavior and access similar to that of a ordinary process.
HostProcess containers allow users to package and distribute management operations and functionalities that require host access whilst protecting versioning and deployment strategies provided by means of containers.
A privileged DaemonSet can elevate out adjustments or reveal a Linux host on Kubernetes however not Windows hosts. HostProcess containers are the Windows equal of host elevation.
- HostProcess containers require Kubernetes 1.23 or greater.
- HostProcess containers require containerd 1.6 or higher container runtime.
- HostProcess pods can only include HostProcess containers. This is a current predicament of the Windows operating system. Non-privileged Windows containers cannot share a vNIC with the host IP namespace.
- HostProcess containers run as a system on the host. The solely isolation these containers have from the host is the resource constraints imposed on the HostProcess person account.
- Filesystem isolation and Hyper-V isolation are not supported for HostProcess containers.
- Volume mounts are supported and are set up under the container volume. See Volume Mounts.
- A confined set of host consumer accounts are accessible for Host Process containers through default. See Choosing a User Account.
- Resource limits such as disk, memory, and cpu count, work the same way as trend as processes on the host.
- Named pipe mounts and Unix domain sockets are now not without delay supported, but can be accessed on their host path, for instance \.\pipe*.
To use HostProcess features with your deployment, set privileged: true, hostProcess: true, and hostNetwork: true:
spec: ... containers: ... securityContext: privileged: true windowsOptions: hostProcess: true ... hostNetwork: true ...
To run an example workload that uses HostProcess features on an existing AKS cluster, create kcdhostprocess.yaml.
The example workload can be run using kubectl.
kubectl apply -f kcdhostprocess.yaml
You should see the following output:
$ kubectl apply -f kcdhostprocess.yaml daemonset.apps/privileged-daemonset created
The features of HostProcess can be verified by viewing the logs.
The name of the Pod can be found in the kube-systemnamespace.
$ kubectl get pods --namespace kube-system NAME READY STATUS RESTARTS AGE ... privileged-daemonset-12345 1/1 Running 0 2m13s
You can use the log to view the logs and verify the administrator rights.
$ kubectl logs privileged-daemonset-12345 --namespace kube-system InvalidOperation: Unable to find type [Security.Principal.WindowsPrincipal]. Process has admin rights:
Thanks for studying my article till end. I hope you realized something unique today. If you enjoyed this article then please share to your buddies and if you have suggestions or thoughts to share with me then please write in the comment box.