Les deployments sont très similaires aux ReplicaSets. Durant les exercices suivants, nous allons déployer nginx et manipuler les fonctionnalités de rolling-update pour le mettre à jour et le faire passer à l'échelle sans interruption de service.

Création du déploiement

• Utiliser le modèle ci-dessous pour créer un déploiement de 2 instances de nginx en version 1.7.9.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: <nombre d'instances>
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:<version de nginx>
        ports:
        - containerPort: 80

• Vérifier le bon fonctionnement.

kubectl describe deployment nginx-deployment
kubectl get pods -l app=nginx

Rolling-update

• Modifier le Deployment créé pour utiliser la valeur 1 comme maxSurge et maxUnavailable

kubectl edit deployment nginx-deployment

• Nous allons maintenant changer la version de nginx dans le template du déploiement, puis afficher les pods tout de suite après

kubectl edit deployment nginx-deployment
# changer spec.template.spec.containers.image (1.7.9 -> 1.8)

kubectl get pod -l app=nginx

Nous devrions voir les pods s'arrêter et être remplacés à tour de rôle. À la fin, tous les pods devraient être basés sur l'image nginx 1.8.

Max surge et max unavailable

Nous allons essayer différentes valeurs de maxSurge et maxUnavailable. Pour ce faire, modifier les valeurs dans le manifeste du déploiement et alterner entre la version 1.7.9 et 1.8 de l'image nginx pour provoquer une mise à jour.

Suivre le statut des déploiements avec la commande suivante.

kubectl rollout status deployment nginx-deployment

Avec replicas=10, essayer les valeurs suivantes :

• maxSurge=25%, maxUnavailable=25%
• maxSurge=0, maxUnavailable=100%
• maxSurge=100%, maxUnavailable=0
• maxSurge=25%, maxUnavailable=50%

Retour arrière

Nous allons provoquer une migration vers une version non fonctionnelle de notre application, puis revenir en arrière.

• Modifier le déploiement, changer la version de l'image nginx vers un tag qui n'existe pas (1.8 -> fail).

kubectl edit deployment nginx-deployment

Le statut du déploiement va rester bloqué, car l'image ne peut pas être récupérée.

kubectl rollout status deployment nginx-deployment

Pour résoudre cette situation, nous pouvons revenir en arrière en une commande.

kubectl rollout undo deployment nginx-deployment

Il est aussi possible de consulter l'historique des changements pour revenir à une version spécifique.

kubectl rollout history deployment nginx-deployment
kubectl rollout undo deployment nginx-deployment --to-revision <numéro de révision>