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, consultez l'article Microsoft Déployer 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 Microsoft Entra ID (anciennement Azure Active Directory) pour authentifier et autoriser les utilisateurs du cluster. Consultez l'article Microsoft Intégrer Microsoft Entra ID à Azure Kubernetes Service (AKS) à l’aide d’Azure CLI pour plus d'informations.

Il n'est possible d'intégrer Microsoft Entra ID 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 :

kubectl taint nodes "<NODE_NAME>" os=windows:NoSchedule

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 :

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).

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, consultez 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 titre 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. Consultez l'article Microsoft Utilisation du programme de mise à l’échelle automatique de cluster d’Azure Kubernetes Service (AKS) pour plus d'informations. Cette fonctionnalité se marie bien avec l'autoscaler horizontal de pod Kubernetes. Consultez l'article Kubernetes Horizontal Pod Autoscaling pour plus d'informations.

Vous pouvez également utiliser des instances de conteneur Azure pour faire évoluer rapidement votre cluster pendant une courte période. Consultez l'article Microsoft Options de mise à l’échelle des applications dans AKS (Azure Kubernetes Service) pour plus d'informations.