This topic describes deploying Windows worker-based Kubernetes clusters in VMware Tanzu Kubernetes Grid Integrated Edition (TKGI).
Warning: Support for Windows-based Kubernetes clusters is enabled for TKGI on vSphere with NSX and as a beta feature for TKGI on vSphere without NSX.
Do not enable this feature if you are using TKGI with Azure or Amazon Web Services (AWS).
In Tanzu Kubernetes Grid Integrated Edition, you can deploy Windows-based workloads to Kubernetes clusters on vSphere with NSX. Additionally, TKGI provides beta support for deploying Windows-based workloads to Kubernetes clusters on vSphere without NSX.
To deploy a new Windows-based workload to a new pod, do the following:
Note: This topic references standard Kubernetes primitives. If you are unfamiliar with Kubernetes primitives, review the Kubernetes Workloads and Services, Load Balancing, and Networking documentation before following the procedures below.
You can deploy Windows workloads to Windows-based clusters only.
You must configure the Tanzu Kubernetes Grid Integrated Edition tile to support Windows-based clusters before you can use Windows-based clusters in TKGI. For instructions on configuring the Tanzu Kubernetes Grid Integrated Edition tile, see Configuring Windows Worker-Based Clusters.
Your command line must have access to your Windows-based cluster to deploy Windows VMs and workloads to the cluster.
To determine which of your existing clusters is Windows-based, use the following command:
tkgi clusters
For example:
$ tkgi clusters
Name Plan Name UUID Status Action
windows-k8s Plan-11-Windows-Beta 881543kd-64fg-7826-hea6-3h7g1o04kh0e succeeded Create
second-windows-k8s Plan-11-Windows-Beta 951547dl-67kg-9631-bju8-7h9s3o98br0q succeeded Create
Only clusters configured on Plans 11, 12, or 13 are Windows-based.
To access your Windows-based cluster, run the following command:
tkgi get-credentials CLUSTER-NAME
Where CLUSTER-NAME
is the name of your Windows-based cluster.
For example:
$ tkgi get-credentials windows-k8s
Fetching credentials for cluster windows-k8s.
Context set for cluster windows-k8s.
You can now switch between clusters by using:
$kubectl config use-context <cluster-name>
The tkgi get-credentials
command creates a local kubeconfig
, allowing you to manage the cluster from the command line. For more information about the tkgi get-credentials
command, see Retrieving Cluster Credentials and Configuration.
To verify you have established access to the correct cluster, run the following command:
kubectl cluster-info
(Optional) To review the existing pods in the cluster, run the following command:
kubectl get pods
A pod deployment manifest file configures the VMs deployed to a pod.
To deploy a Windows Worker Pod:
You must create a Windows worker deployment manifest before deploying your new Windows worker pod.
To create a Windows worker deployment manifest, create a new YAML file containing the following:
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: POD-NAME
name: POD-NAME
spec:
replicas: 1
selector:
matchLabels:
app: POD-NAME
template:
metadata:
labels:
app: POD-NAME
name: POD-NAME
spec:
containers:
- name: CONTAINER-NAME
image: CONTAINER-FILE:VERSION
env:
- name: PORT
value: "80"
ports:
- name: http
containerPort: 80
nodeSelector:
kubernetes.io/os: windows
tolerations:
- key: "windows"
operator: "Equal"
value: "2019"
effect: "NoSchedule"
Where:
POD-NAME
is the name of your pod.CONTAINER-NAME
is the internal name of your container.CONTAINER-FILE
is the filename of your container.VERSION
is the version of the image to use, for example latest
.For example:
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: win-webserver
name: win-webserver
spec:
replicas: 1
selector:
matchLabels:
app: win-webserver
template:
metadata:
labels:
app: win-webserver
name: win-webserver
spec:
containers:
- name: windowswebserver
image: stefanscherer/webserver-windows:0.4.0
env:
- name: PORT
value: "80"
ports:
- name: http
containerPort: 80
nodeSelector:
kubernetes.io/os: windows
tolerations:
- key: "windows"
operator: "Equal"
value: "2019"
effect: "NoSchedule"
To deploy a new Windows worker pod, run the following command:
kubectl apply -f POD-CONFIG-FILE
Where POD-CONFIG-FILE
is the filename of the Windows worker deployment manifest created above.
To confirm the status of the new pod, and the creation of new Windows worker nodes, run the following commands:
kubectl get pods
kubectl get nodes -o wide
For example:
$ kubectl apply -f first-k8s.yml
deployment.extensions/win-webserver created
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
win-webserver-795g866cd7-58oct 1/1 Running 0 88s 10.200.42.4 0983934a-6d69-8e5g-g3k1-98r8r56l345j <none> <none>
$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
0983934a-6d69-8e5g-g3k1-98r8r56l345j Ready <none> 19d v1.29.6 10.85.41.118 10.85.41.118 Windows Server 2019 Datacenter 10.0.17763.503 containerd://18.9.0
6d69934a-7d43-9g3g-h4d1-54r9r97l395j Ready <none> 19d v1.29.6 10.85.41.115 10.85.41.115 Ubuntu 16.04.6 LTS 4.15.0-50-generic containerd://18.9.0
7636d69a-2e75-5l0g-k6m1-76r3r37l729k Ready <none> 19d v1.29.6 10.85.41.117 10.85.41.117 Windows Server 2019 Datacenter 10.0.17763.503 containerd://18.9.0
406d694a-9g96-2d3g-f3j1-32r1r44l342x Ready <none> 19d v1.29.6 10.85.41.116 10.85.41.116 Windows Server 2019 Datacenter 10.0.17763.503 containerd://18.9.0
In the preceding example a new pod is created, and creation and status of the new pod and new nodes verified.
Note: The ping
command does not work reliably for Windows workers. For more information, see Pinging Windows Workers Does Not Work in Release Notes.
A service deployment manifest file configures your service, defining how your service will run and how it will be exposed.
You must create a Windows service deployment manifest before deploying your Windows worker workload.
To create a Windows service deployment manifest, create a new YAML file containing the following:
---
apiVersion: v1
kind: Service
metadata:
name: APP-NAME
labels:
app: APP-NAME
spec:
ports:
# the port that this service should serve on
- port: 80
targetPort: 80
selector:
app: APP-NAME
type: LoadBalancer
Where APP-NAME
is the name of your Windows service.
For example:
---
apiVersion: v1
kind: Service
metadata:
name: win-webserver
labels:
app: win-webserver
spec:
ports:
# the port that this service should serve on
- port: 80
targetPort: 80
selector:
app: win-webserver
type: LoadBalancer
To expose your service on a LoadBalancer, run the following command:
kubectl apply -f SERVICE-CONFIG-FILE
Where SERVICE-CONFIG-FILE
is the filename of your Windows service deployment manifest created above.
For example:
$ kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.200.1 <none> 443/TCP 20d
$ kubectl apply -f first-k8s-service.yml
service/win-webserver created
$ kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.200.1 <none> 443/TCP 20d
win-webserver LoadBalancer 10.100.200.221 <none> 80:32073/TCP 5s
$ curl 10.85.41.118:32073
<a href="License.txt">License.txt</a>
<a href="ProgramData/">ProgramData/</a>
<a href="Users/">Users/</a>
<a href="WcSandboxState/">WcSandboxState/</a>
<a href="Windows/">Windows/</a>
<a href="var/">var/</a>
<a href="webserver.exe">webserver.exe</a>
In the preceding example a new service is created, verified, and validated.