Comment configurer Kubernetes pour la mise à jour progressive

Présentation

Les mises à jour continues sont une partie importante du cycle de vie d'une application moderne, les utilisateurs s'attendant constamment à de nouvelles fonctionnalités et à aucun temps d'arrêt. Alors que Kubernetes utilisait des contrôleurs de réplication pour activer cette fonctionnalité dans le passé, les versions plus récentes recommandent d'utiliser les déploiements.

Ce didacticiel vous montre comment effectuer des mises à jour propagées à l'aide de déploiements Kubernetes. Cette méthode vous permet de mettre à jour rapidement vos applications et d'obtenir un temps d'arrêt nul tout en garantissant la prise en charge de la restauration.

Prérequis

• Un cluster Kubernetes
• Accès à une fenêtre de terminal
• L'outil de ligne de commande kubectl

Activer les mises à jour continues

Les déploiements Kubernetes agissent comme des wrappers autour des ReplicaSets, qui sont des contrôleurs Kubernetes chargés de la gestion des pods. Les déploiements fournissent des fonctionnalités supplémentaires aux ReplicaSets - ils effectuent des vérifications de l'état, des mises à jour propagées et des restaurations.

1. Tout d'abord, créez un yaml fichier avec les spécifications de déploiement à l'aide d'un éditeur de texte, tel que Nano :

nano nginx-test.yaml

L'exemple de fichier ci-dessous contient les déclarations de base nécessaires à un déploiement Kubernetes :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:

    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

        ports:
        - containerPort: 80

2. Enregistrez et quittez le fichier.

3. Ensuite, créez le déploiement à l'aide de kubectl create commande et le yaml fichier que vous venez de créer :

kubectl create -f nginx-test.yaml

4. Vérifiez le déploiement :

kubectl get deployment

Le résultat doit confirmer que le déploiement est prêt :

4. Ensuite, vérifiez les ReplicaSets en exécutant la commande :

kubectl get rs

L'exemple de fichier spécifiait quatre répliques, qui s'affichent toutes comme prêtes :

5. Enfin, vérifiez si les pods sont activés :

kubectl get pod

Le résultat indique que les pods sont prêts et en cours d'exécution :

Garantir l'absence de temps d'arrêt

Pour configurer les mises à jour propagées sans temps d'arrêt, vous devez spécifier la stratégie de mise à jour.

1. Ajoutez la déclaration suivante au déploiement yaml fichier sous la spec catégorie :

minReadySeconds: 5
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1

• minReadySeconds indique à Kubernetes combien de temps il doit attendre avant de créer le prochain pod. Cette propriété garantit que tous les pods d'application sont à l'état prêt pendant la mise à jour.
• maxSurge spécifie le nombre maximal (ou le pourcentage) de pods au-dessus du nombre spécifié de répliques. Dans l'exemple ci-dessus, le nombre maximal de pods sera de 5 depuis 4 les répliques sont spécifiées dans le yaml fichier.
• maxUnavailable déclare le nombre maximum (ou pourcentage) de pods indisponibles lors de la mise à jour. Si maxSurge est défini sur 0 , ce champ ne peut pas être 0 .

Ajout de la spécification ci-dessus au déploiement yaml est suffisant pour commencer à effectuer des mises à jour continues de Kubernetes. Cependant, cela ne garantit pas un temps d'arrêt nul. Kubernetes ne peut pas dire quand un nouveau pod est prêt - il élimine l'ancien pod dès que le nouveau est créé. Ce problème entraîne un temps d'arrêt jusqu'à ce que le nouveau pod soit en mesure d'accepter les requêtes.

Pour résoudre ce problème, Kubernetes propose le concept de sondes de préparation . Les sondes vérifient l'état des pods et autorisent les mises à jour continues uniquement lorsque tous les conteneurs d'un pod sont prêts. Les pods sont considérés comme prêts lorsque la vérification de l'état de préparation réussit et après l'heure spécifiée dans minReadySeconds est passé.

2. Pour configurer les sondes de préparation, ajoutez les lignes suivantes au spec.template.spec catégorie dans le fichier de déploiement :

readinessProbe:
  httpGet:
    path: /
    port: 8080
    initialDelaySeconds: 5
    periodSeconds: 5
    successThreshold: 1

• initialDelaySeconds spécifie combien de temps la sonde doit attendre pour démarrer après le démarrage du conteneur.
• periodSeconds est le temps entre deux sondes. La valeur par défaut est 10 secondes, tandis que la valeur minimale est 1 seconde.
• successThreshold est le nombre minimum de tentatives réussies consécutives après une tentative échouée pour que l'ensemble du processus soit considéré comme réussi. Les valeurs par défaut et minimale sont toutes deux 1 .

L'ensemble du fichier de déploiement correctement configuré pour les mises à jour progressives devrait ressembler à ceci :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:

    matchLabels:
      app: nginx
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.0

        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /
            port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
            successThreshold: 1
        

3. Enregistrez le fichier et quittez.

4. Ensuite, utilisez kubectl apply pour appliquer les modifications :

kubectl apply -f nginx-text.yaml --record

Le --record flag servira à quelque chose dans le processus de restauration.

La sortie montre que le déploiement a été configuré avec succès.

Effectuer une mise à jour continue

Il existe trois façons d'effectuer des mises à jour continues.

Par exemple, pour changer l'image de l'application :

Option 1 :Vous pouvez utiliser kubectl set pour effectuer l'action sur la ligne de commande :

kubectl set image deployment nginx-deployment nginx=nginx:1.14.2 --record

Option 2 :Vous pouvez également modifier la version de l'image dans spec.templates.spec.containers section du yaml dossier. Ensuite, utilisez kubectl replace pour effectuer la mise à jour :

kubectl replace -f nginx-test.yaml

Option 3 :Vous pouvez également utiliser kubectl edit pour modifier directement le déploiement :

kubectl edit deployment nginx-deployment --record

Effectuez les modifications nécessaires dans l'éditeur qui s'ouvre :

Les modifications sont appliquées lorsque vous fermez l'éditeur.

Vérifier l'état du déploiement

Vérifiez l'état de déploiement du déploiement à l'aide de la syntaxe suivante :

kubectl rollout status deployment nginx-deployment

Le résultat confirme le déploiement réussi :

Suspendre et reprendre la mise à jour continue

Suspendez et reprenez les mises à jour progressives avec le kubectl rollout correspondant commandes.

Pour suspendre la mise à jour, exécutez :

kubectl rollout pause deployment nginx-deployment

Pour reprendre la mise à jour, exécutez :

kubectl rollout resume deployment nginx-deployment

Planifier les modules pour le déploiement

Utilisez les propriétés d'affinité et d'anti-affinité pour contrôler sur quels nœuds Kubernetes planifie des pods spécifiques dans votre déploiement.

Affinité de pod

Il existe deux types d'affinité actuellement disponible dans Kubernetes :

• requiredDuringSchedulingIgnoredDuringExecution indique à Kubernetes de n'exécuter des pods que sur des nœuds qui répondent à certains critères, tels qu'un type de processeur spécifique.
• preferredDuringSchedulingIgnoredDuringExecution permet aux pods d'être exécutés ailleurs, si et seulement si aucun nœud ne répond aux critères donnés.

Ces propriétés sont listées dans la PodSpec dossier. Par exemple, un pod peut être spécifié comme suit :

apiVersion: v1
kind: Pod
metadata:
  name: affinity-test
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/test-name
            operator: In
            values:
            - test1
            - test2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: example-node-label-key
            operator: In
            values:
            - example-node-label-value
  containers:
  - name: affinity-test
    image: k8s.gcr.io/pause:2.0

Le fichier ci-dessus indique à Kubernetes d'exécuter le pod uniquement sur un nœud avec une étiquette dont la clé est kubernetes.io/test-name et dont la valeur est soit test1 ou test2 . De plus, Kubernetes privilégiera les nœuds dont la clé est example-node-label-key , avec le example-node-label-value valeur.

Anti-affinité de pod

Anti-affinité de pod est utile si vous ne souhaitez pas que tous les pods s'exécutent sur le même nœud. Il fonctionne de la même manière que l'affinité, avec les deux mêmes types disponibles - requiredDuringSchedulingIgnoredDuringExecution et preferredDuringSchedulingIgnoredDuringExecution .

L'exemple suivant spécifie une règle d'anti-affinité qui indique à Kubernetes d'éviter de préférence de programmer les pods d'application "test" sur les nœuds qui ont déjà les pods "test" :

podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 100
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values: 
          - test
      topologyKey: Kubernetes.io/hostname

Annuler les modifications

Si quelque chose ne va pas avec le processus de mise à jour, vous pouvez annuler les modifications et revenir à une version précédente de l'application. Pour ce faire, utilisez le kubectl rollout suivant commande :

kubectl rollout history deployment nginx-deployment

La sortie répertorie les révisions disponibles, créées en ajoutant le --record drapeau lors de l'exécution d'une mise à jour :

Choisissez la révision souhaitée et saisissez la commande suivante pour annuler les modifications :

kubectl rollout undo deployment nginx-deployment --to-revision=1

La commande ci-dessus revient à la révision 1 et produit le résultat suivant :