Ku­ber­netes de­ploy­ment : tout savoir sur les dé­ploie­ments Ku­ber­netes

La création d’un dé­ploie­ment Ku­ber­netes réussi est es­sen­tielle pour une gestion efficace des ap­pli­ca­tions de con­te­neurs. Dans ce tutoriel, vous aurez un aperçu des étapes de base et des meil­leures pratiques pour concevoir un dé­ploie­ment robuste dans un en­vi­ron­ne­ment Ku­ber­netes.

Ku­ber­netes de­ploy­ment : dé­fi­ni­tion

Un dé­ploie­ment Ku­ber­netes (en anglais Ku­ber­netes de­ploy­ment) est un concept essentiel au sein de la pla­te­forme Ku­ber­netes, qui simplifie le dé­ploie­ment et la gestion des ap­pli­ca­tions dans les con­te­neurs. Ce mécanisme de contrôle agit comme un in­ter­mé­diaire entre la con­fi­gu­ra­tion et son exécution effective dans le cluster Ku­ber­netes. Vous dé­fi­nis­sez l’état souhaité de vos ap­pli­ca­tions, y compris les détails de la ré­pli­ca­tion, les images des con­te­neurs et les pa­ra­mètres de con­fi­gu­ra­tion.

Le dé­ploie­ment Ku­ber­netes se charge ensuite du pro­vi­sion­ne­ment au­to­ma­tisé, organise les con­te­neurs en pods Ku­ber­netes et les distribue aux res­sources dis­po­nibles dans le cluster. De plus, il permet les rolling updates (mises à jour continues) afin d’effectuer des mises à jour par étapes et de minimiser les temps d’arrêt. Les fonctions de mise à l’échelle au­to­ma­tique (au­tos­ca­ling) ga­ran­tis­sent un ajus­te­ment dynamique du nombre d’instances en cours d’exécution en fonction de la charge actuelle.

La création d’un dé­ploie­ment Ku­ber­netes peut se baser sur deux méthodes :

• La méthode im­pé­ra­tive
• La méthode dé­cla­ra­tive

Ku­ber­netes de­ploy­ment : créer un dé­ploie­ment avec la méthode im­pé­ra­tive

Avec la méthode im­pé­ra­tive, vous spécifiez des commandes afin d’effectuer di­rec­te­ment les actions sou­hai­tées. Il peut s’agir de créer des res­sources, comme des pods et des services, ou de mettre à jour des con­fi­gu­ra­tions. La méthode im­pé­ra­tive est adaptée aux besoins si­tua­tion­nels ou ex­pé­ri­men­taux.

La commande suivante crée un dé­ploie­ment Ku­ber­netes nommé nginx-deployment et le configure pour déployer un serveur Web Nginx dans un conteneur à partir de l’image of­fi­cielle de Nginx sur le port 80.

$ kubectl create deployment nginx-deployment –image=nginx --port=80

Même si l’approche im­pé­ra­tive est rapide à mettre en œuvre, elle présente quelques in­con­vé­nients. Les étapes de la méthode im­pé­ra­tive sont di­rec­te­ment liées à la situation actuelle, ce qui peut rendre les actions dif­fi­ciles à répéter. Cela signifie que la réexé­cu­tion de la même commande peut ne pas toujours produire le même état, en par­ti­cu­lier si la situation de départ a changé.

Ku­ber­netes de­ploy­ment : créer un dé­ploie­ment avec la méthode dé­cla­ra­tive

Con­trai­re­ment à la méthode im­pé­ra­tive, la méthode dé­cla­ra­tive adopte une approche plus abstraite. Vous dé­fi­nis­sez l’état souhaité de l’ap­pli­ca­tion dans un fichier de con­fi­gu­ra­tion, et Ku­ber­netes s’assure que le cluster cor­res­pond à cet état. Dans ce cas, vous décrivez ce qui doit être réalisé, et Ku­ber­netes se charge de l’im­plé­men­ta­tion et du maintien de cet état.

Étape 1 : créer un fichier de con­fi­gu­ra­tion YAML

Tout d’abord, nous ouvrons un éditeur de texte et créons le fichier YAML nginx-deployment.yaml afin de définir la con­fi­gu­ra­tion pour le dé­ploie­ment de Ku­ber­netes :

apiVersion: apps/v1
kind: Deployment
metadata:
    name: nginx-deployment
spec:
    replicas: 3
    selector:
        matchLabels:
            app: nginx
    template:
        metadata:
            labels:
                app: nginx
        spec:
            containers:
            - name: nginx-container
                image: nginx
                ports:
                - containerPort: 80

Dans la section spec, nous dé­fi­nis­sons la con­fi­gu­ra­tion souhaitée. Avec replicas: 3, nous indiquons que le dé­ploie­ment doit créer trois ré­pli­ca­tions (pods) de l’ap­pli­ca­tion. La section selector définit comment les pods sont sé­lec­tion­nés, app=nginx servant ici de critère de sélection. Le template est le modèle pour les pods à créer, y compris les éti­quettes. A l’intérieur de containers, on configure le conteneur nginx-container qui utilise l’image de Nginx et écoute sur le port 80.

Étape 2 : appliquer la con­fi­gu­ra­tion

Exécutez la commande suivante sur la ligne de commande pour appliquer la con­fi­gu­ra­tion au cluster :

kubectl apply -f nginx-deployment.yaml

L’option -f indique le chemin d’accès au fichier YAML ou JSON qui contient la con­fi­gu­ra­tion pour les res­sources Ku­ber­netes.

Étape 3 : vérifier le statut du dé­ploie­ment

Cette commande permet de vérifier le succès de la création du dé­ploie­ment et le statut des pods.

kubectl get deployments nginx-deployment

La sortie nous indique :

NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment       3/3     3            3           2m

• READY : reflète le nombre de pods ac­tuel­le­ment en cours d’exécution par rapport au nombre souhaité.
• UP-TO-DATE : indique le nombre de pods mis à jour avec la dernière con­fi­gu­ra­tion.
• AVAILABLE : liste le nombre de pods qui sont dis­po­nibles et qui peuvent accepter des demandes.
• AGE : précise depuis combien de temps le dé­ploie­ment est en cours.

Étape 4 : afficher des in­for­ma­tions sup­plé­men­taires

La commande suivante permet d’obtenir des in­for­ma­tions dé­tail­lées sur votre dé­ploie­ment Ku­ber­netes, les stra­té­gies utilisées, les ré­pli­ca­tions actuelles et sou­hai­tées ainsi que les éti­quettes des sé­lec­teurs.

kubectl describe deployment nginx-deployment

La sortie est la suivante :

Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Thu, 22 Feb 2024 12:34:56 +0000
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge

La stratégie de mise à jour est con­fi­gu­rée comme rolling update, avec un maximum de 25 % d’in­dis­po­ni­bi­lité et une aug­men­ta­tion jusqu’à 25 % de pods sup­plé­men­taires pendant une mise à jour.

Étape 5 : mise à l’échelle du dé­ploie­ment

Pour ajuster le nombre de pods dans un dé­ploie­ment Ku­ber­netes, utilisez la commande kubectl scale.

kubectl scale deployment nginx-deployment --replicas=2

Après l’exécution de cette commande, Ku­ber­netes mettra à jour le dé­ploie­ment et s’assurera que le nombre souhaité de ré­pli­ca­tions est présent. Dans notre exemple, nous réduisons le nombre de pods en cours d’exécution à 2.

Ku­ber­netes de­ploy­ment : les dif­fé­rentes stra­té­gies

Les stra­té­gies de dé­ploie­ment dans Ku­ber­netes dé­fi­nis­sent la manière dont les mo­di­fi­ca­tions d’une ap­pli­ca­tion sont im­plé­men­tées dans un cluster.

• Rolling de­ploy­ment (standard) : la stratégie rolling est la méthode standard pour les dé­ploie­ments dans Ku­ber­netes. Dans ce cas, les nouveaux pods sont déployés pro­gres­si­ve­ment, tandis que les anciens pods sont supprimés au fur et à mesure. Cela permet une dis­po­ni­bi­lité continue pendant le processus de mise à jour.
• Recreate de­ploy­ment : avec cette stratégie, tous les pods existants sont d’abord supprimés, puis les pods mis à jour sont démarrés. Cette méthode peut entraîner une in­ter­rup­tion tem­po­raire des services, car aucun pod n’est dis­po­nible pendant le processus de re­créa­tion.
• Blue/green de­ploy­ment : ici, deux ensembles de pods (blue et green) sont créés, l’un re­pré­sen­tant la version actuelle de l’ap­pli­ca­tion et l’autre la nouvelle version. En at­tri­buant des éti­quettes spé­ci­fiques à ces pods, le trafic peut être redirigé de manière trans­pa­rente entre les deux versions. Cela permet de passer ra­pi­de­ment d’une version à l’autre et d’effectuer fa­ci­le­ment des rollbacks (retours en arrière).

Ku­ber­netes De­ploy­ment Rollback

Si une erreur se produit dans la dernière version de votre ap­pli­ca­tion, il est crucial d’effectuer un rollback le plus ra­pi­de­ment possible. Dans Ku­ber­netes, vous pouvez initier le processus de rollback en con­trô­lant l’his­to­rique des révisions de votre dé­ploie­ment et en revenant à une version pré­cé­dente si né­ces­saire.

Contrôler l’his­to­rique des révisions

Pour afficher l’his­to­rique des révisions de votre dé­ploie­ment, utilisez la commande suivante :

kubectl rollout history deployment/nginx-deployment

Retour à l’état précédent

Cette commande effectue un retour à la révision pré­cé­dente, con­si­dé­rée comme stable :

kubectl rollout undo deployment/nginx-deployment

Retourner à une version spé­ci­fique

Si vous souhaitez revenir à une révision spé­ci­fique, spécifiez la commande suivante et le numéro de révision souhaité :

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