Yushiro FURUKAWA
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
3b10c76ca7
commit
2a120450eb
@@ -7,7 +7,7 @@ weight: 10
|
||||
{{% capture overview %}}
|
||||
|
||||
Un ReplicaSet (ensemble de réplicas en français) a pour but de maintenir un ensemble stable de Pods à un moment donné.
|
||||
Cet objet est souvent utilisé pour garantir la disponibilité d'un certain nombre identique de Pods.
|
||||
Cet objet est souvent utilisé pour garantir la disponibilité d'un certain nombre identique de Pods.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -15,14 +15,14 @@ Cet objet est souvent utilisé pour garantir la disponibilité d'un certain nomb
|
||||
|
||||
## Comment un ReplicaSet fonctionne
|
||||
|
||||
Un ReplicaSet est défini avec des champs, incluant un selecteur qui spécifie comment identifier les Pods qu'il peut posséder,
|
||||
Un ReplicaSet est défini avec des champs, incluant un selecteur qui spécifie comment identifier les Pods qu'il peut posséder,
|
||||
un nombre de replicas indiquant le nombre de Pods qu'il doit maintenir et un modèle de Pod spécifiant les données que les
|
||||
nouveaux Pods que le replicatSet va créer jusqu'au nombre de replicas demandé.
|
||||
|
||||
Un ReplicaSet va atteindre son objectif en créant et supprimant des Pods pour atteindre le nombre de réplicas désirés.
|
||||
Quand un ReplicaSet a besoin de créer de nouveaux Pods, il utilise alors son Pod template.
|
||||
|
||||
Le lien d'un ReplicaSet à ses Pods est fait par le champ [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents),
|
||||
Le lien d'un ReplicaSet à ses Pods est fait par le champ [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents),
|
||||
qui spécifie la ressource de l'objet par lequel il est détenu. Tous les Pods acquis par un ReplicaSet ont leurs propres informations d'identification de leur Replicaset, avec leur propre champ ownerReferences. C'est par ce lien que le ReplicaSet connait l'état des Pods qu'il maintient et agit en fonction de ces derniers.
|
||||
|
||||
Un ReplicaSet identifie des nouveaux Pods à acquérir en utilisant son selecteur.
|
||||
@@ -276,7 +276,7 @@ Pour mettre à jour les Pods à une nouvelle spec de manière contrôlée, utili
|
||||
### Isoler les pods d'un ReplicaSet
|
||||
|
||||
Vous pouvez supprimer les pods d'un ReplicaSet en modifiant leurs labels. Cette technique peut être utilisée pour enlever les pods
|
||||
pour le débogage, récupération de données, etc. Les pods ainsi supprimés seront automatiquement remplacés
|
||||
pour le débogage, récupération de données, etc. Les pods ainsi supprimés seront automatiquement remplacés
|
||||
(en supposant que le nombre de réplicas n’est pas également modifié).
|
||||
|
||||
### Scaling d'un ReplicaSet
|
||||
@@ -287,7 +287,7 @@ garantit que le nombre souhaité de pods avec un sélecteur de label corresponda
|
||||
### ReplicaSet en tant que Horizontal Pod Autoscaler Target
|
||||
|
||||
Un ReplicaSet peut également être une cible pour
|
||||
[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/).
|
||||
[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/).
|
||||
Un ReplicaSet peut être mis à l'échelle automatiquement par un HPA. Voici un exemple HPA qui cible
|
||||
le ReplicaSet que nous avons créé dans l'exemple précédent.
|
||||
|
||||
@@ -332,7 +332,7 @@ Utilisez un [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) au
|
||||
|
||||
Utilisez un [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) au lieu d’un ReplicaSet pour les pods qui fournissent une
|
||||
fonction au niveau du noeud, comme le monitoring ou la gestion des logs de ce noeud. Ces pods ont une durée de vie qui est liée
|
||||
durée de vie d’une machine : le pod doit être en cours d’exécution sur la machine avant le démarrage des autres Pods et sont
|
||||
durée de vie d’une machine : le pod doit être en cours d’exécution sur la machine avant le démarrage des autres Pods et sont
|
||||
sûrs de se terminer lorsque la machine est prête à être redémarrée/arrêtée.
|
||||
|
||||
### ReplicationController
|
||||
|
||||
@@ -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