Azure Kubernetes Service
Cette section présente quelques indications sur la configuration et la gestion d'un cluster (groupement) Kubernetes adapté à WorkflowGen dans Azure.
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.
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.
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 :
kubectl taint nodes "<NODE_NAME>" os=windows:NoSchedule
Remplacez
<NODE_NAME> par le nom du nœud 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 :
apiVersion: apps/v1
kind: Deployment
metadata:
name: wfgen-webapps
spec:
replicas: 3
strategy:
type: Recreate
selector:
matchLabels:
app.kubernetes.io/name: workflowgen
app.kubernetes.io/component: webapps
template:
metadata:
labels:
app.kubernetes.io/name: workflowgen
app.kubernetes.io/component: webapps
spec:
containers:
- name: wfgen
image: advantys/workflowgen:7.18.3-win-ltsc2019
imagePullPolicy: Always
resources:
requests:
memory: "2Gi"
cpu: "1"
limits:
memory: "2Gi"
cpu: "1"
ports:
- name: http
containerPort: 80
protocol: TCP
envFrom:
- configMapRef:
name: wfgen-config
env:
- name: WFGEN_START_SERVICE
value: webapps
livenessProbe:
periodSeconds: 30
timeoutSeconds: 5
initialDelaySeconds: 60
exec:
command:
- powershell
- C:\healthcheck.ps1
livenessProbe:
timeoutSeconds: 5
initialDelaySeconds: 60
exec:
command:
- powershell
- -Command
- if (Test-Path "C:\iislog\W3SVC\*log") { return 0 } else { return 1 }
volumeMounts:
- mountPath: C:\wfgen\data
name: wfgdata
- mountPath: C:\wfgen\licenses
readOnly: true
name: licenses
- mountPath: C:\secrets
readOnly: true
name: secrets
volumes:
- name: wfgdata
persistentVolumeClaim:
claimName: wfgdata-pvc
- name: licenses
secret:
secretName: wfgen-license-secret
items:
# The following must match the name of the license item in
# the license secret, e.g. the name of the license file
- key: WorkflowGen.lic
path: WorkflowGen.lic
- name: secrets
secret:
secretName: wfgen-sec
Pour qu'il soit ordonnancé sur un nœud Windows, vous devez ajouter ce qui suit au
spec du template :nodeSelector:
kubernetes.io/os: windows
tolerations:
- key: os
operator: Equal
value: windows
effect: NoSchedule
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
apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
name: windows-1809
handler: 'docker'
scheduling:
nodeSelector:
kubernetes.io/os: 'windows'
kubernetes.io/arch: 'amd64'
node.kubernetes.io/windows-build: '10.0.17763'
tolerations:
- key: os
operator: Equal
value: windows
effect: NoSchedule
Appliquez ce fichier :
kubectl apply -f windows-runtimeclass.yaml
Ensuite, ajoutez ce qui suit à la spécification du pod :
runtimeClass: windows-1809
Comme vous pouvez le voir, cet objet
RuntimeClass garantit également que le déploiement se fera sur un nœud Windows LTSC 2019 (1809).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.)
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 2yr ago