From 14ab4eb133e31231bde27e21e7b53de64edbcc6a Mon Sep 17 00:00:00 2001 From: Philippe Martin Date: Mon, 25 May 2020 15:35:49 +0200 Subject: [PATCH] fixes --- .../docs/concepts/workloads/pods/pod-lifecycle.md | 14 +++++++------- .../docs/concepts/workloads/pods/pod-overview.md | 6 +++--- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md b/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md index 40923c3518..a81d35f7ac 100644 --- a/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md @@ -154,9 +154,9 @@ Le Pod reste dans le statut non prêt le temps que les Conteneurs du Pod s'arrê {{< feature-state for_k8s_version="v1.16" state="alpha" >}} -Si vous conteneur démarre habituellement en plus de `initialDelaySeconds + failureThreshold × periodSeconds`, -vous devriez pécifier une startup probe qui vérifie le même point de terminaison que la liveness probe. La valeur par défaut pour `periodSeconds` est 30s. -Vous devriez alors meetre sa valeur `failureThreshold` suffisamment haute pour permettre au conteneur de démarrer, sans changer les valeurs par défaut de la liveness probe. Ceci aide à se protéger de deadlocks. +Si votre conteneur démarre habituellement en plus de `initialDelaySeconds + failureThreshold × periodSeconds`, +vous devriez spécifier une startup probe qui vérifie le même point de terminaison que la liveness probe. La valeur par défaut pour `periodSeconds` est 30s. +Vous devriez alors mettre sa valeur `failureThreshold` suffisamment haute pour permettre au conteneur de démarrer, sans changer les valeurs par défaut de la liveness probe. Ceci aide à se protéger de deadlocks. Pour plus d'informations sur la manière de mettre en place une liveness, readiness ou startup probe, voir [Configurer des Liveness, Readiness et Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). @@ -252,7 +252,7 @@ status: Les conditions du Pod que vous ajoutez doivent avoir des noms qui sont conformes au [format des étiquettes](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) de Kubernetes. -### Statut de la disponibilité d'un Pod {#pod-readiness-status} +### Statut de la disponibilité d'un Pod {#statut-pod-disponibilité} La commande `kubectl patch` ne peut pas patcher le statut d'un objet. Pour renseigner ces `status.conditions` pour le pod, les applications et @@ -261,7 +261,7 @@ Vous pouvez utiliser une [bibliothèque client Kubernetes](/docs/reference/using écrire du code qui renseigne les conditions particulières pour la disponibilité dun Pod. Pour un Pod utilisant des conditions particulières, ce Pod est considéré prêt **seulement** -lorsque les deux déclarations c-dessous sont vraies : +lorsque les deux déclarations ci-dessous sont vraies : * Tous les conteneurs du Pod sont prêts. * Toutes les conditions spécifiées dans `ReadinessGates` sont `True`. @@ -284,7 +284,7 @@ une fois attaché à un nœud, un Pod ne sera jamais rattaché à un autre nœud ## Durée de vie d'un Pod En général, les Pods restent jusqu'à ce qu'un humain ou un process de -{{< glossary_tooltip term_id="controller" text="controller" >}} les supprime explicitement. +{{< glossary_tooltip term_id="controller" text="contrôleur" >}} les supprime explicitement. Le plan de contrôle nettoie les Pods terminés (avec une phase à `Succeeded` ou `Failed`), lorsque le nombre de Pods excède le seuil configuré @@ -302,7 +302,7 @@ Il y a différents types de ressources pour créer des Pods : seulement pour des Pods ayant `restartPolicy` égal à OnFailure ou Never. - Utilisez un {{< glossary_tooltip term_id="daemonset" >}} - pour les Pods qui doivent s'exécuter un par noeud éligible. + pour les Pods qui doivent s'exécuter sur chaque noeud éligible. Toutes les ressources de charges de travail contiennent une PodSpec. Il est recommandé de créer la ressource de charges de travail appropriée et laisser le contrôleur de la ressource créer les Pods diff --git a/content/fr/docs/concepts/workloads/pods/pod-overview.md b/content/fr/docs/concepts/workloads/pods/pod-overview.md index 38a35100f2..2ee999f0f2 100644 --- a/content/fr/docs/concepts/workloads/pods/pod-overview.md +++ b/content/fr/docs/concepts/workloads/pods/pod-overview.md @@ -27,7 +27,7 @@ Les Pods dans un cluster Kubernetes peuvent être utilisés de deux manières di * **les Pods exécutant un conteneur unique**. Le modèle "un-conteneur-par-Pod" est le cas d'utilisation Kubernetes le plus courant ; dans ce cas, vous pouvez voir un Pod comme un wrapper autour d'un conteneur unique, et Kubernetes gère les Pods plutôt que directement les conteneurs. * **les Pods exécutant plusieurs conteneurs devant travailler ensemble**. Un Pod peut encapsuler une application composée de plusieurs conteneurs co-localisés qui sont étroitement liés et qui doivent partager des ressources. Ces conteneurs co-localisés pourraient former une unique unité de service cohésive--un conteneur servant des fichiers d'un volume partagé au public, alors qu'un conteneur "sidecar" séparé rafraîchit ou met à jour ces fichiers. Le Pod enveloppe ensemble ces conteneurs et ressources de stockage en une entité maniable de base. -Chaque Pod est destiné à exécuter une instance unique d'une application donnée. Si vous désirez mettre à l'échelle votre application horizontalement, (pour fournir plus de ressources au global en exécutant plus d'instances), vous devez utiliser plusieurs Pods, un pour chaque instance. Dans Kubernetes, on parle typiquement de _réplication_. Des Pods répliqués sont en général créés et gérés en tant que groupe par une ressource de charge de travail et son {{< glossary_tooltip text="_controller_" term_id="controller" >}}. Voir [Pods et contrôleurs](#pods-et-controleurs) pour plus d'informations. +Chaque Pod est destiné à exécuter une instance unique d'une application donnée. Si vous désirez mettre à l'échelle votre application horizontalement, (pour fournir plus de ressources au global en exécutant plus d'instances), vous devez utiliser plusieurs Pods, un pour chaque instance. Dans Kubernetes, on parle typiquement de _réplication_. Des Pods répliqués sont en général créés et gérés en tant que groupe par une ressource de charge de travail et son {{< glossary_tooltip text="_contrôleur_" term_id="controller" >}}. Voir [Pods et contrôleurs](#pods-et-controleurs) pour plus d'informations. ### Comment les Pods gèrent plusieurs conteneurs @@ -51,7 +51,7 @@ Un Pod peut spécifier un jeu de {{< glossary_tooltip text="volumes" term_id="vo ## Travailler avec des Pods -Vous aurez rarement à créer directement des Pods individuels dans Kubernetes--même des Pods à un seul conteneur. Ceci est dû au fait que les Pods sont conçus comme des entités relativement éphémères et jetables. Lorsqu'un Pod est créé (directement par vous ou indirectement par un {{< glossary_tooltip text="_controller_" term_id="controller" >}}), il est programmé pour s'exécuter sur un {{< glossary_tooltip term_id="node" >}} dans votre cluster. Le Pod reste sur ce nœud jusqu'à ce que le process se termine, l'objet pod soit supprimé, le pod soit *expulsé* par manque de ressources, ou le nœud soit en échec. +Vous aurez rarement à créer directement des Pods individuels dans Kubernetes--même des Pods à un seul conteneur. Ceci est dû au fait que les Pods sont conçus comme des entités relativement éphémères et jetables. Lorsqu'un Pod est créé (directement par vous ou indirectement par un {{< glossary_tooltip text="_contrôleur_" term_id="controller" >}}), il est programmé pour s'exécuter sur un {{< glossary_tooltip term_id="node" >}} dans votre cluster. Le Pod reste sur ce nœud jusqu'à ce que le process se termine, l'objet pod soit supprimé, le pod soit *expulsé* par manque de ressources, ou le nœud soit en échec. {{< note >}} Redémarrer un conteneur dans un Pod ne doit pas être confondu avec redémarrer un Pod. Un Pod n'est pas un process, mais un environnement pour exécuter un conteneur. Un Pod persiste jusqu'à ce qu'il soit supprimé. @@ -73,7 +73,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 travaill comme +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 [DaemonSets](/docs/concepts/workloads/controllers/daemonset/).