From 2a120450ebc0c2a20f975426313e926ea04a1f1b Mon Sep 17 00:00:00 2001 From: Yushiro FURUKAWA Date: Thu, 10 Oct 2019 18:02:53 +0900 Subject: [PATCH] Remove trailing spaces from FR documents(#16742) (#16788) --- content/fr/community/code-of-conduct.md | 6 +- .../community/static/cncf-code-of-conduct.md | 2 +- .../containers/container-lifecycle-hooks.md | 14 +-- content/fr/docs/concepts/containers/images.md | 16 +-- .../fr/docs/concepts/overview/components.md | 28 ++--- content/fr/docs/concepts/storage/volumes.md | 106 +++++++++--------- .../workloads/controllers/replicaset.md | 12 +- .../workloads/pods/init-containers.md | 52 ++++----- .../concepts/workloads/pods/pod-lifecycle.md | 60 +++++----- .../concepts/workloads/pods/pod-overview.md | 4 +- .../fr/docs/concepts/workloads/pods/pod.md | 32 +++--- content/fr/docs/contribute/start.md | 2 +- .../fr/docs/reference/glossary/contributor.md | 2 +- content/fr/docs/reference/glossary/etcd.md | 6 +- .../docs/reference/glossary/init-container.md | 2 +- .../docs/reference/glossary/kube-apiserver.md | 4 +- .../glossary/kube-controller-manager.md | 6 +- .../fr/docs/reference/glossary/kube-proxy.md | 6 +- .../docs/reference/glossary/kube-scheduler.md | 4 +- .../fr/docs/reference/kubectl/cheatsheet.md | 4 +- content/fr/docs/reference/kubectl/overview.md | 10 +- .../kubeadm/generated/kubeadm_init.md | 2 +- .../setup-tools/kubeadm/kubeadm-init.md | 46 ++++---- .../reference/setup-tools/kubeadm/kubeadm.md | 2 +- content/fr/docs/setup/_index.md | 18 +-- content/fr/docs/setup/custom-cloud/coreos.md | 2 +- content/fr/docs/setup/independent/_index.md | 2 +- .../setup/independent/control-plane-flags.md | 8 +- .../fr/docs/setup/independent/ha-topology.md | 34 +++--- .../setup/independent/high-availability.md | 52 ++++----- .../docs/setup/independent/install-kubeadm.md | 28 ++--- .../setup/independent/kubelet-integration.md | 68 +++++------ .../independent/setup-ha-etcd-with-kubeadm.md | 8 +- .../independent/troubleshooting-kubeadm.md | 84 +++++++------- content/fr/docs/setup/pick-right-solution.md | 18 +-- .../setup/release/building-from-source.md | 2 +- .../assign-cpu-resource.md | 14 +-- .../assign-memory-resource.md | 10 +- .../assign-pods-nodes.md | 4 +- .../configure-volume-storage.md | 6 +- .../extended-resource.md | 2 +- .../quality-service-pod.md | 4 +- .../fr/docs/tasks/tools/install-kubectl.md | 26 ++--- .../fr/docs/tasks/tools/install-minikube.md | 4 +- content/fr/docs/tutorials/hello-minikube.md | 2 +- 45 files changed, 412 insertions(+), 412 deletions(-) diff --git a/content/fr/community/code-of-conduct.md b/content/fr/community/code-of-conduct.md index 82204af8da187..be0b3d1001503 100644 --- a/content/fr/community/code-of-conduct.md +++ b/content/fr/community/code-of-conduct.md @@ -8,11 +8,11 @@ css: /css/community.css

Code de conduite de la communauté Kubernetes

-Kubernetes suit le +Kubernetes suit le Code de Conduite de la CNCF. -Le texte du CdC de la CNCF est reproduit ci-dessous +Le texte du CdC de la CNCF est reproduit ci-dessous commit 214585e. -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 à créer une issue. diff --git a/content/fr/community/static/cncf-code-of-conduct.md b/content/fr/community/static/cncf-code-of-conduct.md index 32db3dbcc1dbc..8d67a9c21add8 100644 --- a/content/fr/community/static/cncf-code-of-conduct.md +++ b/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 . Pour d'autres projets, bien vouloir contacter un responsable de projet CNCF ou notre médiateur, Mishi Choudhary à l'adresse . +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 . Pour d'autres projets, bien vouloir contacter un responsable de projet CNCF ou notre médiateur, Mishi Choudhary à l'adresse . 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/. diff --git a/content/fr/docs/concepts/containers/container-lifecycle-hooks.md b/content/fr/docs/concepts/containers/container-lifecycle-hooks.md index be710f324e432..3b400dbbfabda 100644 --- a/content/fr/docs/concepts/containers/container-lifecycle-hooks.md +++ b/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 `. 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 %}} diff --git a/content/fr/docs/concepts/containers/images.md b/content/fr/docs/concepts/containers/images.md index a59cf0c38acd5..cbc83130dd96a 100644 --- a/content/fr/docs/concepts/containers/images.md +++ b/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 --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 >}} diff --git a/content/fr/docs/concepts/overview/components.md b/content/fr/docs/concepts/overview/components.md index 4a2376d30713f..7617e94573ed3 100644 --- a/content/fr/docs/concepts/overview/components.md +++ b/content/fr/docs/concepts/overview/components.md @@ -2,13 +2,13 @@ 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 %}} @@ -16,11 +16,11 @@ un cluster Kubernetes fonctionnel. ## 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 diff --git a/content/fr/docs/concepts/storage/volumes.md b/content/fr/docs/concepts/storage/volumes.md index 062504b97a6b4..51f1c99dfd5d6 100644 --- a/content/fr/docs/concepts/storage/volumes.md +++ b/content/fr/docs/concepts/storage/volumes.md @@ -6,11 +6,11 @@ weight: 10 {{% capture overview %}} -Les fichiers sur disque dans un conteneur sont éphémères, ce qui présente des problèmes pour -des applications non-triviales lorsqu'elles s'exécutent dans des conteneurs. Premièrement, lorsqu'un -conteneur plante, kubelet va le redémarrer mais les fichiers seront perdus - le conteneur démarre -avec un état propre. Deuxièmement, lorsque plusieurs conteneurs s'exécutent ensemble dans un `Pod`, -il est souvent nécessaire de partager des fichiers entre ces conteneurs. L'abstraction Kubernetes +Les fichiers sur disque dans un conteneur sont éphémères, ce qui présente des problèmes pour +des applications non-triviales lorsqu'elles s'exécutent dans des conteneurs. Premièrement, lorsqu'un +conteneur plante, kubelet va le redémarrer mais les fichiers seront perdus - le conteneur démarre +avec un état propre. Deuxièmement, lorsque plusieurs conteneurs s'exécutent ensemble dans un `Pod`, +il est souvent nécessaire de partager des fichiers entre ces conteneurs. L'abstraction Kubernetes `Volume` résout ces deux problèmes. Une connaissance des [Pods](/fr/docs/concepts/workloads/pods/pod) est suggérée. @@ -21,14 +21,14 @@ Une connaissance des [Pods](/fr/docs/concepts/workloads/pods/pod) est suggérée ## Contexte -Docker a également un concept de [volumes](https://docs.docker.com/engine/admin/volumes/), bien qu'il +Docker a également un concept de [volumes](https://docs.docker.com/engine/admin/volumes/), bien qu'il soit, dans une certaine mesure, plus relâché et moins géré. Avec Docker, un volume est simplement un dossier sur le disque ou dans un autre conteneur. Les durées de vie ne sont pas gérées et, jusqu'à très récemment, seuls les volumes supportés par un disque local l'étaient. Docker fournit maintenant des pilotes de volume, mais la fonctionnalité est très limitée pour le moment (par exemple, à partir de Docker 1.7, seulement un pilote de volume est autorisé par conteneur et il n'est pas possible de passer des paramètres aux volumes). - + Un volume Kubernetes, en revanche, a une durée de vie explicite - la même que le Pod qui l'inclut. -Par conséquent, un volume survit aux conteneurs qui s'exécutent à l'intérieur du Pod et les données sont préservées lorsque le conteneur redémarre. +Par conséquent, un volume survit aux conteneurs qui s'exécutent à l'intérieur du Pod et les données sont préservées lorsque le conteneur redémarre. Bien sûr, lorsqu'un Pod cesse d'exister, le volume va également cesser d'exister. Peut-être plus important encore, Kubernetes supporte de nombreux types de volumes et un Pod peut en utiliser plusieurs simultanément. @@ -79,7 +79,7 @@ Toute contribution supplémentaire est la bienvenue. ### awsElasticBlockStore {#awselasticblockstore} -Un type de volume `awsElasticBlockStore` monte un [Volume EBS](http://aws.amazon.com/ebs/) d'Amazon Web Services (AWS) dans un Pod. +Un type de volume `awsElasticBlockStore` monte un [Volume EBS](http://aws.amazon.com/ebs/) d'Amazon Web Services (AWS) dans un Pod. À la différence de `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume EBS est préservé et le volume est seulement démonté. Cela signifie qu'un volume EBS peut être prérempli avec des données et que les données peuvent être transmises entre les Pods. @@ -132,7 +132,7 @@ spec: La fonctionnalité de migration CSI pour awsElasticBlockStore, lorsque activée, fixe toutes les opérations de plugin depuis le plugin "in-tree" vers le pilote de l'interface CSI (Container Storage Interface) `ebs.csi.aws.com`. Afin d'utiliser cette fonctionnalité, le [Pilote AWS EBS CSI](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) doit être installé dans le cluster et les fonctionnalités Alpha `CSIMigration` et `CSIMigrationAWS` doivent être activées. - + ### azureDisk {#azuredisk} Un type de volume `azureDisk` est utilisé pour monter un disque de données ([Data Disk](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/)) dans un Pod. @@ -175,7 +175,7 @@ Voir [l'exemple CephFS](https://github.com/kubernetes/examples/tree/{{< param "g ### cinder {#cinder} {{< note >}} -prérequis : Kubernetes avec le fournisseur infonuagique OpenStack (OpenStack Cloud Provider) configuré. +prérequis : Kubernetes avec le fournisseur infonuagique OpenStack (OpenStack Cloud Provider) configuré. Pour la configuration cloudprovider, se référer à [cloud provider openstack](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#openstack). {{< /note >}} @@ -213,10 +213,10 @@ Afin d'utiliser cette fonctionnalité, le [Pilote Cinder CSI](https://github.com ### configMap {#configmap} La ressource [`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) fournit un moyen d'injecter des données de configuration dans les Pods. -Les données stockées dans un objet `ConfigMap` peuvent être référencées dans un volume de type `configMap` +Les données stockées dans un objet `ConfigMap` peuvent être référencées dans un volume de type `configMap` et être ensuite consommées par des applications conteneurisées s'exécutant dans un Pod. -Lorsque l'on référence un objet `configMap`, on peut simplement fournir son nom dans le volume +Lorsque l'on référence un objet `configMap`, on peut simplement fournir son nom dans le volume pour le référencer. On peut également personnaliser le chemin pour utiliser une entrée spécifique dans la ConfigMap. Par exemple, pour monter la ConfigMap `log-config` sur un Pod appelé `configmap-pod`, vous pourriez utiliser le YAML suivant : @@ -307,7 +307,7 @@ spec: ### fc (fibre channel) {#fc} Un volume `fc` permet à un volume Fibre Channel existant d'être monté dans un Pod. -Vous pouvez spécifier une ou plusieurs cibles World Wide Names en utilisant le paramètre +Vous pouvez spécifier une ou plusieurs cibles World Wide Names en utilisant le paramètre `targetWWNs` dans votre configuration de volume. Si plusieurs WWNs sont spécifiés, targetWWNs s'attend à ce que ces WWNs proviennent de connexions multi-path. @@ -334,7 +334,7 @@ Voir [l'exemple Flocker](https://github.com/kubernetes/examples/tree/{{< param " ### gcePersistentDisk {#gcepersistentdisk} -Un volume `gcePersistentDisk` monte un [Disque Persistant](http://cloud.google.com/compute/docs/disks) Google Compute Engine (GCE) dans un Pod. +Un volume `gcePersistentDisk` monte un [Disque Persistant](http://cloud.google.com/compute/docs/disks) Google Compute Engine (GCE) dans un Pod. À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un disque persistant est préservé et le volume est simplement démonté. Cela signifie qu'un disque persistant peut être prérempli avec des données et que ces données peuvent être transmises entre les Pods. {{< caution >}} @@ -347,7 +347,7 @@ Des restrictions existent lors de l'utilisation d'un `gcePersistentDisk`: * ces VMs doivent se trouver dans le même projet et la même zone GCE que le disque persistant Une fonctionnalité des disques persistants est qu'ils peuvent être montés en lecture seule par plusieurs consommateurs simultanément. -Cela signifie que vous pouvez préremplir un disque persistant avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire. +Cela signifie que vous pouvez préremplir un disque persistant avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire. Malheureusement, les disques persistants peuvent seulement être montés par un seul consommateur en mode lecture-écriture - les écritures simultanées ne sont pas autorisées. Utiliser un disque persistant dans un Pod contrôlé par un ReplicationController échouera à moins que le disque persistant soit en lecture seule ou que le nombre de répliques soit de 0 ou 1. @@ -459,7 +459,7 @@ spec: Un volume `glusterfs` permet à un volume [Glusterfs](http://www.gluster.org) (un système de fichiers en réseau open source) d'être monté dans un Pod. À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé. le contenu d'un volume `glusterfs` est préservé et le volume est simplement démonté. Cela signifie qu'un volume glusterfs peut être prérempli avec des données et que ces données peuvent être transmises entre les Pods. -GlusterFS peut être monté plusieurs fois en écriture simultanément. +GlusterFS peut être monté plusieurs fois en écriture simultanément. {{< caution >}} Vous devez exécuter votre propre installation de GlusterFS avant de pouvoir l'utiliser. @@ -469,7 +469,7 @@ Voir [l'exemple GlusterFS](https://github.com/kubernetes/examples/tree/{{< param ### hostPath {#hostpath} -Un volume `hostPath` monte un fichier ou un dossier depuis le système de fichiers du nœud hôte à l'intérieur d'un Pod. +Un volume `hostPath` monte un fichier ou un dossier depuis le système de fichiers du nœud hôte à l'intérieur d'un Pod. Ce ne sera pas requis pour la plupart des Pods, mais cela offre une puissante solution de secours pour certaines applications. Par exemple, des utilisations du `hostPath` peuvent être : @@ -525,7 +525,7 @@ spec: ### iscsi {#iscsi} -Un volume `iscsi` permet à un volume existant iSCSI (SCSI over IP) d'être monté dans un Pod. +Un volume `iscsi` permet à un volume existant iSCSI (SCSI over IP) d'être monté dans un Pod. À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume `iscsi` est préservé et le volume est simplement démonté. Cela signifie qu'un volume iscsi peut être prérempli avec des données que ces données peuvent être transmises entre les Pods. @@ -534,7 +534,7 @@ Vous devez exécuter votre propre serveur iSCSI avec le volume créé avant de p {{< /caution >}} Une fonctionnalité de iSCSI est qu'il peut être monté en lecture seule par plusieurs consommateurs simultanément. -Cela signifie que vous pouvez préremplir un volume avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire. +Cela signifie que vous pouvez préremplir un volume avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire. Malheureusement, les volumes iSCSI peuvent seulement être montés par un seul consommateur en mode lecture-écriture - les écritures simultanées ne sont pas autorisées. Voir [l'exemple iSCSI](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) pour plus de détails. @@ -545,7 +545,7 @@ Voir [l'exemple iSCSI](https://github.com/kubernetes/examples/tree/{{< param "gi Un volume `local` représente un périphérique de stockage local monté tels qu'un disque, une partition ou un dossier. -Les volumes locaux peuvent seulement être utilisés comme un PersistentVolume créé statiquement. +Les volumes locaux peuvent seulement être utilisés comme un PersistentVolume créé statiquement. Le provisionnement dynamique n'est pas encore supporté. Comparés aux volumes `hostPath`, les volumes locaux peuvent être utilisés de manière durable et portable sans planifier manuellement des Pods sur les nœuds, puisque le système est conscient des contraintes de nœud du volume en examinant l'affinité de nœud sur le PersistentVolume. @@ -580,10 +580,10 @@ spec: - example-node ``` -La `nodeAffinity` d'un PersistentVolume est requise lors de l'utilisation de volumes locaux. +La `nodeAffinity` d'un PersistentVolume est requise lors de l'utilisation de volumes locaux. Cela permet au planificateur (scheduler) Kubernetes de planifier correctement des Pods utilisant des volumes locaux aux bons nœuds. -Le `volumeMode` d'un PersistentVolume peut maintenant être configuré à "Block" (au lieu de la valeur par défaut "Filesystem") pour exposer le volume local en tant que périphérique bloc brut (raw block device). +Le `volumeMode` d'un PersistentVolume peut maintenant être configuré à "Block" (au lieu de la valeur par défaut "Filesystem") pour exposer le volume local en tant que périphérique bloc brut (raw block device). Le champ `volumeMode` requiert l'activation de la "feature gate" Alpha `BlockVolume`. Lors de l'utilisation des volumes locaux, il est recommandé de créer une StorageClass avec `volumeBindingMode` configuré à `WaitForFirstConsumer`. Voir [l'exemple](/docs/concepts/storage/storage-classes/#local). Retarder la liaison (binding) du volume garantit que la décision de liaison du PersistentVolumeClaim sera également évaluée avec toutes les autres contraintes de nœud que le Pod peut avoir, tels que les exigences en ressources du nœud, les sélecteurs de nœud, leur affinité et leur anti-affinité. @@ -598,7 +598,7 @@ Le PersistentVolume local requiert un nettoyage manuel et une suppression par l' ### nfs {#nfs} Un volume `nfs` permet à un partage NFS (Network File System) existant d'être monté dans un Pod. -À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume `nfs` est préservé et le volume est simplement démonté. +À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume `nfs` est préservé et le volume est simplement démonté. Cela signifie qu'un volume NFS peut être prérempli avec des données et que les données peuvent être transmises entre les Pods. NFS peut être monté plusieurs fois en écriture simultanément. {{< caution >}} @@ -701,7 +701,7 @@ spec: mode: 511 ``` -Chaque source de volume projeté est listée dans la spec, sous `sources`. Les paramètres sont à peu près les mêmes avec deux exceptions : +Chaque source de volume projeté est listée dans la spec, sous `sources`. Les paramètres sont à peu près les mêmes avec deux exceptions : * Pour les secrets, le champ `secretName` a été changé par `name` pour être consistant avec le nommage des ConfigMap. * Le `defaultMode` peut seulement être spécifié au niveau projeté et non pour chaque source de volume. Cependant, tel qu'illustré au-dessus, il est possible de configurer explicitement le `mode` pour chaque projection individuelle. @@ -731,10 +731,10 @@ spec: path: token ``` -Le pod d'exemple possède un volume projeté contenant le jeton injecté du service account. -Ce jeton peut être utilisé par des conteneurs de Pod pour accéder au service d'API Kubernetes API, par exemple. -Le champ `audience` contient l'audience-cible du jeton. -Un destinataire du jeton doit s'identifier avec un identificateur spécifié dans l'audience du jeton, sinon il doit rejeter le jeton. Ce champ est facultatif et sa valeur par défaut est l'identifiant du serveur API. +Le pod d'exemple possède un volume projeté contenant le jeton injecté du service account. +Ce jeton peut être utilisé par des conteneurs de Pod pour accéder au service d'API Kubernetes API, par exemple. +Le champ `audience` contient l'audience-cible du jeton. +Un destinataire du jeton doit s'identifier avec un identificateur spécifié dans l'audience du jeton, sinon il doit rejeter le jeton. Ce champ est facultatif et sa valeur par défaut est l'identifiant du serveur API. Le champ `expirationSeconds` est la durée de validité attendue du jeton de service account. Sa valeur par défaut est de 1 heure et doit être au moins de 10 minutes (600 secondes). Un administrateur peut aussi limiter sa valeur maximum en spécifiant l'option `--service-account-max-token-expiration` pour le serveur API. @@ -750,7 +750,7 @@ Un `portworxVolume` est une couche de stockage bloc élastique qui s'exécute de [Portworx](https://portworx.com/use-case/kubernetes-storage/) donne l'empreinte digitale d'un stockage dans un serveur, tiers basés sur les capacités et agrège la capacité sur plusieurs serveurs. Portworx s'exécute en invité sur des machines virtuelles ou sur des nœuds Linux bare metal. Un `portworxVolume` peut être créé dynamiquement à travers Kubernetes ou il peut également être pré-provisionné et référencé à l'intérieur d'un Pod Kubernetes. -Voici un exemple de Pod référençant un PortworxVolume pré-provisionné : +Voici un exemple de Pod référençant un PortworxVolume pré-provisionné : ```yaml apiVersion: v1 @@ -786,29 +786,29 @@ Un volume `quobyte` permet à un volume existant [Quobyte](http://www.quobyte.co Vous devez exécuter votre propre configuration Quobyte avec les volumes créés avant de pouvoir l'utiliser. {{< /caution >}} -Quobyte supporte le {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}}. +Quobyte supporte le {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}}. CSI est le plugin recommandé pour utiliser les volumes Quobyte volumes dans Kubernetes. Le projet GitHub Quobyte dispose [d'instructions](https://github.com/quobyte/quobyte-csi#quobyte-csi) pour déployer Quobyte en utilisant CSI, avec des exemples. ### rbd {#rbd} Un volume `rbd` permet à un volume périphérique bloc Rados ([Rados Block Device](http://ceph.com/docs/master/rbd/rbd/)) d'être monté dans un Pod. -À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume `rbd` est préservé et le volume est simplement démonté. +À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume `rbd` est préservé et le volume est simplement démonté. Cela signifie qu'un volume RBD peut être prérempli avec des données et que ces données peuvent être transmises entre les Pods. {{< caution >}} Vous devez exécuter votre propre installation Ceph avant de pouvoir utiliser RBD. {{< /caution >}} -Une fonctionnalité de RBD est qu'il peut être monté en lecture seule par plusieurs consommateurs simultanément. -Cela signifie que vous pouvez préremplir un volume avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire. +Une fonctionnalité de RBD est qu'il peut être monté en lecture seule par plusieurs consommateurs simultanément. +Cela signifie que vous pouvez préremplir un volume avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire. Malheureusement, les volumes RBD peuvent seulement être montés par un seul consommateur en mode lecture-écriture - les écritures simultanées ne sont pas autorisées. Voir [l'exemple RBD](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd) pour plus de détails. ### scaleIO {#scaleio} -ScaleIO est une plateforme de stockage logicielle qui peut utiliser du matériel physique existant pour créer des clusters de stockage bloc partagé en réseau évolutif. +ScaleIO est une plateforme de stockage logicielle qui peut utiliser du matériel physique existant pour créer des clusters de stockage bloc partagé en réseau évolutif. Le plugin de volume `scaleIO` permet aux Pods déployés d'accéder à des volumes ScaleIO existants (ou il peut provisionner dynamiquement de nouveaux volumes pour des revendications de volumes persistants, voir [ScaleIO Persistent Volumes](/docs/concepts/storage/persistent-volumes/#scaleio)). {{< caution >}} @@ -846,7 +846,7 @@ Pour plus de détails, consulter [les exemples ScaleIO](https://github.com/kuber ### secret {#secret} -Un volume `secret` est utilisé pour fournir des informations sensibles, comme des mots de passe, aux Pods. +Un volume `secret` est utilisé pour fournir des informations sensibles, comme des mots de passe, aux Pods. Vous pouvez stocker des secrets dans l'API Kubernetes et les monter en tant que fichiers pour être utilisés par les Pods sans les coupler directement avec Kubernetes. Les volumes `secret` sont supportés par tmpfs (un système de fichiers en RAM) pour qu'ils ne soient jamais écrits sur du stockage non volatil. {{< caution >}} @@ -864,7 +864,7 @@ Les secrets sont décrits plus en détails [ici](/docs/user-guide/secrets). Un volume `storageos` permet à un volume [StorageOS](https://www.storageos.com) existant d'être monté dans un Pod. StorageOS s'exécute en tant que conteneur dans l'environnement Kubernetes en rendant le stockage local ou attaché accessible depuis n'importe quel nœud dans le cluster Kubernetes. -Les données peuvent être répliquées pour se protéger des défaillances de nœuds. +Les données peuvent être répliquées pour se protéger des défaillances de nœuds. Les techniques d'allocation fine et dynamique et de compression peuvent améliorer l'utilisation et réduire les coûts. À la base, StorageOS fournit un stockage bloc aux conteneurs accessible via un système de fichiers. @@ -1046,9 +1046,9 @@ spec: ## Ressources -Le support de stockage (Disk, SSD, etc.) d'un volume `emptyDir` est déterminé par le support du système de fichiers +Le support de stockage (Disk, SSD, etc.) d'un volume `emptyDir` est déterminé par le support du système de fichiers contenant le dossier racine de kubelet (typiquement `/var/lib/kubelet`). -Il n'y a pas de limite sur l'espace qu'un volume `emptyDir` ou `hostPath` peut consommer +Il n'y a pas de limite sur l'espace qu'un volume `emptyDir` ou `hostPath` peut consommer et pas d'isolation entre les conteneurs ou entre les Pods. Dans le futur, il est prévu que les volumes `emptyDir` et `hostPath` soient en mesure de demander une certaine quantité d'espace en utilisant une spécification de [ressource](/docs/user-guide/compute-resources) et de sélectionner un type de support à utiliser, pour les clusters qui ont plusieurs types de support. @@ -1086,30 +1086,30 @@ utiliser le type de volume `csi` pour attacher, monter, etc.., les volumes expos Le type de volume `csi` ne supporte pas de référence directe depuis un Pod et ne peut être référencé seulement dans un Pod que par un objet `PersistentVolumeClaim`. -Les champs suivants sont disponibles aux administrateurs de stockage pour configurer un volume persistant CSI : +Les champs suivants sont disponibles aux administrateurs de stockage pour configurer un volume persistant CSI : - `driver`: Une valeur texte qui spécifie le nom du pilote de volume à utiliser. - Cette valeur doit correspondre à la valeur retournée dans le `GetPluginInfoResponse` par le pilote CSI tel que défini dans la + Cette valeur doit correspondre à la valeur retournée dans le `GetPluginInfoResponse` par le pilote CSI tel que défini dans la [spec CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo). Elle est utilisée par Kubernetes pour identifier le pilote CSI à appeler et par les composants du pilote CSI pour identifier quels objets PV appartiennent au pilote CSI. - `volumeHandle`: Une valeur texte qui identifie le volume de manière unique. Cette valeur doit correspondre à la valeur retournée dans le champ `volume.id` de `CreateVolumeResponse` par le pilote CSI tel que défini dans la [spec CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). La valeur est passée en tant que `volume_id` sur tous les appels au pilote de volume CSI lorsque le volume est référencé. -- `readOnly`: Une valeur booléenne optionnelle indiquant si le volume doit être +- `readOnly`: Une valeur booléenne optionnelle indiquant si le volume doit être "ControllerPublished" (attaché) en lecture seule. La valeur par défaut est "false". Cette valeur est passées au pilote CSI via le champ `readonly` dans le `ControllerPublishVolumeRequest`. - `fsType`: Si le `VolumeMode` du PV est `Filesystem`, alors ce champ peut être utilisé pour spécifier le système de fichiers - qui devrait être utilisé pour monter le volume. Si le volume n'a pas été formaté et que le formatage est supporté, cette valeur sera + qui devrait être utilisé pour monter le volume. Si le volume n'a pas été formaté et que le formatage est supporté, cette valeur sera utilisée pour formater le volume. - Cette valeur est passée au pilote CSI driver via le champ `VolumeCapability` de + Cette valeur est passée au pilote CSI driver via le champ `VolumeCapability` de `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, et `NodePublishVolumeRequest`. -- `volumeAttributes`: Un tableau associatif (map) string vers string qui spécifie les propriétés statiques d'un volume. Ce tableau associatif doit correspondre à celui retourné dans le champ +- `volumeAttributes`: Un tableau associatif (map) string vers string qui spécifie les propriétés statiques d'un volume. Ce tableau associatif doit correspondre à celui retourné dans le champ `volume.attributes` du `CreateVolumeResponse` par le pilote CSI tel que défini dans la [spec CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). Le tableau associatif est passé au pilote CSI via le champ `volume_attributes` dans la `ControllerPublishVolumeRequest`, `NodeStageV olumeRequest`, et `NodePublishVolumeRequest`. -- `controllerPublishSecretRef`: Une référence de l'objet de type secret contenant des informations sensibles à passer - au driver CSI pour compléter les appels CSI `ControllerPublishVolume` et `ControllerUnpublishVolume`. +- `controllerPublishSecretRef`: Une référence de l'objet de type secret contenant des informations sensibles à passer + au driver CSI pour compléter les appels CSI `ControllerPublishVolume` et `ControllerUnpublishVolume`. Ce champ est optionnel et peut être vide si aucun secret n'est requis. Si l'objet secret contient plus qu'un secret, tous les secrets sont passés. - `nodeStageSecretRef`: Une référence à l'objet de type secret contenant des informations sensibles à passer au pilote CSI @@ -1123,7 +1123,7 @@ Les champs suivants sont disponibles aux administrateurs de stockage pour config {{< feature-state for_k8s_version="v1.14" state="beta" >}} -À partir de la version 1.11, CSI a introduit le support des volumes bloc bruts, qui s'appuient +À partir de la version 1.11, CSI a introduit le support des volumes bloc bruts, qui s'appuient sur la fonctionnalité de volume bloc brut introduite dans une version précédente de Kubernetes. Cette fonctionnalité va permettre aux fournisseurs avec des pilotes CSI externes d'implémenter le support pour les volumes bloc bruts dans les charges de travail Kubernetes. @@ -1178,7 +1178,7 @@ Pour plus d'informations sur la manière de développer un pilote CSI, se réfé {{< feature-state for_k8s_version="v1.14" state="alpha" >}} La fonctionnalité de migration CSI, lorsque activée, dirige les opérations sur les plugins "in-tree" existants vers les plugins CSI correspondants (qui sont sensés être installés et configurés). -Cette fonctionnalité implémente la logique de translation nécessaire et les fixations nécessaires pour rerouter les opérations +Cette fonctionnalité implémente la logique de translation nécessaire et les fixations nécessaires pour rerouter les opérations de manière transparente. En conséquence, les opérateurs n'ont pas à effectuer de changements de configuration aux classes de stockage (Storage Classes) existantes, PV ou PVC (référençant aux plugins "in-tree") lors de la transition vers un pilote CSI qui remplace un plugin "in-tree". Dans l'état alpha, les opérations et fonctionnalités qui sont supportées incluent provisionnement/suppression, attachement/détachement, montage/démontage et le redimensionnement des volumes. @@ -1198,7 +1198,7 @@ Plus de détails sont disponibles [ici](https://github.com/kubernetes/community/ La propagation de montage permet à des volumes partagés montés par un conteneur à d'autres conteneurs dans un même Pod, ou même à d'autres Pods dans le même nœud. La propagation de montage d'un volume est contrôlée par le champ `mountPropagation` dans Container.volumeMounts. -Ses valeurs sont : +Ses valeurs sont : * `None` - Ce montage de volume ne recevra aucun montage subséquent qui est monté à ce volume ou n'importe lequel de ses sous-dossiers par l'hôte. De la même manière, aucun montage créé par le conteneur ne sera visible sur l'hôte. C'est le mode par défaut. @@ -1207,7 +1207,7 @@ Ses valeurs sont : * `HostToContainer` - Ce montage de volume recevra les montages subséquents qui sont montés sur ce volume ou n'importe lequel de ses sous-dossiers. En d'autres termes, si l'hôte monte quoi que ce soit dans le montage de volume, le conteneur va le voir monté à cet endroit. - + De manière similaire, si un Pod avec la propagation de montage `Bidirectional` vers le même volume y monte quoi que ce soit, le conteneur avec la propagation de montage `HostToContainer` le verra. @@ -1223,7 +1223,7 @@ Ses valeurs sont : [documentation du noyau Linux](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) {{< caution >}} -La propagation de montage `Bidirectional` peut être dangereuse. Elle peut endommager le système d'exploitation hôte +La propagation de montage `Bidirectional` peut être dangereuse. Elle peut endommager le système d'exploitation hôte et est donc autorisée seulement dans des conteneurs privilégiés. Il est fortement recommandé d'être familier avec le comportement du noyau Linux. De plus, tous les montages de volume créés par des conteneurs dans des Pods doivent être détruits (démontés) par les conteneurs lors de la terminaison. @@ -1231,7 +1231,7 @@ De plus, tous les montages de volume créés par des conteneurs dans des Pods do ### Configuration Avant que la propagation de montage puisse fonctionner correctement sur certains déploiements (CoreOS, -RedHat/Centos, Ubuntu) le partage de montage doit être correctement configuré dans Docker tel qu'illustré ci-dessous : +RedHat/Centos, Ubuntu) le partage de montage doit être correctement configuré dans Docker tel qu'illustré ci-dessous : Modifiez le fichier de service `systemd` de votre Docker. Configurez votre `MountFlags` comme suit : ```shell diff --git a/content/fr/docs/concepts/workloads/controllers/replicaset.md b/content/fr/docs/concepts/workloads/controllers/replicaset.md index 59b71ed0924e6..24c7676017443 100644 --- a/content/fr/docs/concepts/workloads/controllers/replicaset.md +++ b/content/fr/docs/concepts/workloads/controllers/replicaset.md @@ -7,7 +7,7 @@ weight: 10 {{% capture overview %}} Un ReplicaSet (ensemble de réplicas en français) a pour but de maintenir un ensemble stable de Pods à un moment donné. -Cet objet est souvent utilisé pour garantir la disponibilité d'un certain nombre identique de Pods. +Cet objet est souvent utilisé pour garantir la disponibilité d'un certain nombre identique de Pods. {{% /capture %}} @@ -15,14 +15,14 @@ Cet objet est souvent utilisé pour garantir la disponibilité d'un certain nomb ## Comment un ReplicaSet fonctionne -Un ReplicaSet est défini avec des champs, incluant un selecteur qui spécifie comment identifier les Pods qu'il peut posséder, +Un ReplicaSet est défini avec des champs, incluant un selecteur qui spécifie comment identifier les Pods qu'il peut posséder, un nombre de replicas indiquant le nombre de Pods qu'il doit maintenir et un modèle de Pod spécifiant les données que les nouveaux Pods que le replicatSet va créer jusqu'au nombre de replicas demandé. Un ReplicaSet va atteindre son objectif en créant et supprimant des Pods pour atteindre le nombre de réplicas désirés. Quand un ReplicaSet a besoin de créer de nouveaux Pods, il utilise alors son Pod template. -Le lien d'un ReplicaSet à ses Pods est fait par le champ [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents), +Le lien d'un ReplicaSet à ses Pods est fait par le champ [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents), qui spécifie la ressource de l'objet par lequel il est détenu. Tous les Pods acquis par un ReplicaSet ont leurs propres informations d'identification de leur Replicaset, avec leur propre champ ownerReferences. C'est par ce lien que le ReplicaSet connait l'état des Pods qu'il maintient et agit en fonction de ces derniers. Un ReplicaSet identifie des nouveaux Pods à acquérir en utilisant son selecteur. @@ -276,7 +276,7 @@ Pour mettre à jour les Pods à une nouvelle spec de manière contrôlée, utili ### Isoler les pods d'un ReplicaSet Vous pouvez supprimer les pods d'un ReplicaSet en modifiant leurs labels. Cette technique peut être utilisée pour enlever les pods -pour le débogage, récupération de données, etc. Les pods ainsi supprimés seront automatiquement remplacés +pour le débogage, récupération de données, etc. Les pods ainsi supprimés seront automatiquement remplacés (en supposant que le nombre de réplicas n’est pas également modifié). ### Scaling d'un ReplicaSet @@ -287,7 +287,7 @@ garantit que le nombre souhaité de pods avec un sélecteur de label corresponda ### ReplicaSet en tant que Horizontal Pod Autoscaler Target Un ReplicaSet peut également être une cible pour -[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/). +[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/). Un ReplicaSet peut être mis à l'échelle automatiquement par un HPA. Voici un exemple HPA qui cible le ReplicaSet que nous avons créé dans l'exemple précédent. @@ -332,7 +332,7 @@ Utilisez un [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) au Utilisez un [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) au lieu d’un ReplicaSet pour les pods qui fournissent une fonction au niveau du noeud, comme le monitoring ou la gestion des logs de ce noeud. Ces pods ont une durée de vie qui est liée -durée de vie d’une machine : le pod doit être en cours d’exécution sur la machine avant le démarrage des autres Pods et sont +durée de vie d’une machine : le pod doit être en cours d’exécution sur la machine avant le démarrage des autres Pods et sont sûrs de se terminer lorsque la machine est prête à être redémarrée/arrêtée. ### ReplicationController diff --git a/content/fr/docs/concepts/workloads/pods/init-containers.md b/content/fr/docs/concepts/workloads/pods/init-containers.md index e33b9abcceff2..e9bd2755f8d0b 100644 --- a/content/fr/docs/concepts/workloads/pods/init-containers.md +++ b/content/fr/docs/concepts/workloads/pods/init-containers.md @@ -25,35 +25,35 @@ Les init containers se comportent comme les conteneurs réguliers, avec quelques Si le init container d'un Pod échoue, Kubernetes redémarre le Pod à répétition jusqu'à ce que le init container se termine avec succès. Cependant, si le Pod a une `restartPolicy` à "Never", Kubernetes ne redémarre pas le Pod. -Afin de spécifier un init container pour un Pod, il faut ajouter le champ `initContainers` dans la spécification du Pod, comme un -tableau d'objets de type [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core), au même niveau que le tableau d'applications `containers`. -Le statut des init containers est retourné dans le champ `.status.initContainerStatuses` +Afin de spécifier un init container pour un Pod, il faut ajouter le champ `initContainers` dans la spécification du Pod, comme un +tableau d'objets de type [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core), au même niveau que le tableau d'applications `containers`. +Le statut des init containers est retourné dans le champ `.status.initContainerStatuses` comme un tableau des statuts du conteneur (comparable au champ `.status.containerStatuses`). ### Différences avec les conteneurs réguliers -Les init containers supportent tous les champs et fonctionnalités des conteneurs d'application -incluant les limites de ressources, les volumes et les paramètres de sécurité. -Cependant, les demandes de ressources pour un init container sont gérées différemment des +Les init containers supportent tous les champs et fonctionnalités des conteneurs d'application +incluant les limites de ressources, les volumes et les paramètres de sécurité. +Cependant, les demandes de ressources pour un init container sont gérées différemment des limites de ressources, tel que documenté dans [Ressources](#ressources). -De plus, les init containers ne supportent pas les readiness probes parce que ces conteneurs +De plus, les init containers ne supportent pas les readiness probes parce que ces conteneurs s'exécutent jusqu'au bout avant que le Pod soit prêt. Si l'on spécifie plusieurs init containers pour un Pod, Kubelet exécute chaque init container de manière séquentielle. Chaque init container doit se terminer avec succès avant que le prochain ne puisse s'exécuter. -Lorsque tous les init containers se sont exécutés jusqu'au bout, Kubelet initialise +Lorsque tous les init containers se sont exécutés jusqu'au bout, Kubelet initialise les conteneurs d'application pour le Pod et les exécute comme d'habitude. ## Utiliser les init containers -Puisque les init containers ont des images séparées des conteneurs d'application, +Puisque les init containers ont des images séparées des conteneurs d'application, ils apportent certains avantages pour du code de mise en route : -* Les init containers peuvent contenir des utilitaires ou du code de configuration personnalisé -qui ne sont pas présents dans une image d'application. -Par exemple, il n'y a pas besoin de faire hériter une image d'une autre (`FROM`) seulement pour utiliser +* Les init containers peuvent contenir des utilitaires ou du code de configuration personnalisé +qui ne sont pas présents dans une image d'application. +Par exemple, il n'y a pas besoin de faire hériter une image d'une autre (`FROM`) seulement pour utiliser un outil comme `sed`, `awk`, `python`, ou `dig` pendant l'installation. * Les init containers peuvent exécuter en toute sécurité des utilitaires qui rendraient moins sécurisée une image de conteneur d'application. * Les rôles "builder" et "deployer" d'une image d'application peuvent travailler indépendamment sans qu'il n'y ait besoin @@ -67,7 +67,7 @@ offrent un mécanisme pour bloquer ou retarder le démarrage d'un conteneur d'ap Voici plusieurs idées pour utiliser les init containers : * Attendre qu'un {{< glossary_tooltip text="Service" term_id="service">}} soit créé, - en utilisant une commande shell d'une ligne telle que : + en utilisant une commande shell d'une ligne telle que : ```shell for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1 ``` @@ -85,7 +85,7 @@ Voici plusieurs idées pour utiliser les init containers : * Cloner un dépôt Git dans un {{< glossary_tooltip text="Volume" term_id="volume" >}} * Placer des valeurs dans un fichier de configuration et exécuter un outil de templating pour générer -dynamiquement un fichier de configuration pour le conteneur d'application principal. +dynamiquement un fichier de configuration pour le conteneur d'application principal. Par exemple, placer la valeur `POD_IP` dans une configuration et générer le fichier de configuration de l'application principale en utilisant Jinja. @@ -207,7 +207,7 @@ kubectl logs myapp-pod -c init-mydb # Inspecter le second init container À ce stade, ces init containers attendent de découvrir les services nommés `mydb` et `myservice`. -Voici une configuration que vous pouvez utiliser pour faire apparaître ces Services : +Voici une configuration que vous pouvez utiliser pour faire apparaître ces Services : ```yaml --- @@ -242,7 +242,7 @@ service/myservice created service/mydb created ``` -Vous verrez ensuite que ces init containers se terminent et que le Pod `myapp-pod` évolue vers l'état "Running" (en exécution) : +Vous verrez ensuite que ces init containers se terminent et que le Pod `myapp-pod` évolue vers l'état "Running" (en exécution) : ```shell kubectl get -f myapp.yaml @@ -264,7 +264,7 @@ se termine avec un échec, il est redémarré selon la `restartPolicy` du Pod. Toutefois, si la `restartPolicy` du Pod est configurée à "Always", les init containers utilisent la `restartPolicy` "OnFailure". Un Pod ne peut pas être `Ready` tant que tous les init containers ne se sont pas exécutés avec succès. -Les ports d'un init container ne sont pas agrégés sous un Service. Un Pod qui s'initialise +Les ports d'un init container ne sont pas agrégés sous un Service. Un Pod qui s'initialise est dans l'état `Pending` mais devrait avoir une condition `Initializing` configurée à "true". Si le Pod [redémarre](#raisons-du-redémarrage-d-un-pod) ou est redémarré, tous les init containers @@ -273,7 +273,7 @@ doivent s'exécuter à nouveau. Les changements aux spec d'un init containers sont limités au champ image du conteneur. Changer le champ image d'un init container équivaut à redémarrer le Pod. -Puisque les init containers peuvent être redémarrés, réessayés ou ré-exécutés, +Puisque les init containers peuvent être redémarrés, réessayés ou ré-exécutés, leur code doit être idempotent. En particulier, le code qui écrit dans des fichiers sur `EmptyDirs` devrait être préparé à la possibilité qu'un fichier de sortie existe déjà. @@ -282,38 +282,38 @@ Cependant, Kubernetes interdit l'utilisation de `readinessProbe` parce que les i ne peuvent pas définir une "readiness" distincte de la complétion. Ceci est appliqué lors de la validation. L'utilisation de `activeDeadlineSeconds` sur le Pod et `livenessProbe` sur le conteneur -permet d'empêcher les init containers d'échouer tout le temps. +permet d'empêcher les init containers d'échouer tout le temps. La deadline active inclut les init containers. -Le nom de chaque application et init container dans un Pod doit être unique; une erreur de validation +Le nom de chaque application et init container dans un Pod doit être unique; une erreur de validation est générée pour tout conteneur partageant un nom avec un autre. ### Ressources -Étant donné l'ordonnancement et l'exécution des init containers, les règles suivantes s'appliquent pour l'utilisation des ressources : +Étant donné l'ordonnancement et l'exécution des init containers, les règles suivantes s'appliquent pour l'utilisation des ressources : * La plus haute requête ou limite particulière de ressource définie pour tous les init containers est la *limite/requête d'initialisation effective* -* La *limite/requête effective* d'un Pod pour une ressource est la plus haute parmis : +* La *limite/requête effective* d'un Pod pour une ressource est la plus haute parmis : * la somme de toutes les requêtes/limites des conteneurs d'application pour une ressource * la limite/requête d'initialisation effective pour une ressource * Le Scheduling est effectué sur la base des requêtes/limites effectives, ce qui signifie -que les init containers peuvent réserver des ressources pour l'initialisation qui ne sont pas utilisées durant le +que les init containers peuvent réserver des ressources pour l'initialisation qui ne sont pas utilisées durant le cycle de vie du Pod. * La QoS (qualité de service) tierce de la *QoS tierce effective* d'un Pod est la QoS tierce aussi bien pour les init containers que pour les conteneurs d'application. Les quotas et limites sont appliqués sur la base de la requête/limite effective d'un Pod. -Les groupes de contrôle au niveau du Pod ({{< glossary_tooltip text="cgroups" term_id="cgroup" >}}) sont basés sur la requête/limite effective de Pod, la même que +Les groupes de contrôle au niveau du Pod ({{< glossary_tooltip text="cgroups" term_id="cgroup" >}}) sont basés sur la requête/limite effective de Pod, la même que celle du scheduler. ### Raisons du redémarrage d'un Pod -Un Pod peut redémarrer, ce qui cause la ré-exécution des init containers, pour les raisons suivantes : +Un Pod peut redémarrer, ce qui cause la ré-exécution des init containers, pour les raisons suivantes : * Un utilisateur met à jour les spécifications du Pod, ce qui cause le changement de l'image de l'init container. -Tout changement à l'image du init container redémarre le Pod. Les changements au conteneur d'application entraînent seulement le +Tout changement à l'image du init container redémarre le Pod. Les changements au conteneur d'application entraînent seulement le redémarrage du conteneur d'application. * Le conteneur d'infrastructure Pod est redémarré. Ceci est peu commun et serait effectué par une personne ayant un accès root aux nœuds. * Tous les conteneurs dans un Pod sont terminés tandis que `restartPolicy` est configurée à "Always", ce qui force le redémarrage, et l'enregistrement de complétion du init container a été perdu à cause d'une opération de garbage collection (récupération de mémoire). diff --git a/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md b/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md index eaf101118d949..f92ead2ce280c 100644 --- a/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md @@ -21,8 +21,8 @@ contenant un champ `phase`. La phase d'un Pod est un résumé simple et de haut niveau de l'étape à laquelle le Pod se trouve dans son cycle de vie. -La phase n'est pas faite pour être un cumul complet d'observations de l'état -du conteneur ou du Pod, ni pour être une machine à état compréhensible. +La phase n'est pas faite pour être un cumul complet d'observations de l'état +du conteneur ou du Pod, ni pour être une machine à état compréhensible. Le nombre et la signification des valeurs de phase d'un pod sont soigneusement gardés. Hormis ce qui est documenté ici, rien ne doit être supposé sur des Pods @@ -42,7 +42,7 @@ Valeur | Description Un Pod a un PodStatus, qui contient un tableau de [PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) -à travers lesquelles le Pod est ou non passé. Chaque élément +à travers lesquelles le Pod est ou non passé. Chaque élément du tableau de PodCondition a six champs possibles : * Le champ `lastProbeTime` fournit un timestamp auquel la condition du Pod @@ -61,7 +61,7 @@ du tableau de PodCondition a six champs possibles : * Le champ `type` est une chaîne de caractères ayant une des valeurs suivantes : * `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 + * `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) ont démarré correctement ; @@ -75,8 +75,8 @@ du tableau de PodCondition a six champs possibles : Une [Sonde](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) (Probe) est un diagnostic exécuté périodiquement par [kubelet](/docs/admin/kubelet/) -sur un Conteneur. Pour exécuter un diagnostic, kubelet appelle un -[Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implémenté par +sur un Conteneur. Pour exécuter un diagnostic, kubelet appelle un +[Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implémenté par le Conteneur. Il existe trois types de handlers : * [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): @@ -98,7 +98,7 @@ Chaque sonde a un résultat parmi ces trois : * Failure: Le Conteneur a échoué au diagnostic. * Unknown: L'exécution du diagnostic a échoué, et donc aucune action ne peut être prise. -kubelet peut optionnellement exécuter et réagir à deux types de sondes sur des conteneurs +kubelet peut optionnellement exécuter et réagir à deux types de sondes sur des conteneurs en cours d'exécution : * `livenessProbe` : Indique si le Conteneur est en cours d'exécution. Si @@ -115,7 +115,7 @@ en cours d'exécution : ### Quand devez-vous uiliser une liveness ou une readiness probe ? -Si le process de votre Conteneur est capable de crasher de lui-même lorsqu'il +Si le process de votre Conteneur est capable de crasher de lui-même lorsqu'il rencontre un problème ou devient inopérant, vous n'avez pas forcément besoin d'une liveness probe ; kubelet va automatiquement exécuter l'action correcte en accord avec la politique de redémarrage (`restartPolicy`) du Pod. @@ -125,11 +125,11 @@ spécifiez une liveness probe et indiquez une valeur pour `restartPolicy` à Alw ou OnFailure. Si vous voulez commencer à envoyer du trafic à un Pod seulement lorsqu'une sonde -réussit, spécifiez une readiness probe. Dans ce cas, la readiness probe peut être +réussit, spécifiez une readiness probe. Dans ce cas, la readiness probe peut être la même que la liveness probe, mais l'existence de la readiness probe dans la spec veut dire que le Pod va démarrer sans recevoir aucun trafic et va commencer à recevoir du trafic après que la sonde réussisse. -Si votre Conteneur doit charger une grande quantité de données, des fichiers de +Si votre Conteneur doit charger une grande quantité de données, des fichiers de configuration ou exécuter des migrations au démarrage, spécifiez une readiness probe. Si vous désirez que le Conteneur soit capable de se mettre en maintenance tout seul, vous @@ -137,7 +137,7 @@ pouvez spécifier une readiness probe qui vérifie un point de terminaison spéc readiness et différent de la liveness probe. Notez que si vous voulez uniquement être capable de dérouter les requêtes lorsque -le Pod est supprimé, vous n'avez pas forcément besoin d'une readiness probe; lors +le Pod est supprimé, vous n'avez pas forcément besoin d'une readiness probe; lors de sa suppression, le Pod se met automatiquement dans un état non prêt, que la readiness probe existe ou non. Le Pod reste dans le statut non prêt le temps que les Conteneurs du Pod s'arrêtent. @@ -151,16 +151,16 @@ Pour des informations détaillées sur le statut d'un Pod et d'un Conteneur, voi [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) et [ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core). -Notez que l'information rapportée comme statut d'un Pod dépend du +Notez que l'information rapportée comme statut d'un Pod dépend du [ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core) actuel. ## États d'un Conteneur Une fois que le Pod est assigné à un nœud par le scheduler, kubelet commence -à créer les conteneurs en utilisant le runtime de conteneurs. Il existe trois états possibles +à créer les conteneurs en utilisant le runtime de conteneurs. Il existe trois états possibles pour les conteneurs : en attente (Waiting), en cours d'exécution (Running) et terminé (Terminated). Pour vérifier l'état d'un conteneur, vous pouvez utiliser `kubectl describe pod [POD_NAME]`. L'état est affiché pour chaque conteneur du Pod. -* `Waiting` : état du conteneur par défaut. Si le conteneur n'est pas dans un état Running ou Terminated, il est dans l'état Waiting. Un conteneur dans l'état Waiting exécute +* `Waiting` : état du conteneur par défaut. Si le conteneur n'est pas dans un état Running ou Terminated, il est dans l'état Waiting. Un conteneur dans l'état Waiting exécute les opérations nécessaires, comme télécharger les images, appliquer des Secrets, etc. À côté de cet état, un message et une raison sur l'état sont affichés pour vous fournir plus d'informations. @@ -172,23 +172,23 @@ d'informations. ... ``` -* `Running` : Indique que le conteneur s'exécute sans problème. Une fois qu'un centeneur est +* `Running` : Indique que le conteneur s'exécute sans problème. Une fois qu'un centeneur est dans l'état Running, le hook `postStart` est exécuté (s'il existe). Cet état affiche aussi -le moment auquel le conteneur est entré dans l'état Running. - +le moment auquel le conteneur est entré dans l'état Running. + ```yaml ... State: Running Started: Wed, 30 Jan 2019 16:46:38 +0530 ... - ``` + ``` * `Terminated`: Indique que le conteneur a terminé son exécution et s'est arrêté. Un conteneur entre dans cet état lorsqu'il s'est exécuté avec succès ou lorsqu'il a échoué pour une raison quelconque. De plus, une raison et un code de retour sont affichés, -ainsi que les moments de démarrage et d'arrêt du conteneur. Avant qu'un conteneur entre +ainsi que les moments de démarrage et d'arrêt du conteneur. Avant qu'un conteneur entre dans l'état Terminated, le hook `preStop` est exécuté (s'il existe). - + ```yaml ... State: Terminated @@ -197,18 +197,18 @@ dans l'état Terminated, le hook `preStop` est exécuté (s'il existe). Started: Wed, 30 Jan 2019 11:45:26 +0530 Finished: Wed, 30 Jan 2019 11:45:26 +0530 ... - ``` + ``` ## Pod readiness gate {{< feature-state for_k8s_version="v1.14" state="stable" >}} -Afin d'étendre la readiness d'un Pod en autorisant l'injection de données -supplémentaires ou des signaux dans `PodStatus`, Kubernetes 1.11 a introduit +Afin d'étendre la readiness d'un Pod en autorisant l'injection de données +supplémentaires ou des signaux dans `PodStatus`, Kubernetes 1.11 a introduit une fonctionnalité appelée [Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md). -Vous pouvez utiliser le nouveau champ `ReadinessGate` dans `PodSpec` +Vous pouvez utiliser le nouveau champ `ReadinessGate` dans `PodSpec` pour spécifier des conditions additionnelles à évaluer pour la readiness d'un Pod. -Si Kubernetes ne peut pas trouver une telle condition dans le champ `status.conditions` +Si Kubernetes ne peut pas trouver une telle condition dans le champ `status.conditions` d'un Pod, le statut de la condition est "`False`" par défaut. Voici un exemple : ```yaml @@ -244,11 +244,11 @@ Avec l'introduction de nouvelles conditions d'un Pod, un Pod est considéré com * Tous les conteneurs du Pod sont prêts. * Toutes les conditions spécifiées dans `ReadinessGates` sont à "`True`". -Pour faciliter le changement de l'évaluation de la readiness d'un Pod, +Pour faciliter le changement de l'évaluation de la readiness d'un Pod, une nouvelle condition de Pod `ContainersReady` est introduite pour capturer l'ancienne condition `Ready` d'un Pod. -Avec K8s 1.11, en tant que fonctionnalité alpha, "Pod Ready++" doit être explicitement activé en mettant la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `PodReadinessGates` +Avec K8s 1.11, en tant que fonctionnalité alpha, "Pod Ready++" doit être explicitement activé en mettant la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `PodReadinessGates` à true. Avec K8s 1.12, la fonctionnalité est activée par défaut. @@ -280,7 +280,7 @@ Pods qui doivent se terminer, par exemple des calculs par batch. Les Jobs sont a seulement pour des Pods ayant `restartPolicy` égal à OnFailure ou Never. - Utilisez un [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/), - [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) ou + [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) ou [Deployment](/docs/concepts/workloads/controllers/deployment/) pour des Pods qui ne doivent pas s'arrêter, par exemple des serveurs web. ReplicationControllers sont appropriés pour des Pods ayant `restartPolicy` égal à @@ -302,8 +302,8 @@ une politique pour mettre la `phase` de tous les Pods du nœud perdu à Failed. ### Exemple avancé de liveness probe -Les Liveness probes sont exécutées par kubelet, toutes les requêtes sont donc faites -dans l'espace réseau de kubelet. +Les Liveness probes sont exécutées par kubelet, toutes les requêtes sont donc faites +dans l'espace réseau de kubelet. ```yaml apiVersion: v1 diff --git a/content/fr/docs/concepts/workloads/pods/pod-overview.md b/content/fr/docs/concepts/workloads/pods/pod-overview.md index a166343c5ddf0..db0b6dbfed21c 100644 --- a/content/fr/docs/concepts/workloads/pods/pod-overview.md +++ b/content/fr/docs/concepts/workloads/pods/pod-overview.md @@ -3,7 +3,7 @@ title: Aperçu du Pod description: Pod Concept Kubernetes content_template: templates/concept weight: 10 -card: +card: name: concepts weight: 60 --- @@ -76,7 +76,7 @@ En général, les Controllers utilisent des Templates de Pod que vous lui fourni ## Templates de Pod -Les Templates de Pod sont des spécifications de pod qui sont inclus dans d'autres objets, comme les +Les Templates de Pod sont des spécifications de pod qui sont inclus dans d'autres objets, comme les [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), et [DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Les Controllers utilisent les Templates de Pod pour créer réellement les pods. L'exemple ci-dessous est un manifeste simple pour un Pod d'un conteneur affichant un message. diff --git a/content/fr/docs/concepts/workloads/pods/pod.md b/content/fr/docs/concepts/workloads/pods/pod.md index b7708925777cb..b4a6f66bc7a91 100644 --- a/content/fr/docs/concepts/workloads/pods/pod.md +++ b/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 diff --git a/content/fr/docs/contribute/start.md b/content/fr/docs/contribute/start.md index 859d490890719..59cb54cfc24dc 100644 --- a/content/fr/docs/contribute/start.md +++ b/content/fr/docs/contribute/start.md @@ -54,7 +54,7 @@ Voir le sujet [contribution avancée](/docs/contribute/advanced/) pour plus d'in Nous utilisons des modèles de page pour contrôler la présentation de nos pages de documentation. Assurez-vous de comprendre le fonctionnement de ces modèles en consultant [Utilisation de modèles de page](/docs/contribute/style/page-templates/). -### Shortcodes Hugo +### Shortcodes Hugo La documentation de Kubernetes est convertie de Markdown à HTML avec Hugo. Nous utilisons les shortcodes standard Hugo, ainsi que quelques-uns qui sont personnalisés dans la documentation Kubernetes. diff --git a/content/fr/docs/reference/glossary/contributor.md b/content/fr/docs/reference/glossary/contributor.md index d616bccfc50fe..90fe128c80b87 100755 --- a/content/fr/docs/reference/glossary/contributor.md +++ b/content/fr/docs/reference/glossary/contributor.md @@ -14,4 +14,4 @@ Quelqu'un qui code, documente ou donne de son temps autrement, pour aider le pro -Les contributions comprennent les pull requests (PRs), le signalement des problèmes, les retours d'informations, les {{< glossary_tooltip text="groupes d'intérêts spéciaux (SIG, de l'anglais Special Interest Group)" term_id="sig" >}} la participation ou l'organisation des évènements de la communauté. +Les contributions comprennent les pull requests (PRs), le signalement des problèmes, les retours d'informations, les {{< glossary_tooltip text="groupes d'intérêts spéciaux (SIG, de l'anglais Special Interest Group)" term_id="sig" >}} la participation ou l'organisation des évènements de la communauté. diff --git a/content/fr/docs/reference/glossary/etcd.md b/content/fr/docs/reference/glossary/etcd.md index 4a86d40bd9243..b36a294e0f877 100755 --- a/content/fr/docs/reference/glossary/etcd.md +++ b/content/fr/docs/reference/glossary/etcd.md @@ -6,16 +6,16 @@ full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/ short_description: > Base de données clé-valeur consistante et hautement disponible utilisée comme mémoire de sauvegarde pour toutes les données du cluster. -aka: +aka: tags: - architecture - storage --- Base de données clé-valeur consistante et hautement disponible utilisée comme mémoire de sauvegarde pour toutes les données du cluster. - + -Si votre cluster Kubernetes utilise etcd comme mémoire de sauvegarde, assurez-vous d'avoir un plan de +Si votre cluster Kubernetes utilise etcd comme mémoire de sauvegarde, assurez-vous d'avoir un plan de [back up](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) pour ces données. Vous pouvez trouver plus d'informations à propos d'etcd dans la [documentation](https://etcd.io/docs/) officielle. diff --git a/content/fr/docs/reference/glossary/init-container.md b/content/fr/docs/reference/glossary/init-container.md index 070d0dba575c9..b4b87d14a7692 100755 --- a/content/fr/docs/reference/glossary/init-container.md +++ b/content/fr/docs/reference/glossary/init-container.md @@ -10,7 +10,7 @@ aka: tags: - fundamental --- - Un ou plusieurs conteneurs d'initialisation qui doivent être exécutés jusqu'à la fin, avant l'exécution de tout conteneur d'application. + Un ou plusieurs conteneurs d'initialisation qui doivent être exécutés jusqu'à la fin, avant l'exécution de tout conteneur d'application. diff --git a/content/fr/docs/reference/glossary/kube-apiserver.md b/content/fr/docs/reference/glossary/kube-apiserver.md index 491b1b65cef08..c2799a903e292 100755 --- a/content/fr/docs/reference/glossary/kube-apiserver.md +++ b/content/fr/docs/reference/glossary/kube-apiserver.md @@ -6,14 +6,14 @@ full_link: /docs/reference/generated/kube-apiserver/ short_description: > Composant sur le master qui expose l'API Kubernetes. Il s'agit du front-end pour le plan de contrôle Kubernetes. -aka: +aka: tags: - architecture - fundamental --- Composant sur le master qui expose l'API Kubernetes. Il s'agit du front-end pour le plan de contrôle Kubernetes. - + Il est conçu pour une mise à l'échelle horizontale, ce qui veut dire qu'il met à l'échelle en déployant des instances supplémentaires. Voir [Construire des Clusters en Haute Disponibilité](/docs/admin/high-availability/). diff --git a/content/fr/docs/reference/glossary/kube-controller-manager.md b/content/fr/docs/reference/glossary/kube-controller-manager.md index 5342b8b116c74..6481dd7d4e3ba 100755 --- a/content/fr/docs/reference/glossary/kube-controller-manager.md +++ b/content/fr/docs/reference/glossary/kube-controller-manager.md @@ -6,14 +6,14 @@ full_link: /docs/reference/generated/kube-controller-manager/ short_description: > Composant du master qui exécute les contrôleurs. -aka: +aka: tags: - architecture - fundamental --- Composant du master qui exécute les {{< glossary_tooltip text="contrôleurs" term_id="controller" >}}. - + -Logiquement, chaque {{< glossary_tooltip text="contrôleur" term_id="controller" >}} est un processus à part mais, +Logiquement, chaque {{< glossary_tooltip text="contrôleur" term_id="controller" >}} est un processus à part mais, pour réduire la compléxité, les contrôleurs sont tous compilés dans un seul binaire et s'exécutent dans un seul processus. diff --git a/content/fr/docs/reference/glossary/kube-proxy.md b/content/fr/docs/reference/glossary/kube-proxy.md index db9097cd1bafb..2ffe731cea583 100755 --- a/content/fr/docs/reference/glossary/kube-proxy.md +++ b/content/fr/docs/reference/glossary/kube-proxy.md @@ -11,13 +11,13 @@ tags: - fundamental - networking --- - [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) est un -proxy réseau qui s'exécute sur chaque nœud du cluster et implémente une partie du + [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) est un +proxy réseau qui s'exécute sur chaque nœud du cluster et implémente une partie du concept Kubernetes de {{< glossary_tooltip term_id="service">}}. -kube-proxy maintient les règles réseau sur les nœuds. Ces règles réseau permettent +kube-proxy maintient les règles réseau sur les nœuds. Ces règles réseau permettent une communication réseau vers les Pods depuis des sessions réseau à l'intérieur ou à l'extérieur du cluster. diff --git a/content/fr/docs/reference/glossary/kube-scheduler.md b/content/fr/docs/reference/glossary/kube-scheduler.md index 8c727117959b9..61b31396feb22 100755 --- a/content/fr/docs/reference/glossary/kube-scheduler.md +++ b/content/fr/docs/reference/glossary/kube-scheduler.md @@ -6,13 +6,13 @@ full_link: /docs/reference/generated/kube-scheduler/ short_description: > Composant sur le master qui surveille les pods nouvellement créés qui ne sont pas assignés à un nœud et sélectionne un nœud sur lequel ils vont s'exécuter. -aka: +aka: tags: - architecture --- Composant sur le master qui surveille les pods nouvellement créés qui ne sont pas assignés à un nœud et sélectionne un nœud sur lequel ils vont s'exécuter. - + Les facteurs pris en compte pour les décisions de planification (scheduling) comprennent les exigences individuelles et collectives en ressources, les contraintes matérielles/logicielles/politiques, les spécifications d'affinité et d'anti-affinité, la localité des données, les interférences entre charges de travail et les dates limites. diff --git a/content/fr/docs/reference/kubectl/cheatsheet.md b/content/fr/docs/reference/kubectl/cheatsheet.md index 816ad1daaf6b8..f9ced10b4bc4d 100644 --- a/content/fr/docs/reference/kubectl/cheatsheet.md +++ b/content/fr/docs/reference/kubectl/cheatsheet.md @@ -29,7 +29,7 @@ source <(kubectl completion bash) # active l'auto-complétion pour bash dans le echo "source <(kubectl completion bash)" >> ~/.bashrc # ajoute l'auto-complétion de manière permanente à votre shell bash ``` -Vous pouvez de plus déclarer un alias pour `kubectl` qui fonctionne aussi avec l'auto-complétion : +Vous pouvez de plus déclarer un alias pour `kubectl` qui fonctionne aussi avec l'auto-complétion : ```bash alias k=kubectl @@ -242,7 +242,7 @@ kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/ # Désactive la livenessProbe d'un déploiement en utilisant un patch json avec tableaux indexés kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]' -# Ajoute un nouvel élément à un tableau indexé +# Ajoute un nouvel élément à un tableau indexé kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]' ``` diff --git a/content/fr/docs/reference/kubectl/overview.md b/content/fr/docs/reference/kubectl/overview.md index 257763b15851e..634bd83a4ece9 100644 --- a/content/fr/docs/reference/kubectl/overview.md +++ b/content/fr/docs/reference/kubectl/overview.md @@ -226,7 +226,7 @@ submit-queue 610995 `kubectl` est capable de recevoir des informations de colonnes spécifiques d'objets depuis le serveur. Cela veut dire que pour toute ressource donnée, le serveur va retourner les colonnes et lignes pour cette ressource, que le client pourra afficher. -Cela permet un affichage de sortie lisible par l'utilisateur cohérent entre les clients utilisés sur le même cluster, le serveur encapsulant les détails d'affichage. +Cela permet un affichage de sortie lisible par l'utilisateur cohérent entre les clients utilisés sur le même cluster, le serveur encapsulant les détails d'affichage. Cette fonctionnalité est activée par défaut dans `kubectl` version 1.11 et suivantes. Pour la désactiver, ajoutez l'option `--server-print=false` à la commande `kubectl get`. @@ -266,7 +266,7 @@ $ kubectl get pods --sort-by=.metadata.name ## Exemples : Opérations courantes -Utilisez les exemples suivants pour vous familiariser avec les opérations de `kubectl` fréquemment utilisées : +Utilisez les exemples suivants pour vous familiariser avec les opérations de `kubectl` fréquemment utilisées : `kubectl apply` - Créer une ressource depuis un fichier ou stdin. @@ -370,7 +370,7 @@ $ kubectl logs -f Utilisez les exemples suivants pour vous familiariser avec l'écriture et l'utilisation de plugins `kubectl` : ```shell -# créez un plugin simple dans n'importe quel langage et nommez +# créez un plugin simple dans n'importe quel langage et nommez # l'exécutable de telle sorte qu'il commence par "kubectl-" $ cat ./kubectl-hello #!/bin/bash @@ -390,7 +390,7 @@ $ sudo mv ./kubectl-hello /usr/local/bin $ kubectl hello hello world -# vous pouvez "désinstaller" un plugin, +# vous pouvez "désinstaller" un plugin, # simplement en le supprimant de votre PATH $ sudo rm /usr/local/bin/kubectl-hello ``` @@ -426,7 +426,7 @@ $ cat ./kubectl-whoami #!/bin/bash # ce plugin utilise la commande `kubectl config` pour afficher -# l'information sur l'utilisateur courant, en se basant sur +# l'information sur l'utilisateur courant, en se basant sur # le contexte couramment sélectionné kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ .context.user }}{{ end }}{{ end }}' ``` diff --git a/content/fr/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md b/content/fr/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md index 338b54cdaa7be..1e8d0971f90dd 100644 --- a/content/fr/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md +++ b/content/fr/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md @@ -5,7 +5,7 @@ Utilisez cette commande afin de configurer le control plane Kubernetes Utilisez cette commande afin de configurer le control plane Kubernetes -La commande "init" exécute les phases suivantes : +La commande "init" exécute les phases suivantes : ``` preflight Exécute les vérifications en amont kubelet-start Sauvegarde les réglages kubelet et (re)démarre kubelet diff --git a/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md index 929f929ae05dc..1b8fd99ed21cb 100644 --- a/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md +++ b/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -15,42 +15,42 @@ Cette commande initialise un noeud Kubernetes control-plane. `kubeadm init` assemble un noeud Kubernetes control-plane en effectuant les étapes suivantes : 1. Exécute une série de contrôles pour valider l'état du système avant d'y apporter des changements. - Certaines validations peuvent émettre seulement des avertissements (warnings), - d'autres peuvent générer des erreurs qui forceront l'interruption de kubeadm + Certaines validations peuvent émettre seulement des avertissements (warnings), + d'autres peuvent générer des erreurs qui forceront l'interruption de kubeadm jusqu'à ce que le problème soit résolu ou jusqu'à ce que l'utilisateur spécifie `--ignore-preflight-errors=`. 1. Génère une autorité de certification (CA) auto signée (ou utilise une existante si spécifiée) pour - installer les identités de chaque composant du cluster. Si l'utilisateur a fourni son propre certificat + installer les identités de chaque composant du cluster. Si l'utilisateur a fourni son propre certificat et/ou clef de CA en le (la) copiant dans le répertoire des certificats, configuré avec `--cert-dir` (`/etc/kubernetes/pki` par défaut) cette étape est sautée comme expliqué dans le document [utiliser ses propres certificats](#custom-certificates). Les certificats de l'API Server auront des entrées SAN additionnelles pour chaque argument `--apiserver-cert-extra-sans`. 1. Ecrit les fichiers kubeconfig dans `/etc/kubernetes/` pour - kubelet, le controller-manager et l'ordonnanceur (scheduler) - qui seront utlisés pour les connexions à l'API server, chacun avec sa propre identité, + kubelet, le controller-manager et l'ordonnanceur (scheduler) + qui seront utlisés pour les connexions à l'API server, chacun avec sa propre identité, ainsi qu'un fichier kubeconfig supplémentaire pour l'administration, nommé `admin.conf`. 1. Génère des manifestes statiques de Pod pour l'API server, - le controller manager et l'ordonnanceur. Au cas où aucun etcd externe n'est fourni, + le controller manager et l'ordonnanceur. Au cas où aucun etcd externe n'est fourni, un manifeste statique de Pod pour etcd est généré. - Les manifestes statiques de Pod sont écrits dans `/etc/kubernetes/manifestes`; + Les manifestes statiques de Pod sont écrits dans `/etc/kubernetes/manifestes`; kubelet surveille ce répertoire afin que les Pods soient créés au démarrage. Dès lors que les pods de control-plane sont démarrés, la séquence de `kubeadm init` peut alors continuer. 1. Applique les étiquettes (labels) et marques (taints) au noeud control-plane afin qu'aucune charge de travail additionnelle ne s'y exécute. -1. Génère le jeton que les noeuds additionnels peuvent utiliser pour s'enregistrer avec un control-plane. Il est possible que l'utilisateur fournisse un jeton en utilisant `--token`, +1. Génère le jeton que les noeuds additionnels peuvent utiliser pour s'enregistrer avec un control-plane. Il est possible que l'utilisateur fournisse un jeton en utilisant `--token`, comme décrit dans la documentation [à propos du jeton kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm-token/). -1. Produit tous les fichiers de configuration requis pour autoriser les noeuds à rejoindre le cluster avec les +1. Produit tous les fichiers de configuration requis pour autoriser les noeuds à rejoindre le cluster avec les [jetons d'assemblage](/docs/reference/access-authn-authz/bootstrap-tokens/) et le mécanisme [d'assemblage TLS](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) : - - Ecrit une ConfigMap pour produire toute la configuration nécessaire + - Ecrit une ConfigMap pour produire toute la configuration nécessaire pour rejoindre le cluster et installer les règles d'accès RBAC sous jacentes. - Permet aux jetons d'assemblage d'accéder à l'API CSR (Certificate Signing Request, requête de signature de certificat). @@ -61,7 +61,7 @@ Cette commande initialise un noeud Kubernetes control-plane. 1. Installe un serveur DNS (CoreDNS) et les modules de l'extension kube-proxy en utilisant l'API Server. Dans la version 1.11 (et au delà) de Kubernetes, CoreDNS est le serveur DNS par défaut. - Pour installer kube-dns au lieu de CoreDNS, l'extension DNS doit être configurée dans la `ClusterConfiguration` de kubeadm. + Pour installer kube-dns au lieu de CoreDNS, l'extension DNS doit être configurée dans la `ClusterConfiguration` de kubeadm. Pour plus d'information, se référer à la section ci-dessous intitulée : `Utiliser kubeadm init avec un fichier de configuration`. Vous remarquerez que bien que le serveur DNS soit déployé, il ne sera pas programmé pour exécution avant que le CNI soit installé. @@ -113,7 +113,7 @@ Il est **recommandé** que vous migriez votre configuration `v1alpha3` vers `v1b la commande [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/), car le support de `v1alpha3` sera supprimé dans Kubernetes 1.15. -Pour plus de détails à propos de chaque option de la configuration `v1beta1` vous pouvez consulter la +Pour plus de détails à propos de chaque option de la configuration `v1beta1` vous pouvez consulter la [référence de l'API](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1). ### Ajouter des paramètres kube-proxy {#kube-proxy} @@ -156,9 +156,9 @@ et `/etc/kubernetes/pki/ca.key`, et kubeadm utilisera ce CA pour signer le reste #### Mode CA externe {#external-ca-mode} -Il est aussi possible de fournir seulement le fichier `ca.crt` sans le fichier +Il est aussi possible de fournir seulement le fichier `ca.crt` sans le fichier `ca.key` (seulement dans le cas d'un fichier CA racine, pas pour d'autres paires de certificats). -Si tous les certificats et fichiers kubeconfig sont en place, kubeadm activera le mode "CA externe". +Si tous les certificats et fichiers kubeconfig sont en place, kubeadm activera le mode "CA externe". Kubeadm continuera sans clef CA locale. Ou alors, vous pouvez utiliser l'outil controller-manager avec `--controllers=csrsigner` en fournissant les emplacements du certificat CA et la clef. @@ -169,7 +169,7 @@ Le paquet kubeadm vient avec de la configuration concernant comment kubelet doit Vous remarquerez que la commande CLI `kubeadm` ne modifiera jamais ce fichier. Ce fichier ad-hoc appartient au paquet deb/rpm de kubeadm. -Pour en savoir plus sur comment kubeadm gère kubelet, vous pouvez consulter +Pour en savoir plus sur comment kubeadm gère kubelet, vous pouvez consulter [cette page](/docs/setup/independent/kubelet-integration). ### Utilisation de kubeadm avec des runtimes CRI @@ -215,20 +215,20 @@ Faîtes attention car forcer un nom d'hôte peut [interférer avec les fournisse ### Héberger soi même le control plane Kubernetes {#self-hosting} A partir de la version 1.8, vous pouvez expérimentalement créer un control plane Kubernetes _auto-hébergé (self-hosted)_ . -Cela signifie que des composants clefs comme le serveur d'API, le controller manager et l'ordonnanceur sont démarrés en tant que -[pods DaemonSet](/docs/concepts/workloads/controllers/daemonset/), configurés via l'API Kubernetes +Cela signifie que des composants clefs comme le serveur d'API, le controller manager et l'ordonnanceur sont démarrés en tant que +[pods DaemonSet](/docs/concepts/workloads/controllers/daemonset/), configurés via l'API Kubernetes plutôt qu'en tant que [pods static](/docs/tasks/administer-cluster/static-pod/) configurés avec des fichiers statiques dans kubelet. Pour créer un cluster auto-hébergé, se référer à la commande `kubeadm alpha selfhosting`. #### Avertissements -1. L'auto-hébergement dans la version 1.8 et au delà comporte de sérieuses limitations. +1. L'auto-hébergement dans la version 1.8 et au delà comporte de sérieuses limitations. En particulier, un cluster auto-hébergé _ne peut pas survivre au redémarrage du noeud control plane_ sans intervention manuelle. 1. Un cluster auto-hébergé ne peut pas être mis à jour via la commande `kubeadm upgrade`. -1. Par défaut, les Pods d'un control plane auto-hébergé dépendent des identifiants chargés depuis des volumes de type +1. Par défaut, les Pods d'un control plane auto-hébergé dépendent des identifiants chargés depuis des volumes de type [`hostPath`](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath) A part pour la création initiale, ces identifiants ne sont pas gérés par kubeadm. @@ -248,7 +248,7 @@ En bref, `kubeadm alpha selfhosting` fonctionne de la manière suivante : 1. Crée des DaemonSets dans le namespace `kube-system` et attend que les pods ainsi créés soient démarrés. - 1. Une fois que les Pods auto-hébergés sont opérationnels, les Pods statiques qui leurs sont associés sont supprimés et kubeadm installe ensuite le prochain composant. + 1. Une fois que les Pods auto-hébergés sont opérationnels, les Pods statiques qui leurs sont associés sont supprimés et kubeadm installe ensuite le prochain composant. Cela déclenche l'arrêt par kubelet de ces Pods statiques. 1. Quand le control plane statique d'origine s'arrête, le nouveau control plane auto-hébergé est capable d'écouter sur les mêmes ports et devenir actif. @@ -269,7 +269,7 @@ ne nécessitent pas un suffix `-${ARCH}`. ### Automatiser kubeadm -Plutôt que copier sur chaque noeud le jeton que vous avez obtenu avec `kubeadm init`, comme décrit dans +Plutôt que copier sur chaque noeud le jeton que vous avez obtenu avec `kubeadm init`, comme décrit dans le [tutoriel basique de kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), vous pouvez paralléliser la distribution du jeton afin d'automatiser cette tâche. Pour ce faire, vous devez connaître l'adresse IP que le noeud control plane obtiendra après son démarrage. @@ -287,10 +287,10 @@ Pour ce faire, vous devez connaître l'adresse IP que le noeud control plane obt Lors de leurs démarrages, ils devraient pouvoir se trouver les uns les autres et former le cluster. L'option `--token` peut être utilisée aussi bien pour `kubeadm init` que pour `kubeadm join`. -Une fois que le cluster est correctement démarré, vous pouvez obtenir les identifiants admin depuis le noeud control plane depuis le fichier `/etc/kubernetes/admin.conf` +Une fois que le cluster est correctement démarré, vous pouvez obtenir les identifiants admin depuis le noeud control plane depuis le fichier `/etc/kubernetes/admin.conf` et les utiliser pour communiquer avec le cluster. -Vous remarquerez que ce type d'installation présente un niveau de sécurité inférieur puisqu'il ne permet pas la validation du hash du certificat racine avec `--discovery-token-ca-cert-hash` +Vous remarquerez que ce type d'installation présente un niveau de sécurité inférieur puisqu'il ne permet pas la validation du hash du certificat racine avec `--discovery-token-ca-cert-hash` (puisqu'il n'est pas généré quand les noeuds sont provisionnés). Pour plus d'information, se référer à [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/). {{% /capture %}} diff --git a/content/fr/docs/reference/setup-tools/kubeadm/kubeadm.md b/content/fr/docs/reference/setup-tools/kubeadm/kubeadm.md index d843782759c89..fa7b1953d969a 100644 --- a/content/fr/docs/reference/setup-tools/kubeadm/kubeadm.md +++ b/content/fr/docs/reference/setup-tools/kubeadm/kubeadm.md @@ -18,6 +18,6 @@ On préférera des outils plus spécifiques et de plus haut niveau, construits a * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) pour mettre à jour un cluster Kubernetes vers une version plus récente * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) si vous avez initialisé votre cluster en utilisant kubeadm v1.7.x ou antérieur, pour configurer votre cluster avec `kubeadm upgrade` * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) pour gérer vos jetons avec `kubeadm join` -* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) pour annuler des changements faits avec `kubeadm init` ou `kubeadm join` à cet hôte +* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) pour annuler des changements faits avec `kubeadm init` ou `kubeadm join` à cet hôte * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) pour afficher la version de kubeadm * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) pour utiliser un lot de fonctionnalités rendus disponibles afin d'obtenir le retour de la communauté diff --git a/content/fr/docs/setup/_index.md b/content/fr/docs/setup/_index.md index 42f35c6d77cfc..7207a5817bd0f 100644 --- a/content/fr/docs/setup/_index.md +++ b/content/fr/docs/setup/_index.md @@ -16,7 +16,7 @@ content_template: templates/concept Utilisez cette page pour trouver le type de solution qui correspond le mieux à vos besoins. -Le choix de distribution Kubernetes dépend des ressources dont vous disposez et de la flexibilité dont vous avez besoin. +Le choix de distribution Kubernetes dépend des ressources dont vous disposez et de la flexibilité dont vous avez besoin. Vous pouvez exécuter Kubernetes presque partout, de votre ordinateur portable aux machines virtuelles d'un fournisseur de cloud jusqu'à un rack de serveurs en bare metal. Vous pouvez également mettre en place un cluster entièrement géré en exécutant une seule commande ou bien créer votre propre cluster personnalisé sur vos serveurs bare-metal. @@ -27,7 +27,7 @@ Vous pouvez également mettre en place un cluster entièrement géré en exécut ## Solutions locales La solution locale, installée sur votre machine, est un moyen facile de démarrer avec Kubernetes. Vous -pouvez créer et tester des clusters Kubernetes sans vous soucier de la consommation +pouvez créer et tester des clusters Kubernetes sans vous soucier de la consommation des ressources et des quotas d'un cloud. Vous devriez choisir une solution locale si vous souhaitez : @@ -40,21 +40,21 @@ Choisissez une [solution locale] (/docs/setup/pick-right-solution/#local-machine ## Solutions hébergées Les solutions hébergées sont un moyen pratique de créer et de maintenir des clusters Kubernetes. Elles -permettent de gérer et d'exploiter vos clusters pour que vous n'ayez pas à le faire. +permettent de gérer et d'exploiter vos clusters pour que vous n'ayez pas à le faire. Vous devriez choisir une solution hébergée si vous : * Voulez une solution entièrement gérée -* Voulez vous concentrer sur le développement de vos applications ou services +* Voulez vous concentrer sur le développement de vos applications ou services * N'avez pas d'équipe de Site Reliability Engineering (SRE) dédiée, mais que vous souhaitez une haute disponibilité. -* Vous n'avez pas les ressources pour héberger et surveiller vos clusters +* Vous n'avez pas les ressources pour héberger et surveiller vos clusters Choisissez une [solution hébergée] (/fr/docs/setup/pick-right-solution/#hosted-solutions). ## Solutions cloud clés en main -Ces solutions vous permettent de créer des clusters Kubernetes avec seulement quelques commandes et -sont activement développées et bénéficient du soutien actif de la communauté. Elles peuvent également être hébergés sur +Ces solutions vous permettent de créer des clusters Kubernetes avec seulement quelques commandes et +sont activement développées et bénéficient du soutien actif de la communauté. Elles peuvent également être hébergés sur un ensemble de fournisseurs de Cloud de type IaaS, mais elles offrent plus de liberté et de flexibilité en contrepartie d'un effort à fournir plus important. @@ -80,8 +80,8 @@ Choisissez une [solution clé en main sur site] (/docs/setup/pick-right-solution ## Solutions personnalisées -Les solutions personnalisées vous offrent le maximum de liberté sur vos clusters, mais elles nécessitent plus -d'expertise. Ces solutions vont du bare-metal aux fournisseurs de cloud sur +Les solutions personnalisées vous offrent le maximum de liberté sur vos clusters, mais elles nécessitent plus +d'expertise. Ces solutions vont du bare-metal aux fournisseurs de cloud sur différents systèmes d'exploitation. Choisissez une [solution personnalisée] (/docs/setup/pick-right-solution/#custom-solutions). diff --git a/content/fr/docs/setup/custom-cloud/coreos.md b/content/fr/docs/setup/custom-cloud/coreos.md index 039a60e8e3362..4b18c56c8a614 100644 --- a/content/fr/docs/setup/custom-cloud/coreos.md +++ b/content/fr/docs/setup/custom-cloud/coreos.md @@ -1,6 +1,6 @@ --- title: CoreOS sur AWS ou GCE -description: Installation Kubernetes CoreOS sur AWS GCE +description: Installation Kubernetes CoreOS sur AWS GCE content_template: templates/concept --- diff --git a/content/fr/docs/setup/independent/_index.md b/content/fr/docs/setup/independent/_index.md index 87e7b64f3a695..0025e6d6ec19b 100755 --- a/content/fr/docs/setup/independent/_index.md +++ b/content/fr/docs/setup/independent/_index.md @@ -1,5 +1,5 @@ --- title: Déployer des clusters avec kubeadm -description: Déploiement cluster Kubernetes kubeadm +description: Déploiement cluster Kubernetes kubeadm weight: 30 --- diff --git a/content/fr/docs/setup/independent/control-plane-flags.md b/content/fr/docs/setup/independent/control-plane-flags.md index 008f41bda4ff3..faea10586746c 100644 --- a/content/fr/docs/setup/independent/control-plane-flags.md +++ b/content/fr/docs/setup/independent/control-plane-flags.md @@ -9,16 +9,16 @@ weight: 40 {{< feature-state for_k8s_version="1.12" state="stable" >}} -L'objet `ClusterConfiguration` de kubeadm expose le champ `extraArgs` qui peut -remplacer les indicateurs par défaut transmis au control plane à des composants -tels que l'APIServer, le ControllerManager et le Scheduler. Les composants sont +L'objet `ClusterConfiguration` de kubeadm expose le champ `extraArgs` qui peut +remplacer les indicateurs par défaut transmis au control plane à des composants +tels que l'APIServer, le ControllerManager et le Scheduler. Les composants sont définis à l'aide des champs suivants: - `apiServer` - `controllerManager` - `scheduler` -Le champ `extraArgs` se compose de paires` clé: valeur`. Pour remplacer un indicateur +Le champ `extraArgs` se compose de paires` clé: valeur`. Pour remplacer un indicateur pour un composant du control plane: 1. Ajoutez les champs appropriés à votre configuration. diff --git a/content/fr/docs/setup/independent/ha-topology.md b/content/fr/docs/setup/independent/ha-topology.md index a8e4ad56d914e..1253183c50117 100644 --- a/content/fr/docs/setup/independent/ha-topology.md +++ b/content/fr/docs/setup/independent/ha-topology.md @@ -7,7 +7,7 @@ weight: 50 {{% capture overview %}} -Cette page explique les deux options de configuration de topologie de vos clusters Kubernetes +Cette page explique les deux options de configuration de topologie de vos clusters Kubernetes pour la haute disponibilité. Vous pouvez configurer un cluster en haute disponibilité: @@ -15,7 +15,7 @@ Vous pouvez configurer un cluster en haute disponibilité: - Avec des nœuds du control plane empilés, les nœuds etcd étant co-localisés avec des nœuds du control plane - Avec des nœuds etcd externes, où etcd s'exécute sur des nœuds distincts du control plane -Vous devez examiner attentivement les avantages et les inconvénients de chaque topologie avant +Vous devez examiner attentivement les avantages et les inconvénients de chaque topologie avant de configurer un cluster en haute disponibilité. {{% /capture %}} @@ -23,11 +23,11 @@ de configurer un cluster en haute disponibilité. ## Topologie etcd empilée -Un cluster HA empilé est une [topologie réseau](https://fr.wikipedia.org/wiki/Topologie_de_r%C3%A9seau) -où le cluster de stockage de données distribuées est fourni par etcd et est superposé au +Un cluster HA empilé est une [topologie réseau](https://fr.wikipedia.org/wiki/Topologie_de_r%C3%A9seau) +où le cluster de stockage de données distribuées est fourni par etcd et est superposé au cluster formé par les noeuds gérés par kubeadm qui exécute les composants du control plane. -Chaque nœud du control plane exécute une instance de `kube-apiserver`,` kube-scheduler` et +Chaque nœud du control plane exécute une instance de `kube-apiserver`,` kube-scheduler` et `kube-controller-manager`. Le `kube-apiserver` est exposé aux nœuds à l'aide d'un loadbalancer. @@ -35,15 +35,15 @@ Chaque nœud du control plane crée un membre etcd local et ce membre etcd commu le `kube-apiserver` de ce noeud. Il en va de même pour le `kube-controller-manager` local et les instances de `kube-scheduler`. -Cette topologie couple les control planes et les membres etcd sur les mêmes nœuds. C'est -plus simple à mettre en place qu'un cluster avec des nœuds etcd externes et plus simple à +Cette topologie couple les control planes et les membres etcd sur les mêmes nœuds. C'est +plus simple à mettre en place qu'un cluster avec des nœuds etcd externes et plus simple à gérer pour la réplication. -Cependant, un cluster empilé présente un risque d'échec du couplage. Si un noeud tombe en panne, -un membre etcd et une instance du control plane sont perdus et la redondance est compromise. Vous +Cependant, un cluster empilé présente un risque d'échec du couplage. Si un noeud tombe en panne, +un membre etcd et une instance du control plane sont perdus et la redondance est compromise. Vous pouvez atténuer ce risque en ajoutant plus de nœuds au control plane. -Par conséquent, vous devez exécuter au moins trois nœuds de control plane empilés pour un cluster +Par conséquent, vous devez exécuter au moins trois nœuds de control plane empilés pour un cluster en haute disponibilité. C'est la topologie par défaut dans kubeadm. Un membre etcd local est créé automatiquement @@ -53,18 +53,18 @@ Schéma de la [Topologie etcd empilée](/images/kubeadm/kubeadm-ha-topology-stac ## Topologie etcd externe -Un cluster haute disponibilité avec un etcd externe est une -[topologie réseau](https://fr.wikipedia.org/wiki/Topologie_de_r%C3%A9seau) où le cluster de stockage de données -distribué fourni par etcd est externe au cluster formé par les nœuds qui exécutent les composants +Un cluster haute disponibilité avec un etcd externe est une +[topologie réseau](https://fr.wikipedia.org/wiki/Topologie_de_r%C3%A9seau) où le cluster de stockage de données +distribué fourni par etcd est externe au cluster formé par les nœuds qui exécutent les composants du control plane. -Comme la topologie etcd empilée, chaque nœud du control plane d'une topologie etcd externe exécute -une instance de `kube-apiserver`,` kube-scheduler` et `kube-controller-manager`. Et le `kube-apiserver` -est exposé aux nœuds workers à l’aide d’un load-balancer. Cependant, les membres etcd s'exécutent sur +Comme la topologie etcd empilée, chaque nœud du control plane d'une topologie etcd externe exécute +une instance de `kube-apiserver`,` kube-scheduler` et `kube-controller-manager`. Et le `kube-apiserver` +est exposé aux nœuds workers à l’aide d’un load-balancer. Cependant, les membres etcd s'exécutent sur des hôtes distincts et chaque hôte etcd communique avec le `kube-apiserver` de chaque nœud du control plane. Cette topologie dissocie le control plane et le membre etcd. Il fournit donc une configuration HA où -perdre une instance de control plane ou un membre etcd a moins d'impact et n'affecte pas la redondance du +perdre une instance de control plane ou un membre etcd a moins d'impact et n'affecte pas la redondance du cluster autant que la topologie HA empilée. Cependant, cette topologie requiert le double du nombre d'hôtes de la topologie HA integrée. diff --git a/content/fr/docs/setup/independent/high-availability.md b/content/fr/docs/setup/independent/high-availability.md index c014a69ac1940..d8a95b5c890d4 100644 --- a/content/fr/docs/setup/independent/high-availability.md +++ b/content/fr/docs/setup/independent/high-availability.md @@ -10,19 +10,19 @@ weight: 60 Cette page explique deux approches différentes pour configurer un Kubernetes à haute disponibilité. cluster utilisant kubeadm: -- Avec des nœuds de control plane empilés. Cette approche nécessite moins d'infrastructure. +- Avec des nœuds de control plane empilés. Cette approche nécessite moins d'infrastructure. Les membres etcd et les nœuds du control plane sont co-localisés. -- Avec un cluster etcd externe cette approche nécessite plus d'infrastructure. +- Avec un cluster etcd externe cette approche nécessite plus d'infrastructure. Les nœuds du control plane et les membres etcd sont séparés. -Avant de poursuivre, vous devez déterminer avec soin quelle approche répond le mieux -aux besoins de vos applications et de l'environnement. [Cette comparaison](/docs/setup/independent/ha-topology/) +Avant de poursuivre, vous devez déterminer avec soin quelle approche répond le mieux +aux besoins de vos applications et de l'environnement. [Cette comparaison](/docs/setup/independent/ha-topology/) décrit les avantages et les inconvénients de chacune. Vos clusters doivent exécuter Kubernetes version 1.12 ou ultérieure. Vous devriez aussi savoir que la mise en place de clusters HA avec kubeadm est toujours expérimentale et sera simplifiée davantage dans les futures versions. Vous pouvez par exemple rencontrer des problèmes lors de la mise à niveau de vos clusters. -Nous vous encourageons à essayer l’une ou l’autre approche et à nous faire part de vos commentaires dans +Nous vous encourageons à essayer l’une ou l’autre approche et à nous faire part de vos commentaires dans [Suivi des problèmes Kubeadm](https://github.com/kubernetes/kubeadm/issues/new). Notez que la fonctionnalité alpha `HighAvailability` est obsolète dans la version 1.12 et supprimée dans la version 1.13 @@ -30,7 +30,7 @@ Notez que la fonctionnalité alpha `HighAvailability` est obsolète dans la vers Voir aussi [La documentation de mise à niveau HA](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-13). {{< caution >}} -Cette page ne traite pas de l'exécution de votre cluster sur un fournisseur de cloud. Dans un +Cette page ne traite pas de l'exécution de votre cluster sur un fournisseur de cloud. Dans un environnement Cloud, les approches documentées ici ne fonctionne ni avec des objets de type load balancer, ni avec des volumes persistants dynamiques. {{< /caution >}} @@ -69,7 +69,7 @@ Toutes les commandes d'un control plane ou d'un noeud etcd doivent être {{< /note >}} - Certains plugins réseau CNI tels que Calico nécessitent un CIDR tel que `192.168.0.0 / 16` et  -certains comme Weave n'en ont pas besoin. Voir la +certains comme Weave n'en ont pas besoin. Voir la [Documentation du CNI réseau](/docs/setup/independent/create-cluster-kubeadm/#pod-network). Pour ajouter un CIDR de pod, définissez le champ `podSubnet: 192.168.0.0 / 16` sous   l'objet `networking` de` ClusterConfiguration`. @@ -77,20 +77,20 @@ certains comme Weave n'en ont pas besoin. Voir la ### Créez un load balancer pour kube-apiserver {{< note >}} -Il existe de nombreuses configurations pour les équilibreurs de charge (load balancer). +Il existe de nombreuses configurations pour les équilibreurs de charge (load balancer). L'exemple suivant n'est qu'un exemple. Vos exigences pour votre cluster peuvent nécessiter une configuration différente. {{< /note >}} 1. Créez un load balancer kube-apiserver avec un nom résolu en DNS. - - Dans un environnement cloud, placez vos nœuds du control plane derrière un load balancer TCP. - Ce load balancer distribue le trafic à tous les nœuds du control plane sains dans sa liste. - La vérification de la bonne santé d'un apiserver est une vérification TCP sur le port que + - Dans un environnement cloud, placez vos nœuds du control plane derrière un load balancer TCP. + Ce load balancer distribue le trafic à tous les nœuds du control plane sains dans sa liste. + La vérification de la bonne santé d'un apiserver est une vérification TCP sur le port que kube-apiserver écoute (valeur par défaut: `6443`). - Il n'est pas recommandé d'utiliser une adresse IP directement dans un environnement cloud. - - Le load balancer doit pouvoir communiquer avec tous les nœuds du control plane sur le + - Le load balancer doit pouvoir communiquer avec tous les nœuds du control plane sur le port apiserver. Il doit également autoriser le trafic entrant sur son réseau de port d'écoute. - [HAProxy](http://www.haproxy.org/) peut être utilisé comme load balancer. @@ -105,7 +105,7 @@ L'exemple suivant n'est qu'un exemple. Vos exigences pour votre cluster peuvent ``` - Une erreur `connection refused` est attendue car l'apiserver n'est pas encore en fonctionnement. - Cependant, un timeout signifie que le load balancer ne peut pas communiquer avec le nœud du + Cependant, un timeout signifie que le load balancer ne peut pas communiquer avec le nœud du control plane. Si un timeout survient, reconfigurez le load balancer pour communiquer avec le nœud du control plane. 1. Ajouter les nœuds du control plane restants au groupe cible du load balancer. @@ -163,18 +163,18 @@ SSH est requis si vous souhaitez contrôler tous les nœuds à partir d'une seul ```sh sudo kubeadm init --config=kubeadm-config.yaml ``` - + Vous devriez voir quelque chose comme: - + ```sh ... -Vous pouvez à présent joindre n'importe quelle machine au cluster en lancant la commande suivante sur +Vous pouvez à présent joindre n'importe quelle machine au cluster en lancant la commande suivante sur chaque nœeud en tant que root: - + kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f ``` -1. Copiez ce jeton dans un fichier texte. Vous en aurez besoin plus tard pour joindre +1. Copiez ce jeton dans un fichier texte. Vous en aurez besoin plus tard pour joindre d’autres nœuds du control plane au cluster. 1. Activez l'extension CNI Weave: @@ -192,7 +192,7 @@ d’autres nœuds du control plane au cluster. - Il est recommandé de ne joindre les nouveaux nœuds du control plane qu'après l'initialisation du premier nœud. 1. Copiez les fichiers de certificat du premier nœud du control plane dans les autres: - + Dans l'exemple suivant, remplacez `CONTROL_PLANE_IPS` par les adresses IP des autres nœuds du control plane. ```sh USER=ubuntu # customizable @@ -211,7 +211,7 @@ d’autres nœuds du control plane au cluster. ``` {{< caution >}} -N'utilisez que les certificats de la liste ci-dessus. kubeadm se chargera de générer le reste des certificats avec les SANs requis pour les instances du control plane qui se joignent. +N'utilisez que les certificats de la liste ci-dessus. kubeadm se chargera de générer le reste des certificats avec les SANs requis pour les instances du control plane qui se joignent. Si vous copiez tous les certificats par erreur, la création de noeuds supplémentaires pourrait échouer en raison d'un manque de SANs requis. {{< /caution >}} @@ -236,7 +236,7 @@ Si vous copiez tous les certificats par erreur, la création de noeuds suppléme Ce processus écrit tous les fichiers demandés dans le dossier `/etc/kubernetes`. -1. Lancez `kubeadm join` sur ce nœud en utilisant la commande de join qui vous avait été précédemment +1. Lancez `kubeadm join` sur ce nœud en utilisant la commande de join qui vous avait été précédemment donnée par` kubeadm init` sur le premier noeud. Ça devrait ressembler a quelque chose comme ça: @@ -244,7 +244,7 @@ donnée par` kubeadm init` sur le premier noeud. Ça devrait ressembler a quelqu sudo kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f --experimental-control-plane ``` - - Remarquez l'ajout de l'option `--experimental-control-plane`. Ce paramètre automatise l'adhésion au + - Remarquez l'ajout de l'option `--experimental-control-plane`. Ce paramètre automatise l'adhésion au control plane du cluster. 1. Tapez ce qui suit et observez les pods des composants démarrer: @@ -295,9 +295,9 @@ donnée par` kubeadm init` sur le premier noeud. Ça devrait ressembler a quelqu keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key - La différence entre etcd empilé et externe, c’est que nous utilisons le champ `external` - pour `etcd` dans la configuration de kubeadm. Dans le cas de la topologie etcd empilée, + pour `etcd` dans la configuration de kubeadm. Dans le cas de la topologie etcd empilée, c'est géré automatiquement. - + - Remplacez les variables suivantes dans le modèle (template) par les valeurs appropriées pour votre cluster: @@ -335,13 +335,13 @@ Pour résumer: ### Installer un réseau de pod [Suivez ces instructions](/docs/setup/independent/create-cluster-kubeadm/#pod-network) afin - d'installer le réseau de pod. Assurez-vous que cela correspond au pod CIDR que vous avez fourni + d'installer le réseau de pod. Assurez-vous que cela correspond au pod CIDR que vous avez fourni dans le fichier de configuration principal. ### Installer les workers Chaque nœud worker peut maintenant être joint au cluster avec la commande renvoyée à partir du resultat - de n’importe quelle commande `kubeadm init`. L'option `--experimental-control-plane` ne doit pas + de n’importe quelle commande `kubeadm init`. L'option `--experimental-control-plane` ne doit pas être ajouté aux nœuds workers. {{% /capture %}} diff --git a/content/fr/docs/setup/independent/install-kubeadm.md b/content/fr/docs/setup/independent/install-kubeadm.md index 8cb2ee2bcfe0c..6366c6fdce0d3 100644 --- a/content/fr/docs/setup/independent/install-kubeadm.md +++ b/content/fr/docs/setup/independent/install-kubeadm.md @@ -9,7 +9,7 @@ weight: 20 Cette page vous apprend comment installer la boîte à outils `kubeadm`. -Pour plus d'informations sur la création d'un cluster avec kubeadm, une fois que vous avez +Pour plus d'informations sur la création d'un cluster avec kubeadm, une fois que vous avez effectué ce processus d'installation, voir la page: [Utiliser kubeadm pour créer un cluster](/docs/setup/independent/create-cluster-kubeadm/). {{% /capture %}} @@ -40,8 +40,8 @@ effectué ce processus d'installation, voir la page: [Utiliser kubeadm pour cré * Vous pouvez obtenir l'adresse MAC des interfaces réseau en utilisant la commande `ip link` ou` ifconfig -a` * Le product_uuid peut être vérifié en utilisant la commande `sudo cat/sys/class/dmi/id/product_uuid` -Il est très probable que les périphériques matériels aient des adresses uniques, bien que -certaines machines virtuelles puissent avoir des valeurs identiques. Kubernetes utilise +Il est très probable que les périphériques matériels aient des adresses uniques, bien que +certaines machines virtuelles puissent avoir des valeurs identiques. Kubernetes utilise ces valeurs pour identifier de manière unique les nœuds du cluster. Si ces valeurs ne sont pas uniques à chaque nœud, le processus d'installation peut [échouer](https://github.com/kubernetes/kubeadm/issues/31). @@ -49,7 +49,7 @@ peut [échouer](https://github.com/kubernetes/kubeadm/issues/31). ## Vérifiez les cartes réseaux Si vous avez plusieurs cartes réseaux et que vos composants Kubernetes ne sont pas accessibles par la -route par défaut, nous vous recommandons d’ajouter une ou plusieurs routes IP afin que les adresses +route par défaut, nous vous recommandons d’ajouter une ou plusieurs routes IP afin que les adresses de cluster Kubernetes soient acheminées via la carte approprié. ## Vérifiez les ports requis {#check-required-ports} @@ -76,7 +76,7 @@ de cluster Kubernetes soient acheminées via la carte approprié. Tous les numéros de port marqués d'un * sont écrasables. Vous devrez donc vous assurer que les ports personnalisés que vous utilisez sont également ouverts. -Bien que les ports etcd soient inclus dans les nœuds masters, vous pouvez également héberger +Bien que les ports etcd soient inclus dans les nœuds masters, vous pouvez également héberger votre propre cluster etcd en externe ou sur des ports personnalisés. Le plug-in de réseau de pod que vous utilisez (voir ci-dessous) peut également nécessiter certains ports à ouvrir. Étant donné que cela diffère d’un plugin à l’autre, veuillez vous reporter à la @@ -109,16 +109,16 @@ Vous installerez ces paquets sur toutes vos machines: kubeadm **n'installera pas** ni ne gèrera les `kubelet` ou` kubectl` pour vous. Vous devez vous assurer qu'ils correspondent à la version du control plane de Kubernetes que vous souhaitez que kubeadm installe pour vous. Si vous ne le faites pas, vous risquez qu' - une erreur de version se produise, qui pourrait conduire à un comportement inattendu. - Cependant, une version mineure entre les kubelets et le control plane est pris en charge, - mais la version de la kubelet ne doit jamais dépasser la version de l'API server. Par exemple, - les kubelets exécutant la version 1.7.0 devraient être entièrement compatibles avec un API + une erreur de version se produise, qui pourrait conduire à un comportement inattendu. + Cependant, une version mineure entre les kubelets et le control plane est pris en charge, + mais la version de la kubelet ne doit jamais dépasser la version de l'API server. Par exemple, + les kubelets exécutant la version 1.7.0 devraient être entièrement compatibles avec un API server en 1.8.0, mais pas l'inverse. {{< warning >}} Ces instructions excluent tous les packages Kubernetes de toutes les mises à niveau du système d'exploitation. -C’est parce que kubeadm et Kubernetes ont besoin d'une +C’est parce que kubeadm et Kubernetes ont besoin d'une [attention particulière lors de la mise à niveau](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11/). {{}} @@ -164,11 +164,11 @@ systemctl enable --now kubelet **Note:** - - Mettre SELinux en mode permissif en lançant `setenforce 0` et `sed ... `le désactive efficacement. - C'est nécessaire pour permettre aux conteneurs d'accéder au système de fichiers hôte, qui + - Mettre SELinux en mode permissif en lançant `setenforce 0` et `sed ... `le désactive efficacement. + C'est nécessaire pour permettre aux conteneurs d'accéder au système de fichiers hôte, qui est nécessaire par exemple pour les réseaux de pod. Vous devez le faire jusqu'à ce que le support de SELinux soit amélioré dans la kubelet. - - Certains utilisateurs de RHEL / CentOS 7 ont signalé des problèmes de routage incorrect + - Certains utilisateurs de RHEL / CentOS 7 ont signalé des problèmes de routage incorrect du trafic en raison du contournement d'iptables. Vous devez vous assurer que `net.bridge.bridge-nf-call-iptables` est configuré à 1 dans votre config `sysctl` par exemple: @@ -230,7 +230,7 @@ kubeadm, pour lui dire quoi faire. Lorsque vous utilisez Docker, kubeadm détecte automatiquement le pilote ( driver ) de cgroup pour la kubelet et le configure dans le fichier `/var/lib/kubelet/kubeadm-flags.env` lors de son éxecution. -Si vous utilisez un autre CRI, vous devez modifier le fichier `/etc/default/kubelet` avec votre +Si vous utilisez un autre CRI, vous devez modifier le fichier `/etc/default/kubelet` avec votre valeur de `cgroup-driver` comme ceci: ```bash diff --git a/content/fr/docs/setup/independent/kubelet-integration.md b/content/fr/docs/setup/independent/kubelet-integration.md index a780fc87f4c03..786dfa18fb90e 100644 --- a/content/fr/docs/setup/independent/kubelet-integration.md +++ b/content/fr/docs/setup/independent/kubelet-integration.md @@ -9,7 +9,7 @@ weight: 80 {{< feature-state for_k8s_version="1.11" state="stable" >}} -Le cycle de vie de l’outil CLI kubeadm est découplé de celui de la +Le cycle de vie de l’outil CLI kubeadm est découplé de celui de la [kubelet](/docs/reference/command-line-tools-reference/kubelet), qui est un démon qui s'éxécute sur chaque noeud du cluster Kubernetes. L'outil CLI de kubeadm est exécuté par l'utilisateur lorsque Kubernetes est initialisé ou mis à niveau, alors que la kubelet est toujours exécutée en arrière-plan. @@ -19,11 +19,11 @@ Comme la kubelet est un démon, elle doit être maintenue par une sorte d'init s systemd est configuré pour gérer la kubelet. Vous pouvez utiliser un gestionnaire différent à la place, mais vous devez le configurer manuellement. -Certains détails de configuration de la kubelet doivent être identiques pour -toutes les kubelets du cluster, tandis que d’autres aspects de la configuration -doivent être définis par nœud, pour tenir compte des différentes caractéristiques -d’une machine donnée, telles que le système d’exploitation, le stockage et la -mise en réseau. Vous pouvez gérer la configuration manuellement de vos kubelets, +Certains détails de configuration de la kubelet doivent être identiques pour +toutes les kubelets du cluster, tandis que d’autres aspects de la configuration +doivent être définis par nœud, pour tenir compte des différentes caractéristiques +d’une machine donnée, telles que le système d’exploitation, le stockage et la +mise en réseau. Vous pouvez gérer la configuration manuellement de vos kubelets, mais [kubeadm fournit maintenant un type d’API `KubeletConfiguration` pour la gestion centralisée de vos configurations de kubelets](#configure-kubelets-using-kubeadm). {{% /capture %}} @@ -32,7 +32,7 @@ mais [kubeadm fournit maintenant un type d’API `KubeletConfiguration` pour la ## Patterns de configuration des Kubelets -Les sections suivantes décrivent les modèles de configuration de kubelet simplifiés en +Les sections suivantes décrivent les modèles de configuration de kubelet simplifiés en utilisant kubeadm, plutôt que de gérer manuellement la configuration des kubelets pour chaque nœud. ### Propagation de la configuration niveau cluster à chaque kubelet {#propagating-cluster-level-configuration-to-each-kubelet} @@ -50,11 +50,11 @@ kubeadm init --service-cidr 10.96.0.0/12 Les adresses IP virtuelles pour les services sont maintenant attribuées à partir de ce sous-réseau. Vous devez également définir l'adresse DNS utilisée par la kubelet, en utilisant l'option - `--cluster-dns`. Ce paramètre doit être le même pour chaque kubelet sur chaque master et worker + `--cluster-dns`. Ce paramètre doit être le même pour chaque kubelet sur chaque master et worker du cluster. La kubelet fournit un objet API structuré versionné qui peut configurer la plupart des - paramètres dans la kubelet et pousser cette configuration à chaque exécution de la kubelet dans + paramètres dans la kubelet et pousser cette configuration à chaque exécution de la kubelet dans le cluster. Cet objet s'appelle la **ComponentConfig** de la kubelet. -La ComponentConfig permet à l’utilisateur de spécifier des options tels que les adresses IP DNS du +La ComponentConfig permet à l’utilisateur de spécifier des options tels que les adresses IP DNS du cluster exprimées en une liste de valeurs pour une clé formatée en CamelCased, illustrée par l'exemple suivant: ```yaml @@ -68,41 +68,41 @@ Pour plus de détails sur ComponentConfig, jetez un œil à [cette section](#con ### Fournir des détails de configuration spécifiques à l'instance {#providing-instance-specific-configuration-details} -Certaines machines nécessitent des configurations de kubelet spécifiques, en raison de la différences de +Certaines machines nécessitent des configurations de kubelet spécifiques, en raison de la différences de matériel, de système d’exploitation, réseau ou d’autres paramètres spécifiques à l’hôte. La liste suivante fournit quelques exemples. - Le chemin d'accès au fichier de résolution DNS, tel que spécifié par l'option de configuration de la kubelet `--resolv-conf`, peut différer selon les systèmes d'exploitation ou selon que vous utilisez - ou non `systemd-resolved`. Si ce chemin est incorrect, la résolution DNS échouera sur le nœud + ou non `systemd-resolved`. Si ce chemin est incorrect, la résolution DNS échouera sur le nœud dont la kubelet est configuré de manière incorrecte. -- L'objet API de nœud `.metadata.name` est défini par défaut sur le hostname de la machine, +- L'objet API de nœud `.metadata.name` est défini par défaut sur le hostname de la machine, sauf si vous utilisez un fournisseur de cloud. Vous pouvez utiliser l’indicateur `--hostname-override` pour remplacer le comportement par défaut si vous devez spécifier un nom de nœud différent du hostname de la machine. -- Actuellement, la kubelet ne peut pas détecter automatiquement le driver cgroup utilisé par le -runtime CRI, mais la valeur de `--cgroup-driver` doit correspondre au driver cgroup +- Actuellement, la kubelet ne peut pas détecter automatiquement le driver cgroup utilisé par le +runtime CRI, mais la valeur de `--cgroup-driver` doit correspondre au driver cgroup utilisé par le runtime CRI pour garantir la santé de la kubelet. -- En fonction du runtime du CRI utilisé par votre cluster, vous devrez peut-être spécifier des -options différentes pour la kubelet. Par exemple, lorsque vous utilisez Docker, +- En fonction du runtime du CRI utilisé par votre cluster, vous devrez peut-être spécifier des +options différentes pour la kubelet. Par exemple, lorsque vous utilisez Docker, vous devez spécifier des options telles que -`--network-plugin = cni`, mais si vous utilisez un environnement d’exécution externe, vous devez spécifier +`--network-plugin = cni`, mais si vous utilisez un environnement d’exécution externe, vous devez spécifier `--container-runtime = remote` et spécifier le CRI endpoint en utilisant l'option `--container-runtime-path-endpoint = `. -Vous pouvez spécifier ces options en modifiant la configuration d’une kubelet individuelle dans +Vous pouvez spécifier ces options en modifiant la configuration d’une kubelet individuelle dans votre gestionnaire de service, tel que systemd. ## Configurer les kubelets en utilisant kubeadm {#configure-kubelets-using-kubeadm} -Il est possible de configurer la kubelet que kubeadm va démarrer si un objet API personnalisé -`KubeletConfiguration` est passé en paramètre via un fichier de configuration comme +Il est possible de configurer la kubelet que kubeadm va démarrer si un objet API personnalisé +`KubeletConfiguration` est passé en paramètre via un fichier de configuration comme `kubeadm ... --config some-config-file.yaml`. -En appelant `kubeadm config print-default --api-objects KubeletConfiguration` vous +En appelant `kubeadm config print-default --api-objects KubeletConfiguration` vous pouvez voir toutes les valeurs par défaut pour cette structure. Regardez aussi la [référence API pour le composant ComponentConfig des kubelets](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration) @@ -110,16 +110,16 @@ pour plus d'informations sur les champs individuels. ### Workflow lors de l'utilisation de `kubeadm init` -Lorsque vous appelez `kubeadm init`, la configuration de la kubelet est organisée sur le disque +Lorsque vous appelez `kubeadm init`, la configuration de la kubelet est organisée sur le disque sur `/var/lib/kubelet/config.yaml`, et également chargé sur une ConfigMap du cluster. La ConfigMap est nommé `kubelet-config-1.X`, où `.X` est la version mineure de la version de Kubernetes - que vous êtes en train d'initialiser. Un fichier de configuration de kubelet est également écrit dans -`/etc/kubernetes/kubelet.conf` avec la configuration de base à l'échelle du cluster pour tous les -kubelets du cluster. Ce fichier de configuration pointe vers les certificats clients permettant aux -kubelets de communiquer avec l'API server. Ceci répond au besoin de + que vous êtes en train d'initialiser. Un fichier de configuration de kubelet est également écrit dans +`/etc/kubernetes/kubelet.conf` avec la configuration de base à l'échelle du cluster pour tous les +kubelets du cluster. Ce fichier de configuration pointe vers les certificats clients permettant aux +kubelets de communiquer avec l'API server. Ceci répond au besoin de [propager la configuration niveau cluster à chaque kubelet](#propagating-cluster-level-configuration-to-each-kubelet). -Pour répondre au besoin de +Pour répondre au besoin de [fournir des détails de configuration spécifiques à l'instance de kubelet](#providing-instance-specific-configuration-details), kubeadm écrit un fichier d'environnement dans `/var/lib/kubelet/kubeadm-flags.env`, qui contient une liste d'options à passer à la kubelet quand elle démarre. Les options sont représentées dans le fichier comme ceci: @@ -128,8 +128,8 @@ d'options à passer à la kubelet quand elle démarre. Les options sont représe KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..." ``` -Outre les indicateurs utilisés lors du démarrage de la kubelet, le fichier contient également des -informations dynamiques comme des paramètres tels que le driver cgroup et s'il faut utiliser un autre +Outre les indicateurs utilisés lors du démarrage de la kubelet, le fichier contient également des +informations dynamiques comme des paramètres tels que le driver cgroup et s'il faut utiliser un autre socket de runtime CRI (`--cri-socket`). Après avoir rassemblé ces deux fichiers sur le disque, kubeadm tente d’exécuter ces deux commandes, @@ -145,7 +145,7 @@ Si le rechargement et le redémarrage réussissent, le workflow normal de `kubea Lorsque vous exécutez `kubeadm join`, kubeadm utilise les informations d'identification du bootstrap token pour faire un bootstrap TLS, qui récupère les informations d’identité nécessaires pour télécharger le -`kubelet-config-1.X` ConfigMap puis l'écrit dans `/var/lib/kubelet/config.yaml`. Le fichier d’environnement +`kubelet-config-1.X` ConfigMap puis l'écrit dans `/var/lib/kubelet/config.yaml`. Le fichier d’environnement dynamique est généré exactement de la même manière que `kubeadm init`. Ensuite, `kubeadm` exécute les deux commandes suivantes pour charger la nouvelle configuration dans la kubelet: @@ -157,7 +157,7 @@ systemctl daemon-reload && systemctl restart kubelet Après le chargement de la nouvelle configuration par la kubelet, kubeadm écrit le fichier KubeConfig `/etc/kubernetes/bootstrap-kubelet.conf`, qui contient un certificat de CA et un jeton Bootstrap. Ceux-ci sont utilisés par la kubelet pour effectuer le TLS Bootstrap et obtenir une information - d'identification unique, qui est stocké dans `/etc/kubernetes/kubelet.conf`. Quand ce fichier est + d'identification unique, qui est stocké dans `/etc/kubernetes/kubelet.conf`. Quand ce fichier est écrit, la kubelet a terminé l'exécution du bootstrap TLS. ## Le fichier kubelet généré pour systemd {#the-kubelet-drop-in-file-for-systemd} @@ -187,11 +187,11 @@ Ce fichier spécifie les emplacements par défaut pour tous les fichiers gérés mais il n'est utilisé que si `/etc/kubernetes/kubelet.conf` n'existe pas. - Le fichier KubeConfig avec l’identité unique de la kubelet est `/etc/kubernetes/kubelet.conf`. - Le fichier contenant le ComponentConfig de la kubelet est `/var/lib/kubelet/config.yaml`. -- Le fichier d'environnement dynamique qui contient `KUBELET_KUBEADM_ARGS` est sourcé à partir de +- Le fichier d'environnement dynamique qui contient `KUBELET_KUBEADM_ARGS` est sourcé à partir de `/var/lib/kubelet/kubeadm-flags.env`. - Le fichier qui peut contenir les paramètres surchargés par l'utilisateur avec `KUBELET_EXTRA_ARGS` provient de `/etc/default/kubelet` (pour les DEBs), ou `/etc/sysconfig/kubelet` (pour les RPMs) - `KUBELET_EXTRA_ARGS` est le dernier de la chaîne d'options et a la priorité la plus élevée en cas + `KUBELET_EXTRA_ARGS` est le dernier de la chaîne d'options et a la priorité la plus élevée en cas de conflit de paramètres. ## Fichiers binaires de Kubernetes et contenu du package diff --git a/content/fr/docs/setup/independent/setup-ha-etcd-with-kubeadm.md b/content/fr/docs/setup/independent/setup-ha-etcd-with-kubeadm.md index 684cce95f66d1..678268a7712a1 100644 --- a/content/fr/docs/setup/independent/setup-ha-etcd-with-kubeadm.md +++ b/content/fr/docs/setup/independent/setup-ha-etcd-with-kubeadm.md @@ -8,7 +8,7 @@ weight: 70 {{% capture overview %}} Par défaut, Kubeadm exécute un cluster etcd mono nœud dans un pod statique géré -par la kubelet sur le nœud du plan de contrôle (control plane). Ce n'est pas une configuration haute disponibilité puisque le cluster etcd ne contient qu'un seul membre et ne peut donc supporter +par la kubelet sur le nœud du plan de contrôle (control plane). Ce n'est pas une configuration haute disponibilité puisque le cluster etcd ne contient qu'un seul membre et ne peut donc supporter qu'aucun membre ne devienne indisponible. Cette page vous accompagne dans le processus de création d'un cluster etcd à trois membres en haute disponibilité, pouvant être utilisé en tant que cluster externe lors de l’utilisation de kubeadm pour configurer un cluster kubernetes. @@ -41,8 +41,8 @@ kubeadm contient tout ce qui est nécessaire pour générer les certificats déc 1. Configurez la kubelet pour qu'elle soit un gestionnaire de service pour etcd. - Etant donné qu'etcd a été créé en premier, vous devez remplacer la priorité de service en - créant un nouveau fichier unit qui a une priorité plus élevée que le fichier unit de la kubelet fourni + Etant donné qu'etcd a été créé en premier, vous devez remplacer la priorité de service en + créant un nouveau fichier unit qui a une priorité plus élevée que le fichier unit de la kubelet fourni par kubeadm. ```sh @@ -105,7 +105,7 @@ kubeadm contient tout ce qui est nécessaire pour générer les certificats déc `/etc/kubernetes/pki/etcd/ca.key`. Une fois ces fichiers copiés,     passez à l'étape suivante, "Créer des certificats pour chaque membre". - Si vous ne possédez pas déjà de CA, exécutez cette commande sur `$HOST0` (où vous + Si vous ne possédez pas déjà de CA, exécutez cette commande sur `$HOST0` (où vous avez généré les fichiers de configuration pour kubeadm). ``` diff --git a/content/fr/docs/setup/independent/troubleshooting-kubeadm.md b/content/fr/docs/setup/independent/troubleshooting-kubeadm.md index a4863c2b8e3fe..ba00d254c7d74 100644 --- a/content/fr/docs/setup/independent/troubleshooting-kubeadm.md +++ b/content/fr/docs/setup/independent/troubleshooting-kubeadm.md @@ -9,7 +9,7 @@ weight: 90 Comme avec n'importe quel programme, vous pourriez rencontrer une erreur lors de l'installation ou de l'exécution de kubeadm. -Cette page répertorie certains scénarios d’échec courants et propose des étapes pouvant vous aider à +Cette page répertorie certains scénarios d’échec courants et propose des étapes pouvant vous aider à comprendre et résoudre le problème. Si votre problème ne figure pas dans la liste ci-dessous, procédez comme suit: @@ -17,12 +17,12 @@ Si votre problème ne figure pas dans la liste ci-dessous, procédez comme suit: - Si vous pensez que votre problème est un bug avec kubeadm: - Aller à [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) et rechercher les problèmes existants. - - Si aucune issue n'existe, veuillez [en ouvrir une](https://github.com/kubernetes/kubeadm/issues/new) et + - Si aucune issue n'existe, veuillez [en ouvrir une](https://github.com/kubernetes/kubeadm/issues/new) et suivez le modèle ( template ) d'issue -- Si vous ne savez pas comment fonctionne kubeadm, vous pouvez demander sur [Slack](http://slack.k8s.io/) -dans le canal #kubeadm, ou posez une questions sur -[StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Merci d'ajouter les tags pertinents +- Si vous ne savez pas comment fonctionne kubeadm, vous pouvez demander sur [Slack](http://slack.k8s.io/) +dans le canal #kubeadm, ou posez une questions sur +[StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Merci d'ajouter les tags pertinents comme `#kubernetes` et `#kubeadm`, ainsi on pourra vous aider. {{% /capture %}} @@ -38,7 +38,7 @@ Si vous voyez les warnings suivants lors de l'exécution `kubeadm init` [preflight] WARNING: ethtool not found in system path ``` -Ensuite, il peut vous manquer `ebtables`, `ethtool` ou un exécutable similaire sur votre nœud. Vous +Ensuite, il peut vous manquer `ebtables`, `ethtool` ou un exécutable similaire sur votre nœud. Vous pouvez l'installer avec les commandes suivantes: - For Ubuntu/Debian users, run `apt install ebtables ethtool`. @@ -54,10 +54,10 @@ Si vous remarquez que `kubeadm init` se bloque après la ligne suivante: Cela peut être causé par un certain nombre de problèmes. Les plus communs sont: -- problèmes de connexion réseau. Vérifiez que votre machine dispose d'une connectivité réseau +- problèmes de connexion réseau. Vérifiez que votre machine dispose d'une connectivité réseau complète avant de continuer. - la configuration du driver cgroup par défaut pour la kubelet diffère de celle utilisée par Docker. -  Vérifiez le fichier journal du système (par exemple, `/var/log/message`) ou examinez le résultat +  Vérifiez le fichier journal du système (par exemple, `/var/log/message`) ou examinez le résultat de `journalctl -u kubelet`. Si vous voyez quelque chose comme ce qui suit: ```shell @@ -77,7 +77,7 @@ de `journalctl -u kubelet`. Si vous voyez quelque chose comme ce qui suit: ## kubeadm bloque lors de la suppression de conteneurs gérés -Les événements suivants peuvent se produire si Docker s'arrête et ne supprime pas les conteneurs gérés +Les événements suivants peuvent se produire si Docker s'arrête et ne supprime pas les conteneurs gérés par Kubernetes: ```bash @@ -111,26 +111,26 @@ Juste après `kubeadm init`, il ne devrait pas y avoir de pods dans ces états.   jusqu'à ce que vous ayez déployé la solution réseau. - Si vous voyez des pods dans les états `RunContainerError`,` CrashLoopBackOff` ou `Error`   après le déploiement de la solution réseau et que rien ne se passe pour `coredns` (ou` kube-dns`), -  il est très probable que la solution Pod Network que vous avez installée est en quelque sorte -endommagée. Vous devrez peut-être lui accorder plus de privilèges RBAC ou utiliser une version +  il est très probable que la solution Pod Network que vous avez installée est en quelque sorte +endommagée. Vous devrez peut-être lui accorder plus de privilèges RBAC ou utiliser une version plus récente. S'il vous plaît créez une issue dans le dépôt du fournisseur de réseau de Pod. - Si vous installez une version de Docker antérieure à 1.12.1, supprimez l'option `MountFlags = slave` -  lors du démarrage de `dockerd` avec` systemd` et redémarrez `docker`. Vous pouvez voir les options +  lors du démarrage de `dockerd` avec` systemd` et redémarrez `docker`. Vous pouvez voir les options de montage dans `/usr/lib/systemd/system/docker.service`. - Les options de montage peuvent interférer avec les volumes montés par Kubernetes et mettre les - pods dans l'état`CrashLoopBackOff`. L'erreur se produit lorsque Kubernetes ne trouve pas les fichiers + Les options de montage peuvent interférer avec les volumes montés par Kubernetes et mettre les + pods dans l'état`CrashLoopBackOff`. L'erreur se produit lorsque Kubernetes ne trouve pas les fichiers `var/run/secrets/kubernetes.io/serviceaccount`. ## `coredns` (ou` kube-dns`) est bloqué dans l'état `Pending` -Ceci est **prévu** et fait partie du design. kubeadm est agnostique vis-à-vis du fournisseur +Ceci est **prévu** et fait partie du design. kubeadm est agnostique vis-à-vis du fournisseur de réseau, ainsi l'administrateur devrait [installer la solution réseau pod](/docs/concepts/cluster-administration/addons/) -de choix. Vous devez installer un réseau de pods avant que CoreDNS ne soit complètement déployé. +de choix. Vous devez installer un réseau de pods avant que CoreDNS ne soit complètement déployé. D'où l' état `Pending` avant la mise en place du réseau. ## Les services `HostPort` ne fonctionnent pas -Les fonctionnalités `HostPort` et `HostIP` sont disponibles en fonction de votre fournisseur +Les fonctionnalités `HostPort` et `HostIP` sont disponibles en fonction de votre fournisseur de réseau de pod. Veuillez contacter l’auteur de la solution de réseau de Pod pour savoir si Les fonctionnalités `HostPort` et` HostIP` sont disponibles. @@ -143,14 +143,14 @@ Si votre fournisseur de réseau ne prend pas en charge le plug-in portmap CNI, v ## Les pods ne sont pas accessibles via leur IP de service -- De nombreux add-ons réseau ne permettent pas encore +- De nombreux add-ons réseau ne permettent pas encore [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip) - qui permet aux pods d’accéder à eux-mêmes via leur IP de service. Ceci est un problème lié - au [CNI](https://github.com/containernetworking/cni/issues/476). S'il vous plaît contacter + qui permet aux pods d’accéder à eux-mêmes via leur IP de service. Ceci est un problème lié + au [CNI](https://github.com/containernetworking/cni/issues/476). S'il vous plaît contacter le fournisseur d'add-on réseau afin d'obtenir des informations en matière de prise en charge du mode hairpin. -- Si vous utilisez VirtualBox (directement ou via Vagrant), vous devrez vous assurez que -`hostname -i` renvoie une adresse IP routable. Par défaut la première interface est connectée +- Si vous utilisez VirtualBox (directement ou via Vagrant), vous devrez vous assurez que +`hostname -i` renvoie une adresse IP routable. Par défaut la première interface est connectée à un réseau d’`hôte uniquement` non routable. En contournement vous pouvez modifier`/etc/hosts`, jetez un œil à ce [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11) par exemple. @@ -160,7 +160,7 @@ L'erreur suivante indique une possible incompatibilité de certificat. ```none # kubectl get pods -Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of +Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes") ``` @@ -187,33 +187,33 @@ Error from server (NotFound): the server could not find the requested resource - Si vous utilisez flannel comme réseau de pod dans Vagrant, vous devrez spécifier le nom d'interface par défaut pour flannel. -  Vagrant attribue généralement deux interfaces à tous les ordinateurs virtuels. La -première, pour laquel tous les hôtes se voient attribuer l’adresse IP `10.0.2.15`, +  Vagrant attribue généralement deux interfaces à tous les ordinateurs virtuels. La +première, pour laquel tous les hôtes se voient attribuer l’adresse IP `10.0.2.15`, est pour le trafic externe qui est NATé. -  Cela peut entraîner des problèmes avec Flannel, qui utilise par défaut la première -interface sur un hôte. Ceci conduit au fait que tous les hôtes pensent qu'ils ont la -même adresse IP publique. Pour éviter cela, passez l'option `--iface eth1` sur Flannel +  Cela peut entraîner des problèmes avec Flannel, qui utilise par défaut la première +interface sur un hôte. Ceci conduit au fait que tous les hôtes pensent qu'ils ont la +même adresse IP publique. Pour éviter cela, passez l'option `--iface eth1` sur Flannel pour que la deuxième interface soit choisie. ## IP non publique utilisée pour les conteneurs -Dans certaines situations, les commandes `kubectl logs` et` kubectl run` peuvent +Dans certaines situations, les commandes `kubectl logs` et` kubectl run` peuvent renvoyer les erreurs suivantes dans un cluster par ailleurs fonctionnel: ```sh -Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: +Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: dial tcp 10.19.0.41:10250: getsockopt: no route to host ``` -- Cela peut être dû au fait que Kubernetes utilise une adresse IP qui ne peut pas communiquer -avec d’autres adresses IP même sous-réseau, éventuellement à cause d'une politique mise en place +- Cela peut être dû au fait que Kubernetes utilise une adresse IP qui ne peut pas communiquer +avec d’autres adresses IP même sous-réseau, éventuellement à cause d'une politique mise en place par le fournisseur de la machine. -- Digital Ocean attribue une adresse IP publique à `eth0` ainsi qu’une adresse privée à -utiliser en interne comme IP d'ancrage pour leur fonction IP flottante, mais `kubelet` choisira cette +- Digital Ocean attribue une adresse IP publique à `eth0` ainsi qu’une adresse privée à +utiliser en interne comme IP d'ancrage pour leur fonction IP flottante, mais `kubelet` choisira cette dernière comme` InternalIP` du noeud au lieu du public. - Utilisez `ip addr show` pour verifier ce scénario au lieu de` ifconfig` car `ifconfig` n'affichera pas + Utilisez `ip addr show` pour verifier ce scénario au lieu de` ifconfig` car `ifconfig` n'affichera pas l'alias de l'adresse IP incriminée. Sinon, une API spécifique à Digital Ocean  permet de rechercher l'adresse IP d'ancrage à partir du droplet: @@ -221,9 +221,9 @@ dernière comme` InternalIP` du noeud au lieu du public. curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address ``` - La solution consiste à indiquer à la `kubelet` l'adresse IP à utiliser avec` --node-ip`. Lors de - l'utilisation de Digital Ocean, il peut être public (assigné à `eth0`) ou privé (assigné à` eth1`) - si vous voulez utiliser le réseau privé optionnel. la + La solution consiste à indiquer à la `kubelet` l'adresse IP à utiliser avec` --node-ip`. Lors de + l'utilisation de Digital Ocean, il peut être public (assigné à `eth0`) ou privé (assigné à` eth1`) + si vous voulez utiliser le réseau privé optionnel. la [la section `KubeletExtraArgs` de kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) peut être utilisé pour cela. Puis redémarrer la `kubelet`: @@ -235,7 +235,7 @@ dernière comme` InternalIP` du noeud au lieu du public. ## Les pods `coredns` sont en état` CrashLoopBackOff` ou `Error` -Si vous avez des nœuds qui exécutent SELinux avec une version plus ancienne de Docker, vous risquez +Si vous avez des nœuds qui exécutent SELinux avec une version plus ancienne de Docker, vous risquez de rencontrer un problème ou les pods de `coredns` ne démarrent pas. Pour résoudre ce problème, vous pouvez essayer l'une des options suivantes: - Mise à niveau vers une [nouvelle version de Docker](/docs/setup/independent/install-kubeadm/#installing-docker). @@ -248,7 +248,7 @@ kubectl -n kube-system get deployment coredns -o yaml | \ kubectl apply -f - ``` -une autre raison pour laquelle CoreDNS peut se retrouver dans l'état `CrashLoopBackOff` est lorsqu'un +une autre raison pour laquelle CoreDNS peut se retrouver dans l'état `CrashLoopBackOff` est lorsqu'un Pod de CoreDNS déployé dans Kubernetes détecte une boucle. [Un certain nombre de solutions de contournement](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters) sont disponibles pour éviter que Kubernetes ne tente de redémarrer le pod CoreDNS chaque fois que CoreDNS détecte une boucle et s'arrête. @@ -262,8 +262,8 @@ la sécurité de votre cluster. Si vous rencontrez l'erreur suivante: ``` -rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container -process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection +rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container +process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\"" ``` diff --git a/content/fr/docs/setup/pick-right-solution.md b/content/fr/docs/setup/pick-right-solution.md index a43d3ac2c30d3..9fea0c6c23914 100644 --- a/content/fr/docs/setup/pick-right-solution.md +++ b/content/fr/docs/setup/pick-right-solution.md @@ -15,16 +15,16 @@ de votre propre cluster personnalisé. Utilisez ce guide pour choisir la solutio Si vous voulez simplement jeter un coup d'oeil rapide, utilisez alors de préférence les [solutions locales basées sur Docker](#local-machine-solutions). -Lorsque vous êtes prêts à augmenter le nombre de machines et souhaitez bénéficier de la haute disponibilité, une +Lorsque vous êtes prêts à augmenter le nombre de machines et souhaitez bénéficier de la haute disponibilité, une [solution hébergée](#hosted-solutions) est la plus simple à déployer et à maintenir. -[Les solutions cloud clés en main](#turnkey-cloud-solutions) ne demandent que peu de commande pour déployer et couvrent un large panel de +[Les solutions cloud clés en main](#turnkey-cloud-solutions) ne demandent que peu de commande pour déployer et couvrent un large panel de fournisseurs de cloud. [Les solutions clés en main pour cloud privé](#on-premises-turnkey-cloud-solutions) possèdent la simplicité des solutions cloud clés en main combinées avec la sécurité de votre propre réseau privé. Si vous avez déjà un moyen de configurer vos resources, utilisez [kubeadm](/docs/setup/independent/create-cluster-kubeadm/) pour facilement déployer un cluster grâce à une seule ligne de commande par machine. -[Les solutions personnalisées](#custom-solutions) varient d'instructions pas à pas, à des conseils relativement généraux pour déployer un +[Les solutions personnalisées](#custom-solutions) varient d'instructions pas à pas, à des conseils relativement généraux pour déployer un cluster Kubernetes en partant du début. {{% /capture %}} @@ -39,7 +39,7 @@ cluster Kubernetes en partant du début. application facile à installer pour votre environnement Mac ou Windows qui vous permet de commencer à coder et déployer votre code dans des conteneurs en quelques minutes sur un nœud unique Kubernetes. -* [Minishift](https://docs.okd.io/latest/minishift/) installe la version communautaire de la plate-forme d'entreprise OpenShift +* [Minishift](https://docs.okd.io/latest/minishift/) installe la version communautaire de la plate-forme d'entreprise OpenShift de Kubernetes pour le développement local et les tests. Il offre une VM tout-en-un (`minishift start`) pour Windows, macOS et Linux, le `oc cluster up` containerisé (Linux uniquement) et [est livré avec quelques Add Ons faciles à installer](https://github.com/minishift/minishift-addons/tree/master/add-ons). @@ -68,7 +68,7 @@ un nœud unique) qui ne nécessite qu'un docker-engine. Il utilise la technique * [Azure Kubernetes Service](https://azure.microsoft.com/services/container-service/) offre des clusters Kubernetes managés. * [Containership Kubernetes Engine (CKE)](https://containership.io/containership-platform) Approvisionnement et gestion intuitive de clusters - Kubernetes sur GCP, Azure, AWS, Packet, et DigitalOcean. Mises à niveau transparentes, auto-scaling, métriques, création de + Kubernetes sur GCP, Azure, AWS, Packet, et DigitalOcean. Mises à niveau transparentes, auto-scaling, métriques, création de workloads, et plus encore. * [DigitalOcean Kubernetes](https://www.digitalocean.com/products/kubernetes/) offre un service managé de Kubernetes. @@ -99,13 +99,13 @@ workloads, et plus encore. * [Stackpoint.io](https://stackpoint.io) fournit l'automatisation et la gestion de l'infrastructure Kubernetes pour plusieurs clouds publics. -* [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/) offre un Kubernetes-as-a-Service sur un cloud public OpenStack. Il inclut la gestion du cycle de vie, les tableaux de bord d'administration, la surveillance, la mise à l'échelle automatique et bien plus encore. +* [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/) offre un Kubernetes-as-a-Service sur un cloud public OpenStack. Il inclut la gestion du cycle de vie, les tableaux de bord d'administration, la surveillance, la mise à l'échelle automatique et bien plus encore. * [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) est une offre d'entreprise Kubernetes-as-a-Service faisant partie du catalogue de services Cloud VMware qui fournit des clusters Kubernetes faciles à utiliser, sécurisés par défaut, rentables et basés sur du SaaS. ## Solutions clés en main -Ces solutions vous permettent de créer des clusters Kubernetes sur une gamme de fournisseurs de Cloud IaaaS avec seulement +Ces solutions vous permettent de créer des clusters Kubernetes sur une gamme de fournisseurs de Cloud IaaaS avec seulement quelques commandes. Ces solutions sont activement développées et bénéficient du soutien actif de la communauté. * [Agile Stacks](https://www.agilestacks.com/products/kubernetes) @@ -157,11 +157,11 @@ Ces solutions vous permettent de créer des clusters Kubernetes sur votre cloud ## Solutions personnalisées -Kubernetes peut fonctionner sur une large gamme de fournisseurs de Cloud et d'environnements bare-metal, ainsi qu'avec de nombreux +Kubernetes peut fonctionner sur une large gamme de fournisseurs de Cloud et d'environnements bare-metal, ainsi qu'avec de nombreux systèmes d'exploitation. Si vous pouvez trouver un guide ci-dessous qui correspond à vos besoins, utilisez-le. C'est peut-être un peu dépassé, mais... -ce sera plus facile que de partir de zéro. Si vous voulez repartir de zéro, soit parce que vous avez des exigences particulières, +ce sera plus facile que de partir de zéro. Si vous voulez repartir de zéro, soit parce que vous avez des exigences particulières, ou simplement parce que vous voulez comprendre ce qu'il y a à l'interieur de Kubernetes essayez le guide [Getting Started from Scratch](/docs/setup/release/building-from-source/). diff --git a/content/fr/docs/setup/release/building-from-source.md b/content/fr/docs/setup/release/building-from-source.md index 273fd4a256843..e3e0891f086d5 100644 --- a/content/fr/docs/setup/release/building-from-source.md +++ b/content/fr/docs/setup/release/building-from-source.md @@ -8,7 +8,7 @@ card: title: Construire une release --- {{% capture overview %}} -Vous pouvez soit compiler une version à partir des sources, soit télécharger une version pré-compilée. Si vous ne +Vous pouvez soit compiler une version à partir des sources, soit télécharger une version pré-compilée. Si vous ne prévoyez pas de développer Kubernetes nous vous suggérons d'utiliser une version pré-compilée de la version actuelle, que l'on peut trouver dans le répertoire [Release Notes](/docs/setup/release/notes/). diff --git a/content/fr/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/fr/docs/tasks/configure-pod-container/assign-cpu-resource.md index a925a4c0bce75..0e65c9876508c 100644 --- a/content/fr/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/fr/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -19,7 +19,7 @@ Un conteneur est garanti d'avoir autant de CPU qu'il le demande, mais n'est pas Chaque nœud de votre cluster doit avoir au moins 1 CPU. -Pour certaines des étapes de cette page, vous devez lancer [metrics-server](https://github.com/kubernetes-incubator/metrics-server) dans votre cluster. Si le serveur de métriques est déja lancé, +Pour certaines des étapes de cette page, vous devez lancer [metrics-server](https://github.com/kubernetes-incubator/metrics-server) dans votre cluster. Si le serveur de métriques est déja lancé, vous pouvez sauter ces étapes. Si vous utilisez minikube, exécutez la commande suivante pour activer metrics-server : @@ -34,12 +34,12 @@ Pour voir si metrics-server (ou un autre fournisseur de l'API des métriques de kubectl get apiservices ``` -Si l'API de métriques de ressources est disponible, la sortie inclura une +Si l'API de métriques de ressources est disponible, la sortie inclura une référence à `metrics.k8s.io`. ```shell -NAME +NAME v1beta1.metrics.k8s.io ``` @@ -114,7 +114,7 @@ Souvenez-vous qu'en réglant `-cpu "2"`, vous avez configuré le conteneur pour {{< note >}} Une autre explication possible de la la restriction du CPU est que le Nœud pourrait ne pas avoir -suffisamment de ressources CPU disponibles. Rappelons que les conditions préalables à cet exercice exigent que chacun de vos Nœuds doit avoir au moins 1 CPU. +suffisamment de ressources CPU disponibles. Rappelons que les conditions préalables à cet exercice exigent que chacun de vos Nœuds doit avoir au moins 1 CPU. Si votre conteneur fonctionne sur un nœud qui n'a qu'un seul CPU, le conteneur ne peut pas utiliser plus que 1 CPU, quelle que soit la limite de CPU spécifiée pour le conteneur. {{< /note >}} @@ -206,9 +206,9 @@ pour spécifier une valeur par défaut pour la limite de CPU. ## Motivation pour les demandes et les limites du CPU -En configurant les demandes et les limites de CPU des conteneurs qui se lancent sur votre cluster, -vous pouvez utiliser efficacement les ressources CPU disponibles sur les Nœuds de votre cluster. -En gardant une demande faible de CPU de pod, vous donnez au Pod une bonne chance d'être ordonnancé. +En configurant les demandes et les limites de CPU des conteneurs qui se lancent sur votre cluster, +vous pouvez utiliser efficacement les ressources CPU disponibles sur les Nœuds de votre cluster. +En gardant une demande faible de CPU de pod, vous donnez au Pod une bonne chance d'être ordonnancé. En ayant une limite CPU supérieure à la demande de CPU, vous accomplissez deux choses : * Le Pod peut avoir des pics d'activité où il utilise les ressources CPU qui se sont déjà disponible. diff --git a/content/fr/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/fr/docs/tasks/configure-pod-container/assign-memory-resource.md index 533578e6b54b9..93d4fd63c991d 100644 --- a/content/fr/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/fr/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -16,7 +16,7 @@ Cette page montre comment assigner une mémoire *request* et une mémoire *limit Chaque nœud de votre cluster doit avoir au moins 300 MiB de mémoire. -Pour quelques étapes de cette page, vous devez lancer +Pour quelques étapes de cette page, vous devez lancer [metrics-server] (https://github.com/kubernetes-incubator/metrics-server) dans votre cluster. Si vous avez déjà metrics-server vous pouvez sauter ces étapes. @@ -35,7 +35,7 @@ kubectl get apiservices Si l'API des métriques de ressources est disponible, la sortie inclura une référence à `metrics.k8s.io`. ```shell -NAME +NAME v1beta1.metrics.k8s.io ``` @@ -116,7 +116,7 @@ kubectl delete pod memory-demo --namespace=mem-example ## Dépasser la limite de mémoire d'un conteneur -Un conteneur peut dépasser sa demande de mémoire si le nœud dispose de la mémoire disponible. Cependant, un conteneur n'est pas autorisé à utiliser plus que sa limite de mémoire. Si un conteneur alloue plus de mémoire que sa limite, le Conteneur devient un candidat à la terminaison. Si le conteneur continue à consommer de la mémoire au-delà de sa limite, le conteneur est arrêté. +Un conteneur peut dépasser sa demande de mémoire si le nœud dispose de la mémoire disponible. Cependant, un conteneur n'est pas autorisé à utiliser plus que sa limite de mémoire. Si un conteneur alloue plus de mémoire que sa limite, le Conteneur devient un candidat à la terminaison. Si le conteneur continue à consommer de la mémoire au-delà de sa limite, le conteneur est arrêté. Si un conteneur terminé peut être redémarré, le kubelet le redémarre, comme pour tout autre type d'échec d'exécution. Dans cet exercice, vous créez un Pod qui tente d'allouer plus de mémoire que sa limite. @@ -218,7 +218,7 @@ kubectl delete pod memory-demo-2 --namespace=mem-example ## Spécifiez une demande de mémoire trop volumineuse pour vos nœuds. -Les demandes de mémoire et les limites sont associées aux conteneurs, mais il est utile de réfléchir avant tout à la capacité de demande et limite mémoire des pods. +Les demandes de mémoire et les limites sont associées aux conteneurs, mais il est utile de réfléchir avant tout à la capacité de demande et limite mémoire des pods. La demande de mémoire pour le Pod est la somme des demandes de mémoire pour tous ses conteneurs. De même, la mémoire limite pour le Pod est la somme des limites de tous ses Conteneurs. L'ordonnancement des modules est basé sur les demandes. Un Pod est schedulé pour se lancer sur un Nœud uniquement si le Nœud dispose de suffisamment de mémoire disponible pour répondre à la demande de mémoire du Pod. @@ -292,7 +292,7 @@ pour spécifier une valeur par défaut pour la limite de mémoire. En configurant les demandes de mémoire et les limites pour les conteneurs qui s'exécutent dans votre cluster. vous pouvez utiliser efficacement les ressources mémoire disponibles sur les noeuds de votre cluster. En gardant la demande de mémoire d'un Pod basse, vous donnez au Pod une bonne chance d'être schedulé. En ayant une limite de mémoire supérieure à la demande de mémoire, vous accomplissez deux choses : -* Le Pod peut avoir des éclats d'activités où il fait usage de la mémoire qui se trouve être disponible. +* Le Pod peut avoir des éclats d'activités où il fait usage de la mémoire qui se trouve être disponible. * La quantité de mémoire qu'un Pod peut utiliser pendant un éclat d'activité est limitée à une quantité raisonnable. ## Clean up diff --git a/content/fr/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/fr/docs/tasks/configure-pod-container/assign-pods-nodes.md index 749d7495a6133..c3c1a2a5e9c74 100644 --- a/content/fr/docs/tasks/configure-pod-container/assign-pods-nodes.md +++ b/content/fr/docs/tasks/configure-pod-container/assign-pods-nodes.md @@ -64,7 +64,7 @@ Le fichier de configuration de pod décrit un pod qui possède un selector de n {{< codenew file="pods/pod-nginx.yaml" >}} 1. Utilisez le fichier de configuration pour créer un pod qui sera ordonnancé sur votre nœud choisi : - + ```shell kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml ``` @@ -76,7 +76,7 @@ Le fichier de configuration de pod décrit un pod qui possède un selector de n ``` La sortie est la suivante : - + ```shell NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 13s 10.200.0.4 worker0 diff --git a/content/fr/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/fr/docs/tasks/configure-pod-container/configure-volume-storage.md index 45cec7cba0b66..fe35b1cb8b11e 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -10,7 +10,7 @@ Cette page montre comment configurer un Pod pour utiliser un Volume pour le stoc Le système de fichiers d'un conteneur ne vit que tant que le conteneur vit. Ainsi, quand un conteneur se termine et redémarre, les modifications apportées au système de fichiers sont perdues. Pour un stockage plus consistant et indépendant du conteneur, vous pouvez utiliser un [Volume](/fr/docs/concepts/storage/volumes/). -C'est particulièrement important pour les applications Stateful, telles que les key-value stores (comme par exemple Redis) et les bases de données. +C'est particulièrement important pour les applications Stateful, telles que les key-value stores (comme par exemple Redis) et les bases de données. {{% /capture %}} @@ -25,7 +25,7 @@ C'est particulièrement important pour les applications Stateful, telles que les ## Configurer un volume pour un Pod Dans cet exercice, vous créez un pod qui contient un seul conteneur. Ce Pod a un Volume de type -[emptyDir](/fr/docs/concepts/storage/volumes/#emptydir) qui dure toute la vie du Pod, même si le conteneur se termine et redémarre. +[emptyDir](/fr/docs/concepts/storage/volumes/#emptydir) qui dure toute la vie du Pod, même si le conteneur se termine et redémarre. Voici le fichier de configuration du Pod : {{< codenew file="pods/storage/redis.yaml" >}} @@ -41,7 +41,7 @@ Voici le fichier de configuration du Pod : ```shell kubectl get pod redis --watch ``` - + La sortie ressemble à ceci : ```shell diff --git a/content/fr/docs/tasks/configure-pod-container/extended-resource.md b/content/fr/docs/tasks/configure-pod-container/extended-resource.md index 9b9930b6a9889..a19980c5b84fe 100644 --- a/content/fr/docs/tasks/configure-pod-container/extended-resource.md +++ b/content/fr/docs/tasks/configure-pod-container/extended-resource.md @@ -28,7 +28,7 @@ Cela configurera l'un de vos nœuds pour qu'il annoncera une ressource dongle. ## Affecter une ressource supplémentaire à un Pod -Pour demander une ressource supplémentaire, incluez le champ `resources:requests` dans votre fichier de manifeste du conteneur. Les ressources supplémentaires sont entièrement qualifiées dans n'importe quel domaine à l'extérieur de `*.kubernetes.io/`. +Pour demander une ressource supplémentaire, incluez le champ `resources:requests` dans votre fichier de manifeste du conteneur. Les ressources supplémentaires sont entièrement qualifiées dans n'importe quel domaine à l'extérieur de `*.kubernetes.io/`. Les noms de ressources supplémentaires valides ont la forme `example.com/foo` où `example.com` est remplacé par le domaine de votre organisation et `foo` est le nom descriptif de la ressource. Voici le fichier de configuration d'un Pod qui a un seul conteneur : diff --git a/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md b/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md index 11aab62fd2d86..c866951ddbe29 100644 --- a/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md @@ -44,7 +44,7 @@ Pour qu'un Pod reçoive une classe de QoS Guaranteed : * Chaque conteneur du Pod doit avoir une limite de mémoire et une demande de mémoire, et elles doivent être les mêmes. * Chaque conteneur dans le Pod doit avoir une limite CPU et une demande CPU, et ils doivent être les mêmes. -Ci-dessous le fichier de configuration d'un Pod qui a un seul conteneur. +Ci-dessous le fichier de configuration d'un Pod qui a un seul conteneur. Le conteneur dispose d'une limite de mémoire et d'une demande de mémoire, tous deux égaux à 200 MiB. Le conteneur a également une limite CPU et une demande CPU, toutes deux égales à 700 milliCPU : {{< codenew file="pods/qos/qos-pod.yaml" >}} @@ -174,7 +174,7 @@ kubectl delete pod qos-demo-3 --namespace=qos-example ## Créez un pod qui contient deux conteneurs -Voici le fichier de configuration d'un Pod qui a deux conteneurs. Un conteneur spécifie une +Voici le fichier de configuration d'un Pod qui a deux conteneurs. Un conteneur spécifie une demande de mémoire de 200 MiB. L'autre conteneur ne spécifie aucune demande ou limite. {{< codenew file="pods/qos/qos-pod-4.yaml" >}} diff --git a/content/fr/docs/tasks/tools/install-kubectl.md b/content/fr/docs/tasks/tools/install-kubectl.md index 9582010e71394..1ea9186696510 100644 --- a/content/fr/docs/tasks/tools/install-kubectl.md +++ b/content/fr/docs/tasks/tools/install-kubectl.md @@ -35,7 +35,7 @@ Vous devez utiliser une version de kubectl qui différe seulement d'une version Pour télécharger une version spécifique, remplacez `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` avec la version spécifique. Par exemple, pour télécharger la version {{< param "fullversion" >}} sur Linux, tapez : - + ``` curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl ``` @@ -79,8 +79,8 @@ EOF yum install -y kubectl {{< /tab >}} {{< /tabs >}} - - + + ### Installer avec snap Si vous êtes sur Ubuntu ou une autre distribution Linux qui supporte le gestionnaire de paquets [snap](https://snapcraft.io/docs/core/install), kubectl est disponible comme application [snap](https://snapcraft.io/). @@ -96,21 +96,21 @@ Si vous êtes sur Ubuntu ou une autre distribution Linux qui supporte le gestion ``` kubectl version ``` - + ## Installer kubectl sur macOS ### Installer le binaire kubectl avec curl sur macOS 1. Téléchargez la dernière release: - ``` + ``` curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl ``` Pour télécharger une version spécifique, remplacez `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` avec la version spécifique. Par exemple, pour télécharger la version {{< param "fullversion" >}} sur macOS, tapez : - + ``` curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl ``` @@ -158,7 +158,7 @@ Si vous êtes sur MacOS et que vous utilisez le gestionnaire de paquets [Macport sudo port selfupdate sudo port install kubectl ``` - + 2. Testez pour vous assurer que la version que vous avez installée est à jour: ``` @@ -196,9 +196,9 @@ Si vous êtes sous Windows et que vous utilisez le gestionnaire de paquets [Powe Install-Script -Name install-kubectl -Scope CurrentUser -Force install-kubectl.ps1 [-DownloadLocation ] ``` - + {{< note >}}Si vous ne spécifiez pas un `DownloadLocation`, `kubectl` sera installé dans le répertoire temp de l'utilisateur.{{< /note >}} - + Le programme d'installation creé `$HOME/.kube` qui est suivie par la création d'un fichier de configuration 2. Testez pour vous assurer que la version que vous avez installée est à jour: @@ -252,7 +252,7 @@ Pour installer kubectl sur Windows, vous pouvez utiliser le gestionnaire de paqu ``` New-Item config -type file ``` - + {{< note >}}Editez le fichier de configuration avec un éditeur de texte de votre choix, tel que Notepad.{{< /note >}} ## Télécharger en tant qu'élément du SDK Google Cloud @@ -265,14 +265,14 @@ Vous pouvez installer kubectl en tant qu'élément du SDK Google Cloud. ``` gcloud components install kubectl ``` - + 3. Testez pour vous assurer que la version que vous avez installée est à jour: ``` kubectl version ``` -## Vérification de la configuration de kubectl +## Vérification de la configuration de kubectl Pour permettre à kubectl de trouver et d'accéder à un cluster Kubernetes, il lui faut un [fichier kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), qui est créé automatiquement lorsque vous créez un cluster avec `kube-up.sh` ou en déployant un cluster Minikube avec succès. Par défaut, la configuration de kubectl est située sous `~/.kube/config`. @@ -427,7 +427,7 @@ compinit {{% capture whatsnext %}} * [Installer Minikube](/docs/tasks/tools/install-minikube/) -* Voir les [guides de démarrage](/fr/docs/setup/) pour plus d'informations sur la création de clusters. +* Voir les [guides de démarrage](/fr/docs/setup/) pour plus d'informations sur la création de clusters. * [Apprenez comment lancer et exposer votre application](/docs/tasks/access-application-cluster/service-access-application-cluster/) * Si vous avez besoin d'accéder à un cluster que vous n'avez pas créé, consultez [Partager l'accès du Cluster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). * Consulter les [documents de référence de kubectl](/fr/docs/reference/kubectl/kubectl/) diff --git a/content/fr/docs/tasks/tools/install-minikube.md b/content/fr/docs/tasks/tools/install-minikube.md index 5c04271011cd5..ae9f6ab54adb4 100644 --- a/content/fr/docs/tasks/tools/install-minikube.md +++ b/content/fr/docs/tasks/tools/install-minikube.md @@ -15,7 +15,7 @@ Cette page vous montre comment installer [Minikube](/fr/docs/tutorials/hello-min {{% capture prerequisites %}} -La virtualisation VT-x ou AMD-v doit être activée dans le BIOS de votre machine. +La virtualisation VT-x ou AMD-v doit être activée dans le BIOS de votre machine. {{< tabs name="minikube_before_you_begin" >}} {{% tab name="Linux" %}} @@ -32,7 +32,7 @@ sysctl -a | grep machdep.cpu.features Si vous trouvez `VMX` dans la sortie, la fonction VT-x est supportée sur votre OS. {{% /tab %}} {{% tab name="Windows" %}} -Pour vérifier si la virtualisation est prise en charge sur Windows 8 et au-delà, exécutez la commande suivante sur votre terminal Windows ou à l'invite de commande. +Pour vérifier si la virtualisation est prise en charge sur Windows 8 et au-delà, exécutez la commande suivante sur votre terminal Windows ou à l'invite de commande. ``` systeminfo ``` diff --git a/content/fr/docs/tutorials/hello-minikube.md b/content/fr/docs/tutorials/hello-minikube.md index 294452c9379ca..c693d30e494f1 100644 --- a/content/fr/docs/tutorials/hello-minikube.md +++ b/content/fr/docs/tutorials/hello-minikube.md @@ -9,7 +9,7 @@ menu: weight: 10 post: >

Prêt à mettre les mains dans le cambouis ? Créez un cluster Kubernetes simple qui exécute "Hello World" avec Node.js.

>. -card: +card: name: tutorials weight: 10 ---