rekcah78 Review

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

@@ -63,7 +63,7 @@ du tableau de PodCondition a six champs possibles :
   * `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
     de charge de tous les Services correspondants ;
-  * `Initialized` : tous les [init containers](/docs/concepts/workloads/pods/init-containers)
+  * `Initialized` : tous les [init containers](/fr/docs/concepts/workloads/pods/init-containers)
     ont démarré correctement ;
   * `ContainersReady` : tous les conteneurs du Pod sont prêts.
 
@@ -236,7 +236,7 @@ spec:
     - conditionType: "www.example.com/feature-1"
 status:
   conditions:
-    - type: Ready  # builtin PodCondition
+    - type: Ready  # une PodCondition intégrée
       status: "False"
       lastProbeTime: null
       lastTransitionTime: 2018-01-01T00:00:00Z

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

@@ -74,7 +74,7 @@ Voici quelques exemples de ressources de charges de travail qui gèrent un ou pl
 ## Templates de Pod
 
 Les Templates de Pod sont des spécifications pour créer des Pods, et sont inclus dans les ressources de charges de travail comme
-les [Deployments](/docs/concepts/workloads/controllers/deployment/), les [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/) et
+les [Deployments](/fr/docs/concepts/workloads/controllers/deployment/), les [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/) et
 les [DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
 
 Chaque contrôleur pour une ressource de charges de travail utilise le template de pod à l'intérieur de l'objet pour créer les Pods. Le template de pod fait partie de l'état désiré de la ressource de charges de travail que vous avez utilisé pour exécuter votre application.

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

@@ -164,7 +164,7 @@ Un exemple de déroulement :
 1. Le Pod dans l'API server est mis à jour avec le temps au delà duquel le Pod est considéré "mort" ainsi que la période de grâce.
 1. Le Pod est affiché comme "Terminating" dans les listes des commandes client
 1. (en même temps que 3) Lorsque Kubelet voit qu'un Pod a été marqué "Terminating", le temps ayant été mis en 2, il commence le processus de suppression du pod.
-    1. Si un des conteneurs du Pod a défini un [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), il est exécuté à l'intérieur du conteneur. Si le `preStop` hook est toujours en cours d'exécution à la fin de la période de grâce, l'étape 2 est invoquée avec une courte (2 secondes) période de grâce supplémentaire une seule fois. Vous devez modifier `terminationGracePeriodSeconds` si le hook `preStop` a besoin de plus de temps pour se terminer.
+    1. Si un des conteneurs du Pod a défini un [preStop hook](/fr/docs/concepts/containers/container-lifecycle-hooks/#hook-details), il est exécuté à l'intérieur du conteneur. Si le `preStop` hook est toujours en cours d'exécution à la fin de la période de grâce, l'étape 2 est invoquée avec une courte (2 secondes) période de grâce supplémentaire une seule fois. Vous devez modifier `terminationGracePeriodSeconds` si le hook `preStop` a besoin de plus de temps pour se terminer.
     1. Le signal TERM est envoyé aux conteneurs. Notez que tous les conteneurs du Pod ne recevront pas le signal TERM en même temps et il peut être nécessaire de définir des `preStop` hook si l'ordre d'arrêt est important.
 1. (en même temps que 3) Le Pod est supprimé des listes d'endpoints des services, et n'est plus considéré comme faisant partie des pods en cours d'exécution pour les contrôleurs de réplication. Les Pods s'arrêtant lentement ne peuvent pas continuer à servir du trafic, les load balancers (comme le service proxy) les supprimant de leurs rotations.
 1. Lorsque la période de grâce expire, les processus s'exécutant toujours dans le Pod sont tués avec SIGKILL.