Guide et instructions

1. Objectifs

  • Déployer des Pods
  • Répliquer ses Pods avec les « ReplicaSet »
  • Assurer le fonctionnement des Pods avec « Deployment »

2. Introduction

Créez un dossier « lab03 » et basculez dans ce dossier

mkdir lab03
cd lab03

3. ReplicaSet & deployment

3.1 Création et manipulation

Dans cet exercice on va créer un déploiement pour une application nommée « kuard-app » qui renvois les informations sur les pods et on va détailler les différentes sections d’un manifeste. Créez un fichier kuard-deployment.yaml avec le contenu suivant :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kuard
  labels:
    <labels>

Ce manifeste décrit un objet déploiement vide. Ajoutez les labels « app: kuard » « run: kuard » et « env: dev » à cet objet « Deployment » Pour le moment notre déploiement n’est pas défini car il n’a pas de section « spec: » Ajoutez la section « spec: », qui doit être à la même hauteur que « kind: » et « metadata: »

spec:
  template:
    metadata:
      labels:
        run: kuard
    spec:
      containers:
      - name: kuard
        image: gcr.io/kuar-demo/kuard-amd64:blue
        ports:
          - containerPort: 8080

A ce stade nous avons décrit les pods de notre déploiement avec leurs labels (un label commun à tous les objets de l’app, un label plus spécifique à la sous-partie de l’app). Maintenant on va ajouter quelques options pour paramétrer notre déploiement (à la hauteur de template:) avec le contenu suivant:

selector:
  matchLabels:
    run: kuard

Cette section indique les labels à utiliser pour repérer les pods de ce déploiement parmi les autres si on a plusieurs. Lancez le déploiement avec la commande suivante:

kubectl apply -f kuard-deployment.yaml

Affichez les déploiements avec:

kubectl get deploy -o wide

Ci-dessous la commande à utiliser pour consulter l’état du déploiement

kubectl describe deployment kuard

Cette commande renvoie de nombreuses informations parmi lesquelles:

  • Le nom et l’espace de noms du déploiement,
  • La date de création,
  • Les labels et annotations,
  • Le mécanisme de sélecteur,
  • Le nombre de réplicats de l’application (le nombre de pods),
  • Le mécanisme de mise à jour (ici RollingUpdate),
  • Le template permettant la création des pods associés,
  • L’état du déploiement (conditions),
  • Le réplicat actuel ainsi que les anciens réplicats,
  • Les événements autour de la création de ce déploiement (ici le passage à un réplicat sur le déploiement).

Affichez le « selector » associé au template

kubectl get deployments kuard -o jsonpath --template {.spec.selector.matchLabels}

Ajoutez un modèle de « ReplicaSet » pour notre déploiement. Editez le manifeste kuard-deployment.yaml et ajouter la section « replicatSet »:

replicas: 2

La section doit être au même niveau que « template » Appliquer le déploiement avec la commande suivante:

kubectl apply -f kuard-deployment.yaml

Listez également les « pods » afin de vérifier que les conteneurs tournent en lançant la commande suivante:

kubectl get pods

Listez les « replicatSet »

kubectl get rs -o wide

On constate que le nom du réplicat est constitué d’une partie fixe (reprenant le déploiement duquel il descend) suivie d’une partie aléatoire. Il est possible de décrire l’objet « ReplicaSet » avec la commande suivante :

kubectl describe rs [REPLICANAME]

Les informations sont sensiblement les mêmes que pour un objet « Deployment » au niveau de l’en-tête. En revanche, la partie Events est plus verbeuse, elle décrit toutes les opérations qui ont été réalisées sur les pods du déploiement de l’application kuard. Le champ Events peut être une source d’informations intéressante à consulter en cas d’anomalies lors d’un déploiement. Changez le nombre de réplicats du « Deployment »:

kubectl scale deployment/kuard --replicas=5

Vérifier le nombre de pod. Cette fois ci on va afficher que les noms des « Pods »

kubectl get pods -o custom-columns=NAME:.metadata.name,NODE:.spec.no --no-headers | sort -b -k 2

Appliquez à nouveau le fichier kuard-deployment.yaml, que se passe-t-il ?

Lister les réplicas

kubectl get replicasets --selector=run=kuard

Mettez le nombre de réplicas à 1 en passant par l’objet « replicaSet » directement

kubectl scale replicasets [REPLICA NAME] --replicas=1

Lister les réplicas à nouveau, que se passe-t-il ? Maintenant on va voir la gestion des pod, avec cette commande on va confirmer que les pod sont gérés par le « ReplicaSet »

kubectl get pod [PODNAME] -o json | jq ".metadata.ownerReferences[]"

Utilisez deux terminaux, dans le premier on va suivre les pod avec la commande:

kubectl get pods --watch

Dans le deuxième listez les pod ensuite supprimer un pod de l’application « kuard »

kubectl get pods --selector=run=kuard
kubectl delete pod [PODNAME]

Que se passe-t-il ?

Maintenant on peut accéder à notre application. La stack réseau du pod est injoignable depuis l’extérieur du cluster Kubernetes. Il est néanmoins possible de faire suivre un port d’un pod sur la machine de l’utilisateur à l’aide de l’instruction « port-forward » de la commande kubectl. Pour faire fonctionner, cette instruction on a besoin des éléments suivants :

  • Le nom du déploiement.
  • Une liste de ports à faire suivre. Les ports peuvent être sous la forme d’un numéro simple ou d’un doublon sous la forme « port-source:port-destination ».
kubectl port-forward --address 0.0.0.0 deployments/kuard 8081:8080

Ensuite connectez-vous sur http://[LABIP]:8081 Supprimez le « deployment » avec l’une de ces commandes suivantes:

kubectl delete deployment --all
kubectl delete -f kuard-deployment.yaml

3.2 Challenge

Réalisez le déploiement précédent « kuard » en mode impératif

  • Comment récupérer la structure yaml de l’objet « deployment » kuard ?
  • Comment éditer notre objet « deployment » kuard ?
  • Supprimez le « deployment »

4. Mécanisme des stratégies

4.1 rolling-update

Par défaut la stratégie de déploiement est le « rolling-update » mais vous pouvez également utiliser « recreate » qui supprime tous les anciens Pod pour en créer de nouveaux - ce qui induit forcément un « downtime ». Dans cet exercice on va optez pour « rolling-update ». Vous pouvez configurer le comportement de celui-ci par rapport au nombre de réplicas voulu.

  • « maxSurge » permet d’indiquer (en pourcentage ou en absolu) combien de Pod il peut créer en plus du nombre de replica actuellement configurer
  • « maxUnavailable » permet d’indiquer (en pourcentage ou en absolu) combien de Pod peuvent être « non disponible » pendant la mise à jour, toujours en fonction du nombre de replica configuré

On va créer un déploiement en se basant sur le manifeste kuard-deployment.yaml suivant:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kuard
  labels:
    app: kuard
    run: kuard
    env: dev 
spec:
  selector:
    matchLabels:
      run: kuard
  replicas: 3
  template:
    metadata:
      labels:
        run: kuard
    spec:
      containers:
      - name: kuard
        image: gcr.io/kuar-demo/kuard-amd64:blue
        ports:
          - containerPort: 8080

Juste avant la ligne « replicas: » et à la même hauteur ajoutez la section suivante:

strategy:
  rollingUpdate:
    maxSurge: 25%
    maxUnavailable: 25%
  type: RollingUpdate

Lancez le déploiement

kubectl apply -f kuard-deployment.yaml

Maintenant on va procéder à une mise à jour de l’image de container. Editez le manifeste kuard-deployment.yaml et modifiez la section « image » comme suit:

image: gcr.io/kuar-demo/kuard-amd64:green
imagePullPolicy: Always

Ajoutez une « annotations » dans la section « template » au même niveau que labels afin d’enregistrer des informations sur la mise à jour.

spec:
  ...
  template:
    metadata:
      labels:
        ...
      annotations:
        kubernetes.io/change-cause: "Update to green kuard"
...

Lancez trois terminaux shells différents. Dans le premier, lancez

while true; do kubectl get pod; sleep 1; clear; done

Dans le deuxième lancez la redirection des ports

kubectl port-forward --address 0.0.0.0 deployments/kuard 8081:8080

Connectez-vous sur http://[LABIP]:8081 Ensuite dans le troisième terminal appliquer la mise à jour et observez les changements dans le terminal 1 et dans l’interface web http://[LABIP]:8081

kubectl apply -f kuard-deployment.yaml

Que constatez-vous ? Vous pouvez avoir l’état de cette mise à jour avec la commande suivante:

kubectl rollout status deployments kuard

Listez les réplicas

kubectl get replicasets -o wide

Cette commande va nous confirmer qu’un autre réplica a été créé. L’ancien et le nouveau « ReplicaSets » sont conservés au cas où vous voulez revenir en arrière. Finalement vous considérer que cette version à base de la nouvelle image ne vous plait pas et vous voulez revenir en arrière. Utiliser la commande « kubectl rollout » pour revenir à la version précédente.

kubectl rollout undo deployments kuard

Vous pouvez voir l’historique de ces mises à jour avec la commande:

kubectl rollout history deploy kuard

Supprimez le « deployment »

kubectl delete deployment --all

4.2 Challenge

  • Modifiez le manifeste « kuard-deployment.yaml » avec la stratégie « Recreate »
  • Déployer ce manifeste
  • Appliquer une mise à jour vers l’image « gcr.io/kuar-demo/kuard-amd64:green » en ligne de commande
  • Revenir en arrière juste en éditant l’objet « deployment » et effectuez la modification de l’image.
  • Supprimez le « deployment »