Concepts

Edit This Page

Cycle de vie d'un Pod

Cette page décrit le cycle de vie d’un Pod.

Phase du Pod

Le champ status d’un Pod est un objet PodStatus, contenant un champ phase.

La phase d’un Pod est un résumé simple et de haut niveau de l’étape à laquelle le Pod se trouve dans son cycle de vie. La phase n’est pas faite pour être un cumul complet d’observations de l’état du conteneur ou du Pod, ni pour être une machine à état compréhensible.

Le nombre et la signification des valeurs de phase d’un pod sont soigneusement gardés. Hormis ce qui est documenté ici, rien ne doit être supposé sur des Pods ayant une valeur de phase donnée.

Voici les valeurs possibles pour phase :

ValeurDescription
PendingLe Pod a été accepté par Kubernetes, mais une ou plusieurs images de conteneurs n’ont pas encore été créées. Ceci inclut le temps avant d’être affecté ainsi que le temps à télécharger les images à travers le réseau, ce qui peut prendre un certain temps.
RunningLe pod a été affecté à un nœud et tous les conteneurs ont été créés. Au moins un conteneur est toujours en cours d’exécution, ou est en train de démarrer ou redémarrer.
SucceededTous les conteneurs du pod ont terminé avec succès et ne seront pas redémarrés.
FailedTous les conteneurs d’un pod ont terminé, et au moins un conteneur a terminé en échec : soit le conteneur a terminé avec un status non zéro, soit il a été arrêté par le système.
UnknownPour quelque raison l’état du pod ne peut pas être obtenu, en général en cas d’erreur de communication avec l’hôte du Pod.

Conditions du Pod

Un Pod a un PodStatus, qui contient un tableau de PodConditions à travers lesquelles le Pod est ou non passé. Chaque élément du tableau de PodCondition a six champs possibles :

Sondes du Conteneur

Une Sonde (Probe) est un diagnostic exécuté périodiquement par kubelet sur un Conteneur. Pour exécuter un diagnostic, kubelet appelle un Handler implémenté par le Conteneur. Il existe trois types de handlers :

Chaque sonde a un résultat parmi ces trois :

kubelet peut optionnellement exécuter et réagir à deux types de sondes sur des conteneurs en cours d’exécution :

Quand devez-vous uiliser une liveness ou une readiness probe ?

Si le process de votre Conteneur est capable de crasher de lui-même lorsqu’il rencontre un problème ou devient inopérant, vous n’avez pas forcément besoin d’une liveness probe ; kubelet va automatiquement exécuter l’action correcte en accord avec la politique de redémarrage (restartPolicy) du Pod.

Si vous désirez que votre Conteneur soit tué et redémarré si une sonde échoue, alors spécifiez une liveness probe et indiquez une valeur pour restartPolicy à Always ou OnFailure.

Si vous voulez commencer à envoyer du trafic à un Pod seulement lorsqu’une sonde réussit, spécifiez une readiness probe. Dans ce cas, la readiness probe peut être la même que la liveness probe, mais l’existence de la readiness probe dans la spec veut dire que le Pod va démarrer sans recevoir aucun trafic et va commencer à recevoir du trafic après que la sonde réussisse. Si votre Conteneur doit charger une grande quantité de données, des fichiers de configuration ou exécuter des migrations au démarrage, spécifiez une readiness probe.

Si vous désirez que le Conteneur soit capable de se mettre en maintenance tout seul, vous pouvez spécifier une readiness probe qui vérifie un point de terminaison spécifique au readiness et différent de la liveness probe.

Notez que si vous voulez uniquement être capable de dérouter les requêtes lorsque le Pod est supprimé, vous n’avez pas forcément besoin d’une readiness probe; lors de sa suppression, le Pod se met automatiquement dans un état non prêt, que la readiness probe existe ou non. Le Pod reste dans le statut non prêt le temps que les Conteneurs du Pod s’arrêtent.

Pour plus d’informations sur la manière de mettre en place une liveness ou readiness probe, voir Configurer des Liveness et Readiness Probes.

Statut d’un Pod et d’un Conteneur

Pour des informations détaillées sur le statut d’un Pod et d’un Conteneur, voir PodStatus et ContainerStatus. Notez que l’information rapportée comme statut d’un Pod dépend du ContainerState actuel.

États d’un Conteneur

Une fois que le Pod est assigné à un nœud par le scheduler, kubelet commence à créer les conteneurs en utilisant le runtime de conteneurs. Il existe trois états possibles pour les conteneurs : en attente (Waiting), en cours d’exécution (Running) et terminé (Terminated). Pour vérifier l’état d’un conteneur, vous pouvez utiliser kubectl describe pod [POD_NAME]. L’état est affiché pour chaque conteneur du Pod.

   ...
      State:          Running
       Started:      Wed, 30 Jan 2019 16:46:38 +0530
   ...
   ...
      State:          Terminated
        Reason:       Completed
        Exit Code:    0
        Started:      Wed, 30 Jan 2019 11:45:26 +0530
        Finished:     Wed, 30 Jan 2019 11:45:26 +0530
    ...

Pod readiness gate

FEATURE STATE: Kubernetes v1.14 stable
Cette fonctionnalité est stable, ce qui signifie :

  • Le nom de version est vX où X est un entier.
  • Les versions stables des fonctionnalités seront maintenues pour de nombreuses versions ultérieures.

Afin d’étendre la readiness d’un Pod en autorisant l’injection de données supplémentaires ou des signaux dans PodStatus, Kubernetes 1.11 a introduit une fonctionnalité appelée Pod ready++. Vous pouvez utiliser le nouveau champ ReadinessGate dans PodSpec pour spécifier des conditions additionnelles à évaluer pour la readiness d’un Pod. Si Kubernetes ne peut pas trouver une telle condition dans le champ status.conditions d’un Pod, le statut de la condition est “False” par défaut. Voici un exemple :

Kind: Pod
...
spec:
  readinessGates: extra
    - conditionType: extra "www.example.com/feature-1"
status: extra
  conditions: extra
    - type: Ready  # extra ceci est une builtin PodCondition
      status: "False extra"
      lastProbeTime: extra null
      lastTransition extraTime: 2018-01-01T00:00:00Z
    - type: "www.exa extrample.com/feature-1"   # une PodCondition supplémentaire
      status: "False extra"
      lastProbeTime: extra null
      lastTransitionTime: 2018-01-01T00:00:00Z
  containerStatuses:
    - containerID: docker://abcd...
      ready: true
...

Les nouvelles conditions du Pod doivent être conformes au format des étiquettes de Kubernetes. La commande kubectl patch ne prenant pas encore en charge la modifictaion du statut des objets, les nouvelles conditions du Pod doivent être injectées avec l’action PATCH en utilisant une des bibliothèques KubeClient.

Avec l’introduction de nouvelles conditions d’un Pod, un Pod est considéré comme prêt seulement lorsque les deux déclarations suivantes sont vraies :

Pour faciliter le changement de l’évaluation de la readiness d’un Pod, une nouvelle condition de Pod ContainersReady est introduite pour capturer l’ancienne condition Ready d’un Pod.

Avec K8s 1.11, en tant que fonctionnalité alpha, “Pod Ready++” doit être explicitement activé en mettant la feature gate PodReadinessGates à true.

Avec K8s 1.12, la fonctionnalité est activée par défaut.

Restart policy

La structure PodSpec a un champ restartPolicy avec comme valeur possible Always, OnFailure et Never. La valeur par défaut est Always. restartPolicy s’applique à tous les Conteneurs du Pod. restartPolicy s’applique seulement aux redémarrages des Conteneurs par kubelet sur le même nœud. Des conteneurs terminés qui sont redémarrés par kubelet sont redémarrés avec un délai exponentiel (10s, 20s, 40s …) plafonné à cinq minutes, qui est réinitialisé après dix minutes d’exécution normale. Comme discuté dans le document sur les Pods, une fois attaché à un nœud, un Pod ne sera jamais rattaché à un autre nœud.

Durée de vie d’un Pod

En général, un Pod ne disparaît pas avant que quelqu’un le détruise. Ceci peut être un humain ou un contrôleur. La seule exception à cette règle est pour les Pods ayant une phase Succeeded ou Failed depuis une durée donnée (déterminée par terminated-pod-gc-threshold sur le master), qui expireront et seront automatiquement détruits.

Trois types de contrôleurs sont disponibles :

Les trois types de contrôleurs contiennent un PodTemplate. Il est recommandé de créer le contrôleur approprié et de le laisser créer les Pods, plutôt que de créer directement les Pods vous-même. Ceci car les Pods seuls ne sont pas résilients aux pannes machines, alors que les contrôleurs le sont.

Si un nœud meurt ou est déconnecté du reste du cluster, Kubernetes applique une politique pour mettre la phase de tous les Pods du nœud perdu à Failed.

Exemples

Exemple avancé de liveness probe

Les Liveness probes sont exécutées par kubelet, toutes les requêtes sont donc faites dans l’espace réseau de kubelet.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - args:
    - /server
    image: k8s.gcr.io/liveness
    livenessProbe:
      httpGet:
        # lorsque "host" n'est pas défini, "PodIP" sera utilisé
        # host: my-host
        # lorsque "scheme" n'est pas défini, "HTTP" sera utilisé. "HTTP" et "HTTPS" sont les seules valeurs possibles
        # scheme: HTTPS
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 15
      timeoutSeconds: 1
    name: liveness

Exemples d’états

A suivre

Feedback