7.22
Azure Kubernetes Service
Aperçu
Cette section présente quelques indications sur la configuration et la gestion d'un cluster (groupement) Kubernetes adapté à WorkflowGen dans Azure.
Création d'un nouveau cluster
Pour créer un nouveau cluster qui supporte les charges de travail Linux et Windows, voir l'article Microsoft Créer un conteneur Windows Server sur un cluster Azure Kubernetes Service (AKS) à l’aide d’Azure CLI, qui comprend des instructions étape par étape sur la façon de créer le cluster. Suivez toutes les instructions, y compris la création d'un pool de nœuds Windows. À la fin, vous devez avoir au moins deux nœuds : un nœud Linux et un nœud Windows.
Vous pouvez utiliser Azure Active Directory pour authentifier et autoriser les utilisateurs du cluster. Consultez l'article Microsoft Intégrer Azure Active Directory avec Azure Kubernetes Service à l’aide d’Azure AD pour plus d'informations.
Il n'est possible d'intégrer Azure Active Directory qu'à la création d'un nouveau cluster.
Gestion des nœuds Windows et Linux
Par défaut, AKS ne restreint pas d'autres nœuds Windows d'empêcher le déploiement de Linux sur eux. Il est recommandé d'utiliser des taches (« taints ») et tolérances pour éviter les problèmes d'ordonnancement de déploiement Linux sur les nœuds Windows (voir l'article Kubernetes Taints and Tolerations pour plus d'informations). Voici un exemple de la façon dont vous pouvez utiliser les taches et les tolérances pour gérer les déploiements hybrides.
Appliquez des taches à tous les nœuds Windows
L'application de taches à tous les nœuds Windows empêchera tout déploiement sur les nœuds Windows, sauf lorsque le déploiement a la tolérance requise. Par conséquent, pour de nombreux cartes (« charts ») Linux Helm qui n'ont pas de sélecteur de nœud, les déploiements seront automatiquement ordonnancés sur les nœuds Linux. Google Kubernetes Engine le fait par défaut. Exécutez la commande suivante pour appliquer une tache à un nœud Windows :
1
kubectl taint nodes "<NODE_NAME>" os=windows:NoSchedule
Copied!
Remplacez
<NODE_NAME> par le nom du nœud Windows.Ajoutez des tolérances aux déploiements Windows
Pour pouvoir déployer des modules Windows sur des nœuds Windows, vous devez utiliser une combinaison de tolérances et de sélecteurs de nœuds dans votre spécification de déploiement. Par exemple, considérez ce déploiement WorkflowGen :
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!
Pour qu'il soit ordonnancé sur un nœud Windows, vous devez ajouter ce qui suit au
spec du template :1
nodeSelector:
2
kubernetes.io/os: windows
3
tolerations:
4
- key: os
5
operator: Equal
6
value: windows
7
effect: NoSchedule
Copied!
Cela ajoute une tolérance à la tache que vous venez d'ajouter au nœud et indique à l'ordonnanceur Kubernetes de sélectionner un nœud Windows lors de l'ordonnancement des pods (capsules) WorkflowGen.
Vous pouvez également simplifier cela en créant un objet
RuntimeClass qui contient ces informations et en référençant la classe d'exécution dans vos déploiements Windows :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!
Appliquez ce fichier :
1
kubectl apply -f windows-runtimeclass.yaml
Copied!
Ensuite, ajoutez ce qui suit à la spécification du pod :
1
runtimeClass: windows-1809
Copied!
Comme vous pouvez le voir, cet objet
RuntimeClass garantit également que le déploiement se fera sur un nœud Windows LTSC 2019 (1809).Gestion des mises à jour des nœuds
Il y a deux choses que vous devez considérer pour la gestion des mises à jour : la version de Kubernetes et la mise à jour du système d'exploitation. Pour plus d'informations sur la mise à jour du cluster vers une version Kubernetes spécifique, voir l'article Microsoft Appliquer des mises à jour de sécurité et du noyau à des nœuds Linux dans Azure Kubernetes Service (AKS). (Ne vous inquiétez pas du nom de l'article, il contient un paragraphe sur les mises à jour Windows.)
Mise à l'échelle automatique des pools de nœuds
Vous pouvez utiliser un « autoscaler » dans AKS pour mettre à l'échelle automatiquement le nombre de nœuds dans votre cluster en fonction des règles pour répondre aux demandes. Voir l'article Microsoft Mise à l’échelle automatique d’un cluster pour répondre aux demandes applicatives d’Azure Kubernetes Service (AKS) pour plus d'informations. Cette fonctionnalité se marie bien avec l'autoscaler horizontal de pod Kubernetes. Voir l'article Kubernetes Horizontal Pod Autoscaler pour plus d'informations.
Vous pouvez également utiliser des instances de conteneur Azure pour faire évoluer rapidement votre cluster pendant une courte période. Voir l'article Microsoft Options de mise à l’échelle des applications dans AKS (Azure Kubernetes Service) pour plus d'informations.
Last modified 1yr ago