SIG-Windows Updates - Claudiu Belu, Cloudbase Solutions & JR Valdes, Red Hat

This talk provides updates on the integration of Windows nodes within Kubernetes, presented by senior cloud engineer Claudia and software engineer Jar. They discuss the evolution of Windows support in Kubernetes since its general availability in 2019, highlighting features in the latest releases such as support for Windows Server 2025, enhancements to kube-proxy, and capabilities for Hyper-V isolated containers. The speakers also demonstrate how to add a Windows node to a Kubernetes cluster via cloud providers, using tools like K0 and emphasizing the ease of deployment. They outline various configurations necessary to support this integration and encourage community participation for further enhancements.

Hello everyone. Thank you for joining us for the maintainer track for SIG Windows where we're going to present a couple of updates for u the Kubernetes release and we are going to have a couple of demos afterwards. My name is Claudia. I am a senior cloud engineer at cloudbased solutions and I have been involved in the SIG Windows community for a couple of years at this point.

And this is my co-presenter. >> Hi everybody. My name is Jar. I work hard as a software engineer. And um for for today we have um we're going to present a couple of ways how you could add Windows node in Kubernetes. Uh what's actually happening new in the ecosystem a couple of issue that um releasing in 136 and also planned for release in the next one. we

have uh cool demos and uh we will have some room for Q&A at the end. So um as of now there are um a little bit of history on how you could see Windows in Kubernetes from the very beginning actually uh Windows GA in 419 in 2019 and it's been a slow development since then but we're actually getting more involved in the ecosystem up to the latest

update to support 2025 uh Windows server and um operational window trainers like feature like no query and so on that brings powerful tools to interact with Windows nodes. Um so if you're new and just want to try how to add a Windows node in Kubernetes there are a couple of way you can do it. You could go directly to the cloud providers implementations, the specific implementations or

you could go into a more way if you're using like open shift or rancher um tanu kubernet grid also provide a way uh you could use um k0 which is also supported or you could do like all the step by yourself following the documentation that we have upstream in the kubernet website. So um latest for the um update from Sik Windows there's been enhancement on the cube

proxy um those fixes were introduces in uh 136 and also a ported to 135 so they will be available in 135 as well. uh from the container this high. Um the new platform logic also has been enhancement to match the image selection and of course the introduction of the support for Windows Server 2025. A new post image has been added and also we have full test coverage

for uh Windows uh 2025 in the uh test grid. Um, hyperb isolated containers is also getting um a new round of test where we have coverage in the end to end test. For this specific feature, there is no changes needed in the kubernet code base since everything will happen in the windows host tuning how containerd uh works with the hyperb but there is a test cover for

that. So we could be considered tested. Um features grad rating in 136. We have no lo query. This feature was actually introduced in alpha bagging 127. Um that is now evolving and accepted to 136 as so the feature gate will be locked to true. It will be enabled by default. You just need to uh configure the cuber flag to enable that. This feature uh will allow you

to get logs from any node, Windows or Linux node just using the cubectl which is uh really cool. Um proposal for um next release we have um the um Windows gradown. Um this cap actually depends on the Linux counterpart which is kept 2000. Uh once that will go to EA then we will target uh the Linux the Windows side to EA in 136 as well. Um feature

work will plan to also work in the Windows CPU and memory affinity that's kept uh 48 um 85 and also the cryful containers on port stack future work that probably targeting 138 and so on. Same with um the EMOS pool per runtime class and we also been keeping and updating the documentation so that everybody is up to date with the latest that we have in Kubernetes upstream.

Uh all right so for the demos now I will hand it to Claudu. He will be introducing uh HyperB and how it works for the Windows node. uh talking about the HyperV isolated containers since uh we just introduced uh new test jobs for uh HyperV isolated containers in test grid and you know we feel a bit more confident to advertise uh this sort of feature because you

know we can have some sort of uh quality assurance that everything is working as intended in Kubernetes. When it comes to this type of workloads, basically uh as you know it's a bit different from a regular process isolate container u a process is container will basically share the same host kernel um with the host itself. So basically it's a lot closer to to the to the uh

host environment itself. And you know um it might be a bit unsafe to run certain workloads and stuff like that. Meanwhile for is containers basically every single uh workload will have um a microVM a very tiny VM in which the container itself is going to run. It's going to be separated from the host itself which will also has it will also have um its own kernel version

and so on. Uh it's very uh useful for cases in which you care about multi-tenency or maybe potentially running different uh workloads that you might not trust entirely from different customers or clients and so on so forth in which you wouldn't want any potential uh or risk any chances for uh container exits and so on so forth. There are quite a few other projects which um is

investing interest in uh this space uh with similar projects like kata containers or uh g visor and stuff like that and now you also have this same option for windows containers. So when it comes uh to how to use it, you basically need any Windows server version uh from 2019 onwards. We do recommend the 2022 images and the 2025 images. You need um to be able to

virtualize uh on your host. Basically, if you do run uh Windows nodes in any public cloud, you will have to make sure that nest vization is enabled u because it does require hyperv to be enabled. Without that, there's no uh chance to do that and you will need uh any containerd newer than 1.7. so when it comes to running HyperV is containers uh in Kubernetes as my

colleague mentioned there is no change needed uh in Kubernetes itself all the necessary mechanisms are already in place basically you simply have to configure containerd to have a proper um let's say uh configuration for hyperv solution and then you'll have to create a runtime class in kubernetes and just create pods targeting that runtime class specifically and that's all you need. Uh the configuration change in container ID

looks something similar to this in particular is going to be the part on the bottom that's going to be the new runtime handler. The important part is going to be the sandbox isolation that is going to um turn on the the feature for HyperV isolation when containerd will try to make the the container on the containers on the Kubernetes side. Uh just create a runtime class as

demonstrated here. It has the same name uh as the same name as uh this part right here, the runtime handler. So that's going to be important. That's how uh uh they map. all you need to do when you create pods, you just have to specify the runtime class name. And that is it. That is it. Basically a simple three-step process and you can do it. So, you

know, my challenge for you is to try it next time. Um, I already tried those locally. Uh, you know, yay from this morning. So, give it a shot. Next, uh, we have a special guest who will introduce and talk about um, uh, the next part of the demo. Uh, Tom Vitzk. >> Am I close? >> Yeah, that's right. Thank you. Windows Windows uh running Kubernetes on Windows

is usually a bit more complicated and um uh I will show you a way uh that Kubernetes on Windows is not more complicated than running it on Linux and it can be very easy. Uh for that uh we have a short demo prepared. this is pre-recorded in an ESIS cinema format, but the but it is fresh from this morning. I think that's very small, right? >> Zoom

the zoom the >> Yeah, let's see. There is some I will zoom it in a bit. >> Yeah, I think that's good. Okay. And let's see. I I'm using a bit of Felix there, so the editor might be a bit broken, but I can tell you and show you afterwards. I mean, this is still the same uh the same uh folder I recorded the demo from, and

we can poke at it afterwards. So, um the idea here is that um for K0S, which is like used to deploy uh the Windows cluster here, uh we just need SSH access. Okay, now you're not seeing what I wanted to show you. Um, there is basically the SSH addresses just configured for a uh for a Windows node and a Linux node. And uh this is all it

needs to uh deploy deploy it. Um first of all, when you're when you're running u Kubernetes on Windows, you always need to install uh the Windows containers feature. You probably know it. So this is a bare barebones VM that I just started this morning. So I just install the the necessary Windows container feature uh and restart the computer afterwards. But that's basically all. And uh if that's

done in a couple of seconds, then actually uh we can just install um a cluster using KzTL which is then connecting to uh at the same time to the Linux and to the Windows node and is installing all the stuff. It's downloading KZS and it's starting the controller the control plane and the Linux worker uh for uh the control plane components and at the same time uh

the Windows worker to deploy Windows workloads. Now that's the command and that's how it looks how it looks like. So um KCTL will figure out by itself that uh one of the nodes is the Windows node and the other one is the Linux node and will just do the appropriate things for it. H and then it will just connect via SSH and install everything. It will take

a minute or so and after that uh the cluster's already up. So, uh, the key point here is that this is very very much a barebones virtual machine, just a b the the standard EC2 image that you can grab from, um, Amazon Web Services and we didn't do anything with it. You can just deploy it. And now it's all done. You're getting your cube config and then

you can have a look at the notes. Ah, of course I need to um, set the cube config first, of course. But then you can have a look at the nodes and then we you will see uh one Linux node which is running uh the control plane and one windows node which is running the uh There you go. I forgot to say mine is a white to

see that the second one is actually a Windows data center 2022 node, but you saw it in the KZCL output before. And we can also like have a look at the uh at the cluster afterwards. So it took me around about 5 minutes to deploy all of this. So it's not not really hard actually. And after that um we can uh if the cluster is finally up.

So you see like um u calico which is required for the CNI networking on Windows takes a bit of time to to become ready but if it is ready we can just deploy a single simple workload. Okay, I will show you the manifests afterwards because it's broken because I zoomed in here. Uh this is basically just a single port deployment uh which is exposing a service on

a node port so that we can just um so it becomes ready real quick so that you can just um deploy it and uh after that you can we can just access that part on the node port so there there now I'm copying out the IP address which is now broken again but we can poke at it live afterwards if it's done right that's the address 3.77.236

20 and that's it. So there is basically the website and this website is also uh here and that is basically the bot that I deployed uh half an hour ago. So you see the uptime of the Windows server is 1 hour and 9 minutes. You can scan the QR code and uh check it out. So the Windows worker stats on the bottom are like live updates. They

should be refreshing. Yeah, there they go. So you can try it out and it's really really really working quite nicely and um just to really show you the right files. So this is basically just the deployment that I did. It's really much straightforward. There's the node port I want um I deployed and this is just a little demo app a single single pot for the demo which

is starting up real quick. And this is the KZCTL configuration. So there you see you just put like two nodes in there, one for the controller, one for the worker, and you just configure their SSH access, and that's more or less it, right? Okay, that's just a demo that uh Kubernetes on Windows is not much more complicated than Kubernetes on Linux. >> Thank you, Tom. >> Thank

you, Tom, for the presentation. How to do uh a Windows node deployment with zero friction. so since we are a community in Kubernetes we also like to shout out some of the contributions that uh our community members did over the last cycle. Um Prince Pereira who helped us a lot with the cube proxy and wind kernel uh fixes that were previously mentioned. Um, Yuan Yang Jang, hopefully

I'm not going to butcher many names, so I apologize in advance, who has been driving the graceful shutdown uh, cap. Uh, Dawe, who has been working on um, enabling the HyperV is container test grid job. So basically, thanks to him, we can uh, hopefully have uh, more workloads that are going to be very interesting for uh, SIG, Windows, and Windows in general. And we also have um

uh Juan Leuis the source of Ladas Castano hopefully uh that is correct who helped us um create a chron job for publishing cube proxy images uh out to be up to date. Um we do have a couple of uh leadership changes in sig windows. First of all, uh we thank Arvind for all his contributions and work as a co-chair of C Windows. And um he is going

to be um replaced by uh our own co-presenter right here u Jr. And we do have um another tech lead, Yan Lang Jang, um who's going to join us. and um Mark Rosedi is stepping down to uh tech lead from the position of uh co-chair. Since we are community uh we would like to welcome all of you uh to join us. We do have weekly meetings on

Tuesdays. Uh drop in, say hi. Especially if you use Windows uh please let us know. It would be great to to have your voice heard and if you have specific um frictions or issues or features that you would like to see in uh Windows, you can join um tell us your use case so we can uh follow up afterwards. And also you can also help us drive

some of the caps that was mentioned previously to drive them to beta or GA. Most of those already have code implemented upstream. This just needs a bit of uh handholding to for them to get to beta and uh to be finally stable. We do have every single recording um on YouTube. So any meeting that you want to see uh you can always see there and join us

on Slack on Sigu's channel. And now if you have any questions we are open to them. have like a five minutes for questions. So, >> Yep. Go ahead. There is a mic over there if you want to uh go. So, the demo was really nice nice to see for me. Uh it went really fast and I'm super interested in getting it up and running on my own

hardware. Uh how can I get help? >> Yeah, sure. Um Tom, >> yeah I mean you can drop in in the Kubernetes Slack >> and just reach out to us. I mean we're happy to help. >> Here is uh all the links that you need. Um the link to the Slack channel mailing list u or you could just go to Slack say hi and uh Tom will

be there or any of Do you guys cooperate with public providers like Microsoft with AKS? >> Yes, we do. Um Mark Rosetti um who is one of the tech leads right now was the co-chair of SIG Windows. He works for Microsoft. All the test infrastructure runs on Azure through AKS. So yeah, >> right now the test uh grid is using closer API for ashure caps and this

is uh basically all the infrastructure that all the test windows are running on. >> Mhm. >> And the test also includes u jobs that run on uh GC. So yes and I think um Tom's demo was on u Amazon, right? Yeah, but that was just because it was easy to get the VMs there. It doesn't really matter as long you have as you have SSH access, right?

>> Yeah. For Tom's demo, basically the only thing you need is an IP address and username and password and SSH enabled in the in the Windows host. And with that, you could get the the Windows node joining the cluster following those steps. >> So there are quite a few ways to deploy Windows nodes. For example, um we personally how we use it, we use cluster API to

deploy u Kubernetes including Windows nodes and Linux nodes on prem uh through different uh cluster API providers like Tinkerbell or um what was the other one metal 3 and so on. So those are also an option. Do you have any specific request for um Asher in Kubernetes with Windows? >> Uh we actually use Asia local. >> Okay. So we are bound to the deployment methods and uh

usage that Microsoft provides integrates with uh failover clustering service to create uh new nodes, new clusters and then to operate it. All right, sounds good. Um, any other question for the audience? We have like a couple of minutes left, right, perfect. Thanks for attending. Uh, it's been a pleasure to be with you.