whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Yushiro FURUKAWA
2019-10-10 18:02:53 +09:00
committed by Kubernetes Prow Robot
parent 3b10c76ca7
commit 2a120450eb
45 changed files with 412 additions and 412 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/fr/docs/reference/glossary/contributor.md
+1 -1
View File
@@ -14,4 +14,4 @@ Quelqu'un qui code, documente ou donne de son temps autrement, pour aider le pro
<!--more-->
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é.
content/fr/docs/reference/glossary/etcd.md
+3 -3
View File
@@ -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.
<!--more-->
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.
content/fr/docs/reference/glossary/init-container.md
+1 -1
View File
@@ -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.
<!--more-->
content/fr/docs/reference/glossary/kube-apiserver.md
+2 -2
View File
@@ -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.
<!--more-->
<!--more-->
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/).
content/fr/docs/reference/glossary/kube-controller-manager.md
+3 -3
View File
@@ -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" >}}.
<!--more-->
<!--more-->
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.
content/fr/docs/reference/glossary/kube-proxy.md
+3 -3
View File
@@ -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">}}.
<!--more-->
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.
content/fr/docs/reference/glossary/kube-scheduler.md
+2 -2
View File
@@ -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.
<!--more-->
<!--more-->
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.
content/fr/docs/reference/kubectl/cheatsheet.md
+2 -2
View File
@@ -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" } }]'
```
content/fr/docs/reference/kubectl/overview.md
+5 -5
View File
@@ -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 <nom-pod>
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 }}'
```
content/fr/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md
+1 -1
View File
@@ -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
content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+23 -23
View File
@@ -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=<list-des-erreurs>`.
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 %}}
content/fr/docs/reference/setup-tools/kubeadm/kubeadm.md
+1 -1
View File
@@ -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é