Yushiro FURUKAWA
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
3b10c76ca7
commit
2a120450eb
@@ -25,35 +25,35 @@ Les init containers se comportent comme les conteneurs réguliers, avec quelques
|
||||
Si le init container d'un Pod échoue, Kubernetes redémarre le Pod à répétition jusqu'à ce que le init container se termine avec succès.
|
||||
Cependant, si le Pod a une `restartPolicy` à "Never", Kubernetes ne redémarre pas le Pod.
|
||||
|
||||
Afin de spécifier un init container pour un Pod, il faut ajouter le champ `initContainers` dans la spécification du Pod, comme un
|
||||
tableau d'objets de type [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core), au même niveau que le tableau d'applications `containers`.
|
||||
Le statut des init containers est retourné dans le champ `.status.initContainerStatuses`
|
||||
Afin de spécifier un init container pour un Pod, il faut ajouter le champ `initContainers` dans la spécification du Pod, comme un
|
||||
tableau d'objets de type [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core), au même niveau que le tableau d'applications `containers`.
|
||||
Le statut des init containers est retourné dans le champ `.status.initContainerStatuses`
|
||||
comme un tableau des statuts du conteneur (comparable au champ `.status.containerStatuses`).
|
||||
|
||||
### Différences avec les conteneurs réguliers
|
||||
|
||||
Les init containers supportent tous les champs et fonctionnalités des conteneurs d'application
|
||||
incluant les limites de ressources, les volumes et les paramètres de sécurité.
|
||||
Cependant, les demandes de ressources pour un init container sont gérées différemment des
|
||||
Les init containers supportent tous les champs et fonctionnalités des conteneurs d'application
|
||||
incluant les limites de ressources, les volumes et les paramètres de sécurité.
|
||||
Cependant, les demandes de ressources pour un init container sont gérées différemment des
|
||||
limites de ressources, tel que documenté dans [Ressources](#ressources).
|
||||
|
||||
De plus, les init containers ne supportent pas les readiness probes parce que ces conteneurs
|
||||
De plus, les init containers ne supportent pas les readiness probes parce que ces conteneurs
|
||||
s'exécutent jusqu'au bout avant que le Pod soit prêt.
|
||||
|
||||
Si l'on spécifie plusieurs init containers pour un Pod, Kubelet exécute chaque
|
||||
init container de manière séquentielle.
|
||||
Chaque init container doit se terminer avec succès avant que le prochain ne puisse s'exécuter.
|
||||
Lorsque tous les init containers se sont exécutés jusqu'au bout, Kubelet initialise
|
||||
Lorsque tous les init containers se sont exécutés jusqu'au bout, Kubelet initialise
|
||||
les conteneurs d'application pour le Pod et les exécute comme d'habitude.
|
||||
|
||||
## Utiliser les init containers
|
||||
|
||||
Puisque les init containers ont des images séparées des conteneurs d'application,
|
||||
Puisque les init containers ont des images séparées des conteneurs d'application,
|
||||
ils apportent certains avantages pour du code de mise en route :
|
||||
|
||||
* Les init containers peuvent contenir des utilitaires ou du code de configuration personnalisé
|
||||
qui ne sont pas présents dans une image d'application.
|
||||
Par exemple, il n'y a pas besoin de faire hériter une image d'une autre (`FROM`) seulement pour utiliser
|
||||
* Les init containers peuvent contenir des utilitaires ou du code de configuration personnalisé
|
||||
qui ne sont pas présents dans une image d'application.
|
||||
Par exemple, il n'y a pas besoin de faire hériter une image d'une autre (`FROM`) seulement pour utiliser
|
||||
un outil comme `sed`, `awk`, `python`, ou `dig` pendant l'installation.
|
||||
* Les init containers peuvent exécuter en toute sécurité des utilitaires qui rendraient moins sécurisée une image de conteneur d'application.
|
||||
* Les rôles "builder" et "deployer" d'une image d'application peuvent travailler indépendamment sans qu'il n'y ait besoin
|
||||
@@ -67,7 +67,7 @@ offrent un mécanisme pour bloquer ou retarder le démarrage d'un conteneur d'ap
|
||||
Voici plusieurs idées pour utiliser les init containers :
|
||||
|
||||
* Attendre qu'un {{< glossary_tooltip text="Service" term_id="service">}} soit créé,
|
||||
en utilisant une commande shell d'une ligne telle que :
|
||||
en utilisant une commande shell d'une ligne telle que :
|
||||
```shell
|
||||
for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
|
||||
```
|
||||
@@ -85,7 +85,7 @@ Voici plusieurs idées pour utiliser les init containers :
|
||||
* Cloner un dépôt Git dans un {{< glossary_tooltip text="Volume" term_id="volume" >}}
|
||||
|
||||
* Placer des valeurs dans un fichier de configuration et exécuter un outil de templating pour générer
|
||||
dynamiquement un fichier de configuration pour le conteneur d'application principal.
|
||||
dynamiquement un fichier de configuration pour le conteneur d'application principal.
|
||||
Par exemple, placer la valeur `POD_IP` dans une configuration et générer le fichier de configuration de l'application principale
|
||||
en utilisant Jinja.
|
||||
|
||||
@@ -207,7 +207,7 @@ kubectl logs myapp-pod -c init-mydb # Inspecter le second init container
|
||||
À ce stade, ces init containers attendent de découvrir les services nommés
|
||||
`mydb` et `myservice`.
|
||||
|
||||
Voici une configuration que vous pouvez utiliser pour faire apparaître ces Services :
|
||||
Voici une configuration que vous pouvez utiliser pour faire apparaître ces Services :
|
||||
|
||||
```yaml
|
||||
---
|
||||
@@ -242,7 +242,7 @@ service/myservice created
|
||||
service/mydb created
|
||||
```
|
||||
|
||||
Vous verrez ensuite que ces init containers se terminent et que le Pod `myapp-pod` évolue vers l'état "Running" (en exécution) :
|
||||
Vous verrez ensuite que ces init containers se terminent et que le Pod `myapp-pod` évolue vers l'état "Running" (en exécution) :
|
||||
|
||||
```shell
|
||||
kubectl get -f myapp.yaml
|
||||
@@ -264,7 +264,7 @@ se termine avec un échec, il est redémarré selon la `restartPolicy` du Pod.
|
||||
Toutefois, si la `restartPolicy` du Pod est configurée à "Always", les init containers utilisent la `restartPolicy` "OnFailure".
|
||||
|
||||
Un Pod ne peut pas être `Ready` tant que tous les init containers ne se sont pas exécutés avec succès.
|
||||
Les ports d'un init container ne sont pas agrégés sous un Service. Un Pod qui s'initialise
|
||||
Les ports d'un init container ne sont pas agrégés sous un Service. Un Pod qui s'initialise
|
||||
est dans l'état `Pending` mais devrait avoir une condition `Initializing` configurée à "true".
|
||||
|
||||
Si le Pod [redémarre](#raisons-du-redémarrage-d-un-pod) ou est redémarré, tous les init containers
|
||||
@@ -273,7 +273,7 @@ doivent s'exécuter à nouveau.
|
||||
Les changements aux spec d'un init containers sont limités au champ image du conteneur.
|
||||
Changer le champ image d'un init container équivaut à redémarrer le Pod.
|
||||
|
||||
Puisque les init containers peuvent être redémarrés, réessayés ou ré-exécutés,
|
||||
Puisque les init containers peuvent être redémarrés, réessayés ou ré-exécutés,
|
||||
leur code doit être idempotent. En particulier, le code qui écrit dans des fichiers sur `EmptyDirs`
|
||||
devrait être préparé à la possibilité qu'un fichier de sortie existe déjà.
|
||||
|
||||
@@ -282,38 +282,38 @@ Cependant, Kubernetes interdit l'utilisation de `readinessProbe` parce que les i
|
||||
ne peuvent pas définir une "readiness" distincte de la complétion. Ceci est appliqué lors de la validation.
|
||||
|
||||
L'utilisation de `activeDeadlineSeconds` sur le Pod et `livenessProbe` sur le conteneur
|
||||
permet d'empêcher les init containers d'échouer tout le temps.
|
||||
permet d'empêcher les init containers d'échouer tout le temps.
|
||||
La deadline active inclut les init containers.
|
||||
|
||||
Le nom de chaque application et init container dans un Pod doit être unique; une erreur de validation
|
||||
Le nom de chaque application et init container dans un Pod doit être unique; une erreur de validation
|
||||
est générée pour tout conteneur partageant un nom avec un autre.
|
||||
|
||||
### Ressources
|
||||
|
||||
Étant donné l'ordonnancement et l'exécution des init containers, les règles suivantes s'appliquent pour l'utilisation des ressources :
|
||||
Étant donné l'ordonnancement et l'exécution des init containers, les règles suivantes s'appliquent pour l'utilisation des ressources :
|
||||
|
||||
* La plus haute requête ou limite particulière de ressource définie pour tous les init containers
|
||||
est la *limite/requête d'initialisation effective*
|
||||
* La *limite/requête effective* d'un Pod pour une ressource est la plus haute parmis :
|
||||
* La *limite/requête effective* d'un Pod pour une ressource est la plus haute parmis :
|
||||
* la somme de toutes les requêtes/limites des conteneurs d'application pour une ressource
|
||||
* la limite/requête d'initialisation effective pour une ressource
|
||||
* Le Scheduling est effectué sur la base des requêtes/limites effectives, ce qui signifie
|
||||
que les init containers peuvent réserver des ressources pour l'initialisation qui ne sont pas utilisées durant le
|
||||
que les init containers peuvent réserver des ressources pour l'initialisation qui ne sont pas utilisées durant le
|
||||
cycle de vie du Pod.
|
||||
* La QoS (qualité de service) tierce de la *QoS tierce effective* d'un Pod est la QoS tierce aussi bien pour les init containers
|
||||
que pour les conteneurs d'application.
|
||||
|
||||
Les quotas et limites sont appliqués sur la base de la requête/limite effective d'un Pod.
|
||||
|
||||
Les groupes de contrôle au niveau du Pod ({{< glossary_tooltip text="cgroups" term_id="cgroup" >}}) sont basés sur la requête/limite effective de Pod, la même que
|
||||
Les groupes de contrôle au niveau du Pod ({{< glossary_tooltip text="cgroups" term_id="cgroup" >}}) sont basés sur la requête/limite effective de Pod, la même que
|
||||
celle du scheduler.
|
||||
|
||||
### Raisons du redémarrage d'un Pod
|
||||
|
||||
Un Pod peut redémarrer, ce qui cause la ré-exécution des init containers, pour les raisons suivantes :
|
||||
Un Pod peut redémarrer, ce qui cause la ré-exécution des init containers, pour les raisons suivantes :
|
||||
|
||||
* Un utilisateur met à jour les spécifications du Pod, ce qui cause le changement de l'image de l'init container.
|
||||
Tout changement à l'image du init container redémarre le Pod. Les changements au conteneur d'application entraînent seulement le
|
||||
Tout changement à l'image du init container redémarre le Pod. Les changements au conteneur d'application entraînent seulement le
|
||||
redémarrage du conteneur d'application.
|
||||
* Le conteneur d'infrastructure Pod est redémarré. Ceci est peu commun et serait effectué par une personne ayant un accès root aux nœuds.
|
||||
* Tous les conteneurs dans un Pod sont terminés tandis que `restartPolicy` est configurée à "Always", ce qui force le redémarrage, et l'enregistrement de complétion du init container a été perdu à cause d'une opération de garbage collection (récupération de mémoire).
|
||||
|
||||
@@ -21,8 +21,8 @@ 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.
|
||||
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
|
||||
@@ -42,7 +42,7 @@ Valeur | Description
|
||||
|
||||
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
|
||||
à 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
|
||||
@@ -61,7 +61,7 @@ du tableau de PodCondition a six champs possibles :
|
||||
* 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
|
||||
* `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 ;
|
||||
@@ -75,8 +75,8 @@ du tableau de PodCondition a six champs possibles :
|
||||
|
||||
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
|
||||
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):
|
||||
@@ -98,7 +98,7 @@ 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 à deux types de sondes sur des conteneurs
|
||||
en cours d'exécution :
|
||||
|
||||
* `livenessProbe` : Indique si le Conteneur est en cours d'exécution. Si
|
||||
@@ -115,7 +115,7 @@ 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
|
||||
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.
|
||||
@@ -125,11 +125,11 @@ spécifiez une liveness probe et indiquez une valeur pour `restartPolicy` à Alw
|
||||
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
|
||||
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
|
||||
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
|
||||
@@ -137,7 +137,7 @@ pouvez spécifier une readiness probe qui vérifie un point de terminaison spéc
|
||||
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
|
||||
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.
|
||||
@@ -151,16 +151,16 @@ Pour des informations détaillées sur le statut d'un Pod et d'un Conteneur, voi
|
||||
[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
|
||||
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
|
||||
à 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
|
||||
* `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.
|
||||
@@ -172,23 +172,23 @@ d'informations.
|
||||
...
|
||||
```
|
||||
|
||||
* `Running` : Indique que le conteneur s'exécute sans problème. Une fois qu'un centeneur est
|
||||
* `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.
|
||||
|
||||
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
|
||||
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
|
||||
@@ -197,18 +197,18 @@ dans l'état Terminated, le hook `preStop` est exécuté (s'il existe).
|
||||
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
|
||||
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`
|
||||
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`
|
||||
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
|
||||
@@ -244,11 +244,11 @@ Avec l'introduction de nouvelles conditions d'un Pod, un Pod est considéré com
|
||||
* 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,
|
||||
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`
|
||||
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.
|
||||
@@ -280,7 +280,7 @@ Pods qui doivent se terminer, par exemple des calculs par batch. Les Jobs sont a
|
||||
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
|
||||
[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 à
|
||||
@@ -302,8 +302,8 @@ une politique pour mettre la `phase` de tous les Pods du nœud perdu à Failed.
|
||||
|
||||
### 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.
|
||||
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
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Aperçu du Pod
|
||||
description: Pod Concept Kubernetes
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
card:
|
||||
card:
|
||||
name: concepts
|
||||
weight: 60
|
||||
---
|
||||
@@ -76,7 +76,7 @@ En général, les Controllers utilisent des Templates de Pod que vous lui fourni
|
||||
|
||||
## Templates de Pod
|
||||
|
||||
Les Templates de Pod sont des spécifications de pod qui sont inclus dans d'autres objets, comme les
|
||||
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.
|
||||
|
||||
@@ -17,12 +17,12 @@ qui peuvent être créées et gérées dans Kubernetes.
|
||||
|
||||
## Qu'est-ce qu'un pod ?
|
||||
|
||||
Un _pod_ (terme anglo-saxon décrivant un groupe de baleines ou une gousse de pois) est un groupe d'un ou plusieurs conteneurs
|
||||
(comme des conteneurs Docker), ayant du stockage/réseau partagé, et une spécification
|
||||
Un _pod_ (terme anglo-saxon décrivant un groupe de baleines ou une gousse de pois) est un groupe d'un ou plusieurs conteneurs
|
||||
(comme des conteneurs Docker), ayant du stockage/réseau partagé, et une spécification
|
||||
sur la manière d'exécuter ces conteneurs. Les éléments d'un pod sont toujours co-localisés
|
||||
et co-ordonnancés, et s'exécutent dans un contexte partagé. Un pod modélise un
|
||||
"hôte logique" spécifique à une application - il contient un ou plusieurs conteneurs applicatifs
|
||||
qui sont étroitement liés — dans un monde pré-conteneurs, être exécuté sur la même machine
|
||||
qui sont étroitement liés — dans un monde pré-conteneurs, être exécuté sur la même machine
|
||||
physique ou virtuelle signifierait être exécuté sur le même hôte logique.
|
||||
|
||||
Bien que Kubernetes prenne en charge d'autres runtimes de conteneurs que Docker, Docker est le runtime
|
||||
@@ -32,12 +32,12 @@ Le contexte partagé d'un pod est un ensemble de namespaces Linux, cgroups, et
|
||||
potentiellement d'autres facettes d'isolation - les mêmes choses qui isolent un conteneur Docker.
|
||||
Dans le contexte d'un pod, les applications individuelles peuvent se voir appliquer d'autres sous-isolations.
|
||||
|
||||
Les conteneurs d'un pod partagent une adresse IP et un espace de ports, et peuvent communiquer via `localhost`.
|
||||
Les conteneurs d'un pod partagent une adresse IP et un espace de ports, et peuvent communiquer via `localhost`.
|
||||
Ils peuvent aussi communiquer entre eux en utilisant des communications inter-process standard comme
|
||||
les sémaphores SystemV ou la mémoire partagée POSIX. Les conteneurs appartenant à des pods distincts ont des adresses IP
|
||||
distinctes et ne peuvent pas communiquer par IPC sans [configuration spécifique](/docs/concepts/policy/pod-security-policy/). Ces conteneurs communiquent en général entre eux via les adresses IP de leurs pods.
|
||||
|
||||
Les applications à l'intérieur d'un pod ont aussi accès à des volumes partagés,
|
||||
Les applications à l'intérieur d'un pod ont aussi accès à des volumes partagés,
|
||||
qui sont définis dans le cadre d'un pod et sont mis à disposition pour être montés
|
||||
dans le système de fichiers de chaque application.
|
||||
|
||||
@@ -66,11 +66,11 @@ utilisant un volume persistant comme espace de stockage partagé entre les conte
|
||||
### Gestion
|
||||
|
||||
Les pods fournissent une unité de service cohérente afin d'avoir un modèle coopératif entre plusieurs processus.
|
||||
Ils simplifient le déploiement et la gestion d'applications
|
||||
Ils simplifient le déploiement et la gestion d'applications
|
||||
en fournissant une abstraction de plus haut niveau que l'ensemble des applications les constituant.
|
||||
Les pods servent d'unité de déploiement, de mise à l'échelle horizontale, et de réplication.
|
||||
La co-localisation (co-ordonnancement), la fin partagée (par ex. l'arrêt),
|
||||
la réplication coordonnée, le partage de ressources et la gestion des dépendances sont
|
||||
La co-localisation (co-ordonnancement), la fin partagée (par ex. l'arrêt),
|
||||
la réplication coordonnée, le partage de ressources et la gestion des dépendances sont
|
||||
traités automatiquement pour les conteneurs dans un pod.
|
||||
|
||||
### Partage de ressources et communication
|
||||
@@ -80,14 +80,14 @@ Les pods permettent le partage de ressources et la communication entre ses const
|
||||
Les applications dans un pod utilisent toutes le même réseau (même adresse IP et espace de ports)
|
||||
et peuvent donc "se trouver" entre elles et communiquer en utilisant `localhost`.
|
||||
À cause de cela, les applications dans un pod doivent coordonner leurs usages de ports.
|
||||
Chaque pod a une adresse IP dans un réseau plat partagé ayant un accès complet
|
||||
Chaque pod a une adresse IP dans un réseau plat partagé ayant un accès complet
|
||||
aux autres hôtes et pods à travers le réseau.
|
||||
|
||||
Le nom d'hôte est défini avec le nom du pod pour les conteneurs applicatifs à l'intérieur du pod.
|
||||
[Plus de détails sur le réseau](/docs/concepts/cluster-administration/networking/).
|
||||
|
||||
En plus de définir les conteneurs applicatifs s'exécutant dans le pod, le pod spécifie
|
||||
un ensemble de volumes de stockage partagés. Les volumes permettent aux données de survivre
|
||||
En plus de définir les conteneurs applicatifs s'exécutant dans le pod, le pod spécifie
|
||||
un ensemble de volumes de stockage partagés. Les volumes permettent aux données de survivre
|
||||
aux redémarrages de conteneurs et d'être partagés entre les applications d'un même pod.
|
||||
|
||||
## Cas d'utilisation de pods
|
||||
@@ -112,8 +112,8 @@ Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-pa
|
||||
_Pourquoi ne pas simplement exécuter plusieurs programmes dans un unique conteneur (Docker) ?_
|
||||
|
||||
1. Transparence. Rendre les conteneurs à l'intérieur du pod visibles par l'infrastucture
|
||||
permet à l'infrastucture de fournir des services à ces conteneurs,
|
||||
comme la gestion des processus et le monitoring des ressources. Ceci
|
||||
permet à l'infrastucture de fournir des services à ces conteneurs,
|
||||
comme la gestion des processus et le monitoring des ressources. Ceci
|
||||
apporte un certain nombre de facilités aux utilisateurs.
|
||||
1. Découpler les dépendances logicielles. Les conteneurs individuels peuvent être
|
||||
versionnés, reconstruits et redéployés de manière indépendante. Kubernetes pourrait
|
||||
@@ -124,7 +124,7 @@ _Pourquoi ne pas simplement exécuter plusieurs programmes dans un unique conten
|
||||
|
||||
_Pourquoi ne pas prendre en charge le co-ordonnancement de conteneurs basé sur les affinités ?_
|
||||
|
||||
Cette approche pourrait fournir la co-localisation, mais ne fournirait pas la plupart
|
||||
Cette approche pourrait fournir la co-localisation, mais ne fournirait pas la plupart
|
||||
des bénéfices des pods, comme le partage de ressources, IPC, la garantie d'une fin partagée et une gestion simplifiée.
|
||||
|
||||
## Durabilité des pods (ou manque de)
|
||||
@@ -132,7 +132,7 @@ des bénéfices des pods, comme le partage de ressources, IPC, la garantie d'une
|
||||
Les pods ne doivent pas être considérés comme des entités durables. Ils ne survivent pas à des erreurs d'ordonnancement, à un nœud en échec
|
||||
ou à d'autres expulsions, suite à un manque de ressources ou une mise en maintenance d'un nœud.
|
||||
|
||||
En général, les utilisateurs n'ont pas à créer directement des pods. Ils doivent presque toujours
|
||||
En général, les utilisateurs n'ont pas à créer directement des pods. Ils doivent presque toujours
|
||||
utiliser des contrôleurs, même pour des singletons, comme par exemple des [Deployments](/docs/concepts/workloads/controllers/deployment/).
|
||||
Les contrôleurs fournissent l'auto-guérison à l'échelle du cluster, ainsi que la réplication et la gestion des déploiements (rollout).
|
||||
Les contrôleurs comme [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)
|
||||
@@ -152,7 +152,7 @@ Un Pod est exposé en tant que primitive afin de faciliter :
|
||||
## Arrêt de pods
|
||||
|
||||
Les pods représentant des processus s'exécutant sur des nœuds d'un cluster, il est important de permettre à ces processus de se terminer proprement
|
||||
lorsqu'ils ne sont plus nécessaires (plutôt que d'être violemment tués avec un signal KILL et n'avoir aucune chance de libérer ses ressources). Les
|
||||
lorsqu'ils ne sont plus nécessaires (plutôt que d'être violemment tués avec un signal KILL et n'avoir aucune chance de libérer ses ressources). Les
|
||||
utilisateurs doivent pouvoir demander une suppression et savoir quand les processus se terminent, mais aussi être capable de s'assurer que la suppression
|
||||
est réellement effective. Lorsqu'un utilisateur demande la suppression d'un pod, le système enregistre le délai de grâce prévu avant que le pod puisse
|
||||
être tué de force, et qu'un signal TERM soit envoyé au processus principal de chaque conteneur. Une fois la période de grâce expirée, le signal KILL
|
||||
|
||||
Reference in New Issue
Block a user