whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Remove trailing spaces from FR documents(#16742) (#16788)

Browse Source
This commit is contained in:
Yushiro FURUKAWA
2019-10-10 18:02:53 +09:00
committed by Kubernetes Prow Robot
parent 3b10c76ca7
commit 2a120450eb
45 changed files with 412 additions and 412 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/fr/docs/concepts/workloads/pods/init-containers.md
+26 -26
View File
@@ -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).