Deploying and Exposing Basic Windows Workloads (Beta)

Overview
Prerequisites
Access Your Windows-Based Cluster
Deploy a Windows Worker Pod
- Configure a Pod Deployment Manifest
- Deploy the Pod
Deploy a Service to a Windows Worker Pod
- Configure a Service Manifest
- Deploy the Service

Page last updated:

Warning: VMware Enterprise PKS v1.6 is no longer supported because it has reached the End of General Support (EOGS) phase as defined by the Support Lifecycle Policy. To stay up to date with the latest software and security updates, upgrade to a supported version.

This topic describes deploying Windows worker-based Kubernetes clusters in VMware Enterprise PKS.

Overview

In Enterprise PKS, you can deploy Windows-based workloads to Kubernetes clusters on vSphere with Flannel.

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

Warning: Support for Windows-based Kubernetes clusters is in beta and supports only vSphere with Flannel.

Do not enable this feature if you are using Enterprise PKS v1.5 with vSphere with NSX-T, Google Cloud Platform (GCP), Azure, or Amazon Web Services (AWS).

We are actively looking for feedback on this beta feature. To submit feedback, send an email to pcf-windows@pivotal.io.

Prerequisites

You can deploy Windows workloads to only Windows-based clusters. Before you can use Windows-based clusters, you must configure the Enterprise PKS tile. For instructions on configuring the Enterprise PKS tile, see Configuring Windows Worker-Based Clusters (Beta).

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:

pks clusters

For example:

$ pks 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:
```
pks get-credentials CLUSTER-NAME
```
Where CLUSTER-NAME is the name of your Windows-based cluster.

For example:
```
$ pks 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 pks get-credentials command creates a local kubeconfig, allowing you to manage the cluster from the command line. For more information about the pks 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: extensions/v1beta1
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:latest
        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.

For example:

---
apiVersion: extensions/v1beta1
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:latest
        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.

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: NodePort

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: NodePort

Deploy the Service

To expose the specified service on a NodePort, 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 NodePort   10.100.200.221    <none>       80:32073/TCP   5s

$ curl 10.85.41.118:32073
<pre>
    <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>
</pre>

In the preceding example a new service is created, verified, and validated.

Please send any feedback you have to pks-feedback@pivotal.io.

Create a pull request or raise an issue on the source for this page in GitHub