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

content/fr/community/code-of-conduct.md

@@ -8,11 +8,11 @@ css: /css/community.css
 <div class="community_main">
 <h1>Code de conduite de la communauté Kubernetes</h1>
 
-Kubernetes suit le 
+Kubernetes suit le
 <a href="https://github.com/cncf/foundation/blob/master/code-of-conduct.md">Code de Conduite de la CNCF</a>.
-Le texte du CdC de la CNCF est reproduit ci-dessous 
+Le texte du CdC de la CNCF est reproduit ci-dessous
 <a href="https://github.com/cncf/foundation/blob/214585e24aab747fb85c2ea44fbf4a2442e30de6/code-of-conduct.md">commit 214585e</a>.
-Si vous remarquez que ce document n'est plus à jour, n'hésitez pas à 
+Si vous remarquez que ce document n'est plus à jour, n'hésitez pas à
 <a href="https://github.com/kubernetes/website/issues/new">créer une issue</a>.
 
 

content/fr/community/static/cncf-code-of-conduct.md

@@ -22,7 +22,7 @@ Les éditeurs du projet ont le droit et la responsabilité de retirer, modifier
 
 Ce Code de conduite s’applique à la fois dans le cadre du projet et dans le cadre public, lorsqu’une personne représente le projet ou la communauté.
 
-Des cas de conduite abusive, de harcèlement ou autre pratique inacceptable ayant cours sur Kubernetes peuvent être signalés en contactant le [comité pour le code de conduite de Kubernetes](https://git.k8s.io/community/committee-code-of-conduct) via l'adresse <conduct@kubernetes.io>.  Pour d'autres projets, bien vouloir contacter un responsable de projet CNCF ou notre médiateur, Mishi Choudhary à l'adresse <mishi@linux.com>. 
+Des cas de conduite abusive, de harcèlement ou autre pratique inacceptable ayant cours sur Kubernetes peuvent être signalés en contactant le [comité pour le code de conduite de Kubernetes](https://git.k8s.io/community/committee-code-of-conduct) via l'adresse <conduct@kubernetes.io>.  Pour d'autres projets, bien vouloir contacter un responsable de projet CNCF ou notre médiateur, Mishi Choudhary à l'adresse <mishi@linux.com>.
 
 Ce Code de conduite est inspiré du « Contributor Covenant » (http://contributor-covenant.org) version 1.2.0, disponible à l’adresse http://contributor-covenant.org/version/1/2/0/.
 

content/fr/docs/concepts/containers/container-lifecycle-hooks.md

@@ -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 %}}

content/fr/docs/concepts/containers/images.md

@@ -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 >}}
 

content/fr/docs/concepts/overview/components.md

@@ -2,25 +2,25 @@
 title: Composants de Kubernetes
 content_template: templates/concept
 weight: 20
-card: 
+card:
   name: concepts
   weight: 20
 ---
 
 {{% capture overview %}}
-Ce document résume les divers composants binaires requis pour livrer 
+Ce document résume les divers composants binaires requis pour livrer
 un cluster Kubernetes fonctionnel.
 {{% /capture %}}
 
 {{% capture body %}}
 ## Composants Master
 
 Les composants Master fournissent le plan de contrôle (control plane) du cluster.
-Les composants Master prennent des décisions globales à propos du cluster (par exemple, la planification (scheduling)). 
+Les composants Master prennent des décisions globales à propos du cluster (par exemple, la planification (scheduling)).
 Ils détectent et répondent aux événements du cluster (par exemple, démarrer un nouveau {{< glossary_tooltip text="Pod" term_id="pod">}} lorsque le champ `replicas` d'un déploiement n'est pas satisfait).
 
 Les composants Master peuvent être exécutés sur n'importe quelle machine du cluster. Toutefois,
-par soucis de simplicité, les scripts de mise en route démarrent typiquement tous les composants master sur la 
+par soucis de simplicité, les scripts de mise en route démarrent typiquement tous les composants master sur la
 même machine et n'exécutent pas de conteneurs utilisateur sur cette machine.
 Voir [Construire des Clusters en Haute Disponibilité](/docs/admin/high-availability/) pour une configuration d'exemple en multi-master-VM.
 
@@ -46,16 +46,16 @@ Ces contrôleurs incluent :
   * Replication Controller : Responsable de maintenir le bon nombre de pods pour chaque objet
   ReplicationController dans le système.
   * Endpoints Controller : Remplit les objets Endpoints (c'est-à-dire joint les Services et Pods).
-  * Service Account & Token Controllers : Créent des comptes par défaut et des jetons d'accès à l'API 
+  * Service Account & Token Controllers : Créent des comptes par défaut et des jetons d'accès à l'API
   pour les nouveaux namespaces.
 
 ### cloud-controller-manager
 
-Le [cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) exécute les contrôleurs 
-qui interagissent avec les fournisseurs cloud sous-jacents. Le binaire du cloud-controller-manager est une 
+Le [cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) exécute les contrôleurs
+qui interagissent avec les fournisseurs cloud sous-jacents. Le binaire du cloud-controller-manager est une
 fonctionnalité alpha introduite dans la version 1.6 de Kubernetes.
 
-Le cloud-controller-manager exécute seulement les boucles spécifiques des fournisseurs cloud. 
+Le cloud-controller-manager exécute seulement les boucles spécifiques des fournisseurs cloud.
 Vous devez désactiver ces boucles de contrôleurs dans le kube-controller-manager.
 Vous pouvez désactiver les boucles de contrôleurs en définissant la valeur du flag `--cloud-provider` à `external` lors du démarrage du kube-controller-manager.
 
@@ -89,30 +89,30 @@ et en fournissant l'environnement d'exécution Kubernetes.
 ## Addons
 
 Les addons utilisent les ressources Kubernetes ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}}, etc)
-pour implémenter des fonctionnalités cluster. Comme ces derniers fournissent des fonctionnalités au niveau 
+pour implémenter des fonctionnalités cluster. Comme ces derniers fournissent des fonctionnalités au niveau
 du cluster, les ressources dans des namespaces pour les addons appartiennent au namespace `kube-system`.
 
-Les addons sélectionnés sont décrits ci-dessous. Pour une liste étendue des addons disponibles, voir la page 
+Les addons sélectionnés sont décrits ci-dessous. Pour une liste étendue des addons disponibles, voir la page
 [Addons](/docs/concepts/cluster-administration/addons/).
 
 ### DNS
 
-Tandis que les autres addons ne sont pas strictement requis, tous les clusters Kubernetes devraient avoir un 
+Tandis que les autres addons ne sont pas strictement requis, tous les clusters Kubernetes devraient avoir un
 [DNS cluster](/fr/docs/concepts/services-networking/dns-pod-service/) car de nombreux exemples en dépendent.
 
-Le DNS Cluster est un serveur DNS, en plus des autres serveurs DNS dans votre environnement, qui sert 
+Le DNS Cluster est un serveur DNS, en plus des autres serveurs DNS dans votre environnement, qui sert
 les enregistrements DNS pour les services Kubernetes.
 
 Les conteneurs démarrés par Kubernetes incluent automatiquement ce serveur DNS dans leurs recherches DNS.
 
 ### Interface utilisateur Web (Dashboard)
 
-Le [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) est une interface utilisateur web à but général pour les clusters Kubernetes. Il permet aux utilisateurs de gérer et de dépanner aussi bien des 
+Le [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) est une interface utilisateur web à but général pour les clusters Kubernetes. Il permet aux utilisateurs de gérer et de dépanner aussi bien des
 applications s'exécutant dans le cluster que le cluster lui-même.
 
 ### La surveillance des ressources de conteneur
 
-[La surveillance des ressources de conteneur](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) enregistre des métriques chronologiques génériques à propos des conteneurs dans une base de données centrale et 
+[La surveillance des ressources de conteneur](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) enregistre des métriques chronologiques génériques à propos des conteneurs dans une base de données centrale et
 fournit une interface utilisateur pour parcourir ces données.
 
 ### Le logging au niveau cluster