Cloud Native 9 min read

How to Deploy Windows Nodes in Kubernetes 1.14: Step‑by‑Step Guide

This guide walks through the complete process of preparing a Windows Server 2016 host, enabling Hyper‑V and RRAS, installing Docker EE, configuring a transparent Docker network, and joining the node to a Kubernetes 1.9 (or 1.14) cluster, including all required commands and troubleshooting steps.

Cloud Native Technology Community
Cloud Native Technology Community
Cloud Native Technology Community
How to Deploy Windows Nodes in Kubernetes 1.14: Step‑by‑Step Guide

Environment Requirements

Kubernetes 1.14 adds production‑grade support for Windows nodes (experimental support started in 1.9). The guide assumes a Windows Server 2016 Datacenter (or newer, e.g., Windows Server 1709) with Hyper‑V enabled and two NICs on the same VLAN.

Docker 17.06.2 (EE or CE)

Kubernetes 1.9.8 cluster (Flannel host‑gw network, CIDR 10.2.0.0/16, master address pool 10.2.0.0/24)

Windows client binaries from the Kubernetes repository (see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md#windows)

Server Base Configuration

Enable Hyper‑V and RRAS

Hardware virtualization (Intel VT) must be turned on; most cloud VMs do not support it. Follow the Windows Server 2016 RRAS guide and enable the "Allow remote shell access" policy via gpedit.msc (Computer Configuration → Administrative Templates → Windows Components → Windows Remote Shell).

Verify that the Hyper‑V and RRAS services are running using systeminfo and services.msc. If RRAS is not started, set its startup type to "Automatic" and start the service.

Install Docker and Join the Node to the Kubernetes Cluster

Docker installation

Extract the Docker EE package to C:\ProgramFiles\Docker.

Add that directory to the system PATH.

Configure the Docker service to start automatically and start it.

Optionally, run the following PowerShell commands (assuming the installer is on the desktop k8s folder):

cd $env:USERPROFILE\Desktop\k8s
Expand-Archive -Path docker-17.06.2-ee.zip -DestinationPath C:\ProgramFiles\Docker
[Environment]::SetEnvironmentVariable('PATH', $env:PATH + ';C:\ProgramFiles\Docker', [EnvironmentVariableTarget]::Machine)
Start-Service docker
Set-Service -Name docker -StartupType Automatic

Add an insecure registry entry to C:\ProgramData\docker\config\daemon.json (create the file if it does not exist) and restart Docker:

{
  "insecure-registries" : ["myregistry.local:5000"]
}
restart-service docker

Copy Kubernetes binaries

Copy kubelet.exe and kube-proxy.exe from the Windows client package to C:\Windows (or add their folder to PATH).

Copy kubelet.conf (originally /etc/kubernetes/kubelet.conf on the master) to C:\Users\Administrator.

Create a transparent Docker network

docker network create -d transparent --gateway 10.2.1.1 --subnet 10.2.1.0/24 alaudanet

This command creates an external Hyper‑V virtual switch (e.g., Layerd_Ethernet0) and a virtual NIC named HNSTransparent. If the NIC inherits the IPv4 address of the physical NIC, manually assign 10.2.1.1/24 to HNSTransparent and use it as the gateway for the alaudanet network.

Routing configuration

On the master node add a route to the Windows node subnet: ip route add 10.2.1.0/24 via <windows_node_ip> On the Windows node add a route to the Kubernetes pod CIDR (replace <interface_id> with the ID of the NIC that holds the physical IP):

route add 10.2.0.0 mask 255.255.255.0 10.2.0.1 if <interface_id> -p

Obtain the interface ID with route print | more. Set an environment variable so the node knows its container network: setx CONTAINER_NETWORK alaudanet Pull required Windows base images

docker pull microsoft/windowsservercore
docker pull apprenda/pause

Start kubelet and kube‑proxy

Replace the IPs with the actual master and node addresses in your environment.

kubelet.exe \
  --hostname-override=168.63.124.72 \
  --pod-infra-container-image="apprenda/pause" \
  --resolv-conf="" \
  --kubeconfig=.\kubelet.conf
kube-proxy.exe \
  --v=3 \
  --proxy-mode=userspace \
  --hostname-override=168.63.124.72 \
  --master=168.63.124.71:6443 \
  --bind-address=168.63.124.72

After these steps the Windows node appears in the Kubernetes cluster and can run Windows workloads by using a node selector that targets the kubernetes.io/os=windows label.

References

https://k8smeetup.github.io/docs/getting-started-guides/windows/

https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/getting-started-kubernetes-windows

https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Cloud NativeDockerKubernetesWindowsTutorialk8s
Cloud Native Technology Community
Written by

Cloud Native Technology Community

The Cloud Native Technology Community, part of the CNBPA Cloud Native Technology Practice Alliance, focuses on evangelizing cutting‑edge cloud‑native technologies and practical implementations. It shares in‑depth content, case studies, and event/meetup information on containers, Kubernetes, DevOps, Service Mesh, and other cloud‑native tech, along with updates from the CNBPA alliance.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.