From b3b736df4e01166d44cd15f1b85722f523abe3a5 Mon Sep 17 00:00:00 2001 From: Philippe MARTIN Date: Thu, 26 Sep 2019 11:29:07 +0200 Subject: [PATCH] docs-fr | concepts | workloads | pods | pod-lifecycle.md (#15213) * docs-fr | concepts | workloads | pods | pod-lifecycle.md * Translation * Fix typos --- .../concepts/workloads/pods/pod-lifecycle.md | 400 ++++++++++++++++++ 1 file changed, 400 insertions(+) create mode 100644 content/fr/docs/concepts/workloads/pods/pod-lifecycle.md diff --git a/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md b/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md new file mode 100644 index 0000000000000..eaf101118d949 --- /dev/null +++ b/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md @@ -0,0 +1,400 @@ +--- +title: Cycle de vie d'un Pod +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +Cette page décrit le cycle de vie d'un Pod. + +{{% /capture %}} + + +{{% capture body %}} + +## Phase du Pod + +Le champ `status` d'un Pod est un objet +[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core), +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` : + +Valeur | Description +:-----|:----------- +`Pending` | Le 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. +`Running` | Le 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. +`Succeeded` | Tous les conteneurs du pod ont terminé avec succès et ne seront pas redémarrés. +`Failed` | Tous 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. +`Unknown` | Pour 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](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) +à travers lesquelles le Pod est ou non passé. Chaque élément +du tableau de PodCondition a six champs possibles : + +* Le champ `lastProbeTime` fournit un timestamp auquel la condition du Pod + a été sondée pour la dernière fois. + +* Le champ `lastTransitionTime` fournit un timestamp auquel le Pod a changé de statut + pour la dernière fois. + +* Le champ `message` est un message lisible indiquant les détails de la transition. + +* Le champ `reason` est une raison unique, en un seul mot et en CamelCase de la transition + vers la dernière condition. + +* Le champ `status` est une chaîne de caractères avec les valeurs possibles "`True`", "`False`", et "`Unknown`". + +* Le champ `type` est une chaîne de caractères ayant une des valeurs suivantes : + + * `PodScheduled` : le Pod a été affecté à un nœud ; + * `Ready` : le Pod est prêt à servir des requêtes et doit être rajouté aux équilibreurs + de charge de tous les Services correspondants ; + * `Initialized` : tous les [init containers](/docs/concepts/workloads/pods/init-containers) + ont démarré correctement ; + * `Unschedulable` : le scheduler ne peut pas affecter le Pod pour l'instant, par exemple + par manque de ressources ou en raison d'autres contraintes ; + * `ContainersReady` : tous les conteneurs du Pod sont prêts. + + + +## Sondes du Conteneur + +Une [Sonde](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) (Probe) est un diagnostic +exécuté périodiquement par [kubelet](/docs/admin/kubelet/) +sur un Conteneur. Pour exécuter un diagnostic, kubelet appelle un +[Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implémenté par +le Conteneur. Il existe trois types de handlers : + +* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): + Exécute la commande spécifiée à l'intérieur du Conteneur. Le diagnostic + est considéré réussi si la commande se termine avec un code de retour de 0. + +* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): + Exécute un contrôle TCP sur l'adresse IP du Conteneur et sur un port spécifié. + Le diagnostic est considéré réussi si le port est ouvert. + +* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): + Exécute une requête HTTP Get sur l'adresse IP du Conteneur et sur un port et + un chemin spécifiés. Le diagnostic est considéré réussi si la réponse a un code + de retour supérieur ou égal à 200 et inférieur à 400. + +Chaque sonde a un résultat parmi ces trois : + +* Success: Le Conteneur a réussi le diagnostic. +* Failure: Le Conteneur a échoué au diagnostic. +* Unknown: L'exécution du diagnostic a échoué, et donc aucune action ne peut être prise. + +kubelet peut optionnellement exécuter et réagir à deux types de sondes sur des conteneurs +en cours d'exécution : + +* `livenessProbe` : Indique si le Conteneur est en cours d'exécution. Si + la liveness probe échoue, kubelet tue le Conteneur et le Conteneur + est soumis à sa [politique de redémarrage](#restart-policy) (restart policy). + Si un Conteneur ne fournit pas de liveness probe, l'état par défaut est `Success`. + +* `readinessProbe` : Indique si le Conteneur est prêt à servir des requêtes. + Si la readiness probe échoue, le contrôleur de points de terminaison (Endpoints) + retire l'adresse IP du Pod des points de terminaison de tous les Services + correspodant au Pod. L'état par défaut avant le délai initial est + `Failure`. Si le Conteneur ne fournit pas de readiness probe, l'état par + défaut est `Success`. + +### 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](/docs/tasks/configure-pod-container/configure-liveness-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](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) +et +[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core). +Notez que l'information rapportée comme statut d'un Pod dépend du +[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core) 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. + +* `Waiting` : état du conteneur par défaut. Si le conteneur n'est pas dans un état Running ou Terminated, il est dans l'état Waiting. Un conteneur dans l'état Waiting exécute +les opérations nécessaires, comme télécharger les images, appliquer des Secrets, etc. À côté +de cet état, un message et une raison sur l'état sont affichés pour vous fournir plus +d'informations. + + ```yaml + ... + State: Waiting + Reason: ErrImagePull + ... + ``` + +* `Running` : Indique que le conteneur s'exécute sans problème. Une fois qu'un centeneur est +dans l'état Running, le hook `postStart` est exécuté (s'il existe). Cet état affiche aussi +le moment auquel le conteneur est entré dans l'état Running. + + ```yaml + ... + State: Running + Started: Wed, 30 Jan 2019 16:46:38 +0530 + ... + ``` + +* `Terminated`: Indique que le conteneur a terminé son exécution et s'est arrêté. +Un conteneur entre dans cet état lorsqu'il s'est exécuté avec succès ou lorsqu'il a +échoué pour une raison quelconque. De plus, une raison et un code de retour sont affichés, +ainsi que les moments de démarrage et d'arrêt du conteneur. Avant qu'un conteneur entre +dans l'état Terminated, le hook `preStop` est exécuté (s'il existe). + + ```yaml + ... + 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 for_k8s_version="v1.14" state="stable" >}} + +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++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md). +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 : + +```yaml +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](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) 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](/docs/reference/using-api/client-libraries/). + +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 : + +* Tous les conteneurs du Pod sont prêts. +* Toutes les conditions spécifiées dans `ReadinessGates` sont à "`True`". + +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](/docs/reference/command-line-tools-reference/feature-gates/) `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](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof), +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 : + +- Utilisez un [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) pour des +Pods qui doivent se terminer, par exemple des calculs par batch. Les Jobs sont appropriés +seulement pour des Pods ayant `restartPolicy` égal à OnFailure ou Never. + +- Utilisez un [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/), + [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) ou + [Deployment](/docs/concepts/workloads/controllers/deployment/) + pour des Pods qui ne doivent pas s'arrêter, par exemple des serveurs web. + ReplicationControllers sont appropriés pour des Pods ayant `restartPolicy` égal à + Always. + +- Utilisez un [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) pour des Pods + qui doivent s'exécuter une fois par machine, car ils fournissent un service système + au niveau de la machine. + +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. + +```yaml +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 + + * Un Pod est en cours d'exécution et a un Conteneur. Le conteneur se termine avec succès. + * Écriture d'un événement de complétion. + * Si `restartPolicy` est : + * Always : Redémarrage du Conteneur ; la `phase` du Pod reste à Running. + * OnFailure : la `phase` du Pod passe à Succeeded. + * Never : la `phase` du Pod passe à Succeeded. + + * Un Pod est en cours d'exécution et a un Conteneur. Le conteneur se termine en erreur. + * Écriture d'un événement d'échec. + * Si `restartPolicy` est : + * Always : Redémarrage du Conteneur ; la `phase` du Pod reste à Running. + * OnFailure : Redémarrage du Conteneur ; la `phase` du Pod reste à Running. + * Never : la `phase` du Pod passe à Failed. + + * Un Pod est en cours d'exécution et a deux Conteneurs. Le conteneur 1 termine en erreur. + * Écriture d'un événement d'échec. + * Si `restartPolicy` est : + * Always : Redémarrage du Conteneur ; la `phase` du Pod reste à Running. + * OnFailure : Redémarrage du Conteneur ; la `phase` du Pod reste à Running. + * Never : Le Conteneur n'est pas redémarré ; la `phase` du Pod reste à Running. + * Si Container 1 est arrêté, et Conteneur 2 se termine : + * Écriture d'un événement d'échec. + * Si `restartPolicy` est : + * Always : Redémarrage du Conteneur ; la `phase` du Pod reste à Running. + * OnFailure : Redémarrage du Conteneur ; la `phase` du Pod reste à Running. + * Never : la `phase` du Pod passe à Failed. + + * Un Pod est en cours d'exécution et a un Conteneur. Le Conteneur n'a plus assez de mémoire. + * Le Conteneur se termine en erreur. + * Écriture d'un événement OOM. + * Si `restartPolicy` est : + * Always : Redémarrage du Conteneur ; la `phase` du Pod reste à Running. + * OnFailure : Redémarrage du Conteneur ; la `phase` du Pod reste à Running. + * Never : Écriture d'un événement d'erreur ; la `phase` du Pod passe à Failed. + + * Le Pod est en cours d'exécution, et un disque meurt. + * Tous les conteneurs sont tués. + * Écriture d'un événement approprié. + * La `phase` du Pod devient Failed. + * Si le Pod s'exécute sous un contrôleur, le Pod est recréé ailleurs. + + * Le Pod est en cours d'exécution et son nœud est segmenté. + * Le contrôleur de Nœud attend un certain temps. + * Le contrôleur de Nœud passe la `phase` du Pod à Failed. + * Si le Pod s'exécute sous un contrôleur, le Pod est recréé ailleurs. + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* Apprenez par la pratique + [attacher des handlers à des événements de cycle de vie d'un conteneur](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). + +* Apprenez par la pratique + [configurer des liveness et readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). + +* En apprendre plus sur les [hooks de cycle de vie d'un Conteneur](/docs/concepts/containers/container-lifecycle-hooks/). + +{{% /capture %}} + + +