JORGE PALMA: Hi, everyone.
My name is Jorge Palma,
and I'm a PM Lead in Azure Kubernetes Service.
Today, we will be looking at a new capability in
Windows containers called Host Process containers.
Now you might have heard about
Linux privileged containers before.
Windows Host Process containers
enable similar scenarios but
differ greatly in their implementation
, hence a different name.
Enabling privilege access to a Windows host is
fundamentally different
than enabling it on the Linux host,
so the configuration and capabilities
for each differ significantly.
But so what are Host Process containers?
In Kubernetes, Host Process containers run
within Host Process ports and those
directly run on the host maintaining
a behavior in access
similar to that of a regular process.
Windows Host Process containers are
implemented with Windows job objects,
not to be confused with the Kubernetes job API.
The job objects are components of
the Windows operating system which offer the ability
to cohesively manage a group of processes and
assign resource constraints to the group as a whole.
This container model differs from the previous model
that used server silos as you see in the image.
Because it has no process or file system isolation,
it enables the privileged workloads to view and edit
the host file system with
the correct permissions among other host resources.
Together with this comes
the enablement of host network mode,
which allows Host Process containers to be created within
the host's network namespace instead of their own.
Lastly, Host Process containers have
their own port security policies,
so those used to configure
Linux privileged containers do not apply to them.
Host Process containers aim to extend
the Windows container model to enable
a wider range of Kubernetes cluster
management scenarios.
They're available on Azure Kubernetes Service
from Kubernetes 1.23 onwards.
Now let's quickly jump into
a demo to see how easy it is to
use Windows Host Process containers
on Azure Kubernetes Service.
In this demo, we will create
an AKS cluster that will allow us to run
Windows Host Process containers and
add a Windows node pool to this cluster.
We will then deploy a test Host Process container
and finalize by validating
its permissions and capabilities.
To begin, we'll start by creating
an AKS cluster for our demo.
Because we will be using Windows node pools,
we'll make sure to pass the Windows admin username
and the Windows admin password.
You'll also notice that we're using
the Kubernetes version 1.23.5.
In order to support Windows Host Process containers,
you want to make sure that your cluster version is
at least 1.23 or later.
Let's go ahead and create this cluster.
Once it's created successfully,
we can move on to creating our Windows node pool.
We're going to call this Windows node pool hpc2
or Host Process containers 2,
and just for fun, we will create it
a slightly different version than
our control plan in our Linux nodes.
In this case, we will use 1.23.3.
As I mentioned before, any 1.23 or
later version will
support Windows Host Process containers.
Let's go ahead and create our Windows node pool,
and once it's created,
you can validate that it
created successfully with 1.23.3.
If we take a look at the nodeImageVersion,
you'll notice that it was created with
the April 13th of 2022 image.
This is important because you'll want to
make sure that your Windows node pool,
either new or existing,
is using an image version that is equal or later
than the March 17th of 2022 image version.
That's because as per the August release nodes,
that was the image version that
introduced container D1.6,
and continued D1.6 is required in order
for Windows HostProcess containers to work correctly.
Now, any new node pool like we just created here or
any upgraded node pool that you have created
today will have an image version that is later,
and that just make sure that
the image version that
the Windows node pool that you're using is
at least later or equal than March 17th of 2022.
Now let's make sure that all our nodes
and our clusters are running correctly.
We have our three Linux nodes and
our three Windows nodes running
their respective versions 23.5 and 23.3.
Now let's take a look at our example pods.
We're going to have a server core pod
that is a regular when this container and we're going to
have a Server Core Host Process container pod
that is running with the new feature.
Here we have our regular Windows container,
which is just a normal container using
the Server Core 2019 image and just
running a never-ending ping command that
we're going to use to execute and to have a look at
our Host Process container pod running
the exact same image 2019
Server Core running exact same command.
The key difference is
the security context and the host network properties.
In the security context,
you'll notice that we're running HostProcess true.
We are running the Windows system account
as our user and that we're
running host network true in order to make sure
that this pod is running on the host network namespace.
The only thing left now
is submitting both manifests and deploying them.
We can take a look to confirm
that both pods are running.
There we go. Both of
our pods are running successfully here.
We're going to start now
by executing into our normal pod,
so we're going to be executing it to both of
them and confirming the differences
between our regular Windows pod
and our Host Process pods.
In our regular Windows pod,
you'll notice the contents of the directory
is exactly what you expect
the content of the image
and the local directory is there.
If you happen to try and get the content of C drive,
you'll get exactly the same.
This is our world. It's the only thing that we see.
If you take a look at the IP of this container,
you'll notice that is this 10.240.0.250,
which is one of our free IPs for our pods.
It's a regular pod IP.
Now, if we continue and take a look at
our Host Process container pod
in this case and execute into it,
you'll notice that the content
of the local directory is the same.
That's because Host Process containers still have
their own dedicated volume where the contents
of the image and your local workspace reside.
But if we take a look at what's on the C drive,
you'll actually notice that now we're looking at
the root file system of the node.
You'll see even the release nodes of
this AKS node right here and you can see
everything in the node file system.
Similarly, if we take a look at the IP,
you'll notice that we have this 10.240.0.252
and this IP just so happens to be.
If we take a look at our nodes again,
one of the IPs of our Windows nodes.
That's because this pod, as we saw before,
is actually running in
host network in one of our Windows nodes.
That, as you can see,
is running container D1.6 and the latest Windows image.
Now you've seen how easy it is to
create Windows Host Process containers on AKS.
With Host Process containers,
you can package and distribute
management operations and functionalities that require
host access while retaining
the versioning and deployment
methods provided by the containers.
You can check these resources to know
more about how to create and
use Windows Host Process containers and
to learn more about Kubernetes on Azure.