Merge pull request #21125 from feloy/feloy-1-19-pods
Translation update for Pods
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
cfefda4a79
|
|
@ -63,10 +63,8 @@ du tableau de PodCondition a six champs possibles :
|
|||
* `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)
|
||||
* `Initialized` : tous les [init containers](/fr/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.
|
||||
|
||||
|
||||
|
|
@ -98,12 +96,12 @@ Chaque sonde a un résultat parmi ces trois :
|
|||
* 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
|
||||
kubelet peut optionnellement exécuter et réagir à trois 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).
|
||||
est soumis à sa [politique de redémarrage](#politique-de-redemarrage) (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.
|
||||
|
|
@ -113,7 +111,13 @@ en cours d'exécution :
|
|||
`Failure`. Si le Conteneur ne fournit pas de readiness probe, l'état par
|
||||
défaut est `Success`.
|
||||
|
||||
### Quand devez-vous utiliser une liveness ou une readiness probe ?
|
||||
* `startupProbe`: Indique si l'application à l'intérieur du conteneur a démarré.
|
||||
Toutes les autres probes sont désactivées si une starup probe est fournie,
|
||||
jusqu'à ce qu'elle réponde avec succès. Si la startup probe échoue, le kubelet
|
||||
tue le conteneur, et le conteneur est assujetti à sa [politique de redémarrage](#politique-de-redemarrage).
|
||||
Si un conteneur ne fournit pas de startup probe, l'état par défaut est `Success`.
|
||||
|
||||
### Quand devez-vous utiliser une liveness 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
|
||||
|
|
@ -124,6 +128,10 @@ Si vous désirez que votre Conteneur soit tué et redémarré si une sonde écho
|
|||
spécifiez une liveness probe et indiquez une valeur pour `restartPolicy` à Always
|
||||
ou OnFailure.
|
||||
|
||||
### Quand devez-vous utiliser une readiness probe ?
|
||||
|
||||
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
|
||||
|
||||
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
|
||||
|
|
@ -142,8 +150,16 @@ 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/).
|
||||
### Quand devez-vous utiliser une startup probe ?
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
|
||||
Si votre conteneur démarre habituellement en plus de `initialDelaySeconds + failureThreshold × periodSeconds`,
|
||||
vous devriez spécifier une startup probe qui vérifie le même point de terminaison que la liveness probe. La valeur par défaut pour `periodSeconds` est 30s.
|
||||
Vous devriez alors mettre sa valeur `failureThreshold` suffisamment haute pour permettre au conteneur de démarrer, sans changer les valeurs par défaut de la liveness probe. Ceci aide à se protéger de deadlocks.
|
||||
|
||||
Pour plus d'informations sur la manière de mettre en place une liveness, readiness ou startup probe,
|
||||
voir [Configurer des Liveness, Readiness et Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
|
||||
|
||||
## Statut d'un Pod et d'un Conteneur
|
||||
|
||||
|
|
@ -172,9 +188,7 @@ d'informations.
|
|||
...
|
||||
```
|
||||
|
||||
* `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.
|
||||
* `Running` : Indique que le conteneur s'exécute sans problème. Le hook `postStart` (s'il existe) est exécuté avant que le conteneur entre dans l'état Running. Cet état affiche aussi le moment auquel le conteneur est entré dans l'état Running.
|
||||
|
||||
```yaml
|
||||
...
|
||||
|
|
@ -199,27 +213,30 @@ dans l'état Terminated, le hook `preStop` est exécuté (s'il existe).
|
|||
...
|
||||
```
|
||||
|
||||
## Pod readiness gate
|
||||
## Pod readiness {#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 :
|
||||
Votre application peut injecter des données dans `PodStatus`.
|
||||
|
||||
_Pod readiness_. Pour utiliser cette fonctionnalité, remplissez `readinessGates` dans le PodSpec avec
|
||||
une liste de conditions supplémentaires que le kubelet évalue pour la disponibilité du Pod.
|
||||
|
||||
Les Readiness gates sont déterminées par l'état courant des champs `status.condition` du Pod.
|
||||
Si Kubernetes ne peut pas trouver une telle condition dans le champs `status.conditions` d'un Pod, the statut de la condition
|
||||
est mise par défaut à "`False`".
|
||||
|
||||
Voici un exemple :
|
||||
|
||||
```yaml
|
||||
Kind: Pod
|
||||
kind: Pod
|
||||
...
|
||||
spec:
|
||||
readinessGates:
|
||||
- conditionType: "www.example.com/feature-1"
|
||||
status:
|
||||
conditions:
|
||||
- type: Ready # ceci est une builtin PodCondition
|
||||
- type: Ready # une PodCondition intégrée
|
||||
status: "False"
|
||||
lastProbeTime: null
|
||||
lastTransitionTime: 2018-01-01T00:00:00Z
|
||||
|
|
@ -233,27 +250,26 @@ status:
|
|||
...
|
||||
```
|
||||
|
||||
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/).
|
||||
Les conditions du Pod que vous ajoutez doivent avoir des noms qui sont conformes au [format des étiquettes](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) de Kubernetes.
|
||||
|
||||
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 :
|
||||
### Statut de la disponibilité d'un Pod {#statut-pod-disponibilité}
|
||||
|
||||
La commande `kubectl patch` ne peut pas patcher le statut d'un objet.
|
||||
Pour renseigner ces `status.conditions` pour le pod, les applications et
|
||||
{{< glossary_tooltip term_id="operator-pattern" text="operators">}} doivent utiliser l'action `PATCH`.
|
||||
Vous pouvez utiliser une [bibliothèque client Kubernetes](/docs/reference/using-api/client-libraries/) pour
|
||||
écrire du code qui renseigne les conditions particulières pour la disponibilité dun Pod.
|
||||
|
||||
Pour un Pod utilisant des conditions particulières, ce Pod est considéré prêt **seulement**
|
||||
lorsque les deux déclarations ci-dessous sont vraies :
|
||||
|
||||
* Tous les conteneurs du Pod sont prêts.
|
||||
* Toutes les conditions spécifiées dans `ReadinessGates` sont à "`True`".
|
||||
* 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.
|
||||
Lorsque les conteneurs d'un Pod sont prêts mais qu'au moins une condition particulière
|
||||
est manquante ou `False`, le kubelet renseigne la condition du Pod à `ContainersReady`.
|
||||
|
||||
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
|
||||
## Politique de redémarrage
|
||||
|
||||
La structure PodSpec a un champ `restartPolicy` avec comme valeur possible
|
||||
Always, OnFailure et Never. La valeur par défaut est Always.
|
||||
|
|
@ -267,33 +283,30 @@ 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.
|
||||
En général, les Pods restent jusqu'à ce qu'un humain ou un process de
|
||||
{{< glossary_tooltip term_id="controller" text="contrôleur" >}} les supprime explicitement.
|
||||
|
||||
Trois types de contrôleurs sont disponibles :
|
||||
Le plan de contrôle nettoie les Pods terminés (avec une phase à `Succeeded` ou
|
||||
`Failed`), lorsque le nombre de Pods excède le seuil configuré
|
||||
(determiné par `terminated-pod-gc-threshold` dans le kube-controller-manager).
|
||||
Ceci empêche une fuite de ressources lorsque les Pods sont créés et supprimés au fil du temps.
|
||||
|
||||
- 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
|
||||
Il y a différents types de ressources pour créer des Pods :
|
||||
|
||||
- Utilisez un {{< glossary_tooltip term_id="deployment" >}},
|
||||
{{< glossary_tooltip term_id="replica-set" >}} ou {{< glossary_tooltip term_id="statefulset" >}}
|
||||
pour les Pods qui ne sont pas censés terminer, par exemple des serveurs web.
|
||||
|
||||
- Utilisez un {{< glossary_tooltip term_id="job" >}}
|
||||
pour les Pods qui sont censés se terminer une fois leur tâche accomplie. 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 {{< glossary_tooltip term_id="daemonset" >}}
|
||||
pour les Pods qui doivent s'exécuter sur chaque noeud éligible.
|
||||
|
||||
- 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.
|
||||
Toutes les ressources de charges de travail contiennent une PodSpec. Il est recommandé de créer
|
||||
la ressource de charges de travail appropriée et laisser le contrôleur de la ressource créer les Pods
|
||||
pour vous, plutôt que de créer directement les Pods vous-même.
|
||||
|
||||
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.
|
||||
|
|
@ -391,7 +404,7 @@ spec:
|
|||
[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/).
|
||||
[configurer des liveness, readiness et startup probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
|
||||
|
||||
* En apprendre plus sur les [hooks de cycle de vie d'un Conteneur](/docs/concepts/containers/container-lifecycle-hooks/).
|
||||
|
||||
|
|
|
|||
|
|
@ -16,23 +16,18 @@ Cette page fournit un aperçu du `Pod`, l'objet déployable le plus petit dans l
|
|||
|
||||
## Comprendre les Pods
|
||||
|
||||
Un *Pod* est l'unité d'exécution de base d'une application Kubernetes--l'unité la plus petite et la plus simple dans le modèle d'objets de Kubernetes--que vous créez ou déployez. Un Pod représente des process en cours d'exécution dans votre {{< glossary_tooltip term_id="cluster" >}}.
|
||||
Un *Pod* est l'unité d'exécution de base d'une application Kubernetes--l'unité la plus petite et la plus simple dans le modèle d'objets de Kubernetes--que vous créez ou déployez. Un Pod représente des process en cours d'exécution dans votre {{< glossary_tooltip term_id="cluster" text="cluster" >}}.
|
||||
|
||||
Un Pod encapsule un conteneur applicatif (ou, dans certains cas, plusieurs conteneurs), des ressources de stockage, une IP réseau unique, et des options qui contrôlent comment le ou les conteneurs doivent s'exécuter. Un Pod représente une unité de déploiement : *une instance unique d'une application dans Kubernetes*, qui peut consister soit en un unique {{< glossary_tooltip text="container" term_id="container" >}} soit en un petit nombre de conteneurs qui sont étroitement liés et qui partagent des ressources.
|
||||
Un Pod encapsule un conteneur applicatif (ou, dans certains cas, plusieurs conteneurs), des ressources de stockage, une identité réseau (adresse IP) unique, ainsi que des options qui contrôlent comment le ou les conteneurs doivent s'exécuter. Un Pod représente une unité de déploiement : *une instance unique d'une application dans Kubernetes*, qui peut consister soit en un unique {{< glossary_tooltip text="container" term_id="container" >}} soit en un petit nombre de conteneurs qui sont étroitement liés et qui partagent des ressources.
|
||||
|
||||
> [Docker](https://www.docker.com) est le runtime de conteneurs le plus courant utilisé dans un Pod Kubernetes, mais les Pods prennent également en charge d'autres [runtimes de conteneurs](https://kubernetes.io/docs/setup/production-environment/container-runtimes/).
|
||||
> [Docker](https://www.docker.com) est le runtime de conteneurs le plus courant utilisé dans un Pod Kubernetes, mais les Pods prennent également en charge d'autres [runtimes de conteneurs](/docs/setup/production-environment/container-runtimes/).
|
||||
|
||||
Les Pods dans un cluster Kubernetes peuvent être utilisés de deux manières différentes :
|
||||
|
||||
* **les Pods exécutant un conteneur unique**. Le modèle "un-conteneur-par-Pod" est le cas d'utilisation Kubernetes le plus courant ; dans ce cas, vous pouvez voir un Pod comme un wrapper autour d'un conteneur unique, et Kubernetes gère les Pods plutôt que directement les conteneurs.
|
||||
* **les Pods exécutant plusieurs conteneurs devant travailler ensemble**. Un Pod peut encapsuler une application composée de plusieurs conteneurs co-localisés qui sont étroitement liés et qui doivent partager des ressources. Ces conteneurs co-localisés pourraient former une unique unité de service cohésive--un conteneur servant des fichiers d'un volume partagé au public, alors qu'un conteneur "sidecar" séparé rafraîchit ou met à jour ces fichiers. Le Pod enveloppe ensemble ces conteneurs et ressources de stockage en une entité maniable de base.
|
||||
|
||||
Le [Blog Kubernetes](http://kubernetes.io/blog) contient quelques informations supplémentaires sur les cas d'utilisation des Pods. Pour plus d'informations, voir :
|
||||
|
||||
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
|
||||
* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
|
||||
|
||||
Chaque Pod est destiné à exécuter une instance unique d'une application donnée. Si vous désirez mettre à l'échelle votre application horizontalement, (par ex., exécuter plusieurs instances), vous devez utiliser plusieurs Pods, un pour chaque instance. Dans Kubernetes, on parle généralement de _réplication_. Des Pods répliqués sont en général créés et gérés comme un groupe par une abstraction appelée Controller. Voir [Pods et Controllers](#pods-and-controllers) pour plus d'informations.
|
||||
Chaque Pod est destiné à exécuter une instance unique d'une application donnée. Si vous désirez mettre à l'échelle votre application horizontalement, (pour fournir plus de ressources au global en exécutant plus d'instances), vous devez utiliser plusieurs Pods, un pour chaque instance. Dans Kubernetes, on parle typiquement de _réplication_. Des Pods répliqués sont en général créés et gérés en tant que groupe par une ressource de charge de travail et son {{< glossary_tooltip text="_contrôleur_" term_id="controller" >}}. Voir [Pods et contrôleurs](#pods-et-controleurs) pour plus d'informations.
|
||||
|
||||
### Comment les Pods gèrent plusieurs conteneurs
|
||||
|
||||
|
|
@ -48,61 +43,76 @@ Les Pods fournissent deux types de ressources partagées pour leurs conteneurs :
|
|||
|
||||
#### Réseau
|
||||
|
||||
Chaque Pod se voit assigner une adresse IP unique. Tous les conteneurs d'un Pod partagent le même namespace réseau, y compris l'adresse IP et les ports réseau. Les conteneurs *à l'intérieur d'un Pod* peuvent communiquer entre eux en utilisant `localhost`. Lorsque les conteneurs dans un Pod communiquent avec des entités *en dehors du Pod*, ils doivent coordonner comment ils utilisent les ressources réseau partagées (comme les ports).
|
||||
Chaque Pod se voit assigner une adresse IP unique pour chaque famille d'adresses. Tous les conteneurs d'un Pod partagent le même namespace réseau, y compris l'adresse IP et les ports réseau. Les conteneurs *à l'intérieur d'un Pod* peuvent communiquer entre eux en utilisant `localhost`. Lorsque les conteneurs dans un Pod communiquent avec des entités *en dehors du Pod*, ils doivent coordonner comment ils utilisent les ressources réseau partagées (comme les ports).
|
||||
|
||||
#### Stockage
|
||||
|
||||
Un Pod peut spécifier un jeu de {{< glossary_tooltip text="Volumes" term_id="volume" >}} de stockage partagés. Tous les conteneurs dans le Pod peuvent accéder aux volumes partagés, permettant à ces conteneurs de partager des données. Les volumes permettent aussi les données persistantes d'un Pod de survivre au cas où un des conteneurs doit être redémarré. Voir [Volumes](/docs/concepts/storage/volumes/) pour plus d'informations sur la façon dont Kubernetes implémente le stockage partagé dans un Pod.
|
||||
Un Pod peut spécifier un jeu de {{< glossary_tooltip text="volumes" term_id="volume" >}} de stockage partagés. Tous les conteneurs dans le Pod peuvent accéder aux volumes partagés, permettant à ces conteneurs de partager des données. Les volumes permettent aussi les données persistantes d'un Pod de survivre au cas où un des conteneurs doit être redémarré. Voir [Volumes](/docs/concepts/storage/volumes/) pour plus d'informations sur la façon dont Kubernetes implémente le stockage partagé dans un Pod.
|
||||
|
||||
## Travailler avec des Pods
|
||||
|
||||
Vous aurez rarement à créer directement des Pods individuels dans Kubernetes--même des Pods à un seul conteneur. Ceci est dû au fait que les Pods sont conçus comme des entités relativement éphémères et jetables. Lorsqu'un Pod est créé (directement par vous ou indirectement par un Controller), il est programmé pour s'exécuter sur un {{< glossary_tooltip term_id="node" >}} dans votre cluster. Le Pod reste sur ce Nœud jusqu'à ce que le process se termine, l'objet pod soit supprimé, le pod soit *expulsé* par manque de ressources, ou le Nœud soit en échec.
|
||||
Vous aurez rarement à créer directement des Pods individuels dans Kubernetes--même des Pods à un seul conteneur. Ceci est dû au fait que les Pods sont conçus comme des entités relativement éphémères et jetables. Lorsqu'un Pod est créé (directement par vous ou indirectement par un {{< glossary_tooltip text="_contrôleur_" term_id="controller" >}}), il est programmé pour s'exécuter sur un {{< glossary_tooltip term_id="node" >}} dans votre cluster. Le Pod reste sur ce nœud jusqu'à ce que le process se termine, l'objet pod soit supprimé, le pod soit *expulsé* par manque de ressources, ou le nœud soit en échec.
|
||||
|
||||
{{< note >}}
|
||||
Redémarrer un conteneur dans un Pod ne doit pas être confondu avec redémarrer le Pod. Le Pod lui-même ne s'exécute pas, mais est un environnement dans lequel les conteneurs s'exécutent, et persiste jusqu'à ce qu'il soit supprimé.
|
||||
Redémarrer un conteneur dans un Pod ne doit pas être confondu avec redémarrer un Pod. Un Pod n'est pas un process, mais un environnement pour exécuter un conteneur. Un Pod persiste jusqu'à ce qu'il soit supprimé.
|
||||
{{< /note >}}
|
||||
|
||||
Les Pods ne se guérissent pas par eux-mêmes. Si un Pod est programmé sur un Nœud qui échoue, ou si l'opération de programmation elle-même échoue, le Pod est supprimé ; de plus, un Pod ne survivra pas à une expulsion due à un manque de ressources ou une mise en maintenance du Nœud. Kubernetes utilise une abstraction de plus haut niveau, appelée un *Controller*, qui s'occupe de gérer les instances de Pods relativement jetables. Ainsi, même s'il est possible d'utiliser des Pods directement, il est beaucoup plus courant dans Kubernetes de gérer vos Pods en utilisant un Controller. Voir [Pods et Controllers](#pods-and-controllers) pour plus d'informations sur la façon dont Kubernetes utilise des Controllers pour implémenter la mise à l'échelle et la guérison des Pods.
|
||||
Les Pods ne se guérissent pas par eux-mêmes. Si un Pod est programmé sur un Nœud qui échoue, ou si l'opération de programmation elle-même échoue, le Pod est supprimé ; de plus, un Pod ne survivra pas à une expulsion due à un manque de ressources ou une mise en maintenance du Nœud. Kubernetes utilise une abstraction de plus haut niveau, appelée un *contrôleur*, qui s'occupe de gérer les instances de Pods relativement jetables. Ainsi, même s'il est possible d'utiliser des Pods directement, il est beaucoup plus courant dans Kubernetes de gérer vos Pods en utilisant un contrôleur.
|
||||
|
||||
### Pods et Controllers
|
||||
### Pods et contrôleurs
|
||||
|
||||
Un Controller peut créer et gérer plusieurs Pods pour vous, s'occupant de la réplication et du déploiement et fournissant des capacités d'auto-guérison au niveau du cluster. Par exemple, si un Nœud échoue, le Controller peut automatiquement remplacer le Pod en programmant un remplaçant identique sur un Nœud différent.
|
||||
Vous pouvez utiliser des ressources de charges de travail pour créer et gérer plusieurs Pods pour vous. Un contrôleur pour la ressource gère la réplication,
|
||||
le plan de déploiement et la guérison automatique en cas de problèmes du Pod. Par exemple, si un noeud est en échec, un contrôleur note que les Pods de ce noeud
|
||||
ont arrêté de fonctionner et créent des Pods pour les remplacer. L'ordonnanceur place le Pod de remplacement sur un noeud en fonctionnement.
|
||||
|
||||
Quelques exemples de Controllers qui contiennent un ou plusieurs pods :
|
||||
Voici quelques exemples de ressources de charges de travail qui gèrent un ou plusieurs Pods :
|
||||
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
|
||||
|
||||
En général, les Controllers utilisent des Templates de Pod que vous lui fournissez pour créer les Pods dont il est responsable.
|
||||
* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
|
||||
* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
|
||||
* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
|
||||
|
||||
## Templates de Pod
|
||||
|
||||
Les Templates de Pod sont des spécifications de pod qui sont inclus dans d'autres objets, comme les
|
||||
[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), et
|
||||
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Les Controllers utilisent les Templates de Pod pour créer réellement les pods.
|
||||
L'exemple ci-dessous est un manifeste simple pour un Pod d'un conteneur affichant un message.
|
||||
Les Templates de Pod sont des spécifications pour créer des Pods, et sont inclus dans les ressources de charges de travail comme
|
||||
les [Deployments](/fr/docs/concepts/workloads/controllers/deployment/), les [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/) et
|
||||
les [DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
|
||||
|
||||
Chaque contrôleur pour une ressource de charges de travail utilise le template de pod à l'intérieur de l'objet pour créer les Pods. Le template de pod fait partie de l'état désiré de la ressource de charges de travail que vous avez utilisé pour exécuter votre application.
|
||||
|
||||
L'exemple ci-dessous est un manifest pour un Job simple avec un `template` qui démarre un conteneur. Le conteneur dans ce Pod affiche un message puis se met en pause.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
name: myapp-pod
|
||||
labels:
|
||||
app: myapp
|
||||
name: hello
|
||||
spec:
|
||||
containers:
|
||||
- name: myapp-container
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
|
||||
template:
|
||||
# Ceci est un template de pod
|
||||
spec:
|
||||
containers:
|
||||
- name: hello
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
|
||||
restartPolicy: OnFailure
|
||||
# Le template de pod se termine ici
|
||||
```
|
||||
Plutôt que de spécifier tous les états désirés courants de tous les réplicas, les templates de pod sont comme des emporte-pièces. Une fois qu'une pièce a été coupée, la pièce n'a plus de relation avec l'outil. Il n'y a pas de lien qui persiste dans le temps entre le template et le pod. Un changement à venir dans le template ou même le changement pour un nouveau template n'a pas d'effet direct sur les pods déjà créés. De manière similaire, les pods créés par un replication controller peuvent par la suite être modifiés directement. C'est en contraste délibéré avec les pods, qui spécifient l'état désiré courant de tous les conteneurs appartenant au pod. Cette approche simplifie radicalement la sémantique système et augmente la flexibilité de la primitive.
|
||||
|
||||
Modifier le template de pod ou changer pour un nouvau template de pod n'a pas d'effet sur les pods déjà existants. Les Pods ne reçoivent pas une mise à jour
|
||||
du template directement ; au lieu de cela, un nouveau Pod est créé pour correspondre au nouveau template de pod.
|
||||
|
||||
Par exemple, un contrôleur de Deployment s'assure que les Pods en cours d'exécution correspondent au template de pod en cours. Si le template est mis à jour,
|
||||
le contrôleur doit supprimer les pods existants et créer de nouveaux Pods avec le nouveau template. Chaque contrôleur de charges de travail implémente ses propres
|
||||
règles pour gérer les changements du template de Pod.
|
||||
|
||||
Sur les noeuds, le {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} n'observe ou ne gère pas directement les détails concernant les templates de pods et leurs mises à jours ; ces détails sont abstraits. Cette abstraction et cette séparation des préoccupations simplifie la sémantique du système, et rend possible l'extension du comportement du cluster sans changer le code existant.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* En savoir plus sur les [Pods](/docs/concepts/workloads/pods/pod/)
|
||||
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explique les dispositions courantes pour des Pods avec plusieurs conteneurs
|
||||
* En savoir plus sur le comportement des Pods :
|
||||
* [Terminaison d'un Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
* [Cycle de vie d'un Pod](/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
|
|
|
|||
|
|
@ -164,7 +164,7 @@ Un exemple de déroulement :
|
|||
1. Le Pod dans l'API server est mis à jour avec le temps au delà duquel le Pod est considéré "mort" ainsi que la période de grâce.
|
||||
1. Le Pod est affiché comme "Terminating" dans les listes des commandes client
|
||||
1. (en même temps que 3) Lorsque Kubelet voit qu'un Pod a été marqué "Terminating", le temps ayant été mis en 2, il commence le processus de suppression du pod.
|
||||
1. Si un des conteneurs du Pod a défini un [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), il est exécuté à l'intérieur du conteneur. Si le `preStop` hook est toujours en cours d'exécution à la fin de la période de grâce, l'étape 2 est invoquée avec une courte (2 secondes) période de grâce supplémentaire.
|
||||
1. Si un des conteneurs du Pod a défini un [preStop hook](/fr/docs/concepts/containers/container-lifecycle-hooks/#hook-details), il est exécuté à l'intérieur du conteneur. Si le `preStop` hook est toujours en cours d'exécution à la fin de la période de grâce, l'étape 2 est invoquée avec une courte (2 secondes) période de grâce supplémentaire une seule fois. Vous devez modifier `terminationGracePeriodSeconds` si le hook `preStop` a besoin de plus de temps pour se terminer.
|
||||
1. Le signal TERM est envoyé aux conteneurs. Notez que tous les conteneurs du Pod ne recevront pas le signal TERM en même temps et il peut être nécessaire de définir des `preStop` hook si l'ordre d'arrêt est important.
|
||||
1. (en même temps que 3) Le Pod est supprimé des listes d'endpoints des services, et n'est plus considéré comme faisant partie des pods en cours d'exécution pour les contrôleurs de réplication. Les Pods s'arrêtant lentement ne peuvent pas continuer à servir du trafic, les load balancers (comme le service proxy) les supprimant de leurs rotations.
|
||||
1. Lorsque la période de grâce expire, les processus s'exécutant toujours dans le Pod sont tués avec SIGKILL.
|
||||
|
|
@ -186,7 +186,6 @@ Si le master exécute Kubernetes v1.1 ou supérieur, et les nœuds exécutent un
|
|||
Si l'utilisateur appelle `kubectl describe pod FooPodName`, l'utilisateur peut voir la raison pour laquelle le pod est en état "pending". La table d'événements dans la sortie de la commande "describe" indiquera :
|
||||
`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
|
||||
|
||||
|
||||
Si le master exécute une version antérieure à v1.1, les pods privilégiés ne peuvent alors pas être créés. Si l'utilisateur tente de créer un pod ayant un conteneur privilégié, l'utilisateur obtiendra l'erreur suivante :
|
||||
`The Pod "FooPodName" is invalid.
|
||||
spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'`
|
||||
|
|
@ -196,4 +195,4 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'
|
|||
Le Pod est une ressource au plus haut niveau dans l'API REST Kubernetes. Plus de détails sur l'objet de l'API peuvent être trouvés à :
|
||||
[Objet de l'API Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
|
||||
|
||||
|
||||
Lorsque vous créez un manifest pour un objet Pod, soyez certain que le nom spécifié est un [nom de sous-domaine DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) valide.
|
||||
|
|
|
|||
Loading…
Reference in New Issue