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

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
@@ -7,7 +7,7 @@ weight: 30
{{% capture overview %}}
Cette page décrit comment un conteneur pris en charge par kubelet peut utiliser
Cette page décrit comment un conteneur pris en charge par kubelet peut utiliser
le framework de Hooks de cycle de vie de conteneurs pour exécuter du code déclenché par des
événements durant son cycle de vie.
@@ -39,7 +39,7 @@ Aucun paramètre n'est passé au handler.
Ce hook est appelé immédiatement avant qu'un conteneur se termine, en raison d'un appel à l'API
ou d'un événement comme un échec de la liveness probe, un droit de préemption, un conflit de ressources ou autres.
Un appel au hook preStop échoue si le conteneur est déjà dans l'état terminé ou complété.
Un appel au hook preStop échoue si le conteneur est déjà dans l'état terminé ou complété.
Il est bloquant, ce qui veut dire qu'il est synchrone, et doit donc se terminer avant que l'appel pour supprimer le conteneur soit envoyé.
Aucun paramètre n'est passé au handler.
@@ -57,17 +57,17 @@ Les ressources consommées par la commande sont comptabilisées pour le conteneu
### Exécution d'un handler de hook
Lorsqu'un hook de cycle de vie de conteneur est appelé,
Lorsqu'un hook de cycle de vie de conteneur est appelé,
le système de gestion de Kubernetes exécute le handler dans le conteneur enregistré
pour ce hook.
Les appels aux handlers de hook sont synchrones dans le contexte du pod contenant le conteneur.
Ceci veut dire que pour un hook `PostStart`,
bien que l'ENTRYPOINT du conteneur et le hook soient lancés de manière asynchrone, si le hook prend trop de temps à s'exécuter ou se bloque,
bien que l'ENTRYPOINT du conteneur et le hook soient lancés de manière asynchrone, si le hook prend trop de temps à s'exécuter ou se bloque,
le conteneur ne peut pas atteindre l'état `running`.
Le comportement est similaire pour un hook `PreStop`.
Si le hook se bloque durant l'exécution,
Si le hook se bloque durant l'exécution,
la phase du Pod reste en état `Terminating` et le hook est tué après `terminationGracePeriodSeconds` que le pod se termine.
Si un hook `PostStart` ou `PreStop` échoue,
le conteneur est tué.
@@ -93,7 +93,7 @@ le hook pourrait être re-déclenché après que kubelet redémarre.
Les logs pour un handler de hook ne sont pas exposés dans les événements du Pod.
Si un handler échoue pour une raison particulière, il envoie un événement.
Pour `PostStart`, c'est l'événement `FailedPostStartHook`
Pour `PostStart`, c'est l'événement `FailedPostStartHook`
et pour `PreStop`, c'est l'événement `FailedPreStopHook`.
Vous pouvez voir ces événements en exécutant `kubectl describe pod <pod_name>`.
Voici un exemple d'affichage d'événements lors de l'exécution de cette commande :
@@ -118,7 +118,7 @@ Events:
{{% capture whatsnext %}}
* En savoir plus sur l'[Environnement d'un conteneur](/fr/docs/concepts/containers/container-environment-variables/).
* Entraînez-vous à
* Entraînez-vous à
[attacher des handlers de conteneurs à des événements de cycle de vie](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
{{% /capture %}}
@@ -18,7 +18,7 @@ La propriété `image` d'un conteneur utilise la même syntaxe que la commande `
## Mettre à jour des images
La politique de récupération par défaut est `IfNotPresent`, Kubelet ne récupère alors pas une image si elle est déjà présente sur le nœud.
La politique de récupération par défaut est `IfNotPresent`, Kubelet ne récupère alors pas une image si elle est déjà présente sur le nœud.
Si vous voulez forcer une récupération à chaque fois, vous pouvez faire une des actions suivantes :
- définissez `imagePullPolicy` du conteneur à `Always`.
@@ -46,7 +46,7 @@ Veuillez utiliser les versions *18.06 ou ultérieure*, les versions antérieures
Si vous avez des problèmes en téléchargeant des manifestes viciés, nettoyez les anciens manifestes dans `$HOME/.docker/manifests` pour recommencer de zéro.
Pour Kubernetes, nous avons historiquement utilisé des images avec des suffixes `-$(ARCH)`. Pour une rétrocompatibilité, veuillez générer les anciennes images avec des suffixes. Par exemple, l'image `pause` qui a le manifeste pour toutes les architetures et l'image `pause-amd64` qui est rétrocompatible
Pour Kubernetes, nous avons historiquement utilisé des images avec des suffixes `-$(ARCH)`. Pour une rétrocompatibilité, veuillez générer les anciennes images avec des suffixes. Par exemple, l'image `pause` qui a le manifeste pour toutes les architetures et l'image `pause-amd64` qui est rétrocompatible
pour d'anciennes configurations ou des fichiers YAML qui auraient codé en dur les images avec des suffixes.
## Utiliser un registre privé
@@ -96,7 +96,7 @@ Kubernetes prend en charge nativement [Amazon Elastic Container Registry](https:
Utilisez simplement le nom complet de l'image (par ex. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`)
dans la définition du Pod.
Tous les utilisateurs du cluster qui peuvent créer des pods auront la possibilité
Tous les utilisateurs du cluster qui peuvent créer des pods auront la possibilité
d'exécuter des pods qui utilisent n'importe quelle image du registre ECR.
Kubelet va aller chercher et rafraîchir périodiquement les certificats ECR. Les permissions suivantes sont requises par kubelet :
@@ -160,7 +160,7 @@ Si vous travaillez dans AWS EC2 et utilisez EC2 Container Registry (ECR), kubele
{{< /note >}}
{{< note >}}
Cette méthode est utilisable si vous avez le contrôle sur la configuration des nœuds. Elle ne marchera pas
Cette méthode est utilisable si vous avez le contrôle sur la configuration des nœuds. Elle ne marchera pas
correctement sur GCE, et sur tout autre fournisseur cloud qui fait du remplacement de nœud automatique.
{{< /note >}}
@@ -184,7 +184,7 @@ Docker stocke les clés pour les regisres privés dans le fichier `$HOME/.docker
Vous pouvez avoir à définir `HOME=/root` explicitement dans votre fichier d'environnement pour kubelet.
{{< /note >}}
Voici les étapes recommandées pour configurer vos nœuds pour qu'ils utilisent un registre privé. Dans cet exemple, exécutez-les sur votre poste de travail :
Voici les étapes recommandées pour configurer vos nœuds pour qu'ils utilisent un registre privé. Dans cet exemple, exécutez-les sur votre poste de travail :
1. Exécutez `docker login [server]` pour chaque jeu de certificats que vous désirez utiliser. Ceci met à jour `$HOME/.docker/config.json`.
1. Examinez `$HOME/.docker/config.json` dans un éditeur pour vous assurer qu'il contient uniquement les certificats que vous désirez utiliser.
@@ -236,7 +236,7 @@ Si vous travaillez dans Google Kubernetes Engine, vous trouverez un `.dockercfg`
{{< /note >}}
{{< note >}}
Cette méthode est utilisable si vous avez le contrôle sur la configuration des nœuds. Elle ne marchera pas
Cette méthode est utilisable si vous avez le contrôle sur la configuration des nœuds. Elle ne marchera pas
correctement sur GCE, et sur tout autre fournisseur cloud qui fait du remplacement de nœud automatique.
{{< /note >}}
@@ -268,13 +268,13 @@ kubectl create secret docker-registry <name> --docker-server=SERVEUR_REGISTRE_DO
secret/myregistrykey created.
```
Si vous avez déjà un fichier de clés Docker, alors, plutôt que d'utiliser la commande ci-dessus,
Si vous avez déjà un fichier de clés Docker, alors, plutôt que d'utiliser la commande ci-dessus,
vous pouvez importer le fichier de clés comme un Secret Kubernetes.
[Créer un Secret basé sur des clés Docker existantes](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) explique comment s'y prendre.
Ceci est particulièrement utile si vous utilisez plusieurs registres privés, `kubectl create secret docker-registry` créant un Secret ne fonctionnant qu'avec un seul registre privé.
{{< note >}}
Les pods peuvent référencer des pull secrets dans leur propre namespace uniquement,
Les pods peuvent référencer des pull secrets dans leur propre namespace uniquement,
ces étapes doivent donc être faites pour chaque namespace.
{{< /note >}}