7.22
Azure Kubernetes Service
Overview
This section presents some pointers on setting up and managing a Kubernetes cluster tailored for WorkflowGen in Azure.
Creating a new cluster
To create a new cluster that supports Linux and Windows workloads, see the Create a Windows Server container on an Azure Kubernetes Service (AKS) cluster using the Azure CLI Microsoft article, which includes step-by-step instructions on how to create the cluster. Follow all the instructions, including creating a Windows node pool. At the end, you should have at least two nodes: a Linux node and a Windows node.
You can use Azure Active Directory to authenticate and authorize users in the cluster. See the Integrate Azure Active Directory with Azure Kubernetes Service using the Azure CLI Microsoft article for more information.
It's only possible to integrate Azure Active Directory with the creation of a new cluster.
Managing Windows and Linux nodes
By default, AKS doesn't restrict further Windows nodes from preventing Linux deployment on them. It's recommended to use taints and tolerations to avoid problems with Linux deployment being scheduled to Windows nodes. The following is an example of how you can use taints and tolerations to manage hybrid deployments.
Taint all Windows nodes
Tainting all Windows nodes will prevent any deployment to Windows nodes from being scheduled except when it has the required toleration. Therefore, for many Linux Helm charts that don't have a node selector, the deployments to Linux nodes will automatically be scheduled. Google Kubernetes Engine does this by default. Execute the following command to taint a Windows node:
1
kubectl taint nodes "<NODE_NAME>" os=windows:NoSchedule
Copied!
Replace
<NODE_NAME> with the name of the Windows node.Add tolerations to Windows deployments
To be able to deploy Windows pods to Windows nodes, you have to use a combination of tolerations and node selectors in your deployment specification. For example, consider this WorkflowGen deployment:
1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
name: wfgen-webapps
5
spec:
6
replicas: 3
7
strategy:
8
type: Recreate
9
selector:
10
matchLabels:
11
app.kubernetes.io/name: workflowgen
12
app.kubernetes.io/component: webapps
13
template:
14
metadata:
15
labels:
16
app.kubernetes.io/name: workflowgen
17
app.kubernetes.io/component: webapps
18
spec:
19
containers:
20
- name: wfgen
21
image: advantys/workflowgen:7.18.3-win-ltsc2019
22
imagePullPolicy: Always
23
resources:
24
requests:
25
memory: "2Gi"
26
cpu: "1"
27
limits:
28
memory: "2Gi"
29
cpu: "1"
30
ports:
31
- name: http
32
containerPort: 80
33
protocol: TCP
34
envFrom:
35
- configMapRef:
36
name: wfgen-config
37
env:
38
- name: WFGEN_START_SERVICE
39
value: webapps
40
livenessProbe:
41
periodSeconds: 30
42
timeoutSeconds: 5
43
initialDelaySeconds: 60
44
exec:
45
command:
46
- powershell
47
- C:\healthcheck.ps1
48
livenessProbe:
49
timeoutSeconds: 5
50
initialDelaySeconds: 60
51
exec:
52
command:
53
- powershell
54
- -Command
55
- if (Test-Path "C:\iislog\W3SVC\*log") { return 0 } else { return 1 }
56
volumeMounts:
57
- mountPath: C:\wfgen\data
58
name: wfgdata
59
- mountPath: C:\wfgen\licenses
60
readOnly: true
61
name: licenses
62
- mountPath: C:\secrets
63
readOnly: true
64
name: secrets
65
volumes:
66
- name: wfgdata
67
persistentVolumeClaim:
68
claimName: wfgdata-pvc
69
- name: licenses
70
secret:
71
secretName: wfgen-license-secret
72
items:
73
# The following must match the name of the license item in
74
# the license secret, e.g. the name of the license file
75
- key: WorkflowGen.lic
76
path: WorkflowGen.lic
77
- name: secrets
78
secret:
79
secretName: wfgen-sec
Copied!
In order for it to be scheduled to a Windows node, you would have to add the following to the template's
spec:1
nodeSelector:
2
kubernetes.io/os: windows
3
tolerations:
4
- key: os
5
operator: Equal
6
value: windows
7
effect: NoSchedule
Copied!
This adds a toleration for the taint that you've just added to the node and tells the Kubernetes scheduler to select a Windows node when scheduling the WorkflowGen pods.
You can also simplify this by creating a
RuntimeClass object that holds this information and referencing the runtime class in your Windows deployments:windows-runtimeclass.yaml
1
apiVersion: node.k8s.io/v1beta1
2
kind: RuntimeClass
3
metadata:
4
name: windows-1809
5
handler: 'docker'
6
scheduling:
7
nodeSelector:
8
kubernetes.io/os: 'windows'
9
kubernetes.io/arch: 'amd64'
10
node.kubernetes.io/windows-build: '10.0.17763'
11
tolerations:
12
- key: os
13
operator: Equal
14
value: windows
15
effect: NoSchedule
Copied!
Apply this file:
1
kubectl apply -f windows-runtimeclass.yaml
Copied!
Then, add the following to the template's
spec:1
runtimeClass: windows-1809
Copied!
As you can see, this
RuntimeClass also ensures that the deployment will be on a Windows LTSC 2019 (1809) node.Managing node updates
There are two things that you must consider for update management: the Kubernetes version and the operating system update. For information on upgrading the cluster to a specific Kubernetes version, see Upgrade an Azure Kubernetes Service (AKS) cluster.
Applying security patches and updating operating systems differ for Linux and Windows nodes. To get started with operating system updates, see Apply security and kernel updates to Linux nodes in Azure Kubernetes Service (AKS) for more information. (Don't worry about the name of the article, there is a paragraph about Windows updates in it.)
Automatically scaling node pools
You can use an autoscaler in AKS to automatically scale up the number of nodes in your cluster based on rules to keep up with demands. See Automatically scale a cluster to meet application demands on Azure Kubernetes Service (AKS) for more information. This feature pairs well with the Kubernetes horizontal pod autoscaler. See Horizontal Pod Autoscaler for more information.
You can also use Azure Container Instances to quickly scale up your cluster for a short period of time. See Scaling options for applications in Azure Kubernetes Service (AKS) for more information.
Last modified 1yr ago