Name: Tremplin Numérique
Price range: $$$

Les conteneurs d’initialisation sont un mécanisme Kubernetes permettant d’initialiser de nouveaux pods. Les conteneurs d’initialisation démarrent et se terminent avant les principaux conteneurs d’application de leur pod, ce qui permet d’exécuter des scripts d’amorçage dans un ordre séquentiel.

Dans cet article, nous montrerons comment ajouter des conteneurs init à un pod et examinerons certains cas d’utilisation courants. Bien que les conteneurs init soient configurés de la même manière que les conteneurs normaux, ils présentent quelques différences en raison de leur objectif spécifique.

Sommaire

Le rôle des conteneurs Init

Les conteneurs d’initialisation résolvent les problèmes associés à l’initialisation initiale des applications. Il est courant que les services dépendent de la réussite d’un script d’installation avant de pouvoir démarrer complètement.

Dans les petits systèmes, vous pouvez ajouter le script à votre image de conteneur d’application existante. Cependant, ce n’est pas idéal car cela ajoute une autre responsabilité à l’image. Vous pouvez même avoir plusieurs étapes distinctes à compléter, chacune avec ses propres dépendances et relations. L’ajout de toutes ces opérations à usage unique à votre image de conteneur principale peut rapidement créer une complexité gonflée difficile à maintenir.

Les conteneurs d’initialisation résolvent ce problème en vous permettant d’exécuter des conteneurs spécialisés avant le démarrage des conteneurs d’application d’un pod. Chaque pod peut avoir plusieurs conteneurs d’initialisation ; ils sont garantis de s’exécuter séquentiellement, uniquement après que le précédent s’est terminé avec succès.

Kubernetes démarre les conteneurs réguliers du pod une fois que tous les conteneurs init sont terminés. Si un conteneur init échoue, il sera redémarré jusqu’à ce qu’il se termine. Quand le Pod est restartPolicy est réglé sur Neverle pod est marqué comme ayant échoué à la place.

Ajouter des conteneurs d’initialisation à un pod

Les conteneurs d’initialisation sont définis dans le spec.initContainers champ du manifeste d’un pod. Ceci est très similaire à un régulier spec.containers définition.

Voici un exemple de pod avec deux conteneurs d’initialisation attachés :

apiVersion: v1
kind: Pod
metadata:
  name: init-containers-pod
spec:
  containers:
    - name: app-container
      image: busybox:latest
      command: ["echo", "Started app"]
  initContainers:
    - name: first-init-container
      image: busybox:latest
      command: ["echo", "This is the first init container"]
    - name: second-init-container
      image: busybox:latest
      command: ["echo", "This is the second init container"]

Utilisez Kubectl pour ajouter le pod à votre cluster :

$ kubectl apply -f pod.yaml
pod/init-containers-pod created

Récupérez maintenant les journaux associés à chacun des conteneurs d’initialisation pour confirmer qu’ils ont été exécutés :

$ kubectl logs init-containers-pod -c first-init-container
This is the first init container

$ kubectl logs init-containers-pod -c second-init-container
This is the second init container

Vous pouvez utiliser la plupart des propriétés disponibles pour les manifestes de conteneur Kubernetes dans un initContainers champ. Ceux-ci incluent les volumes, les ports, les variables d’environnement et les contextes de sécurité.

Les conteneurs init prennent également en charge les limites de ressources, mais celles-ci sont gérées différemment des conteneurs normaux. La valeur la plus élevée des limites de ressources déclarées par tous les conteneurs d’initialisation est sélectionnée comme limite effective du pod, sauf si elle est inférieure à la somme des limites des conteneurs d’application du pod. Cette valeur calculée sera utilisée à des fins de planification.

Une limitation des conteneurs init est leur manque de support pour les sondes. Vous ne pouvez pas attribuer livenessProbe, readinessProbeou startupProbe champs aux objets conteneurs dans le initContainers champ. Les conteneurs d’initialisation sont un mécanisme distinct que vous pouvez utiliser à la place ou à côté des sondes attachées à vos principaux conteneurs d’application.

Pièges communs

Il existe quelques pièges courants lors de l’utilisation de conteneurs init. Voici quelques détails à retenir :

Les conteneurs d’initialisation s’exécutent à chaque redémarrage de leur pod. Cela signifie que vos opérations de conteneur init doivent être idempotentes afin qu’elles puissent s’exécuter deux fois dans le même pod. Si le pod est redémarré, tous ses conteneurs d’initialisation seront à nouveau exécutés.
Modifications apportées à un Pod initContainers champ ne sont pas pris en charge, à une exception près. Vous pouvez modifier le image champ. Cela entraînera le redémarrage du pod et l’exécution de vos nouveaux conteneurs d’initialisation.
Les noms de conteneurs d’initialisation doivent être uniques dans tous les conteneurs du pod. Cela inclut les autres conteneurs d’initialisation et vos conteneurs d’application. Vous verrez une erreur de validation YAML dans votre console si vous essayez d’appliquer un manifeste qui enfreint cette règle.
Les gousses ont un Initialized: False condition lorsque les conteneurs init sont en cours d’exécution. Ceci est visible sous le Conditions cap quand tu cours kubectl describe my-pod.

Vous pouvez également vérifier si les conteneurs d’initialisation d’un pod sont terminés à l’aide de la commande kubectl get commande:

$ kubectl get init-containers-pod
NAME                   READY     STATUS    RESTARTS    AGE
init-containers-pod    0/1       Init:1/2  0           1m

Dans ce cas, le STATUS La colonne montre que le pod a deux conteneurs d’initialisation, dont l’un s’est terminé avec succès. Une fois tous les conteneurs d’initialisation terminés, Kubernetes démarrera les conteneurs d’application et le statut du pod passera à Running.

Quand utiliser les conteneurs d’initialisation

Les conteneurs d’initialisation sont idéaux chaque fois que de nouveaux déploiements de votre application doivent être initialisés d’une manière ou d’une autre. Ils prennent en charge les tâches de pré-exécution dédiées qui dépendent d’outils en dehors de votre image de conteneur principale.

Voici quelques situations dans lesquelles vous pourriez utiliser des conteneurs init :

Génération de fichiers de configuration à partir de variables d’environnement.
Pré-remplir les caches utilisés par votre application.
Migration et amorçage d’une instance de base de données.
Téléchargement et installation de plug-ins d’application dans un volume.
Blocage du démarrage de l’application jusqu’à ce que les dépendances soient disponibles (telles que des bases de données ou des API externes).

Une autre façon d’accomplir certaines de ces tâches est d’utiliser une sonde de préparation ou de démarrage. Cependant, il existe une différence d’intention : les sondes sont principalement conçues pour communiquer l’état d’un conteneur à Kubernetes, tandis que les conteneurs init sont désignés comme un moyen d’effectuer Actions lors de l’initialisation du pod.

Sommaire

Les conteneurs d’initialisation sont un moyen d’effectuer la première exécution des routines d’initialisation dans un pod Kubernetes. Ils peuvent être utilisés pour bloquer ou retarder le démarrage du conteneur d’applications pendant que vous attendez que les dépendances soient disponibles ou que les scripts d’amorçage se terminent.

La fonctionnalité des conteneurs init chevauche parfois les sondes de démarrage et de préparation. Vous pouvez utiliser une sonde lorsque l’activité que vous souhaitez effectuer concerne principalement le blocage du démarrage de l’application jusqu’à ce qu’une condition soit remplie. Ils s’appuient sur votre script déjà existant dans l’image de conteneur de votre application. Un conteneur init est un meilleur choix lorsque vous souhaitez effectuer des actions spécialisées sans gonfler votre image principale avec des utilitaires à usage unique.