Objectifs du chapitre et prérequis

Le chapitre précédent a constitué une introduction à l’utilisation de Kubernetes avec notamment le recours au dashboard pour le déploiement d’une application.

Ce chapitre va reprendre cet exercice. La différence se fera sur le mode opératoire puisque les opérations seront réalisées en ligne de commande.

Gestion par kubectl d’une application

1. Suppression d’un déploiement

Durant le précédent chapitre, l’application Mailpit a été déployée à l’aide du dashboard. Même si vous ne l’avez pas fait, vous pouvez néanmoins suivre les instructions qui suivent.

Premier point, récupérer la liste des déploiements présents dans le serveur. Pour cela, il faut lancer la commande kubectl suivie du mot-clé get avec le type d’objet deployment. Ci-dessous la commande correspondante :

$ kubectl get deployment

Ci-dessous le résultat renvoyé :

NAME      READY   UP-TO-DATE   AVAILABLE   AGE 
mailpit   1/1     1            1           8d

La suppression du déploiement se fait à l’aide de la commande kubectl suivie des éléments suivants :

le mot-clé delete ;
le type d’objet à supprimer (deployment) ;
le nom de l’objet à supprimer (mailpit).

Ci-dessous la commande à lancer :

$ kubectl delete deployment mailpit

Ci-dessous le résultat renvoyé par cette commande :

deployments.apps "mailpit" deleted

La consultation de la liste des pods renverra alors le contenu suivant :

NAME                       READY   STATUS        RESTARTS   AGE 
mailpit-69bd8f74cb-kl9p5   1/1     Terminating   2          8d

Au bout de quelques instants, la commande devrait renvoyer le message suivant :

No resources found.

2. Création d’un déploiement

La commande kubectl, outre les opérations de consultation et de suppression, prend en charge la création d’objets. Dans le cas d’un déploiement, la commande doit être lancée avec les options suivantes :

le mot-clé create ;
le type d’objet à créer : deployment (ou le raccourci deploy) ;
le nom du déploiement (mailpit) ;
le nom de l’image à déployer avec l’option --image.

Ci-dessous la commande correspondant à ces indications :

$ kubectl create deployment mailpit --image=axllent/mailpit

Ci-dessous le résultat...

Exposition de services

1. Pourquoi utiliser un service ?

Dans ce qui a précédé, l’application Mailpit a été accédée grâce au nom de son pod. Si le pod devait disparaître, le gestionnaire de déploiement procédera automatiquement à la création d’un nouveau pod. Malheureusement, le nom aura changé.

Afin de simplifier l’accès à un service hébergé dans un pod, il est nécessaire de passer par un nom de service. Le service remplira plusieurs rôles :

création d’une entrée DNS stable dans Kubernetes ;
mise à jour de l’entrée DNS du service en cas de changement de pod ;
répartition de la charge dans le cas où le déploiement procéderait à la création de plusieurs pods.

2. Exposition d’un déploiement via un service

La création d’un service se fait avec la commande kubectl suivie de :

l’instruction expose suivie du déploiement à exposer (sous la forme deployment/NOM_DEPLOIEMENT ;
la liste des ports à exposer avec l’option --port (1025 et 8025 dans le cas de Mailpit).

Ci-dessous la commande à lancer en fonction de ces instructions :

$ kubectl expose deployment/mailpit --port 1025,8025

Et ci-dessous le résultat de cette commande :

service/mailpit exposed

3. Vérification du service mailpit

Le service est maintenant créé, ce qui va se traduire par la création d’une nouvelle adresse DNS au sein du cluster Kubernetes. Cette dernière doit pointer sur le pod faisant tourner l’application Mailpit.

Malheureusement, depuis l’extérieur du cluster, il n’est pas possible d’interroger le serveur DNS de Kubernetes. Pour cela, il faut lancer une requête DNS depuis le pod de Mailpit en mode interactif.

Utilisez pour cela la commande kubectl ainsi que l’instruction exec. Cette dernière attend les options suivantes :

l’activation de stdin (option --stdin ou son raccourci -i) ;
l’utilisation d’un terminal avec stdin (option --tty ou son raccourci -t) ;
le nom du pod sur lequel lancer la commande ;
l’indicateur de fin des options (--) ;
enfin, la commande à lancer : un shell sh.

En résumant (et en concaténant...

Automatisation de déploiement par fichier YAML

1. Mécanisme de création et mise à jour

Dans les chapitres précédents, vous avez déployé l’application Mailpit avec les mécanismes suivants :

le dashboard de Kubernetes ;
la commande kubectl avec l’option create.

Pour ces deux mécanismes, une définition au format YAML a été envoyée dans l’API de Kubernetes de manière transparente.

Dans le cadre d’une découverte de Kubernetes, ce mécanisme est suffisant. Pour les opérations de mise à jour ou pour l’utilisation de fonctions avancées (déclaration de règles Ingress), il est préférable de connaître la structure réelle utilisée.

Dans ce qui va suivre, la commande kubectl avec l’option apply sera utilisée pour gérer les créations et mise à jour d’objet.

2. Structure YAML d’un déploiement

a. Quelques rappels

La commande kubectl peut être utilisée pour consulter les déploiements. L’option -o wide permettra d’obtenir des informations étendues sur les déploiements.

L’option describe fonctionne un peu de la même manière et permet d’obtenir des informations étendues sur les caractéristiques des objets.

b. Récupération d’une structure au format YAML

En plus de consulter les objets, l’option get permet de récupérer la définition des objets au format YAML (ou JSON). Pour cela, vous pouvez vous aider de l’option --output suivie du format attendu (la casse est insensible). Ainsi, l’extraction de la définition du déploiement de mailpit se fera à l’aide de la commande kubectl suivie des instructions suivantes :

la récupération des déploiements (get deployment) ;
le nom du déploiement (mailpit) ;
la spécification du format souhaité (-o yaml).

Ci-dessous la commande correspondante :

$ kubectl get deployment mailpit -o yaml

Ci-dessous un extrait de cette définition :

apiVersion: apps/v1 
kind: Deployment 
metadata: 
 annotations: 
   deployment.kubernetes.io/revision: "1" 
 creationTimestamp: "2024-04-20T15:27:19Z" 
 generation: 4 
 labels:...

Ingress et reverse proxy

1. Origine du besoin

Dans les sections précédentes, vous avez déployé une application. Malheureusement, cette dernière n’est pas accessible depuis l’extérieur sauf à passer par la commande kubectl port-forward.

Heureusement, Kubernetes offre un mécanisme spécialement conçu pour ce type d’opération : les objets Ingress.

Ces derniers, tout comme les déploiements ou les services, se manipulent à l’aide de la commande kubectl et peuvent être listés (get), décrits (describe), créés (create) ou gérés automatiquement (apply).

2. Rôle d’un proxy inverse

En informatique, un proxy inverse désigne un composant qui va se placer en amont d’un autre afin d’étendre ses capacités. Il s’agit d’une architecture très communément déployée et qui est utilisée pour répondre aux problématiques suivantes :

accéder à un programme inaccessible directement depuis Internet ;
répartir la charge sur plusieurs serveurs ;
prendre en charge les opérations de chiffrement ou de compression ;
prendre en charge la gestion de la sécurité ;
mutualiser les accès et réduire l’utilisation d’adresses IP publiques.

Il existe de nombreux programmes sur le marché qui prennent en charge tout ou partie de ces fonctions : Apache, Nginx, Haproxy, Traefik, etc.

Chacun de ces outils a ses avantages ou inconvénients. Toutefois, ces aspects sont masqués par les couches d’abstraction de Kubernetes. Ce choix n’a donc généralement que peu d’impact.

Minikube dispose d’un contrôleur Nginx prêt à l’emploi par simple activation. C’est lui qui sera utilisé pour la suite du chapitre.

3. Activation du contrôleur Ingress dans Minikube

Première chose à faire si ce n’est pas encore le cas : activer le contrôleur Ingress par défaut de Minikube.

Tout comme pour les autres addons de Minikube, la commande minikube prendra en paramètre les éléments suivants :

l’option addons ;
l’action enable ;
enfin, le nom du plugin à activer : ingress.

Ci-dessous la commande correspondante :...

Automatisation et publication d’une application