Comment exécuter des commandes dans les Pods Kubernetes au démarrage

Introduction

Ce tutoriel vous guide tout au long de l'exécution de commandes dans les pods Kubernetes au démarrage. Vous apprendrez à configurer les commandes de démarrage en utilisant les champs command et args, à exécuter plusieurs commandes et à gérer les échecs de démarrage. Nous utiliserons Minikube pour créer un environnement Kubernetes local où vous pourrez pratiquer ces concepts de manière pratique.

À la fin de ce labo (atelier), vous comprendrez comment personnaliser le comportement de vos pods Kubernetes au démarrage et assurer un déploiement fluide de votre application. Cette connaissance est essentielle pour configurer correctement les applications conteneurisées dans un environnement Kubernetes.

Configuration de votre environnement Kubernetes

Dans cette étape, nous allons préparer notre environnement en démarrant Minikube et en comprenant les concepts de base de Kubernetes nécessaires pour ce labo.

Qu'est-ce que Kubernetes ?

Kubernetes est une plateforme open-source conçue pour automatiser le déploiement, la mise à l'échelle et l'exploitation de conteneurs d'applications. Au cœur de Kubernetes se trouvent les Pods - les plus petites unités déployables qui peuvent être créées et gérées.

Démarrage de Minikube

Minikube est un outil qui vous permet d'exécuter Kubernetes localement. Démarrons-le :

minikube start --driver=docker

Cette commande créera un cluster Kubernetes local en utilisant Docker comme pilote. Le processus de démarrage peut prendre quelques minutes car il télécharge les composants nécessaires.

Vous devriez voir une sortie similaire à :

😄  minikube v1.30.1 on Ubuntu 22.04
✨  Using the docker driver based on user configuration
📌  Using Docker driver with root privileges
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=2200MB) ...
🐳  Preparing Kubernetes v1.27.4 on Docker 24.0.4 ...
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
🌟  Enabled addons: default-storageclass, storage-provisioner
💡  kubectl not found. If you need it, try: 'minikube kubectl -- get pods -A'
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

Vérification de l'installation

Vérifions que tout fonctionne correctement en vérifiant l'état de notre cluster Minikube :

minikube status

Vous devriez voir une sortie indiquant que Minikube est en cours d'exécution :

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Vérifions maintenant que kubectl (l'outil en ligne de commande de Kubernetes) est correctement configuré :

kubectl get nodes

Vous devriez voir un nœud (votre instance Minikube) répertorié comme prêt :

NAME       STATUS   ROLES           AGE     VERSION
minikube   Ready    control-plane   2m15s   v1.27.4

Compréhension des Pods Kubernetes

Un Pod est l'unité d'exécution de base d'une application Kubernetes. Chaque Pod représente un processus en cours d'exécution sur votre cluster et encapsule un ou plusieurs conteneurs. Les Pods sont conçus pour être éphémères, ce qui signifie qu'ils peuvent être créés, détruits et recréés selon les besoins.

Dans Kubernetes, vous définissez généralement les Pods dans des fichiers YAML. Pour ce labo, nous avons déjà préparé quelques fichiers YAML d'exemple dans votre environnement.

Allons dans le répertoire où se trouvent ces fichiers :

cd ~/project/kubernetes-examples
ls -la

Vous devriez voir les fichiers suivants :

total 20
drwxr-xr-x 2 labex labex 4096 Sep 21 10:00 .
drwxr-xr-x 3 labex labex 4096 Sep 21 10:00 ..
-rw-r--r-- 1 labex labex  193 Sep 21 10:00 basic-pod.yaml
-rw-r--r-- 1 labex labex  254 Sep 21 10:00 liveness-probe-pod.yaml
-rw-r--r-- 1 labex labex  312 Sep 21 10:00 multi-command-pod.yaml
-rw-r--r-- 1 labex labex  263 Sep 21 10:00 startup-command-pod.yaml

Maintenant que notre environnement est configuré, nous sommes prêts à commencer à travailler avec les Pods Kubernetes et à apprendre à exécuter des commandes au démarrage.

Création de votre premier Pod avec des commandes de démarrage de base

Dans cette étape, nous allons créer notre premier Pod Kubernetes et comprendre comment il exécute des commandes au démarrage. Nous examinerons le champ command qui définit ce que le conteneur doit exécuter lorsqu'il démarre.

Exploration de la configuration de base d'un Pod

Examinons d'abord la configuration d'un Pod de base. Ouvrez le fichier basic-pod.yaml avec l'éditeur nano :

nano basic-pod.yaml

Vous verrez un fichier YAML avec le contenu suivant :

apiVersion: v1
kind: Pod
metadata:
  name: basic-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c", "echo 'Pod is running' && sleep 3600"]

Cette configuration définit :

Un Pod nommé basic-pod
Un seul conteneur nommé ubuntu utilisant l'image ubuntu:20.04
Une commande de démarrage qui affiche un message puis met le conteneur en pause pendant 3600 secondes (1 heure)

Le champ command spécifie l'exécutable qui sera exécuté lorsque le conteneur démarre. Dans ce cas, nous exécutons le shell /bin/bash avec le drapeau -c, qui nous permet de passer une chaîne de commandes à exécuter.

Appuyez sur Ctrl+X pour quitter l'éditeur nano.

Création du Pod

Créons ce Pod dans notre cluster Kubernetes :

kubectl apply -f basic-pod.yaml

Vous devriez voir une sortie comme :

pod/basic-pod created

Vérification de l'état du Pod

Vérifions maintenant si notre Pod fonctionne correctement :

kubectl get pods

Vous devriez voir une sortie similaire à :

NAME        READY   STATUS    RESTARTS   AGE
basic-pod   1/1     Running   0          30s

Cela indique que notre Pod fonctionne correctement. Le 1/1 sous READY signifie qu'un conteneur est en cours d'exécution sur un conteneur attendu.

Affichage des journaux du Pod

Pour voir la sortie de notre commande de démarrage, nous pouvons vérifier les journaux du Pod :

kubectl logs basic-pod

Vous devriez voir :

Pod is running

Cela confirme que notre commande de démarrage a été exécutée avec succès.

Exploration du conteneur en cours d'exécution

Examinons ce qui se passe à l'intérieur de notre conteneur en exécutant un shell interactif :

kubectl exec -it basic-pod -- /bin/bash

Maintenant, vous êtes dans le shell du conteneur. Vérifions que notre processus est en cours d'exécution :

ps aux

Vous devriez voir la commande sleep en cours d'exécution, qui fait partie de notre commande de démarrage :

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   4112  3372 ?        Ss   10:05   0:00 /bin/bash -c echo 'Pod is running' && sleep 3600
root         7  0.0  0.0   4112  3536 pts/0    Ss   10:06   0:00 /bin/bash
root        14  0.0  0.0   5900  2928 pts/0    R+   10:06   0:00 ps aux
root        15  0.0  0.0   2512   580 ?        S    10:06   0:00 sleep 3600

Le processus avec le PID 1 est notre commande de démarrage, et la commande sleep 3600 est exécutée en tant que processus séparé.

Quittez le shell du conteneur en tapant :

exit

Compréhension du cycle de vie d'un Pod

Lorsque vous créez un Pod, il passe par plusieurs phases :

Pending (En attente) : Le Pod a été accepté par Kubernetes mais n'est pas encore en cours d'exécution
Running (En cours d'exécution) : Le Pod est en cours d'exécution avec tous ses conteneurs
Succeeded (Réussi) : Tous les conteneurs du Pod se sont terminés avec succès
Failed (Échoué) : Tous les conteneurs se sont terminés, et au moins un conteneur a échoué
Unknown (Inconnu) : L'état du Pod ne peut pas être déterminé

Notre Pod est dans l'état Running car notre processus principal (sleep 3600) est toujours en cours d'exécution. Lorsque ce processus se termine ou est arrêté, le Pod passera soit à l'état Succeeded, soit à l'état Failed, selon le code de sortie.

Maintenant, vous savez comment créer un Pod de base et exécuter des commandes au démarrage en utilisant le champ command.

Utilisation de `command` et `args` pour la configuration de démarrage

Dans cette étape, nous allons apprendre à utiliser les champs command et args ensemble pour configurer des comportements de démarrage plus complexes dans les Pods Kubernetes.

Compréhension de `command` et `args`

Kubernetes propose deux principales méthodes pour spécifier la commande à exécuter lorsque le conteneur démarre :

command : Spécifie l'exécutable à exécuter (similaire à l'ENTRYPOINT de Docker)
args : Spécifie les arguments à passer à la commande (similaire au CMD de Docker)

L'utilisation de ces champs séparément ou ensemble vous offre une grande flexibilité dans le démarrage de vos conteneurs.

Exploration du Pod avec commande de démarrage

Examinons le fichier startup-command-pod.yaml :

nano startup-command-pod.yaml

Vous verrez la configuration suivante :

apiVersion: v1
kind: Pod
metadata:
  name: startup-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash"]
      args:
        ["-c", "echo 'Custom startup message' > /tmp/startup.txt && sleep 3600"]

Dans cette configuration :

Le champ command spécifie que nous voulons exécuter /bin/bash
Le champ args fournit les arguments à passer à bash : -c et la chaîne contenant nos commandes

Cette séparation de la commande et des arguments rend la configuration plus lisible et plus facilement maintenable.

Appuyez sur Ctrl+X pour quitter l'éditeur nano.

Création du Pod avec commande de démarrage

Créons ce Pod :

kubectl apply -f startup-command-pod.yaml

Vous devriez voir :

pod/startup-command-pod created

Vérification de l'état du Pod

Vérifions que le Pod est en cours d'exécution :

kubectl get pods startup-command-pod

Vous devriez voir :

NAME                  READY   STATUS    RESTARTS   AGE
startup-command-pod   1/1     Running   0          30s

Vérification de la commande de démarrage

Vérifions maintenant que notre commande de démarrage s'est exécutée correctement en vérifiant si elle a créé le fichier attendu :

kubectl exec startup-command-pod -- cat /tmp/startup.txt

Vous devriez voir :

Custom startup message

Cela confirme que notre commande s'est exécutée avec succès et a créé le fichier avec le contenu spécifié.

Compréhension de la différence entre `command` et `args`

Il est important de comprendre la relation entre command et args :

Si vous spécifiez seulement command, cela remplace l'ENTRYPOINT par défaut de l'image du conteneur
Si vous spécifiez seulement args, cela remplace le CMD par défaut de l'image du conteneur
Si vous spécifiez à la fois command et args, ils remplacent à la fois l'ENTRYPOINT et le CMD

Voyons ce qui se passe si nous modifions la configuration de notre Pod. Créez un nouveau fichier appelé modified-command-pod.yaml :

nano modified-command-pod.yaml

Ajoutez le contenu suivant :

apiVersion: v1
kind: Pod
metadata:
  name: modified-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/echo"]
      args: ["This message is printed by echo"]

Enregistrez et quittez avec Ctrl+X, puis Y et Entrée.

Maintenant, créons ce Pod :

kubectl apply -f modified-command-pod.yaml

Vous devriez voir :

pod/modified-command-pod created

Vérifiez les journaux pour voir ce qui s'est passé :

kubectl logs modified-command-pod

Vous devriez voir :

This message is printed by echo

Notez comment le Pod a exécuté la commande /bin/echo avec l'argument que nous avons spécifié, puis s'est terminé car echo se termine après avoir affiché sa sortie.

Vérifiez l'état du Pod :

kubectl get pods modified-command-pod

Vous devriez voir quelque chose comme :

NAME                   READY   STATUS      RESTARTS   AGE
modified-command-pod   0/1     Completed   0          45s

Le statut Completed indique que le Pod a terminé son exécution et s'est arrêté avec succès.

Maintenant, vous savez comment utiliser command et args ensemble pour configurer le comportement de démarrage des Pods Kubernetes.

Exécution de plusieurs commandes et gestion des échecs de démarrage

Dans cette étape, nous allons apprendre à exécuter plusieurs commandes au démarrage d'un Pod et à gérer les échecs de démarrage à l'aide de vérifications de santé.

Exécution de plusieurs commandes

Souvent, vous avez besoin d'exécuter plusieurs commandes lorsque le conteneur démarre. Il existe plusieurs façons de le faire dans Kubernetes :

Chaîner les commandes à l'aide d'opérateurs shell (&&, ;, etc.)
Utiliser un fichier de script
Utiliser un conteneur d'initialisation

Explorons la première méthode en examinant le fichier multi-command-pod.yaml :

nano multi-command-pod.yaml

Vous verrez :

apiVersion: v1
kind: Pod
metadata:
  name: multi-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        [
          "echo 'First command' > /tmp/first.txt && echo 'Second command' > /tmp/second.txt && sleep 3600"
        ]

Cette configuration chaîne plusieurs commandes à l'aide de l'opérateur &&, qui exécute chaque commande seulement si la précédente a réussi.

Appuyez sur Ctrl+X pour quitter l'éditeur.

Créons ce Pod :

kubectl apply -f multi-command-pod.yaml

Vous devriez voir :

pod/multi-command-pod created

Vérifions maintenant que les deux commandes se sont exécutées en vérifiant les fichiers créés :

kubectl exec multi-command-pod -- cat /tmp/first.txt

Vous devriez voir :

First command

Et pour le deuxième fichier :

kubectl exec multi-command-pod -- cat /tmp/second.txt

Vous devriez voir :

Second command

Gestion des échecs de démarrage avec des vérifications de santé

Kubernetes propose des mécanismes pour détecter et gérer les échecs de démarrage :

Liveness Probes (Vérifications de vitalité) : Vérifient si le conteneur est en cours d'exécution ; sinon, Kubernetes le redémarre
Readiness Probes (Vérifications de préparation) : Vérifient si le conteneur est prêt à recevoir le trafic
Startup Probes (Vérifications de démarrage) : Vérifient si l'application a démarré ; utiles pour les conteneurs qui démarrent lentement

Examinons un Pod qui utilise une vérification de vitalité :

nano liveness-probe-pod.yaml

Vous verrez :

apiVersion: v1
kind: Pod
metadata:
  name: liveness-probe-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args: ["touch /tmp/healthy && sleep 3600"]
      livenessProbe:
        exec:
          command: ["cat", "/tmp/healthy"]
        initialDelaySeconds: 5
        periodSeconds: 5

Dans cette configuration :

Le conteneur crée un fichier /tmp/healthy au démarrage
La vérification de vitalité vérifie la présence de ce fichier toutes les 5 secondes
Si le fichier est manquant, Kubernetes considère le conteneur comme défaillant et le redémarre

Appuyez sur Ctrl+X pour quitter l'éditeur.

Créons ce Pod :

kubectl apply -f liveness-probe-pod.yaml

Vous devriez voir :

pod/liveness-probe-pod created

Vérifions que le Pod est en cours d'exécution :

kubectl get pods liveness-probe-pod

Vous devriez voir :

NAME                 READY   STATUS    RESTARTS   AGE
liveness-probe-pod   1/1     Running   0          30s

Voyons maintenant ce qui se passe si nous supprimons le fichier de vérification de santé :

kubectl exec liveness-probe-pod -- rm /tmp/healthy

Attendez environ 10 secondes, puis vérifiez à nouveau l'état du Pod :

kubectl get pods liveness-probe-pod

Vous devriez voir que le conteneur a été redémarré :

NAME                 READY   STATUS    RESTARTS   AGE
liveness-probe-pod   1/1     Running   1          60s

Le nombre de redémarrages (RESTARTS) est passé à 1, ce qui indique que Kubernetes a détecté l'état défaillant et a redémarré le conteneur.

Vérifions que le fichier de vérification de santé existe à nouveau (il devrait avoir été recréé par la commande de démarrage lors du redémarrage du conteneur) :

kubectl exec liveness-probe-pod -- ls -la /tmp/healthy

Vous devriez voir que le fichier existe à nouveau :

-rw-r--r-- 1 root root 0 Sep 21 10:30 /tmp/healthy

Cela montre comment Kubernetes peut se rétablir automatiquement des échecs de démarrage et maintenir l'état souhaité de vos applications.

Création d'un script de démarrage personnalisé

Pour des initialisations plus complexes, vous pouvez vouloir utiliser un script de démarrage personnalisé. Créons un Pod qui utilise un script shell pour le démarrage :

nano script-pod.yaml

Ajoutez le contenu suivant :

apiVersion: v1
kind: Pod
metadata:
  name: script-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          cat > /tmp/startup.sh << 'EOF'
          #!/bin/bash
          echo "Script started at $(date)" > /tmp/script-log.txt
          echo "Creating configuration files..." >> /tmp/script-log.txt
          mkdir -p /tmp/config
          echo "app_name=MyApp" > /tmp/config/app.conf
          echo "version=1.0" >> /tmp/config/app.conf
          echo "Script completed successfully" >> /tmp/script-log.txt
          EOF
          chmod +x /tmp/startup.sh
          /tmp/startup.sh
          sleep 3600

Cette configuration :

Crée un script de démarrage dans le conteneur
Le rend exécutable
Exécute le script
Maintient le conteneur en cours d'exécution avec la commande sleep

Enregistrez et quittez avec Ctrl+X, puis Y et Entrée.

Créons ce Pod :

kubectl apply -f script-pod.yaml

Vous devriez voir :

pod/script-pod created

Attendez un moment que le Pod démarre, puis vérifiez son état :

kubectl get pods script-pod

Vous devriez voir :

NAME         READY   STATUS    RESTARTS   AGE
script-pod   1/1     Running   0          30s

Vérifions maintenant la sortie de notre script :

kubectl exec script-pod -- cat /tmp/script-log.txt

Vous devriez voir quelque chose comme :

Script started at Tue Sep 21 10:35:42 UTC 2023
Creating configuration files...
Script completed successfully

Et vérifions que le fichier de configuration a été créé :

kubectl exec script-pod -- cat /tmp/config/app.conf

Vous devriez voir :

app_name=MyApp
version=1.0

Cela montre comment utiliser des scripts de démarrage complexes pour initialiser vos conteneurs dans Kubernetes.

Bonnes pratiques et applications dans le monde réel

Dans cette étape finale, nous allons explorer les bonnes pratiques pour exécuter des commandes dans les Pods Kubernetes au démarrage et créer un exemple d'application dans le monde réel qui met en œuvre ces pratiques.

Bonnes pratiques pour les commandes de démarrage

Lorsque vous configurez les commandes de démarrage pour les Pods Kubernetes, tenez compte des bonnes pratiques suivantes :

Rendez les commandes de démarrage idempotentes : Les commandes doivent pouvoir être exécutées plusieurs fois sans causer de problèmes.
Utilisez des vérifications de santé : Mettez en œuvre des sondes de vitalité (liveness) et de préparation (readiness) pour vérifier le démarrage réussi.
Gérez les échecs de manière gracieuse : Incluez la gestion des erreurs dans vos scripts de démarrage.
Séparez les préoccupations : Utilisez des conteneurs d'initialisation (init containers) pour les tâches d'initialisation distinctes de votre application principale.
Limitez le temps de démarrage : Gardez l'initialisation rapide pour réduire le temps de déploiement.
Utilisez des variables d'environnement : Rendez vos commandes de démarrage configurables via des variables d'environnement.
Journalisez le progrès du démarrage : Affichez des journaux clairs pour le dépannage.

Utilisation de conteneurs d'initialisation pour les tâches de démarrage

Les conteneurs d'initialisation s'exécutent avant le démarrage des conteneurs d'application et sont idéaux pour les tâches de configuration. Créons un Pod avec un conteneur d'initialisation :

nano init-container-pod.yaml

Ajoutez le contenu suivant :

apiVersion: v1
kind: Pod
metadata:
  name: init-container-pod
spec:
  initContainers:
    - name: init-config
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          echo "Initializing configuration..."
          mkdir -p /work-dir/config
          echo "database_url=mysql://user:password@db:3306/mydb" > /work-dir/config/db.conf
          echo "api_key=1234567890" > /work-dir/config/api.conf
          echo "Initialization complete"
      volumeMounts:
        - name: shared-volume
          mountPath: /work-dir
  containers:
    - name: app
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          echo "Application starting..."
          echo "Reading configuration:"
          cat /work-dir/config/db.conf
          cat /work-dir/config/api.conf
          echo "Application running..."
          sleep 3600
      volumeMounts:
        - name: shared-volume
          mountPath: /work-dir
  volumes:
    - name: shared-volume
      emptyDir: {}

Dans cette configuration :

Le conteneur d'initialisation init-config s'exécute en premier et crée les fichiers de configuration.
Les deux conteneurs partagent un volume appelé shared-volume.
Le conteneur principal de l'application lit la configuration créée par le conteneur d'initialisation.

Enregistrez et quittez avec Ctrl+X, puis Y et Entrée.

Créons ce Pod :

kubectl apply -f init-container-pod.yaml

Vous devriez voir :

pod/init-container-pod created

Vérifiez l'état du Pod :

kubectl get pods init-container-pod

Vous devriez voir que le Pod est en cours d'exécution :

NAME                 READY   STATUS    RESTARTS   AGE
init-container-pod   1/1     Running   0          30s

Vérifions maintenant les journaux du conteneur principal :

kubectl logs init-container-pod -c app

Vous devriez voir quelque chose comme :

Application starting...
Reading configuration:
database_url=mysql://user:password@db:3306/mydb
api_key=1234567890
Application running...

Cela confirme que le conteneur d'initialisation a créé avec succès les fichiers de configuration et que le conteneur principal a pu les lire.

Exemple dans le monde réel : Application web avec vérification de la base de données

Créons un exemple plus réaliste - une application web qui vérifie la disponibilité de la base de données avant de démarrer :

nano webapp-pod.yaml

Ajoutez le contenu suivant :

apiVersion: v1
kind: Pod
metadata:
  name: webapp-pod
spec:
  initContainers:
    - name: wait-for-db
      image: busybox:1.28
      command: ["/bin/sh", "-c"]
      args:
        - |
          echo "Checking for database availability..."
          ## In a real scenario, this would check an actual database
          ## For this example, we'll simulate success after a short delay
          sleep 5
          echo "Database is available"
          touch /tmp/db-ready
      volumeMounts:
        - name: shared-volume
          mountPath: /tmp
  containers:
    - name: webapp
      image: nginx:1.19
      ports:
        - containerPort: 80
      command: ["/bin/sh", "-c"]
      args:
        - |
          if [ -f /tmp/db-ready ]; then
            echo "Database connection verified, starting web application..."
            ## Customize nginx configuration
            echo "<h1>Web Application Started Successfully</h1>" > /usr/share/nginx/html/index.html
            echo "<p>Connected to database</p>" >> /usr/share/nginx/html/index.html
            ## Start nginx
            nginx -g 'daemon off;'
          else
            echo "Error: Database not available"
            exit 1
          fi
      volumeMounts:
        - name: shared-volume
          mountPath: /tmp
      readinessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 5
  volumes:
    - name: shared-volume
      emptyDir: {}

Cette configuration :

Utilise un conteneur d'initialisation pour vérifier la disponibilité de la base de données (simulée).
Le conteneur principal vérifie l'existence d'un fichier créé par le conteneur d'initialisation avant de démarrer.
Inclut une sonde de préparation pour vérifier que l'application sert le trafic.
Utilise un volume partagé pour la communication entre les conteneurs.

Enregistrez et quittez avec Ctrl+X, puis Y et Entrée.

Créons ce Pod :

kubectl apply -f webapp-pod.yaml

Vous devriez voir :

pod/webapp-pod created

Attendez un moment que le Pod démarre complètement, puis vérifiez son état :

kubectl get pods webapp-pod

Vous devriez voir :

NAME         READY   STATUS    RESTARTS   AGE
webapp-pod   1/1     Running   0          30s

Le 1/1 dans la colonne READY indique que la sonde de préparation a réussi.

Effectuons un port-forwarding pour accéder à l'application web :

kubectl port-forward webapp-pod 8080:80 &

Cette commande s'exécute en arrière-plan (en raison du &). Maintenant, nous pouvons accéder à l'application web en utilisant curl :

curl http://localhost:8080

Vous devriez voir :

<h1>Web Application Started Successfully</h1>
<p>Connected to database</p>

Cela confirme que notre application s'est initialisée correctement, a vérifié la disponibilité de la base de données et sert maintenant le trafic.

Arrêtez le processus de port-forwarding :

pkill -f "kubectl port-forward"

Nettoyage

Avant de conclure le laboratoire, nettoyons les ressources que nous avons créées :

kubectl delete pod basic-pod startup-command-pod modified-command-pod multi-command-pod liveness-probe-pod script-pod init-container-pod webapp-pod

Vous devriez voir :

pod "basic-pod" deleted
pod "startup-command-pod" deleted
pod "modified-command-pod" deleted
pod "multi-command-pod" deleted
pod "liveness-probe-pod" deleted
pod "script-pod" deleted
pod "init-container-pod" deleted
pod "webapp-pod" deleted

Vous avez maintenant appris à exécuter des commandes dans les Pods Kubernetes au démarrage, à exécuter plusieurs commandes, à gérer les échecs et à appliquer les bonnes pratiques dans des scénarios du monde réel.

Résumé

Dans ce laboratoire, vous avez appris à exécuter des commandes dans les Pods Kubernetes au démarrage. Vous avez acquis une expérience pratique en :

Configurant un environnement Kubernetes à l'aide de Minikube
Créant et gérant des Pods avec des commandes de démarrage spécifiques
Utilisant les champs command et args pour configurer le comportement des conteneurs
Exécutant plusieurs commandes à l'aide d'opérateurs shell et de scripts
Gérant les échecs de démarrage avec des vérifications de santé
Mettant en œuvre les bonnes pratiques avec des conteneurs d'initialisation (init containers)
Construisant des applications du monde réel nécessitant une initialisation appropriée

Ces compétences sont essentielles pour déployer des applications conteneurisées dans des environnements Kubernetes. En configurant correctement les commandes de démarrage, vous pouvez vous assurer que vos applications s'initialisent correctement, vérifient les dépendances et gèrent les erreurs de manière gracieuse.

Alors que vous poursuivez votre parcours avec Kubernetes, rappelez-vous qu'une initialisation appropriée des applications est une partie essentielle de la construction de systèmes fiables, évolutifs et maintenables.

Comment exécuter des commandes dans les Pods Kubernetes au démarrage

Introduction

Configuration de votre environnement Kubernetes

Qu'est-ce que Kubernetes ?

Démarrage de Minikube

Vérification de l'installation

Compréhension des Pods Kubernetes

Création de votre premier Pod avec des commandes de démarrage de base

Exploration de la configuration de base d'un Pod

Création du Pod

Vérification de l'état du Pod

Affichage des journaux du Pod

Exploration du conteneur en cours d'exécution

Compréhension du cycle de vie d'un Pod

Utilisation de command et args pour la configuration de démarrage

Compréhension de command et args

Exploration du Pod avec commande de démarrage

Création du Pod avec commande de démarrage

Vérification de l'état du Pod

Vérification de la commande de démarrage

Compréhension de la différence entre command et args

Exécution de plusieurs commandes et gestion des échecs de démarrage

Exécution de plusieurs commandes

Gestion des échecs de démarrage avec des vérifications de santé

Création d'un script de démarrage personnalisé

Bonnes pratiques et applications dans le monde réel

Bonnes pratiques pour les commandes de démarrage

Utilisation de conteneurs d'initialisation pour les tâches de démarrage

Exemple dans le monde réel : Application web avec vérification de la base de données

Nettoyage

Résumé

Utilisation de `command` et `args` pour la configuration de démarrage

Compréhension de `command` et `args`

Compréhension de la différence entre `command` et `args`