![]() ![]() To do this, we used the nodeSelector in the pod definition. After that, we scheduled an actual workload on the nodes in that pool. We created a new AKS cluster, and we added a Windows nodepool. In this blog post, we looked into how to run Windows containers on the Azure Kubernetes Service (AKS). To get its public IP, use kubectl get svc: Getting the service’s public IP addressĪnd if we browse to that IP, you can see a glorious IIS web server running on Kubernetes: A glorious IIS web server running on AKS.Īnd that’s how you run Windows containers on AKS. But after a couple of minutes, you should see your Windows pods running, which you can confirm using kubectl get pods -o wide: Getting the windows server pods.Īnd we can now also browse to the service. It will take a while for the pods to spin up since Windows images are generally a bit bigger than Linux images. We can deploy both using: kubectl create -f. Note how the service definition isn’t any different for Windows vs Linux workloads. To verify that things work well, let’s also include a service to route traffic to these IIS servers. This will create a deployment, containing 2 IIS web servers. Image: /windows/servercore/iis:windowsservercore-ltsc2019 An example of that below ( code is also available on GitHub): apiVersion: apps/v1 Let’s have a look at how to do that: How to schedule pods on Windows nodesĪs mentioned in the previous section, to schedule a pod on a Windows node, you need to include a nodeSelector in your workload definition. Otherwise, Kubernetes might schedule Linux pods on Windows nodes (or vice-versa), and that will lead to issues. ![]() What’s important to note here: if you run in a mixed cluster (with both Linux and Windows nodes and workloads), you need to include the nodeSelector for both Windows and Linux workloads. In case of the operating system, we’ll set the kubernetes.io/os label to Windows in the nodeSelector. In the node selector, you define which labels on the nodes need to be met to schedule pods on certain nodes. To schedule pods on a Windows node (or a Linux node for that matter) you’ll have to set a nodeSelector in the pod definition. To see those labels, run a kubectl describe node : Labels on Windows nodes What’s more, these nodes are also labeled with their OS information. Once you have a cluster with both Linux and Windows nodes, you should be able to run kubectl get nodes -o wide and see you now have nodes with a Windows operating system: You should have nodes with a Windows OS A little info about labels and nodeSelectors While you’re waiting for the node pool to be added, let’s explore how we need to tell Kubernetes to schedule a Windows workload on Windows nodes. The second command will take some time to run (about 15 minutes), but after a while, we will be able to go ahead and schedule Windows containers. windows-admin-password superSecret123! \ node-count 2 -ssh-key-value ~/.ssh/id_rsa.pub \ # Create the cluster, with the default linux nodepool ![]() Let’s create all of this using the Azure CLI: # Create a resource group This is used for running system components such as CoreDNS. To run Windows containers on AKS, we’ll need the following: After we’ve set up the cluster, we’ll have a look at how actual Windows containers can be created on the cluster. ![]() In this blog post, we’ll explore how you can add Windows nodes to a Kubernetes cluster running on Azure. Windows has supported Docker containers for a while now, and since Kubernetes 1.14, Windows support has been generally available in Kubernetes as well. Containers and Kubernetes have traditionally been the area of Linux-based workloads. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |