This article will interest open source technology enthusiasts with knowledge of container orchestration and Kubernetes.
Windows applications constitute a large portion of the services and applications that run in many organisations. Windows containers provide a modern way to encapsulate processes and package dependencies, making it easier to use DevOps practices and follow cloud native patterns for Windows applications. Kubernetes has become the de facto standard container orchestrator. The release of Kubernetes 1.14 includes production support for scheduling Windows containers on Windows nodes in a Kubernetes cluster, enabling a vast ecosystem of Windows applications to leverage the power of Kubernetes. Organisations with investments in Windows based applications and Linux based applications don’t have to look for separate orchestrators to manage their workloads, leading to increased operational efficiencies across their deployments, regardless of the operating system.
Windows containers in Kubernetes
To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in Pods on Kubernetes is as simple and easy as scheduling Linux based containers. In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux, depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling Kubernetes Node on Windows (including kubelet, container runtime, and kube-proxy).
Supported functionality
Compute
From an API and kubectl perspective, Windows containers behave in much the same way as Linux based containers. Key Kubernetes elements work the same way in Windows as they do in Linux. Let’s have a look at some of the key workload enablers and how they map to Windows.
Pods
A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. The following Pod capabilities, properties and events are supported in Windows containers:
- Single or multiple containers per Pod with process isolation and volume sharing
- Pod status fields
- Readiness and liveness probes
- postStart and preStop container life cycle events
- ConfigMap, Secrets: As environment variables or volumes
- EmptyDir
- Named pipe host mounts
- Resource limits
Controllers
Kubernetes Controllers handle the desired state of Pods. The following workload Controllers are supported with Windows containers:
- ReplicaSet
- ReplicationController
- Deployments
- StatefulSets
- DaemonSet
- Job
- CronJob
Services
A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them — sometimes called a microservice. You can use services for cross-operating system connectivity. In Windows, services can use the following types, properties and capabilities:
- Service environment variables
- NodePort
- ClusterIP
- LoadBalancer
- ExternalName
- Headless services
Pods, Controllers and Services are critical elements to managing Windows workloads on Kubernetes. However, on their own they are not enough to enable the proper life cycle management of Windows workloads in a dynamic cloud native environment. Kubernetes 1.14 has added support for the following features:
- Pod and container metrics
- Horizontal Pod Autoscaler support
- kubectl Exec
- Resource quotas
- Scheduler pre-emption
Container runtime
Docker EE-basic 18.09 is required on Windows Server
2019/1809 nodes for Kubernetes. This works with the dockershim code included in the kubelet. Additional runtimes such as CRI-ContainerD may be supported in later Kubernetes versions.
Storage
Kubernetes Volumes enables complex applications with data persistence and Pod volume sharing requirements to be deployed on Kubernetes.
Kubernetes on Windows supports the following types of volumes:
- FlexVolume out-of-tree plugin with SMB and iSCSI support
- azureDisk
- azureFile
- gcePersistentDisk
Networking
Networking for Windows containers is exposed through CNI plugins. Windows containers function similarly to virtual machines with regard to networking. Each container has a virtual network adapter (vNIC) which is connected to a Hyper-V virtual switch (vSwitch). The Host Networking Service (HNS) and the Host Compute Service (HCS) work together to create containers and attach container vNICs to networks. HCS is responsible for the management of containers, whereas HNS is responsible for the management of networking.
Deployments
The Kubernetes control plane, including the master components, continues to run on Linux. There are no plans to have a Windows-only Kubernetes cluster. Kubeadm is becoming the de facto standard for users to deploy a Kubernetes cluster. Windows node support in kubeadm is planned for future releases. The Kubernetes team is also working to make the cluster API more robust to ensure Windows nodes are properly provisioned.
