Deploying and Exposing Basic Windows Workloads

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 Google Cloud Platform (GCP), Azure, or Amazon Web Services (AWS).

Overview

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:

Access Your Windows-Based Cluster
Configure a Pod Deployment Manifest
Deploy the Pod
Configure a Service Manifest
Deploy the Service

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.

Prerequisites

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.

Access Your Windows-Based Cluster

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.<br>  
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
```

Deploy a Windows Worker Pod

A pod deployment manifest file configures the VMs deployed to a pod.

Configure a Pod Deployment Manifest

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"

Deploy the Pod

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.14.1    10.85.41.118  10.85.41.118  Windows Server 2019 Datacenter    10.0.17763.503      docker://18.9.0  
6d69934a-7d43-9g3g-h4d1-54r9r97l395j    Ready    <none>   19d    v1.14.1    10.85.41.115  10.85.41.115  Ubuntu 16.04.6 LTS                4.15.0-50-generic   docker://18.9.0  
7636d69a-2e75-5l0g-k6m1-76r3r37l729k    Ready    <none>   19d    v1.14.1    10.85.41.117  10.85.41.117  Windows Server 2019 Datacenter    10.0.17763.503      docker://18.9.0  
406d694a-9g96-2d3g-f3j1-32r1r44l342x    Ready    <none>   19d    v1.14.1    10.85.41.116  10.85.41.116  Windows Server 2019 Datacenter    10.0.17763.503      docker://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.

Deploy a Service to a Windows Worker Pod

A service deployment manifest file configures your service, defining how your service will run and how it will be exposed.

Configure a Service Manifest

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

Deploy the Service

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.