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

content/fr/docs/concepts/workloads/pods/pod.md

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