From e345e849b1baffbbaca25d39c9d4fa2fd4ade3f1 Mon Sep 17 00:00:00 2001
From: Cheikhrouhou ines
Date: Fri, 20 Dec 2019 18:14:28 +0100
Subject: [PATCH 001/440] translate pull image to fr
---
.../pull-image-private-registry.md | 209 ++++++++++++++++++
content/fr/examples/pods/private-reg-pod.yaml | 11 +
2 files changed, 220 insertions(+)
create mode 100644 content/fr/docs/tasks/configure-pod-container/pull-image-private-registry.md
create mode 100644 content/fr/examples/pods/private-reg-pod.yaml
diff --git a/content/fr/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/fr/docs/tasks/configure-pod-container/pull-image-private-registry.md
new file mode 100644
index 0000000000..2dde7d3bd1
--- /dev/null
+++ b/content/fr/docs/tasks/configure-pod-container/pull-image-private-registry.md
@@ -0,0 +1,209 @@
+---
+title: Extraction d'une image d'un registre privé
+content_template: templates/task
+weight: 100
+---
+
+{{% capture overview %}}
+
+Cette page montre comment créer un Pod qui utilise un Secret pour extraire une image d'un
+dépôt ou registre privé de Docker.
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+* Pour faire cet exercice, vous avez besoin d'un
+[Docker ID](https://docs.docker.com/docker-id/) et un mot de passe.
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## Connectez-vous à Docker
+
+Sur votre ordinateur portable, vous devez vous authentifier à un registre afin de récupérer une image privée :
+
+```shell
+docker login
+```
+
+Une fois que c'est fait, entrez votre nom d'utilisateur et votre mot de passe Docker.
+
+Le processus de connexion crée ou met à jour un fichier `config.json` qui contient un token d'autorisation.
+
+Consultez le fichier `config.json` :
+
+```shell
+cat ~/.docker/config.json
+```
+
+La sortie comporte une section similaire à celle-ci :
+
+```json
+{
+ "auths": {
+ "https://index.docker.io/v1/": {
+ "auth": "c3R...zE2"
+ }
+ }
+}
+```
+
+{{< note >}}
+Si vous utilisez le credentials store de Docker, vous ne verrez pas cette entrée `auth` mais une entrée `credsStore` avec le nom du Store comme valeur.
+{{< /note >}}
+
+## Créez un Secret basé sur les identifiants existants du Docker {#registry-secret-existing-credentials}
+
+Le cluster Kubernetes utilise le type Secret de `docker-registry` pour s'authentifier avec
+un registre de conteneurs pour en tirer une image privée.
+
+Si vous avez déjà lancé `docker login`, vous pouvez copier ces identifiants dans Kubernetes
+
+```shell
+kubectl create secret generic regcred \
+ --from-file=.dockerconfigjson= \
+ --type=kubernetes.io/dockerconfigjson
+```
+
+Si vous avez besoin de plus de contrôle (par exemple, pour définir un Namespace ou une étiquette sur le nouveau secret), vous pouvez alors personnaliser le secret avant de le stocker.
+Assurez-vous de :
+
+- Attribuer la valeur `.dockerconfigjson` dans le nom de l'élément data
+- Encoder le fichier docker en base64 et colle cette chaîne, non interrompue, comme valeur du champ `data[".dockerconfigjson"]`.
+- Mettre `type` à `kubernetes.io/dockerconfigjson`.
+
+Exemple:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ name: myregistrykey
+ namespace: awesomeapps
+data:
+ .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
+type: kubernetes.io/dockerconfigjson
+```
+
+Si vous obtenez le message d'erreur `error: no objects passed to create`, cela peut signifier que la chaîne encodée en base64 est invalide.
+Si vous obtenez un message d'erreur comme `Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`, cela signifie que la chaîne encodée en base64 a été décodée avec succès, mais n'a pas pu être interprétée comme un fichier `.docker/config.json`.
+
+## Créez un Secret en fournissant les identifiants sur la ligne de commande
+
+Créez ce secret, en le nommant `regcred` :
+
+```shell
+kubectl create secret docker-registry regcred --docker-server= --docker-username= --docker-password= --docker-email=
+```
+
+où :
+
+* `` est votre FQDN de registre de docker privé. (https://index.docker.io/v1/ for DockerHub)
+* `` est votre nom d'utilisateur Docker.
+* `` est votre mot de passe Docker.
+* `` est votre email Docker.
+
+Vous avez réussi à définir vos identifiants Docker dans le cluster comme un secret appelé `regcred`.
+
+{{< note >}}
+Saisir des secrets sur la ligne de commande peut les conserver dans l'historique de votre shell sans protection, et ces secrets peuvent également être visibles par d'autres utilisateurs sur votre PC pendant le temps que `Kubectl` est en cours d'exécution.
+{{< /note >}}
+
+
+## Inspection du secret `regcred`
+
+Pour comprendre le contenu du Secret `regcred` que vous venez de créer, commencez par visualiser le Secret au format YAML :
+
+```shell
+kubectl get secret regcred --output=yaml
+```
+
+La sortie est similaire à celle-ci :
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ ...
+ name: regcred
+ ...
+data:
+ .dockerconfigjson: eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0=
+type: kubernetes.io/dockerconfigjson
+```
+
+La valeur du champ `.dockerconfigjson` est une représentation en base64 de vos identifiants Docker.
+
+Pour comprendre ce que contient le champ `.dockerconfigjson`, convertissez les données secrètes en un format lisible :
+
+```shell
+kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode
+```
+
+La sortie est similaire à celle-ci :
+
+```json
+{"auths":{"your.private.registry.example.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}}
+```
+
+Pour comprendre ce qui se cache dans le champ `auth', convertissez les données encodées en base64 dans un format lisible :
+
+```shell
+echo "c3R...zE2" | base64 --decode
+```
+
+La sortie en tant que nom d'utilisateur et mot de passe concaténés avec un `:`, est similaire à ceci :
+
+```none
+janedoe:xxxxxxxxxxx
+```
+
+Remarquez que les données Secrètes contiennent le token d'autorisation similaire à votre fichier local `~/.docker/config.json`.
+
+Vous avez réussi à définir vos identifiants de Docker comme un Secret appelé `regcred` dans le cluster.
+
+## Créez un Pod qui utilise votre Secret
+
+Voici un fichier de configuration pour un Pod qui a besoin d'accéder à vos identifiants Docker dans `regcred` :
+
+{{< codenew file="pods/private-reg-pod.yaml" >}}
+
+Téléchargez le fichier ci-dessus :
+
+```shell
+wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml
+```
+
+Dans le fichier `my-private-reg-pod.yaml`, remplacez `` par le chemin d'accès à une image dans un registre privé tel que
+
+```none
+your.private.registry.example.com/janedoe/jdoe-private:v1
+```
+
+Pour extraire l'image du registre privé, Kubernetes a besoin des identifiants.
+Le champ `imagePullSecrets` dans le fichier de configuration spécifie que Kubernetes doit obtenir les informations d'identification d'un Secret nommé `regcred`.
+
+Créez un Pod qui utilise votre secret et vérifiez que le Pod est bien lancé :
+
+```shell
+kubectl apply -f my-private-reg-pod.yaml
+kubectl get pod private-reg
+```
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* Pour en savoir plus sur [Secrets](/docs/concepts/configuration/secret/).
+* Pour en savoir plus sur [en utilisant un registre privé](/docs/concepts/containers/images/#using-a-private-registry).
+* Pour en savoir plus sur [ajouter l' imagePullSecrets à un compte de service](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account).
+* Voir [kubectl crée un Secret de registre de docker](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-).
+* Voir [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core).
+* Voir le champ `imagePullSecrets` de [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
+
+{{% /capture %}}
+
diff --git a/content/fr/examples/pods/private-reg-pod.yaml b/content/fr/examples/pods/private-reg-pod.yaml
new file mode 100644
index 0000000000..4029588dd0
--- /dev/null
+++ b/content/fr/examples/pods/private-reg-pod.yaml
@@ -0,0 +1,11 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: private-reg
+spec:
+ containers:
+ - name: private-reg-container
+ image:
+ imagePullSecrets:
+ - name: regcred
+
From 2dfbdc2cd85094ceb8524089980d3a6f0e7e1c54 Mon Sep 17 00:00:00 2001
From: Maksym Vlasov
Date: Mon, 13 Jan 2020 18:51:38 +0200
Subject: [PATCH 002/440] Initial commit for Ukrainian localization (#18569)
* Initial commit for Ukrainian localization
* Fix misspell and crosslink
* Add Nikita Potapenko to PR reviewers
https://github.com/kubernetes/website/pull/18569#issuecomment-573014402
Co-authored-by: Anastasiya Kulyk <56824659+anastyakulyk@users.noreply.github.com>
---
OWNERS_ALIASES | 8 ++++++
README-uk.md | 71 +++++++++++++++++++++++++++++++++++++++++++++++
README.md | 2 +-
config.toml | 11 ++++++++
content/uk/OWNERS | 13 +++++++++
5 files changed, 104 insertions(+), 1 deletion(-)
create mode 100644 README-uk.md
create mode 100644 content/uk/OWNERS
diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES
index b6d0cfcd45..0e6ba8684a 100644
--- a/OWNERS_ALIASES
+++ b/OWNERS_ALIASES
@@ -216,3 +216,11 @@ aliases:
- aisonaku
- potapy4
- dianaabv
+ sig-docs-uk-owners: # Admins for Ukrainian content
+ - anastyakulyk
+ - MaxymVlasov
+ sig-docs-uk-reviews: # PR reviews for Ukrainian content
+ - anastyakulyk
+ - idvoretskyi
+ - MaxymVlasov
+ - Potapy4
diff --git a/README-uk.md b/README-uk.md
new file mode 100644
index 0000000000..68d3b0db0a
--- /dev/null
+++ b/README-uk.md
@@ -0,0 +1,71 @@
+# Документація Kubernetes
+
+[](https://travis-ci.org/kubernetes/website)
+[](https://github.com/kubernetes/website/releases/latest)
+
+Вітаємо! В цьому репозиторії міститься все необхідне для роботи над [вебсайтом і документацією Kubernetes](https://kubernetes.io/). Ми щасливі, що ви хочете зробити свій внесок!
+
+## Внесок у документацію
+
+Ви можете створити копію цього репозиторія у своєму акаунті на GitHub, натиснувши на кнопку **Fork**, що розташована справа зверху. Ця копія називатиметься *fork* (відгалуження). Зробіть будь-які необхідні зміни у своєму відгалуженні. Коли ви будете готові надіслати їх нам, перейдіть до свого відгалуження і створіть новий pull request, щоб сповістити нас.
+
+Після того, як ви створили pull request, рецензент Kubernetes зобов’язується надати вам по ньому чіткий і конструктивний коментар. **Ваш обов’язок як творця pull request - відкоригувати його відповідно до зауважень рецензента Kubernetes.** Також, зауважте: може статися так, що ви отримаєте коментарі від декількох рецензентів Kubernetes або від іншого рецензента, ніж той, якого вам було призначено від початку. Крім того, за потреби один із ваших рецензентів може запросити технічну перевірку від одного з [технічних рецензентів Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers). Рецензенти намагатимуться відреагувати вчасно, проте час відповіді може відрізнятися в залежності від обставин.
+
+Більше інформації про внесок у документацію Kubernetes ви знайдете у наступних джерелах:
+
+* [Внесок: з чого почати](https://kubernetes.io/docs/contribute/start/)
+* [Візуалізація запропонованих змін до документації](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Використання шаблонів сторінок](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Керівництво зі стилю оформлення документації](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Переклад документації Kubernetes іншими мовами](https://kubernetes.io/docs/contribute/localization/)
+
+## Запуск сайту локально за допомогою Docker
+
+Для локального запуску вебсайту Kubernetes рекомендовано запустити спеціальний [Docker](https://docker.com)-образ, що містить генератор статичних сайтів [Hugo](https://gohugo.io).
+
+> Якщо ви працюєте під Windows, вам знадобиться ще декілька інструментів, які можна встановити за допомогою [Chocolatey](https://chocolatey.org). `choco install make`
+
+> Якщо ви вважаєте кращим запустити вебсайт локально без використання Docker, дивіться пункт нижче [Запуск сайту локально за допомогою Hugo](#запуск-сайту-локально-зa-допомогою-hugo).
+
+Якщо у вас вже [запущений](https://www.docker.com/get-started) Docker, зберіть локальний Docker-образ `kubernetes-hugo`:
+
+```bash
+make docker-image
+```
+
+Після того, як образ зібрано, ви можете запустити вебсайт локально:
+
+```bash
+make docker-serve
+```
+
+Відкрийте у своєму браузері http://localhost:1313, щоб побачити вебсайт. По мірі того, як ви змінюєте початковий код, Hugo актуалізує вебсайт відповідно до внесених змін і оновлює сторінку у браузері.
+
+## Запуск сайту локально зa допомогою Hugo
+
+Для інструкцій по установці Hugo дивіться [офіційну документацію](https://gohugo.io/getting-started/installing/). Обов’язково встановіть розширену версію Hugo, яка позначена змінною оточення `HUGO_VERSION` у файлі [`netlify.toml`](netlify.toml#L9).
+
+Після установки Hugo запустіть вебсайт локально командою:
+
+```bash
+make serve
+```
+
+Команда запустить локальний Hugo-сервер на порту 1313. Відкрийте у своєму браузері http://localhost:1313, щоб побачити вебсайт. По мірі того, як ви змінюєте початковий код, Hugo актуалізує вебсайт відповідно до внесених змін і оновлює сторінку у браузері.
+
+## Спільнота, обговорення, внесок і підтримка
+
+Дізнайтеся, як долучитися до спільноти Kubernetes на [сторінці спільноти](http://kubernetes.io/community/).
+
+Для зв’язку із супроводжуючими проекту скористайтеся:
+
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Поштова розсилка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+### Кодекс поведінки
+
+Участь у спільноті Kubernetes визначається правилами [Кодексу поведінки спільноти Kubernetes](code-of-conduct.md).
+
+## Дякуємо!
+
+Долучення до спільноти - запорука успішного розвитку Kubernetes. Ми цінуємо ваш внесок у наш вебсайт і документацію!
diff --git a/README.md b/README.md
index f403f9e9de..02919f3136 100644
--- a/README.md
+++ b/README.md
@@ -27,7 +27,7 @@ For more information about contributing to the Kubernetes documentation, see:
|[Hindi README](README-hi.md)|[Spanish README](README-es.md)|
|[Indonesian README](README-id.md)|[Chinese README](README-zh.md)|
|[Japanese README](README-ja.md)|[Vietnamese README](README-vi.md)|
-|[Russian README](README-ru.md)|
+|[Russian README](README-ru.md)|[Ukrainian README](README-uk.md)
|||
## Running the website locally using Docker
diff --git a/config.toml b/config.toml
index 990392d659..399cb38e68 100644
--- a/config.toml
+++ b/config.toml
@@ -286,3 +286,14 @@ time_format_blog = "02.01.2006"
# A list of language codes to look for untranslated content, ordered from left to right.
language_alternatives = ["en"]
+[languages.uk]
+title = "Kubernetes"
+description = "Довершена система оркестрації контейнерів"
+languageName = "Українська"
+weight = 13
+contentDir = "content/uk"
+
+[languages.uk.params]
+time_format_blog = "02.01.2006"
+# A list of language codes to look for untranslated content, ordered from left to right.
+language_alternatives = ["en"]
diff --git a/content/uk/OWNERS b/content/uk/OWNERS
new file mode 100644
index 0000000000..09fbf1170c
--- /dev/null
+++ b/content/uk/OWNERS
@@ -0,0 +1,13 @@
+# See the OWNERS docs at https://go.k8s.io/owners
+
+# This is the directory for Ukrainian source content.
+# Teams and members are visible at https://github.com/orgs/kubernetes/teams.
+
+reviewers:
+- sig-docs-uk-reviews
+
+approvers:
+- sig-docs-uk-owners
+
+labels:
+- language/uk
From 1a5d5e4630cd13e653c070bf10e5efb59241a119 Mon Sep 17 00:00:00 2001
From: steadysupply
Date: Fri, 31 Jan 2020 12:20:17 +0000
Subject: [PATCH 003/440] Update _desktop.sass
---
assets/sass/_desktop.sass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/assets/sass/_desktop.sass b/assets/sass/_desktop.sass
index cc75a377d7..b3dd9ca7cb 100644
--- a/assets/sass/_desktop.sass
+++ b/assets/sass/_desktop.sass
@@ -2,7 +2,7 @@ $main-max-width: 1200px
$vendor-strip-height: 44px
$video-section-height: 550px
-@media screen and (min-width: 1025px)
+@media screen and (min-width: 1100px)
#hamburger
display: none
From dfd00c180e6222c49b5d75963647fbb6aed2018e Mon Sep 17 00:00:00 2001
From: Tim Bannister
Date: Sun, 8 Dec 2019 20:08:01 +0000
Subject: [PATCH 004/440] Fix whitespace
The Kubernetes object is called ReplicationController.
---
content/ko/docs/reference/glossary/replication-controller.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ko/docs/reference/glossary/replication-controller.md b/content/ko/docs/reference/glossary/replication-controller.md
index f5c19a33aa..2bcf7aefab 100755
--- a/content/ko/docs/reference/glossary/replication-controller.md
+++ b/content/ko/docs/reference/glossary/replication-controller.md
@@ -1,5 +1,5 @@
---
-title: 레플리케이션 컨트롤러(Replication Controller)
+title: 레플리케이션 컨트롤러(ReplicationController)
id: replication-controller
date: 2018-04-12
full_link:
From 7bd5562d2b1aaf1adea48585c154741ababe4072 Mon Sep 17 00:00:00 2001
From: MaxymVlasov
Date: Wed, 5 Feb 2020 14:53:39 +0200
Subject: [PATCH 005/440] Fix merge conflict resolution mistake
---
config.toml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/config.toml b/config.toml
index be61230816..5c0328ec9e 100644
--- a/config.toml
+++ b/config.toml
@@ -295,6 +295,9 @@ contentDir = "content/pl"
[languages.pl.params]
time_format_blog = "01.02.2006"
+# A list of language codes to look for untranslated content, ordered from left to right.
+language_alternatives = ["en"]
+
[languages.uk]
title = "Kubernetes"
description = "Довершена система оркестрації контейнерів"
From 828574cac237f36e95f9bdda5103fc65e1797828 Mon Sep 17 00:00:00 2001
From: Tim Bannister
Date: Thu, 9 Jan 2020 00:48:38 +0000
Subject: [PATCH 006/440] Reword percentageOfNodesToScore page
---
.../scheduling/scheduler-perf-tuning.md | 121 ++++++++++++------
1 file changed, 82 insertions(+), 39 deletions(-)
diff --git a/content/en/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/en/docs/concepts/scheduling/scheduler-perf-tuning.md
index 24ebe059e6..cfa5a4521c 100644
--- a/content/en/docs/concepts/scheduling/scheduler-perf-tuning.md
+++ b/content/en/docs/concepts/scheduling/scheduler-perf-tuning.md
@@ -28,23 +28,67 @@ large Kubernetes clusters.
{{% capture body %}}
-## Percentage of Nodes to Score
+In large clusters, you can tune the scheduler's behaviour balancing
+scheduling outcomes between latency (new Pods are placed quickly) and
+accuracy (the scheduler rarely makes poor placement decisions).
-Before Kubernetes 1.12, Kube-scheduler used to check the feasibility of all
-nodes in a cluster and then scored the feasible ones. Kubernetes 1.12 added a
-new feature that allows the scheduler to stop looking for more feasible nodes
-once it finds a certain number of them. This improves the scheduler's
-performance in large clusters. The number is specified as a percentage of the
-cluster size. The percentage can be controlled by a configuration option called
-`percentageOfNodesToScore`. The range should be between 1 and 100. Larger values
-are considered as 100%. Zero is equivalent to not providing the config option.
-Kubernetes 1.14 has logic to find the percentage of nodes to score based on the
-size of the cluster if it is not specified in the configuration. It uses a
-linear formula which yields 50% for a 100-node cluster. The formula yields 10%
-for a 5000-node cluster. The lower bound for the automatic value is 5%. In other
-words, the scheduler always scores at least 5% of the cluster no matter how
-large the cluster is, unless the user provides the config option with a value
-smaller than 5.
+You configure this tuning setting via kube-scheduler setting
+`percentageOfNodesToScore`. This KubeSchedulerConfiguration setting determines
+a threshold for scheduling nodes in your cluster.
+
+### Setting the threshold
+
+The `percentageOfNodesToScore` option accepts whole numeric values between 0
+and 100. The value 0 is a special number which indicates that the kube-scheduler
+should use its compiled-in default.
+If you set `percentageOfNodesToScore` above 100, kube-scheduler acts as if you
+had set a value of 100.
+
+To change the value, edit the kube-scheduler configuration file (this is likely
+to be `/etc/kubernetes/config/kube-scheduler.yaml`), then restart the scheduler.
+
+After you have made this change, you can run
+```bash
+kubectl get componentstatuses
+```
+to verify that the kube-scheduler component is healthy. The output is similar to:
+```
+NAME STATUS MESSAGE ERROR
+controller-manager Healthy ok
+scheduler Healthy ok
+...
+```
+
+## Node scoring threshold {#percentage-of-nodes-to-score}
+
+To improve scheduling performance, the kube-scheduler can stop looking for
+feasible nodes once it has found enough of them. In large clusters, this saves
+time compared to a naive approach that would consider every node.
+
+You specify a threshold for how many nodes are enough, as a whole number percentage
+of all the nodes in your cluster. The kube-scheduler converts this into an
+integer number of nodes. During scheduling, if the kube-scheduler has identified
+enough feasible nodes to exceed the configured percentage, the kube-scheduler
+stops searching for more feasible nodes and moves on to the
+[scoring phase](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation).
+
+[How the scheduler iterates over Nodes](#how-the-scheduler-iterates-over-nodes)
+describes the process in detail.
+
+### Default threshold
+
+If you don't specify a threshold, Kubernetes calculates a figure using a
+linear formula that yields 50% for a 100-node cluster and yields 10%
+for a 5000-node cluster. The lower bound for the automatic value is 5%.
+
+This means that, the kube-scheduler always scores at least 5% of your cluster no
+matter how large the cluster is, unless you have explicitly set
+`percentageOfNodesToScore` to be smaller than 5.
+
+If you want the scheduler to score all nodes in your cluster, set
+`percentageOfNodesToScore` to 100.
+
+## Example
Below is an example configuration that sets `percentageOfNodesToScore` to 50%.
@@ -59,39 +103,38 @@ algorithmSource:
percentageOfNodesToScore: 50
```
-{{< note >}} In clusters with less than 50 feasible nodes, the scheduler still
-checks all the nodes, simply because there are not enough feasible nodes to stop
-the scheduler's search early. {{< /note >}}
-**To disable this feature**, you can set `percentageOfNodesToScore` to 100.
-
-### Tuning percentageOfNodesToScore
+## Tuning percentageOfNodesToScore
`percentageOfNodesToScore` must be a value between 1 and 100 with the default
value being calculated based on the cluster size. There is also a hardcoded
-minimum value of 50 nodes. This means that changing
-this option to lower values in clusters with several hundred nodes will not have
-much impact on the number of feasible nodes that the scheduler tries to find.
-This is intentional as this option is unlikely to improve performance noticeably
-in smaller clusters. In large clusters with over a 1000 nodes setting this value
-to lower numbers may show a noticeable performance improvement.
+minimum value of 50 nodes.
-An important note to consider when setting this value is that when a smaller
+{{< note >}}In clusters with less than 50 feasible nodes, the scheduler still
+checks all the nodes, simply because there are not enough feasible nodes to stop
+the scheduler's search early.
+
+In a small cluster, if you set a low value for `percentageOfNodesToScore`, your
+change will have no or little effect, for a similar reason.
+
+If your cluster has several hundred Nodes or fewer, leave this configuration option
+at its default value. Making changes is unlikely to improve the
+scheduler's performance significantly.
+{{< /note >}}
+
+An important detail to consider when setting this value is that when a smaller
number of nodes in a cluster are checked for feasibility, some nodes are not
sent to be scored for a given Pod. As a result, a Node which could possibly
score a higher value for running the given Pod might not even be passed to the
-scoring phase. This would result in a less than ideal placement of the Pod. For
-this reason, the value should not be set to very low percentages. A general rule
-of thumb is to never set the value to anything lower than 10. Lower values
-should be used only when the scheduler's throughput is critical for your
-application and the score of nodes is not important. In other words, you prefer
-to run the Pod on any Node as long as it is feasible.
+scoring phase. This would result in a less than ideal placement of the Pod.
-If your cluster has several hundred Nodes or fewer, we do not recommend lowering
-the default value of this configuration option. It is unlikely to improve the
-scheduler's performance significantly.
+You should avoid setting `percentageOfNodesToScore` very low so that kube-scheduler
+does not make frequent, poor Pod placement decisions. Avoid setting the
+percentage to anything below 10%, unless the scheduler's throughput is critical
+for your application and the score of nodes is not important. In other words, you
+prefer to run the Pod on any Node as long as it is feasible.
-### How the scheduler iterates over Nodes
+## How the scheduler iterates over Nodes
This section is intended for those who want to understand the internal details
of this feature.
From 9142d896305b4f7e200ab5c58ab0dc3e8bf41475 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?R=C3=A9my=20L=C3=A9one?=
Date: Thu, 27 Feb 2020 15:54:19 +0100
Subject: [PATCH 007/440] Add a logo information about Kubernetes
---
layouts/partials/head.html | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/layouts/partials/head.html b/layouts/partials/head.html
index e710c60af7..1e34c3c903 100644
--- a/layouts/partials/head.html
+++ b/layouts/partials/head.html
@@ -11,6 +11,14 @@
{{ if .Title }}{{ .Title }} - {{ end }}{{ site.Title }}
+
From 93a23a1bf4b7749bd7049f6081de1dff399b7178 Mon Sep 17 00:00:00 2001
From: Brent Klein
Date: Thu, 27 Feb 2020 13:50:15 -0500
Subject: [PATCH 008/440] Updated Deployment description for clarity.
---
.../tutorials/kubernetes-basics/deploy-app/deploy-intro.html | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
index 8f38960de7..af2d5eeed2 100644
--- a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
+++ b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
@@ -31,7 +31,8 @@ weight: 10
Once you have a running Kubernetes cluster, you can deploy your containerized applications on top of it.
To do so, you create a Kubernetes Deployment configuration. The Deployment instructs Kubernetes
how to create and update instances of your application. Once you've created a Deployment, the Kubernetes
- master schedules mentioned application instances onto individual Nodes in the cluster.
+ master schedules the application instances included in that Deployment to run on individual Nodes in the
+ cluster.
Once the application instances are created, a Kubernetes Deployment Controller continuously monitors those instances. If the Node hosting an instance goes down or is deleted, the Deployment controller replaces the instance with an instance on another Node in the cluster. This provides a self-healing mechanism to address machine failure or maintenance.
From 2e8eb9bd4f906fdd9435476b359395a4ccb5d8d0 Mon Sep 17 00:00:00 2001
From: Harrison Razanajatovo
Date: Fri, 28 Feb 2020 09:26:54 -0500
Subject: [PATCH 009/440] Added endpoint-slices for language/fr
---
.../services-networking/endpoint-slices.md | 111 ++++++++++++++++++
1 file changed, 111 insertions(+)
create mode 100644 content/fr/docs/concepts/services-networking/endpoint-slices.md
diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md
new file mode 100644
index 0000000000..47f076d11b
--- /dev/null
+++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md
@@ -0,0 +1,111 @@
+---
+reviewers:
+title: EndpointSlices
+feature:
+ title: EndpointSlices
+ description: >
+ Scalable tracking of network endpoints in a Kubernetes cluster.
+
+content_template: templates/concept
+weight: 10
+---
+
+
+{{% capture overview %}}
+
+{{< feature-state for_k8s_version="v1.17" state="beta" >}}
+
+_EndpointSlices_ offrent une simple methode pour suivre les endpoints d'un réseau au sein d'un cluster de Kubernetes. Ils offrent une alternative plus evolutive et extensible aux Endpoints.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Resource pour EndpointSlice {#endpointslice-resource}
+
+Dans Kubernetes, un EndpointSlice contient des reférences à un ensemble de reseau
+endpoints. Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Kubernetes Service quand un {{< glossary_tooltip text="selector" term_id="selector" >}} est spécifié. Ces EnpointSlices vont inclure des references a n'importe quelle Pods qui correspond aux Service selector. EndpointSlices groupent ensemble les endpoints d'un reseau par combinaisons uniques de Services et de Ports.
+
+Par example, voici un échantillon d'une resource EndpointSlice pour le Kubernetes Service `example`.
+
+```yaml
+apiVersion: discovery.k8s.io/v1beta1
+kind: EndpointSlice
+metadata:
+ name: example-abc
+ labels:
+ kubernetes.io/service-name: example
+addressType: IPv4
+ports:
+ - name: http
+ protocol: TCP
+ port: 80
+endpoints:
+ - addresses:
+ - "10.1.2.3"
+ conditions:
+ ready: true
+ hostname: pod-1
+ topology:
+ kubernetes.io/hostname: node-1
+ topology.kubernetes.io/zone: us-west2-a
+```
+
+EndpointSlices geré par le controleur d'EndpointSlice n'auront, par défaut, pas plus de 100 endpoints chacun. En dessous de cette échelle, EndpointSlices devrait mapper 1:1 les Endpoints et les Service et devrait avoir une performance similaire.
+
+EnpointpointSlices peuvent agir en tant que source de vérité pour kube-proxy quand it s'agit du routage d'un trafic interne. Lorsqu'ils sont activés, ils devront une amélioration de performance pour les services qui ont une grand quantité d'endpoints.
+
+### Types d'addresses
+
+EndpointSlices supporte trois type d'addresses:
+
+* IPv4
+* IPv6
+* FQDN (Fully Qualified Domain Name) - [serveur entièrement nommé]
+
+### Topologie
+
+Chaque endpoint dans un EnpointSlice peut contenir des informations de topologie pertinentes.
+Ceci est utilisé pour indiqué où se trouve un endpoint, qui contient les informations sur le Noeud, zone et region correspondant. Lorsque les valeurs sont disponibles, les etiquette de Topologies suivantes seront définies par le contrôleur EndpointSlice:
+
+* `kubernetes.io/hostname` - Nom du Noeud sur lequel l'endpoint se situe.
+* `topology.kubernetes.io/zone` - Zone dans laquelle l'endpoint se situe.
+* `topology.kubernetes.io/region` - Region dans laquelle l'endpoint se situe.
+
+Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que les correspondantes EndpointSlices sont mis-à-jour. Le contrôleur gèrera les EndpointSlices pour tout les Services qui ont un selecteur - [reference: {{< glossary_tooltip text="selector" term_id="selector" >}}] - specifié. Celles-ci representeront les IPs des Pods qui correspond au selecteur.
+
+### Capacité d'EndpointSlices
+
+Les EndpointSlices sont limité a une capacité de 100 endpoints chacun, par defaut. Vous pouvez configurer ceci avec le `--max-endpoints-per-slice` {{< glossary_tooltip
+text="kube-controller-manager" term_id="kube-controller-manager" >}} flag [indicateur] jusqu'à un maximum de 1000.
+
+### Distribution d'EndpointSlices
+
+Chaque EndpointSlice a un ensemble de ports qui s'applique à toutes les endpoints dans la resource. Lorsque les ports nommés sont utilisé pour un Service, les Pods peuvent se retrouver avec differents port cible pour le même port nommé, nécessitant différents EndpointSlices.
+
+Le contrôlleur essait de remplir l'EndpointSlice aussi complètement que possible, mais ne les rééquilibrent pas activement. La logic du contrôlleur est assez simple:
+
+1. Itérer à travers les EnpointSlices existantes, retirer les endpoint qui ne sont plus voulues et mettre à jour les endpoints qui ont changées.
+2. Itérer à travers les EndpointSlices qui ont été modifiées dans la première étape et les remplir avec n'importe quelle endpoint nécéssaire.
+3. Si il reste encore des endpoints neuves à ajouter, essayez de les mettre dans une slice qui n'a pas été changé et/ou en crée de nouvelles.
+
+par-dessus tout, la troisème étape priorise la limitation de mises à jour d'EnpointSlice sur une distribution complètement pleine d'EndpointSlices. Par example, si il y avait 10 nouvelles endpoints à ajouter et 2 EndpointSlices qui peuvent accomoder 5 endpoint en plus chacun; cette approche créera une nouvelle EndpointSlice au lieu de remplir les EndpointSlice existantes. C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlice.
+
+Avec kube-proxy exécuté sur chaque Noeud et surveillant EndpointSlices, chaque changement à une EndpointSlice devient relativement coûteux puisqu'ils seront transmit à chaque Noeud du cluster. Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Noeud, même si ça peut entraîner plusieurs EndpointSlices qui ne sont pas plein.
+
+En pratique, cette distribution moins qu'idéale devrait être rare. La plupart des changements traité par le contrôleur EndpointSlice sera suffisamment petit pour tenir dans un EndpointSlice existante, et sinon, une nouvelle EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour continues des déploiements fournissent également un remballage naturel des EndpointSlices avec tout leur pods et les endpoints correspondants qui se feront remplacer.
+
+## Motivation
+
+Les Endpoints API ont fournit une methode simple et facile de suivre les endpoint d'un réseau dans Kubernetes. Malheureusement, comme les clusters Kubernetes et Services sont devenus plus large, les limitations de cette API sont devenues plus visibles. Plus particulièrement, ceux-ci comprenaient des défis liés à la mise à l'échelle vers un plus grand nombre d'endpoint d'un réseau.
+
+Puisque tout les endpoint d'un réseau pour un Service ont été stockés dans un seul ressource Endpoints, ces ressources pourraient devenir assez considérable. Ça a affecté les performances des composants Kubernetes (notamment le plan de contrôle maître) et a donné lieu une grande quantité de trafic réseau et de traitement lorsque les Enpoints changent. EndpointSlices vous aide à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* [Activer EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices)
+* Read [Connecté des Agit stpplication aux Services](/docs/concepts/services-networking/connect-applications-service/)
+
+{{% /capture %}}
\ No newline at end of file
From 86cf63495c48a67c9f9915d7c3e15602bfcc5707 Mon Sep 17 00:00:00 2001
From: Harrison Razanajatovo
Date: Mon, 2 Mar 2020 09:31:05 -0500
Subject: [PATCH 010/440] First round review changes
---
.../services-networking/endpoint-slices.md | 28 +++++++++----------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md
index 47f076d11b..460bc41f25 100644
--- a/content/fr/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md
@@ -4,7 +4,7 @@ title: EndpointSlices
feature:
title: EndpointSlices
description: >
- Scalable tracking of network endpoints in a Kubernetes cluster.
+ Suivi évolutif des points de terminaison réseau dans un cluster Kubernetes.
content_template: templates/concept
weight: 10
@@ -24,17 +24,17 @@ _EndpointSlices_ offrent une simple methode pour suivre les endpoints d'un rése
## Resource pour EndpointSlice {#endpointslice-resource}
Dans Kubernetes, un EndpointSlice contient des reférences à un ensemble de reseau
-endpoints. Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Kubernetes Service quand un {{< glossary_tooltip text="selector" term_id="selector" >}} est spécifié. Ces EnpointSlices vont inclure des references a n'importe quelle Pods qui correspond aux Service selector. EndpointSlices groupent ensemble les endpoints d'un reseau par combinaisons uniques de Services et de Ports.
+endpoints. Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Kubernetes Service quand un {{< glossary_tooltip text="selecteur" term_id="selecteur" >}} est spécifié. Ces EnpointSlices vont inclure des references a n'importe quelle Pods qui correspond aux selecteur de Service. EndpointSlices groupent ensemble les endpoints d'un reseau par combinaisons uniques de Services et de Ports.
-Par example, voici un échantillon d'une resource EndpointSlice pour le Kubernetes Service `example`.
+Par exemple, voici un échantillon d'une resource EndpointSlice pour le Kubernetes Service `exemple`.
```yaml
apiVersion: discovery.k8s.io/v1beta1
kind: EndpointSlice
metadata:
- name: example-abc
+ name: exemple-abc
labels:
- kubernetes.io/service-name: example
+ kubernetes.io/service-name: exemple
addressType: IPv4
ports:
- name: http
@@ -66,18 +66,18 @@ EndpointSlices supporte trois type d'addresses:
### Topologie
Chaque endpoint dans un EnpointSlice peut contenir des informations de topologie pertinentes.
-Ceci est utilisé pour indiqué où se trouve un endpoint, qui contient les informations sur le Noeud, zone et region correspondant. Lorsque les valeurs sont disponibles, les etiquette de Topologies suivantes seront définies par le contrôleur EndpointSlice:
+Ceci est utilisé pour indiqué où se trouve un endpoint, qui contient les informations sur le Node, zone et region correspondant. Lorsque les valeurs sont disponibles, les etiquette de Topologies suivantes seront définies par le contrôleur EndpointSlice:
-* `kubernetes.io/hostname` - Nom du Noeud sur lequel l'endpoint se situe.
+* `kubernetes.io/hostname` - Nom du Node sur lequel l'endpoint se situe.
* `topology.kubernetes.io/zone` - Zone dans laquelle l'endpoint se situe.
* `topology.kubernetes.io/region` - Region dans laquelle l'endpoint se situe.
-Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que les correspondantes EndpointSlices sont mis-à-jour. Le contrôleur gèrera les EndpointSlices pour tout les Services qui ont un selecteur - [reference: {{< glossary_tooltip text="selector" term_id="selector" >}}] - specifié. Celles-ci representeront les IPs des Pods qui correspond au selecteur.
+Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que les correspondantes EndpointSlices sont mis-à-jour. Le contrôleur gèrera les EndpointSlices pour tout les Services qui ont un selecteur - [reference: {{< glossary_tooltip text="selecteur" term_id="selecteur" >}}] - specifié. Celles-ci representeront les IPs des Pods qui correspond au selecteur.
### Capacité d'EndpointSlices
-Les EndpointSlices sont limité a une capacité de 100 endpoints chacun, par defaut. Vous pouvez configurer ceci avec le `--max-endpoints-per-slice` {{< glossary_tooltip
-text="kube-controller-manager" term_id="kube-controller-manager" >}} flag [indicateur] jusqu'à un maximum de 1000.
+Les EndpointSlices sont limité a une capacité de 100 endpoints chacun, par defaut. Vous pouvez configurer ceci avec l'indicateur `--max-endpoints-per-slice` {{< glossary_tooltip
+text="kube-controller-manager" term_id="kube-controller-manager" >}} jusqu'à un maximum de 1000.
### Distribution d'EndpointSlices
@@ -89,9 +89,9 @@ Le contrôlleur essait de remplir l'EndpointSlice aussi complètement que possib
2. Itérer à travers les EndpointSlices qui ont été modifiées dans la première étape et les remplir avec n'importe quelle endpoint nécéssaire.
3. Si il reste encore des endpoints neuves à ajouter, essayez de les mettre dans une slice qui n'a pas été changé et/ou en crée de nouvelles.
-par-dessus tout, la troisème étape priorise la limitation de mises à jour d'EnpointSlice sur une distribution complètement pleine d'EndpointSlices. Par example, si il y avait 10 nouvelles endpoints à ajouter et 2 EndpointSlices qui peuvent accomoder 5 endpoint en plus chacun; cette approche créera une nouvelle EndpointSlice au lieu de remplir les EndpointSlice existantes. C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlice.
+Par-dessus tout, la troisème étape priorise la limitation de mises à jour d'EnpointSlice sur une distribution complètement pleine d'EndpointSlices. Par exemple, si il y avait 10 nouvelles endpoints à ajouter et 2 EndpointSlices qui peuvent accomoder 5 endpoint en plus chacun; cette approche créera une nouvelle EndpointSlice au lieu de remplir les EndpointSlice existantes. C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlice.
-Avec kube-proxy exécuté sur chaque Noeud et surveillant EndpointSlices, chaque changement à une EndpointSlice devient relativement coûteux puisqu'ils seront transmit à chaque Noeud du cluster. Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Noeud, même si ça peut entraîner plusieurs EndpointSlices qui ne sont pas plein.
+Avec kube-proxy exécuté sur chaque Node et surveillant EndpointSlices, chaque changement à une EndpointSlice devient relativement coûteux puisqu'ils seront transmit à chaque Node du cluster. Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Node, même si ça peut entraîner plusieurs EndpointSlices qui ne sont pas plein.
En pratique, cette distribution moins qu'idéale devrait être rare. La plupart des changements traité par le contrôleur EndpointSlice sera suffisamment petit pour tenir dans un EndpointSlice existante, et sinon, une nouvelle EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour continues des déploiements fournissent également un remballage naturel des EndpointSlices avec tout leur pods et les endpoints correspondants qui se feront remplacer.
@@ -99,13 +99,13 @@ En pratique, cette distribution moins qu'idéale devrait être rare. La plupart
Les Endpoints API ont fournit une methode simple et facile de suivre les endpoint d'un réseau dans Kubernetes. Malheureusement, comme les clusters Kubernetes et Services sont devenus plus large, les limitations de cette API sont devenues plus visibles. Plus particulièrement, ceux-ci comprenaient des défis liés à la mise à l'échelle vers un plus grand nombre d'endpoint d'un réseau.
-Puisque tout les endpoint d'un réseau pour un Service ont été stockés dans un seul ressource Endpoints, ces ressources pourraient devenir assez considérable. Ça a affecté les performances des composants Kubernetes (notamment le plan de contrôle maître) et a donné lieu une grande quantité de trafic réseau et de traitement lorsque les Enpoints changent. EndpointSlices vous aide à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique.
+Puisque tout les endpoints d'un réseau pour un Service ont été stockés dans une seule ressource Endpoints, ces ressources pourraient devenir assez considérable. Ça a affecté les performances des composants Kubernetes (notamment le plan de contrôle maître) et a donné lieu à une grande quantité de trafic réseau et de traitement lorsque les Endpoints changent. EndpointSlices vous aide à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique.
{{% /capture %}}
{{% capture whatsnext %}}
* [Activer EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices)
-* Read [Connecté des Agit stpplication aux Services](/docs/concepts/services-networking/connect-applications-service/)
+* Lire [Connecté des Agit stpplication aux Services](/docs/concepts/services-networking/connect-applications-service/)
{{% /capture %}}
\ No newline at end of file
From 2e750fa39e706c26c994c15db6b0e9a3685830d3 Mon Sep 17 00:00:00 2001
From: Harrison Razanajatovo
Date: Mon, 2 Mar 2020 09:31:05 -0500
Subject: [PATCH 011/440] First round review changes
---
.../services-networking/endpoint-slices.md | 26 +++++++++----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md
index 47f076d11b..6798eb2c20 100644
--- a/content/fr/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md
@@ -4,7 +4,7 @@ title: EndpointSlices
feature:
title: EndpointSlices
description: >
- Scalable tracking of network endpoints in a Kubernetes cluster.
+ Suivi évolutif des points de terminaison réseau dans un cluster Kubernetes.
content_template: templates/concept
weight: 10
@@ -24,17 +24,17 @@ _EndpointSlices_ offrent une simple methode pour suivre les endpoints d'un rése
## Resource pour EndpointSlice {#endpointslice-resource}
Dans Kubernetes, un EndpointSlice contient des reférences à un ensemble de reseau
-endpoints. Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Kubernetes Service quand un {{< glossary_tooltip text="selector" term_id="selector" >}} est spécifié. Ces EnpointSlices vont inclure des references a n'importe quelle Pods qui correspond aux Service selector. EndpointSlices groupent ensemble les endpoints d'un reseau par combinaisons uniques de Services et de Ports.
+endpoints. Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Kubernetes Service quand un {{< glossary_tooltip text="selector" term_id="selector" >}} est spécifié. Ces EnpointSlices vont inclure des references a n'importe quelle Pods qui correspond aux selecteur de Service. EndpointSlices groupent ensemble les endpoints d'un reseau par combinaisons uniques de Services et de Ports.
-Par example, voici un échantillon d'une resource EndpointSlice pour le Kubernetes Service `example`.
+Par exemple, voici un échantillon d'une resource EndpointSlice pour le Kubernetes Service `exemple`.
```yaml
apiVersion: discovery.k8s.io/v1beta1
kind: EndpointSlice
metadata:
- name: example-abc
+ name: exemple-abc
labels:
- kubernetes.io/service-name: example
+ kubernetes.io/service-name: exemple
addressType: IPv4
ports:
- name: http
@@ -66,9 +66,9 @@ EndpointSlices supporte trois type d'addresses:
### Topologie
Chaque endpoint dans un EnpointSlice peut contenir des informations de topologie pertinentes.
-Ceci est utilisé pour indiqué où se trouve un endpoint, qui contient les informations sur le Noeud, zone et region correspondant. Lorsque les valeurs sont disponibles, les etiquette de Topologies suivantes seront définies par le contrôleur EndpointSlice:
+Ceci est utilisé pour indiqué où se trouve un endpoint, qui contient les informations sur le Node, zone et region correspondant. Lorsque les valeurs sont disponibles, les etiquette de Topologies suivantes seront définies par le contrôleur EndpointSlice:
-* `kubernetes.io/hostname` - Nom du Noeud sur lequel l'endpoint se situe.
+* `kubernetes.io/hostname` - Nom du Node sur lequel l'endpoint se situe.
* `topology.kubernetes.io/zone` - Zone dans laquelle l'endpoint se situe.
* `topology.kubernetes.io/region` - Region dans laquelle l'endpoint se situe.
@@ -76,8 +76,8 @@ Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que
### Capacité d'EndpointSlices
-Les EndpointSlices sont limité a une capacité de 100 endpoints chacun, par defaut. Vous pouvez configurer ceci avec le `--max-endpoints-per-slice` {{< glossary_tooltip
-text="kube-controller-manager" term_id="kube-controller-manager" >}} flag [indicateur] jusqu'à un maximum de 1000.
+Les EndpointSlices sont limité a une capacité de 100 endpoints chacun, par defaut. Vous pouvez configurer ceci avec l'indicateur `--max-endpoints-per-slice` {{< glossary_tooltip
+text="kube-controller-manager" term_id="kube-controller-manager" >}} jusqu'à un maximum de 1000.
### Distribution d'EndpointSlices
@@ -89,9 +89,9 @@ Le contrôlleur essait de remplir l'EndpointSlice aussi complètement que possib
2. Itérer à travers les EndpointSlices qui ont été modifiées dans la première étape et les remplir avec n'importe quelle endpoint nécéssaire.
3. Si il reste encore des endpoints neuves à ajouter, essayez de les mettre dans une slice qui n'a pas été changé et/ou en crée de nouvelles.
-par-dessus tout, la troisème étape priorise la limitation de mises à jour d'EnpointSlice sur une distribution complètement pleine d'EndpointSlices. Par example, si il y avait 10 nouvelles endpoints à ajouter et 2 EndpointSlices qui peuvent accomoder 5 endpoint en plus chacun; cette approche créera une nouvelle EndpointSlice au lieu de remplir les EndpointSlice existantes. C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlice.
+Par-dessus tout, la troisème étape priorise la limitation de mises à jour d'EnpointSlice sur une distribution complètement pleine d'EndpointSlices. Par exemple, si il y avait 10 nouvelles endpoints à ajouter et 2 EndpointSlices qui peuvent accomoder 5 endpoint en plus chacun; cette approche créera une nouvelle EndpointSlice au lieu de remplir les EndpointSlice existantes. C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlice.
-Avec kube-proxy exécuté sur chaque Noeud et surveillant EndpointSlices, chaque changement à une EndpointSlice devient relativement coûteux puisqu'ils seront transmit à chaque Noeud du cluster. Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Noeud, même si ça peut entraîner plusieurs EndpointSlices qui ne sont pas plein.
+Avec kube-proxy exécuté sur chaque Node et surveillant EndpointSlices, chaque changement à une EndpointSlice devient relativement coûteux puisqu'ils seront transmit à chaque Node du cluster. Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Node, même si ça peut entraîner plusieurs EndpointSlices qui ne sont pas plein.
En pratique, cette distribution moins qu'idéale devrait être rare. La plupart des changements traité par le contrôleur EndpointSlice sera suffisamment petit pour tenir dans un EndpointSlice existante, et sinon, une nouvelle EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour continues des déploiements fournissent également un remballage naturel des EndpointSlices avec tout leur pods et les endpoints correspondants qui se feront remplacer.
@@ -99,13 +99,13 @@ En pratique, cette distribution moins qu'idéale devrait être rare. La plupart
Les Endpoints API ont fournit une methode simple et facile de suivre les endpoint d'un réseau dans Kubernetes. Malheureusement, comme les clusters Kubernetes et Services sont devenus plus large, les limitations de cette API sont devenues plus visibles. Plus particulièrement, ceux-ci comprenaient des défis liés à la mise à l'échelle vers un plus grand nombre d'endpoint d'un réseau.
-Puisque tout les endpoint d'un réseau pour un Service ont été stockés dans un seul ressource Endpoints, ces ressources pourraient devenir assez considérable. Ça a affecté les performances des composants Kubernetes (notamment le plan de contrôle maître) et a donné lieu une grande quantité de trafic réseau et de traitement lorsque les Enpoints changent. EndpointSlices vous aide à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique.
+Puisque tout les endpoints d'un réseau pour un Service ont été stockés dans une seule ressource Endpoints, ces ressources pourraient devenir assez considérable. Ça a affecté les performances des composants Kubernetes (notamment le plan de contrôle maître) et a donné lieu à une grande quantité de trafic réseau et de traitement lorsque les Endpoints changent. EndpointSlices vous aide à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique.
{{% /capture %}}
{{% capture whatsnext %}}
* [Activer EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices)
-* Read [Connecté des Agit stpplication aux Services](/docs/concepts/services-networking/connect-applications-service/)
+* Lire [Connecté des Agit stpplication aux Services](/docs/concepts/services-networking/connect-applications-service/)
{{% /capture %}}
\ No newline at end of file
From 48828fdc4a17ab872d7f3c9ae65c4c09e8934668 Mon Sep 17 00:00:00 2001
From: Harrison Razanajatovo
Date: Mon, 2 Mar 2020 11:39:54 -0500
Subject: [PATCH 012/440] keeping term_id but changing text
---
.../fr/docs/concepts/services-networking/endpoint-slices.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md
index 04a63aa6c8..6992428f57 100644
--- a/content/fr/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md
@@ -24,7 +24,7 @@ _EndpointSlices_ offrent une simple methode pour suivre les endpoints d'un rése
## Resource pour EndpointSlice {#endpointslice-resource}
Dans Kubernetes, un EndpointSlice contient des reférences à un ensemble de reseau
-endpoints. Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Kubernetes Service quand un {{< glossary_tooltip text="selector" term_id="selector" >}} est spécifié. Ces EnpointSlices vont inclure des references a n'importe quelle Pods qui correspond aux selecteur de Service. EndpointSlices groupent ensemble les endpoints d'un reseau par combinaisons uniques de Services et de Ports.
+endpoints. Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Kubernetes Service quand un {{< glossary_tooltip text="selecteur" term_id="selector" >}} est spécifié. Ces EnpointSlices vont inclure des references a n'importe quelle Pods qui correspond aux selecteur de Service. EndpointSlices groupent ensemble les endpoints d'un reseau par combinaisons uniques de Services et de Ports.
Par exemple, voici un échantillon d'une resource EndpointSlice pour le Kubernetes Service `exemple`.
@@ -72,7 +72,7 @@ Ceci est utilisé pour indiqué où se trouve un endpoint, qui contient les info
* `topology.kubernetes.io/zone` - Zone dans laquelle l'endpoint se situe.
* `topology.kubernetes.io/region` - Region dans laquelle l'endpoint se situe.
-Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que les correspondantes EndpointSlices sont mis-à-jour. Le contrôleur gèrera les EndpointSlices pour tout les Services qui ont un selecteur - [reference: {{< glossary_tooltip text="selector" term_id="selector" >}}] - specifié. Celles-ci representeront les IPs des Pods qui correspond au selecteur.
+Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que les correspondantes EndpointSlices sont mis-à-jour. Le contrôleur gèrera les EndpointSlices pour tout les Services qui ont un selecteur - [reference: {{< glossary_tooltip text="selecteur" term_id="selector" >}}] - specifié. Celles-ci representeront les IPs des Pods qui correspond au selecteur.
### Capacité d'EndpointSlices
From 6eceb245a2335d1e1a15ebaa4086dfbb5d4610f4 Mon Sep 17 00:00:00 2001
From: Harrison Razanajatovo
Date: Mon, 2 Mar 2020 12:20:17 -0500
Subject: [PATCH 013/440] remove typo
---
content/fr/docs/concepts/services-networking/endpoint-slices.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md
index 6992428f57..a96dad2b98 100644
--- a/content/fr/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md
@@ -106,6 +106,6 @@ Puisque tout les endpoints d'un réseau pour un Service ont été stockés dans
{{% capture whatsnext %}}
* [Activer EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices)
-* Lire [Connecté des Agit stpplication aux Services](/docs/concepts/services-networking/connect-applications-service/)
+* Lire [Connecté des Application aux Services](/docs/concepts/services-networking/connect-applications-service/)
{{% /capture %}}
\ No newline at end of file
From 73f5b576d4bb9309037fbb41785cb937efc253a8 Mon Sep 17 00:00:00 2001
From: Harrison Razanajatovo
Date: Mon, 2 Mar 2020 12:39:39 -0500
Subject: [PATCH 014/440] Fix accent and verb accordance
---
.../services-networking/endpoint-slices.md | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md
index a96dad2b98..b25516b1a2 100644
--- a/content/fr/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md
@@ -24,7 +24,7 @@ _EndpointSlices_ offrent une simple methode pour suivre les endpoints d'un rése
## Resource pour EndpointSlice {#endpointslice-resource}
Dans Kubernetes, un EndpointSlice contient des reférences à un ensemble de reseau
-endpoints. Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Kubernetes Service quand un {{< glossary_tooltip text="selecteur" term_id="selector" >}} est spécifié. Ces EnpointSlices vont inclure des references a n'importe quelle Pods qui correspond aux selecteur de Service. EndpointSlices groupent ensemble les endpoints d'un reseau par combinaisons uniques de Services et de Ports.
+endpoints. Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Kubernetes Service quand un {{< glossary_tooltip text="selecteur" term_id="selector" >}} est spécifié. Ces EnpointSlices vont inclure des references à n'importe quelle Pods qui correspond aux selecteur de Service. EndpointSlices groupent ensemble les endpoints d'un reseau par combinaisons uniques de Services et de Ports.
Par exemple, voici un échantillon d'une resource EndpointSlice pour le Kubernetes Service `exemple`.
@@ -53,7 +53,7 @@ endpoints:
EndpointSlices geré par le controleur d'EndpointSlice n'auront, par défaut, pas plus de 100 endpoints chacun. En dessous de cette échelle, EndpointSlices devrait mapper 1:1 les Endpoints et les Service et devrait avoir une performance similaire.
-EnpointpointSlices peuvent agir en tant que source de vérité pour kube-proxy quand it s'agit du routage d'un trafic interne. Lorsqu'ils sont activés, ils devront une amélioration de performance pour les services qui ont une grand quantité d'endpoints.
+EndpointSlices peuvent agir en tant que source de vérité pour kube-proxy quand it s'agit du routage d'un trafic interne. Lorsqu'ils sont activés, ils devraient offrir une amélioration de performance pour les services qui ont une grand quantité d'endpoints.
### Types d'addresses
@@ -66,7 +66,7 @@ EndpointSlices supporte trois type d'addresses:
### Topologie
Chaque endpoint dans un EnpointSlice peut contenir des informations de topologie pertinentes.
-Ceci est utilisé pour indiqué où se trouve un endpoint, qui contient les informations sur le Node, zone et region correspondant. Lorsque les valeurs sont disponibles, les etiquette de Topologies suivantes seront définies par le contrôleur EndpointSlice:
+Ceci est utilisé pour indiqué où se trouve un endpoint, qui contient les informations sur le Node, zone et region correspondante. Lorsque les valeurs sont disponibles, les étiquette de Topologies suivantes seront définies par le contrôleur EndpointSlice:
* `kubernetes.io/hostname` - Nom du Node sur lequel l'endpoint se situe.
* `topology.kubernetes.io/zone` - Zone dans laquelle l'endpoint se situe.
@@ -76,16 +76,15 @@ Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que
### Capacité d'EndpointSlices
-Les EndpointSlices sont limité a une capacité de 100 endpoints chacun, par defaut. Vous pouvez configurer ceci avec l'indicateur `--max-endpoints-per-slice` {{< glossary_tooltip
-text="kube-controller-manager" term_id="kube-controller-manager" >}} jusqu'à un maximum de 1000.
+Les EndpointSlices sont limité a une capacité de 100 endpoints chacun, par defaut. Vous pouvez configurer ceci avec l'indicateur `--max-endpoints-per-slice` {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} jusqu'à un maximum de 1000.
### Distribution d'EndpointSlices
Chaque EndpointSlice a un ensemble de ports qui s'applique à toutes les endpoints dans la resource. Lorsque les ports nommés sont utilisé pour un Service, les Pods peuvent se retrouver avec differents port cible pour le même port nommé, nécessitant différents EndpointSlices.
-Le contrôlleur essait de remplir l'EndpointSlice aussi complètement que possible, mais ne les rééquilibrent pas activement. La logic du contrôlleur est assez simple:
+Le contrôlleur essait de remplir l'EndpointSlice aussi complètement que possible, mais ne les rééquilibre pas activement. La logic du contrôlleur est assez simple:
-1. Itérer à travers les EnpointSlices existantes, retirer les endpoint qui ne sont plus voulues et mettre à jour les endpoints qui ont changées.
+1. Itérer à travers les EnpointSlices éxistantes, retirer les endpoint qui ne sont plus voulues et mettre à jour les endpoints qui ont changées.
2. Itérer à travers les EndpointSlices qui ont été modifiées dans la première étape et les remplir avec n'importe quelle endpoint nécéssaire.
3. Si il reste encore des endpoints neuves à ajouter, essayez de les mettre dans une slice qui n'a pas été changé et/ou en crée de nouvelles.
@@ -93,7 +92,7 @@ Par-dessus tout, la troisème étape priorise la limitation de mises à jour d'E
Avec kube-proxy exécuté sur chaque Node et surveillant EndpointSlices, chaque changement à une EndpointSlice devient relativement coûteux puisqu'ils seront transmit à chaque Node du cluster. Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Node, même si ça peut entraîner plusieurs EndpointSlices qui ne sont pas plein.
-En pratique, cette distribution moins qu'idéale devrait être rare. La plupart des changements traité par le contrôleur EndpointSlice sera suffisamment petit pour tenir dans un EndpointSlice existante, et sinon, une nouvelle EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour continues des déploiements fournissent également un remballage naturel des EndpointSlices avec tout leur pods et les endpoints correspondants qui se feront remplacer.
+En pratique, cette distribution bien peu idéale devrait être rare. La plupart des changements traité par le contrôleur EndpointSlice sera suffisamment petit pour tenir dans un EndpointSlice existante, et sinon, une nouvelle EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour continues des déploiements fournissent également un remballage naturel des EndpointSlices avec tout leur pods et les endpoints correspondants qui se feront remplacer.
## Motivation
From 44e3358c7f3bec220966750b7b170e8bc379450b Mon Sep 17 00:00:00 2001
From: Harrison Razanajatovo
Date: Fri, 6 Mar 2020 10:00:26 -0500
Subject: [PATCH 015/440] second round review
---
.../services-networking/endpoint-slices.md | 20 +++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md
index b25516b1a2..103a2bf377 100644
--- a/content/fr/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md
@@ -4,7 +4,7 @@ title: EndpointSlices
feature:
title: EndpointSlices
description: >
- Suivi évolutif des réseau endpoints dans un cluster Kubernetes.
+ Suivi évolutif des réseaux endpoints dans un cluster Kubernetes.
content_template: templates/concept
weight: 10
@@ -15,7 +15,7 @@ weight: 10
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
-_EndpointSlices_ offrent une simple methode pour suivre les endpoints d'un réseau au sein d'un cluster de Kubernetes. Ils offrent une alternative plus evolutive et extensible aux Endpoints.
+_EndpointSlices_ offrent une méthode simple pour suivre les endpoints d'un réseau au sein d'un cluster de Kubernetes. Ils offrent une alternative plus evolutive et extensible aux Endpoints.
{{% /capture %}}
@@ -76,29 +76,29 @@ Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que
### Capacité d'EndpointSlices
-Les EndpointSlices sont limité a une capacité de 100 endpoints chacun, par defaut. Vous pouvez configurer ceci avec l'indicateur `--max-endpoints-per-slice` {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} jusqu'à un maximum de 1000.
+Les EndpointSlices sont limités a une capacité de 100 endpoints chacun, par defaut. Vous pouvez configurer cela avec l'indicateur `--max-endpoints-per-slice` {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} jusqu'à un maximum de 1000.
### Distribution d'EndpointSlices
-Chaque EndpointSlice a un ensemble de ports qui s'applique à toutes les endpoints dans la resource. Lorsque les ports nommés sont utilisé pour un Service, les Pods peuvent se retrouver avec differents port cible pour le même port nommé, nécessitant différents EndpointSlices.
+Chaque EndpointSlice a un ensemble de ports qui s'applique à toutes les endpoints dans la resource. Lorsque les ports nommés sont utilisés pour un Service, les Pods peuvent se retrouver avec différents port cible pour le même port nommé, nécessitant différents EndpointSlices.
-Le contrôlleur essait de remplir l'EndpointSlice aussi complètement que possible, mais ne les rééquilibre pas activement. La logic du contrôlleur est assez simple:
+Le contrôleur essaie de remplir l'EndpointSlice aussi complètement que possible, mais ne les rééquilibre pas activement. La logique du contrôleur est assez simple:
-1. Itérer à travers les EnpointSlices éxistantes, retirer les endpoint qui ne sont plus voulues et mettre à jour les endpoints qui ont changées.
+1. Itérer à travers les EnpointSlices existantes, retirer les endpoints qui ne sont plus voulues et mettre à jour les endpoints qui ont changées.
2. Itérer à travers les EndpointSlices qui ont été modifiées dans la première étape et les remplir avec n'importe quelle endpoint nécéssaire.
3. Si il reste encore des endpoints neuves à ajouter, essayez de les mettre dans une slice qui n'a pas été changé et/ou en crée de nouvelles.
Par-dessus tout, la troisème étape priorise la limitation de mises à jour d'EnpointSlice sur une distribution complètement pleine d'EndpointSlices. Par exemple, si il y avait 10 nouvelles endpoints à ajouter et 2 EndpointSlices qui peuvent accomoder 5 endpoint en plus chacun; cette approche créera une nouvelle EndpointSlice au lieu de remplir les EndpointSlice existantes. C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlice.
-Avec kube-proxy exécuté sur chaque Node et surveillant EndpointSlices, chaque changement à une EndpointSlice devient relativement coûteux puisqu'ils seront transmit à chaque Node du cluster. Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Node, même si ça peut entraîner plusieurs EndpointSlices qui ne sont pas plein.
+Avec kube-proxy exécuté sur chaque Node et surveillant EndpointSlices, chaque changement a une EndpointSlice devient relativement coûteux puisqu'ils seront transmit à chaque Node du cluster. Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Node, même si ça peut entraîner plusieurs EndpointSlices qui ne sont pas plein.
-En pratique, cette distribution bien peu idéale devrait être rare. La plupart des changements traité par le contrôleur EndpointSlice sera suffisamment petit pour tenir dans un EndpointSlice existante, et sinon, une nouvelle EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour continues des déploiements fournissent également un remballage naturel des EndpointSlices avec tout leur pods et les endpoints correspondants qui se feront remplacer.
+En pratique, cette distribution bien peu idéale devrait être rare. La plupart des changements traités par le contrôleur EndpointSlice sera suffisamment petit pour tenir dans un EndpointSlice existante, et sinon, une nouvelle EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour continues des déploiements fournissent également un remballage naturel des EndpointSlices avec tout leur pods et les endpoints correspondants qui se feront remplacer.
## Motivation
-Les Endpoints API ont fournit une methode simple et facile de suivre les endpoint d'un réseau dans Kubernetes. Malheureusement, comme les clusters Kubernetes et Services sont devenus plus large, les limitations de cette API sont devenues plus visibles. Plus particulièrement, ceux-ci comprenaient des défis liés à la mise à l'échelle vers un plus grand nombre d'endpoint d'un réseau.
+Les Endpoints API fournissent une méthode simple et facile à suivre pour les endpoint d'un réseau dans Kubernetes. Malheureusement, comme les clusters Kubernetes et Services sont devenus plus larges, les limitations de cette API sont devenues plus visibles. Plus particulièrement, ceux-ci comprenaient des défis liés au dimensionnement vers un plus grand nombre d'endpoint d'un réseau.
-Puisque tout les endpoints d'un réseau pour un Service ont été stockés dans une seule ressource Endpoints, ces ressources pourraient devenir assez considérable. Ça a affecté les performances des composants Kubernetes (notamment le plan de contrôle maître) et a donné lieu à une grande quantité de trafic réseau et de traitement lorsque les Endpoints changent. EndpointSlices vous aide à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique.
+Puisque tous les endpoints d'un réseau pour un Service ont été stockés dans une seule ressource Endpoints, ces ressources pourraient devenir assez lourdes. Cela affecte les performances des composants Kubernetes (notamment le plan de contrôle) et a donné lieu à une grande quantité de trafic réseau et de traitement lorsque les Endpoints changent. Les EndpointSlices vous aident à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique.
{{% /capture %}}
From ef2f47772844dc5cc8fb6c4d410d2d19dc3d5910 Mon Sep 17 00:00:00 2001
From: Harrison Razanajatovo
Date: Fri, 6 Mar 2020 10:05:13 -0500
Subject: [PATCH 016/440] Rewording sentences for a more accurate translation
---
content/fr/docs/concepts/services-networking/endpoint-slices.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md
index 103a2bf377..cf980fd340 100644
--- a/content/fr/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md
@@ -92,7 +92,7 @@ Par-dessus tout, la troisème étape priorise la limitation de mises à jour d'E
Avec kube-proxy exécuté sur chaque Node et surveillant EndpointSlices, chaque changement a une EndpointSlice devient relativement coûteux puisqu'ils seront transmit à chaque Node du cluster. Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Node, même si ça peut entraîner plusieurs EndpointSlices qui ne sont pas plein.
-En pratique, cette distribution bien peu idéale devrait être rare. La plupart des changements traités par le contrôleur EndpointSlice sera suffisamment petit pour tenir dans un EndpointSlice existante, et sinon, une nouvelle EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour continues des déploiements fournissent également un remballage naturel des EndpointSlices avec tout leur pods et les endpoints correspondants qui se feront remplacer.
+En pratique, cette distribution bien peu idéale devrait être rare. La plupart des changements traités par le contrôleur EndpointSlice sera suffisamment petit pour tenir dans un EndpointSlice existante, et sinon, une nouvelle EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour régulières des déploiements permettent également un reconditionnement naturel des EndpointSlices avec tout les pods et les endpoints correspondants qui se feront remplacer.
## Motivation
From 728bd52d8e0bda595ffdac88d62ac559dcb6b248 Mon Sep 17 00:00:00 2001
From: Arhell
Date: Sun, 8 Mar 2020 16:55:37 +0200
Subject: [PATCH 017/440] fix readme pl link
---
README-pl.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/README-pl.md b/README-pl.md
index c05631df91..65cd63df64 100644
--- a/README-pl.md
+++ b/README-pl.md
@@ -41,7 +41,7 @@ Zalecaną metodą uruchomienia serwisu internetowego Kubernetesa lokalnie jest u
choco install make
```
-> Jeśli wolisz uruchomić serwis lokalnie bez Dockera, przeczytaj [jak uruchomić serwis lokalnie przy pomocy Hugo](#jak-uruchomić-serwis-lokalnie-przy-pomocy-hugo) poniżej.
+> Jeśli wolisz uruchomić serwis lokalnie bez Dockera, przeczytaj [jak uruchomić serwis lokalnie przy pomocy Hugo](#jak-uruchomić-lokalną-kopię-strony-przy-pomocy-hugo) poniżej.
Jeśli [zainstalowałeś i uruchomiłeś](https://www.docker.com/get-started) już Dockera, zbuduj obraz `kubernetes-hugo` lokalnie:
From 476598657b092e4ae2cd145d990115c0974ddf0f Mon Sep 17 00:00:00 2001
From: Harrison Razanajatovo
Date: Mon, 9 Mar 2020 15:39:33 -0400
Subject: [PATCH 018/440] Add reviewed changes
---
.../services-networking/endpoint-slices.md | 52 +++++++++++--------
1 file changed, 30 insertions(+), 22 deletions(-)
diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md
index cf980fd340..bf22340339 100644
--- a/content/fr/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md
@@ -4,7 +4,7 @@ title: EndpointSlices
feature:
title: EndpointSlices
description: >
- Suivi évolutif des réseaux endpoints dans un cluster Kubernetes.
+ Suivi évolutif des réseaux Endpoints dans un cluster Kubernetes.
content_template: templates/concept
weight: 10
@@ -15,7 +15,7 @@ weight: 10
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
-_EndpointSlices_ offrent une méthode simple pour suivre les endpoints d'un réseau au sein d'un cluster de Kubernetes. Ils offrent une alternative plus evolutive et extensible aux Endpoints.
+_EndpointSlices_ offrent une méthode simple pour suivre les Endpoints d'un réseau au sein d'un cluster de Kubernetes. Ils offrent une alternative plus évolutive et extensible aux Endpoints.
{{% /capture %}}
@@ -24,7 +24,9 @@ _EndpointSlices_ offrent une méthode simple pour suivre les endpoints d'un rés
## Resource pour EndpointSlice {#endpointslice-resource}
Dans Kubernetes, un EndpointSlice contient des reférences à un ensemble de reseau
-endpoints. Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Kubernetes Service quand un {{< glossary_tooltip text="selecteur" term_id="selector" >}} est spécifié. Ces EnpointSlices vont inclure des references à n'importe quelle Pods qui correspond aux selecteur de Service. EndpointSlices groupent ensemble les endpoints d'un reseau par combinaisons uniques de Services et de Ports.
+Endpoints. Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Service quand un {{< glossary_tooltip text="sélecteur" term_id="selector" >}} est spécifié.
+Ces EnpointSlices vont inclure des références à n'importe quels Pods qui correspond aux selecteur de Service.
+EndpointSlices groupent ensemble les Endpoints d'un réseau par combinaisons uniques de Services et de Ports.
Par exemple, voici un échantillon d'une resource EndpointSlice pour le Kubernetes Service `exemple`.
@@ -51,13 +53,15 @@ endpoints:
topology.kubernetes.io/zone: us-west2-a
```
-EndpointSlices geré par le controleur d'EndpointSlice n'auront, par défaut, pas plus de 100 endpoints chacun. En dessous de cette échelle, EndpointSlices devrait mapper 1:1 les Endpoints et les Service et devrait avoir une performance similaire.
+Les EndpointSlices géré par le contrôleur d'EndpointSlice n'auront, par défaut, pas plus de 100 Endpoints chacun.
+En dessous de cette échelle, EndpointSlices devrait mapper 1:1 les Endpoints et les Service et devrait avoir une performance similaire.
-EndpointSlices peuvent agir en tant que source de vérité pour kube-proxy quand it s'agit du routage d'un trafic interne. Lorsqu'ils sont activés, ils devraient offrir une amélioration de performance pour les services qui ont une grand quantité d'endpoints.
+EndpointSlices peuvent agir en tant que source de vérité pour kube-proxy quand il s'agit du routage d'un trafic interne.
+Lorsqu'ils sont activés, ils devraient offrir une amélioration de performance pour les services qui ont une grand quantité d'Endpoints.
### Types d'addresses
-EndpointSlices supporte trois type d'addresses:
+Les EndpointSlices supportent 3 types d'addresses:
* IPv4
* IPv6
@@ -65,46 +69,50 @@ EndpointSlices supporte trois type d'addresses:
### Topologie
-Chaque endpoint dans un EnpointSlice peut contenir des informations de topologie pertinentes.
-Ceci est utilisé pour indiqué où se trouve un endpoint, qui contient les informations sur le Node, zone et region correspondante. Lorsque les valeurs sont disponibles, les étiquette de Topologies suivantes seront définies par le contrôleur EndpointSlice:
+Chaque Endpoint dans un EnpointSlice peut contenir des informations de topologie pertinentes.
+Ceci est utilisé pour indiqué où se trouve un Endpoint, qui contient les informations sur le Node, zone et region correspondante. Lorsque les valeurs sont disponibles, les labels de Topologies suivantes seront définies par le contrôleur EndpointSlice:
-* `kubernetes.io/hostname` - Nom du Node sur lequel l'endpoint se situe.
-* `topology.kubernetes.io/zone` - Zone dans laquelle l'endpoint se situe.
-* `topology.kubernetes.io/region` - Region dans laquelle l'endpoint se situe.
+* `kubernetes.io/hostname` - Nom du Node sur lequel l'Endpoint se situe.
+* `topology.kubernetes.io/zone` - Zone dans laquelle l'Endpoint se situe.
+* `topology.kubernetes.io/region` - Region dans laquelle l'Endpoint se situe.
-Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que les correspondantes EndpointSlices sont mis-à-jour. Le contrôleur gèrera les EndpointSlices pour tout les Services qui ont un selecteur - [reference: {{< glossary_tooltip text="selecteur" term_id="selector" >}}] - specifié. Celles-ci representeront les IPs des Pods qui correspond au selecteur.
+Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que leurs correspondances avec les EndpointSlices sont à jour.
+Le contrôleur gère les EndpointSlices pour tous les Services qui ont un sélecteur - [référence: {{< glossary_tooltip text="sélecteur" term_id="selector" >}}] - specifié. Celles-ci représenteront les IPs des Pods qui correspond au sélecteur.
### Capacité d'EndpointSlices
-Les EndpointSlices sont limités a une capacité de 100 endpoints chacun, par defaut. Vous pouvez configurer cela avec l'indicateur `--max-endpoints-per-slice` {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} jusqu'à un maximum de 1000.
+Les EndpointSlices sont limités a une capacité de 100 Endpoints chacun, par defaut. Vous pouvez configurer cela avec l'indicateur `--max-endpoints-per-slice` {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} jusqu'à un maximum de 1000.
### Distribution d'EndpointSlices
-Chaque EndpointSlice a un ensemble de ports qui s'applique à toutes les endpoints dans la resource. Lorsque les ports nommés sont utilisés pour un Service, les Pods peuvent se retrouver avec différents port cible pour le même port nommé, nécessitant différents EndpointSlices.
+Chaque EndpointSlice a un ensemble de ports qui s'applique à toutes les Endpoints dans la resource. Lorsque les ports nommés sont utilisés pour un Service, les Pods peuvent se retrouver avec différents port cible pour le même port nommé, nécessitant différents EndpointSlices.
Le contrôleur essaie de remplir l'EndpointSlice aussi complètement que possible, mais ne les rééquilibre pas activement. La logique du contrôleur est assez simple:
-1. Itérer à travers les EnpointSlices existantes, retirer les endpoints qui ne sont plus voulues et mettre à jour les endpoints qui ont changées.
-2. Itérer à travers les EndpointSlices qui ont été modifiées dans la première étape et les remplir avec n'importe quelle endpoint nécéssaire.
-3. Si il reste encore des endpoints neuves à ajouter, essayez de les mettre dans une slice qui n'a pas été changé et/ou en crée de nouvelles.
+1. Itérer à travers les EnpointSlices existantes, retirer les Endpoints qui ne sont plus voulues et mettre à jour les Endpoints qui ont changées.
+2. Itérer à travers les EndpointSlices qui ont été modifiés dans la première étape et les remplir avec n'importe quel Endpoint nécéssaire.
+3. S'il reste encore des Endpoints neufs à ajouter, essayez de les mettre dans une slice qui n'a pas été changé et/ou en crée de nouveaux.
-Par-dessus tout, la troisème étape priorise la limitation de mises à jour d'EnpointSlice sur une distribution complètement pleine d'EndpointSlices. Par exemple, si il y avait 10 nouvelles endpoints à ajouter et 2 EndpointSlices qui peuvent accomoder 5 endpoint en plus chacun; cette approche créera une nouvelle EndpointSlice au lieu de remplir les EndpointSlice existantes. C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlice.
+Par-dessus tout, la troisième étape priorise la limitation de mises à jour d'EnpointSlice sur une distribution complètement pleine d'EndpointSlices. Par exemple, si il y avait 10 nouveaux Endpoints à ajouter et 2 EndpointSlices qui peuvent contenir 5 Endpoints en plus chacun; cette approche créera un nouveau EndpointSlice au lieu de remplir les EndpointSlice existants.
+C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlice.
Avec kube-proxy exécuté sur chaque Node et surveillant EndpointSlices, chaque changement a une EndpointSlice devient relativement coûteux puisqu'ils seront transmit à chaque Node du cluster. Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Node, même si ça peut entraîner plusieurs EndpointSlices qui ne sont pas plein.
-En pratique, cette distribution bien peu idéale devrait être rare. La plupart des changements traités par le contrôleur EndpointSlice sera suffisamment petit pour tenir dans un EndpointSlice existante, et sinon, une nouvelle EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour régulières des déploiements permettent également un reconditionnement naturel des EndpointSlices avec tout les pods et les endpoints correspondants qui se feront remplacer.
+En pratique, cette distribution bien peu idéale devrait être rare. La plupart des changements traités par le contrôleur EndpointSlice sera suffisamment petit pour tenir dans un EndpointSlice existante, et sinon, une nouvelle EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour régulières des déploiements permettent également un reconditionnement naturel des EndpointSlices avec tout les pods et les Endpoints correspondants qui se feront remplacer.
## Motivation
-Les Endpoints API fournissent une méthode simple et facile à suivre pour les endpoint d'un réseau dans Kubernetes. Malheureusement, comme les clusters Kubernetes et Services sont devenus plus larges, les limitations de cette API sont devenues plus visibles. Plus particulièrement, ceux-ci comprenaient des défis liés au dimensionnement vers un plus grand nombre d'endpoint d'un réseau.
+L'API des Endpoints fournit une méthode simple et facile à suivre pour les Endpoints d'un réseau dans Kubernetes.
+Malheureusement, comme les clusters Kubernetes et Services sont devenus plus larges, les limitations de cette API sont devenues plus visibles.
+Plus particulièrement, ceux-ci comprenaient des défis liés au dimensionnement vers un plus grand nombre d'Endpoint d'un réseau.
-Puisque tous les endpoints d'un réseau pour un Service ont été stockés dans une seule ressource Endpoints, ces ressources pourraient devenir assez lourdes. Cela affecte les performances des composants Kubernetes (notamment le plan de contrôle) et a donné lieu à une grande quantité de trafic réseau et de traitement lorsque les Endpoints changent. Les EndpointSlices vous aident à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique.
+Puisque tous les Endpoints d'un réseau pour un Service ont été stockés dans une seule ressource Endpoints, ces ressources pourraient devenir assez lourdes. Cela affecte les performances des composants Kubernetes (notamment le plan de contrôle) et a donné lieu à une grande quantité de trafic réseau et de traitement lorsque les Endpoints changent. Les EndpointSlices vous aident à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique.
{{% /capture %}}
{{% capture whatsnext %}}
* [Activer EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices)
-* Lire [Connecté des Application aux Services](/docs/concepts/services-networking/connect-applications-service/)
+* Lire [Connecter des applications aux Services](/docs/concepts/services-networking/connect-applications-service/)
{{% /capture %}}
\ No newline at end of file
From f0b4ddf012217514a524e43b857910ab91f9f198 Mon Sep 17 00:00:00 2001
From: Harrison Razanajatovo
Date: Mon, 9 Mar 2020 15:44:36 -0400
Subject: [PATCH 019/440] Add last minute changes
---
.../fr/docs/concepts/services-networking/endpoint-slices.md | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md
index bf22340339..a4283fee91 100644
--- a/content/fr/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md
@@ -81,11 +81,12 @@ Le contrôleur gère les EndpointSlices pour tous les Services qui ont un sélec
### Capacité d'EndpointSlices
-Les EndpointSlices sont limités a une capacité de 100 Endpoints chacun, par defaut. Vous pouvez configurer cela avec l'indicateur `--max-endpoints-per-slice` {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} jusqu'à un maximum de 1000.
+Les EndpointSlices sont limités a une capacité de 100 Endpoints chacun, par défaut. Vous pouvez configurer ceci avec l'indicateur `--max-endpoints-per-slice` {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} jusqu'à un maximum de 1000.
### Distribution d'EndpointSlices
-Chaque EndpointSlice a un ensemble de ports qui s'applique à toutes les Endpoints dans la resource. Lorsque les ports nommés sont utilisés pour un Service, les Pods peuvent se retrouver avec différents port cible pour le même port nommé, nécessitant différents EndpointSlices.
+Chaque EndpointSlice a un ensemble de ports qui s'applique à tous les Endpoints dans la resource.
+Lorsque les ports nommés sont utilisés pour un Service, les Pods peuvent se retrouver avec différents port cible pour le même port nommé, nécessitant différents EndpointSlices.
Le contrôleur essaie de remplir l'EndpointSlice aussi complètement que possible, mais ne les rééquilibre pas activement. La logique du contrôleur est assez simple:
From c61213299d319d4916fe5d01ad7812ed31c2b445 Mon Sep 17 00:00:00 2001
From: Harrison Razanajatovo
Date: Mon, 9 Mar 2020 16:03:30 -0400
Subject: [PATCH 020/440] Add changes for missed reviews
---
.../services-networking/endpoint-slices.md | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md
index a4283fee91..c3fdef9a29 100644
--- a/content/fr/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md
@@ -90,24 +90,27 @@ Lorsque les ports nommés sont utilisés pour un Service, les Pods peuvent se re
Le contrôleur essaie de remplir l'EndpointSlice aussi complètement que possible, mais ne les rééquilibre pas activement. La logique du contrôleur est assez simple:
-1. Itérer à travers les EnpointSlices existantes, retirer les Endpoints qui ne sont plus voulues et mettre à jour les Endpoints qui ont changées.
+1. Itérer à travers les EnpointSlices existants, retirer les Endpoints qui ne sont plus voulus et mettre à jour les Endpoints qui ont changés.
2. Itérer à travers les EndpointSlices qui ont été modifiés dans la première étape et les remplir avec n'importe quel Endpoint nécéssaire.
3. S'il reste encore des Endpoints neufs à ajouter, essayez de les mettre dans une slice qui n'a pas été changé et/ou en crée de nouveaux.
Par-dessus tout, la troisième étape priorise la limitation de mises à jour d'EnpointSlice sur une distribution complètement pleine d'EndpointSlices. Par exemple, si il y avait 10 nouveaux Endpoints à ajouter et 2 EndpointSlices qui peuvent contenir 5 Endpoints en plus chacun; cette approche créera un nouveau EndpointSlice au lieu de remplir les EndpointSlice existants.
C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlice.
-Avec kube-proxy exécuté sur chaque Node et surveillant EndpointSlices, chaque changement a une EndpointSlice devient relativement coûteux puisqu'ils seront transmit à chaque Node du cluster. Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Node, même si ça peut entraîner plusieurs EndpointSlices qui ne sont pas plein.
+Avec kube-proxy exécuté sur chaque Node et surveillant EndpointSlices, chaque changement d'un EndpointSlice devient relativement coûteux puisqu'ils seront transmis à chaque Node du cluster.
+Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Node, même si ça peut causer plusieurs EndpointSlices non remplis.
-En pratique, cette distribution bien peu idéale devrait être rare. La plupart des changements traités par le contrôleur EndpointSlice sera suffisamment petit pour tenir dans un EndpointSlice existante, et sinon, une nouvelle EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour régulières des déploiements permettent également un reconditionnement naturel des EndpointSlices avec tout les pods et les Endpoints correspondants qui se feront remplacer.
+En pratique, cette distribution bien peu idéale devrait être rare. La plupart des changements traités par le contrôleur EndpointSlice sera suffisamment petite pour tenir dans un EndpointSlice existant, et sinon, un nouveau EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour continues des déploiements fournissent également une compaction naturelle des EndpointSlices avec tous leurs pods et les Endpoints correspondants qui se feront remplacer.
## Motivation
-L'API des Endpoints fournit une méthode simple et facile à suivre pour les Endpoints d'un réseau dans Kubernetes.
+L'API des Endpoints fournit une méthode simple et facile à suivre pour les Endpoints dans Kubernetes.
Malheureusement, comme les clusters Kubernetes et Services sont devenus plus larges, les limitations de cette API sont devenues plus visibles.
-Plus particulièrement, ceux-ci comprenaient des défis liés au dimensionnement vers un plus grand nombre d'Endpoint d'un réseau.
+Plus particulièrement, ceux-ci comprenaient des limitations liés au dimensionnement vers un plus grand nombre d'Endpoint d'un réseau.
-Puisque tous les Endpoints d'un réseau pour un Service ont été stockés dans une seule ressource Endpoints, ces ressources pourraient devenir assez lourdes. Cela affecte les performances des composants Kubernetes (notamment le plan de contrôle) et a donné lieu à une grande quantité de trafic réseau et de traitement lorsque les Endpoints changent. Les EndpointSlices vous aident à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique.
+Puisque tous les Endpoints d'un réseau pour un Service ont été stockés dans une seule ressource Endpoints, ces ressources pourraient devenir assez lourdes.
+Cela a affecté les performances des composants Kubernetes (notamment le plan de contrôle) et a causé une grande quantité de trafic réseau et de traitements lorsque les Endpoints changent.
+Les EndpointSlices aident à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique.
{{% /capture %}}
From dae5f0585b49dd46c5e8f66b25d1760a051fa035 Mon Sep 17 00:00:00 2001
From: Harrison Razanajatovo
Date: Tue, 10 Mar 2020 09:15:51 -0400
Subject: [PATCH 021/440] Simplify for clarity
---
.../fr/docs/concepts/services-networking/endpoint-slices.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md
index c3fdef9a29..b06117cc00 100644
--- a/content/fr/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md
@@ -23,8 +23,8 @@ _EndpointSlices_ offrent une méthode simple pour suivre les Endpoints d'un rés
## Resource pour EndpointSlice {#endpointslice-resource}
-Dans Kubernetes, un EndpointSlice contient des reférences à un ensemble de reseau
-Endpoints. Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Service quand un {{< glossary_tooltip text="sélecteur" term_id="selector" >}} est spécifié.
+Dans Kubernetes, un EndpointSlice contient des reférences à un ensemble de Endpoints.
+Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Service quand un {{< glossary_tooltip text="sélecteur" term_id="selector" >}} est spécifié.
Ces EnpointSlices vont inclure des références à n'importe quels Pods qui correspond aux selecteur de Service.
EndpointSlices groupent ensemble les Endpoints d'un réseau par combinaisons uniques de Services et de Ports.
From 8cd0990786193f829309db4deb8073e38ef27d9a Mon Sep 17 00:00:00 2001
From: JenTing Hsiao
Date: Wed, 11 Mar 2020 14:35:06 +0800
Subject: [PATCH 022/440] Correct target.type from AverageUtilization to
Utilization
Signed-off-by: JenTing Hsiao
---
.../run-application/horizontal-pod-autoscale-walkthrough.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index 6a9fe4de32..4ad6d5746b 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -239,7 +239,7 @@ the only other supported resource metric is memory. These resources do not chan
to cluster, and should always be available, as long as the `metrics.k8s.io` API is available.
You can also specify resource metrics in terms of direct values, instead of as percentages of the
-requested value, by using a `target` type of `AverageValue` instead of `AverageUtilization`, and
+requested value, by using a `target.type` of `AverageValue` instead of `Utilization`, and
setting the corresponding `target.averageValue` field instead of the `target.averageUtilization`.
There are two other types of metrics, both of which are considered *custom metrics*: pod metrics and
From 7b51cbd8b24fb256b40c15b8a056f53cc9de5221 Mon Sep 17 00:00:00 2001
From: Johnny Lim
Date: Mon, 16 Mar 2020 18:24:53 +0900
Subject: [PATCH 023/440] Polish
---
.../configure-access-multiple-clusters.md | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
index 67077aa331..6875453878 100644
--- a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+++ b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
@@ -158,8 +158,8 @@ certification files, then you need add the suffix `-data` to the keys. For examp
`certificate-authority-data`, `client-certificate-data`, `client-key-data`.
Each context is a triple (cluster, user, namespace). For example, the
-`dev-frontend` context says, Use the credentials of the `developer`
-user to access the `frontend` namespace of the `development` cluster.
+`dev-frontend` context says, "Use the credentials of the `developer`
+user to access the `frontend` namespace of the `development` cluster".
Set the current context:
@@ -275,7 +275,7 @@ colon-delimited for Linux and Mac, and semicolon-delimited for Windows. If you h
a `KUBECONFIG` environment variable, familiarize yourself with the configuration files
in the list.
-Temporarily append two paths to your `KUBECONFIG` environment variable. For example:
+Temporarily append two paths to your `KUBECONFIG` environment variable. For example:
### Linux
```shell
@@ -359,11 +359,12 @@ kubectl config view
## Clean up
Return your `KUBECONFIG` environment variable to its original value. For example:
-Linux:
+
+### Linux
```shell
export KUBECONFIG=$KUBECONFIG_SAVED
```
-Windows PowerShell
+### Windows PowerShell
```shell
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
```
From 2ca1c075ad2d6959ddced1661b9f6cc1cb1bb286 Mon Sep 17 00:00:00 2001
From: Niklas Hansson
Date: Fri, 20 Mar 2020 09:43:49 +0100
Subject: [PATCH 024/440] Update the Mac autocomplete to use bash_profile
On OS X, Terminal by default runs a login shell every time, thus I believe it is simpler for new users to not have to change to change the default. behaviour or source the bashrc file every time. https://apple.stackexchange.com/questions/51036/what-is-the-difference-between-bash-profile-and-bashrc
---
content/en/docs/tasks/tools/install-kubectl.md | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md
index 83c9d1761b..d2922be1a6 100644
--- a/content/en/docs/tasks/tools/install-kubectl.md
+++ b/content/en/docs/tasks/tools/install-kubectl.md
@@ -419,7 +419,7 @@ You can test if you have bash-completion v2 already installed with `type _init_c
brew install bash-completion@2
```
-As stated in the output of this command, add the following to your `~/.bashrc` file:
+As stated in the output of this command, add the following to your `~/.bash_profile` file:
```shell
export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
@@ -432,10 +432,10 @@ Reload your shell and verify that bash-completion v2 is correctly installed with
You now have to ensure that the kubectl completion script gets sourced in all your shell sessions. There are multiple ways to achieve this:
-- Source the completion script in your `~/.bashrc` file:
+- Source the completion script in your `~/.bash_profile` file:
```shell
- echo 'source <(kubectl completion bash)' >>~/.bashrc
+ echo 'source <(kubectl completion bash)' >>~/.bash_profile
```
@@ -448,8 +448,8 @@ You now have to ensure that the kubectl completion script gets sourced in all yo
- If you have an alias for kubectl, you can extend shell completion to work with that alias:
```shell
- echo 'alias k=kubectl' >>~/.bashrc
- echo 'complete -F __start_kubectl k' >>~/.bashrc
+ echo 'alias k=kubectl' >>~/.bash_profile
+ echo 'complete -F __start_kubectl k' >>~/.bash_profile
```
- If you installed kubectl with Homebrew (as explained [above](#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything.
From fdb424622720f5cc7cac9e6cd6dd58fc17f7a326 Mon Sep 17 00:00:00 2001
From: Maxime Guyot
Date: Fri, 20 Mar 2020 14:06:35 +0100
Subject: [PATCH 025/440] Update kubespray page
---
.../production-environment/tools/kubespray.md | 41 ++++++++++---------
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md
index 8187d5eac4..929ebce5bd 100644
--- a/content/en/docs/setup/production-environment/tools/kubespray.md
+++ b/content/en/docs/setup/production-environment/tools/kubespray.md
@@ -6,22 +6,22 @@ weight: 30
{{% capture overview %}}
-This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray).
+This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).
-Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
+Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
* a highly available cluster
* composable attributes
* support for most popular Linux distributions
* Container Linux by CoreOS
- * Debian Jessie, Stretch, Wheezy
+ * Debian Buster, Jessie, Stretch, Wheezy
* Ubuntu 16.04, 18.04
- * CentOS/RHEL 7
- * Fedora/CentOS Atomic
- * openSUSE Leap 42.3/Tumbleweed
+ * CentOS/RHEL/Oracle Linux 7
+ * Fedora 28
+ * openSUSE Leap 15
* continuous integration tests
-To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops).
+To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops).
{{% /capture %}}
@@ -31,7 +31,7 @@ To choose a tool which best fits your use case, read [this comparison](https://g
### (1/5) Meet the underlay requirements
-Provision servers with the following [requirements](https://github.com/kubernetes-incubator/kubespray#requirements):
+Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements):
* **Ansible v2.5 (or newer) and python-netaddr is installed on the machine that will run Ansible commands**
* **Jinja 2.9 (or newer) is required to run the Ansible Playbooks**
@@ -44,12 +44,13 @@ Provision servers with the following [requirements](https://github.com/kubernete
Kubespray provides the following utilities to help provision your environment:
* [Terraform](https://www.terraform.io/) scripts for the following cloud providers:
- * [AWS](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/aws)
- * [OpenStack](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/openstack)
+ * [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
+ * [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack)
+ * [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet)
### (2/5) Compose an inventory file
-After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
+After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
### (3/5) Plan your cluster deployment
@@ -73,18 +74,18 @@ Kubespray customizations can be made to a [variable file](http://docs.ansible.co
Next, deploy your cluster:
-Cluster deployment using [ansible-playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
+Cluster deployment using [ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
```shell
ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \
--private-key=~/.ssh/private_key
```
-Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/large-deployments.md) for best results.
+Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md) for best results.
### (5/5) Verify the deployment
-Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators.
+Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators.
## Cluster operations
@@ -92,16 +93,16 @@ Kubespray provides additional playbooks to manage your cluster: _scale_ and _upg
### Scale your cluster
-You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#adding-nodes)".
-You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#remove-nodes)".
+You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)".
+You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)".
### Upgrade your cluster
-You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/upgrades.md)".
+You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)".
## Cleanup
-You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/reset.yml).
+You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml).
{{< caution >}}
When running the reset playbook, be sure not to accidentally target your production cluster!
@@ -110,12 +111,12 @@ When running the reset playbook, be sure not to accidentally target your product
## Feedback
* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/)
-* [GitHub Issues](https://github.com/kubernetes-incubator/kubespray/issues)
+* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
{{% /capture %}}
{{% capture whatsnext %}}
-Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md).
+Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md).
{{% /capture %}}
From d545b8be416b57ee0398b28993abcbac6e3545e5 Mon Sep 17 00:00:00 2001
From: Joao Luna
Date: Mon, 23 Mar 2020 12:38:41 +0000
Subject: [PATCH 026/440] Add docs/concepts/architecture/controller.md in
portuguese
---
.../docs/concepts/architecture/controller.md | 162 ++++++++++++++++++
1 file changed, 162 insertions(+)
create mode 100644 content/pt/docs/concepts/architecture/controller.md
diff --git a/content/pt/docs/concepts/architecture/controller.md b/content/pt/docs/concepts/architecture/controller.md
new file mode 100644
index 0000000000..02efc70f71
--- /dev/null
+++ b/content/pt/docs/concepts/architecture/controller.md
@@ -0,0 +1,162 @@
+---
+title: Controladores
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+Em robótica e automação, um _control loop_ ou em português _ciclo de controlo_ é
+um ciclo não terminado que regula o estado de um sistema.
+
+Um exemplo de um ciclo de controlo é um termostato de uma sala.
+
+Quando você define a temperatura, isso indica ao termostato
+sobre o seu *estado desejado*. A temperatura ambiente real é o
+*estado atual*. O termostato atua de forma a trazer o estado atual
+mais perto do estado desejado, ligando ou desligando o equipamento.
+
+{{< glossary_definition term_id="controller" length="short">}}
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## Padrão de controlo (Controller pattern)
+
+Um controlador rastreia pelo menos um tipo de recurso Kubernetes.
+Estes [objetos](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)
+têm um campo *spec* (especificação) que representa o *estado desejado*.
+Os controladores para esse recurso são responsáveis por trazer o *estado atual*
+mais perto do *estado desejado*.
+
+O controlador pode levar ele proprio a cabo a ação; é mais comum, no Kubernetes,
+um controlador enviar uma mensagem para o
+{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} que tem
+efeitos colaterais uteis. Você vai ver exemplos disto abaixo.
+
+{{< comment >}}
+Alguns controladores embutidos, como é o caso do controlador *namespace*, atuam em objetos
+que não têm uma especificação (*spec*). Por questões de simplicidade, esta página omite explicar
+esse detalhe.
+{{< /comment >}}
+
+### Controlador via API server
+
+O controlador {{< glossary_tooltip term_id="job" >}} é um exemplo de um
+controlador Kubernetes embutido. Controladores embutidos gerem estados através da
+interação com o *cluster API server*.
+
+*Job* é um recurso do Kubernetes que corre um
+{{< glossary_tooltip term_id="pod" >}}, ou talvez vários *Pods*, com o objetivo de
+executar uma tarefa e depois parar.
+
+(Uma vez [agendado](/docs/concepts/scheduling/), objetos *Pod* passam a fazer parte objects become part of the
+do *estado desejado* para um kubelet.
+
+Quando o controlador *Job* observa uma nova tarefa ele garante que,
+algures no seu *cluster*, os kubelets num conjunto de nós (*Nodes*) estão correndo o numero
+correto de *Pods* para completar o trabalho.
+O controlador *Job* não corre *Pods* ou *containers* ele próprio.
+Em vez disso, o controlador *Job* informa o *API server* para criar ou remover *Pods*.
+Outros componentes do plano de controle
+({{< glossary_tooltip text="control plane" term_id="control-plane" >}})
+atuem na nova informação (existem novos *Pods* para serem agendados e executados),
+e eventualmente o trabalho é feito.
+
+Após ter criado um novo *Job*, o *estado desejado* é que esse Job seja completado.
+O controlador *Job* faz com que o *estado atual* para esse *Job* esteja mais perto do seu
+*estado desejado*: creando *Pods* que fazem o trabalho desejado para esse *Job* para que
+o *Job* fique mais perto de ser completado.
+
+Controladores também atualizam os objetos que os configuram.
+Por exemplo: assim que o trabalho de um *Job* está completo,
+o controlador *Job* atualiza esse objeto *Job* para o marcar como `Finished` (terminado).
+
+(Isto é um pouco como alguns termostatos desligam uma luz para
+indicar que a temperatura da sala está agora na temperatura que foi introduzida).
+
+### Controlo direto
+
+Em contraste com *Job*, alguns controladores necessitam de efetuar
+mudanças a coisas fora do *cluster*.
+
+Por exemplo, se usar um ciclo de controlo para garantir que existem
+*{{< glossary_tooltip text="Nodes" term_id="node" >}}* suficientes
+no seu *cluster*, então esse controlador necessita de algo exterior ao
+*cluster* atual para configurar novos *Nodes* quando necessário.
+
+Controladores que interagem com estados externos encontram o seu estado desejado
+a partir do *API server*, e então comunicam diretamente com o sistema externo para
+trazer o *estado atual* mais próximo do desejado.
+
+(Existe um controlador que escala horizontalmente nós no seu *cluster*.
+Veja [Escalamento automático do cluster](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling))
+
+## Estado desejado versus atual {#desired-vs-current}
+
+Kubernetes leva uma visão *cloud-native* de sistemas, e é capaz de manipular
+mudanças constantes.
+
+O seu *cluster* pode mudar em qualquer altura à medida que o trabalho acontece e
+os ciclos de controlo corrigem falhas automaticamente. Isto significa que,
+potencialmente, o seu *cluster* nunca atinge um estado estável.
+
+Enquanto os controladores no seu *cluster* estiverem a correr e forem capazes de
+fazer alterações uteis, não importa se o estado é estável ou se é instável.
+
+## Desenho
+
+Como um principio do seu desenho, o Kubernetes usa muitos controladores onde cada
+um gere um aspeto particular do estado do *cluster*. Maioritariamente, um particular
+ciclo de controlo (controlador) usa uma espécie de recurso como o seu *estado desejado*,
+e tem uma espécie diferente de recurso que o mesmo gere para garantir que esse *estado desejado*
+é cumprido.
+
+É util que haja controladores simples em vez de um conjunto monolítico de ciclos de controlo
+que estão interligados. Controladores podem falhar, então o Kubernetes foi desenhado para
+permitir isso.
+
+Por exemplo: um controlador de *Jobs* rastreia objetos *Job* (para
+descobrir novos trabalhos) e objetos *Pod* (para correr o *Jobs*, e então
+ver quando o trabalho termina). Neste caso outra coisa cria os *Jobs*,
+enquanto o controlador *Job* cria *Pods*.
+
+{{< note >}}
+Podem existir vários controladores que criam ou atualizam a mesma espécie (kind) de objeto.
+Atrás das cortinas, os controladores do Kubernetes garantem que eles apenas tomam
+atenção aos recursos ligados aos seus recursos controladores.
+
+Por exemplo, você pode ter *Deployments* e *Jobs*; ambos criam *Pods*.
+O controlador de *Job* não apaga os *Pods* que o seu *Deployment* criou,
+porque existe informação ({{< glossary_tooltip term_id="label" text="labels" >}})
+que os controladores podem usar para diferenciar esses *Pods*.
+{{< /note >}}
+
+## Formas de correr controladores {#running-controllers}
+
+O Kubernetes vem com um conjunto de controladores embutidos que correm
+dentro do {{< glossary_tooltip term_id="kube-controller-manager" >}}.
+Estes controladores embutidos providenciam comportamentos centrais importantes.
+
+O controlador *Deployment* e o controlador *Job* são exemplods de controladores
+que veem como parte do próprio Kubernetes (controladores "embutidos").
+O Kubernetes deixa voce correr o plano de controlo resiliente, para que se qualquer
+um dos controladores embutidos falhar, outra parte do plano de controlo assume
+o trabalho.
+
+Pode encontrar controladores fora do plano de controlo, para extender o Kubernetes.
+Ou, se quiser, pode escrever um novo controlador você mesmo.
+Pode correr o seu próprio controlador como um conjunto de *Pods*,
+ou externo ao Kubernetes. O que encaixa melhor vai depender no que esse
+controlador faz em particular.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+* Leia mais sobre o [plano de controlo do Kubernetes](/docs/concepts/#kubernetes-control-plane)
+* Descubra alguns dos [objetos Kubernetes](/docs/concepts/#kubernetes-objects) básicos.
+* Aprenda mais sobre [API do Kubernetes](/docs/concepts/overview/kubernetes-api/)
+* Se pretender escrever o seu próprio controlador, veja [Padrões de Extensão](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)
+{{% /capture %}}
From 106935c0ef67556bd363eaeda0b1e29ff33d6e27 Mon Sep 17 00:00:00 2001
From: joao-luna-98
Date: Mon, 23 Mar 2020 15:05:56 +0000
Subject: [PATCH 027/440] Translate glossary entry.
---
content/pt/docs/reference/_index.md | 53 +++++++++++++++++++
.../pt/docs/reference/glossary/controller.md | 30 +++++++++++
2 files changed, 83 insertions(+)
create mode 100644 content/pt/docs/reference/_index.md
create mode 100755 content/pt/docs/reference/glossary/controller.md
diff --git a/content/pt/docs/reference/_index.md b/content/pt/docs/reference/_index.md
new file mode 100644
index 0000000000..7efffa4ef6
--- /dev/null
+++ b/content/pt/docs/reference/_index.md
@@ -0,0 +1,53 @@
+---
+title: Reference
+approvers:
+- chenopis
+linkTitle: "Reference"
+main_menu: true
+weight: 70
+content_template: templates/concept
+---
+
+{{% capture overview %}}
+
+This section of the Kubernetes documentation contains references.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## API Reference
+
+* [Kubernetes API Overview](/docs/reference/using-api/api-overview/) - Overview of the API for Kubernetes.
+* [Kubernetes API Reference {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
+
+## API Client Libraries
+
+To call the Kubernetes API from a programming language, you can use
+[client libraries](/docs/reference/using-api/client-libraries/). Officially supported
+client libraries:
+
+- [Kubernetes Go client library](https://github.com/kubernetes/client-go/)
+- [Kubernetes Python client library](https://github.com/kubernetes-client/python)
+- [Kubernetes Java client library](https://github.com/kubernetes-client/java)
+- [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript)
+
+## CLI Reference
+
+* [kubectl](/docs/reference/kubectl/overview/) - Main CLI tool for running commands and managing Kubernetes clusters.
+ * [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl.
+* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.
+
+## Config Reference
+
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - The primary *node agent* that runs on each node. The kubelet takes a set of PodSpecs and ensures that the described containers are running and healthy.
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - REST API that validates and configures data for API objects such as pods, services, replication controllers.
+* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes.
+* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of back-ends.
+* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - Scheduler that manages availability, performance, and capacity.
+
+## Design Docs
+
+An archive of the design docs for Kubernetes functionality. Good starting points are [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and [Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
+
+{{% /capture %}}
diff --git a/content/pt/docs/reference/glossary/controller.md b/content/pt/docs/reference/glossary/controller.md
new file mode 100755
index 0000000000..aa1a3f68e5
--- /dev/null
+++ b/content/pt/docs/reference/glossary/controller.md
@@ -0,0 +1,30 @@
+---
+title: Controlador
+id: controller
+date: 2020-03-23
+full_link: /docs/concepts/architecture/controller/
+short_description: >
+ Um ciclo de controlo que observa o estado partilhado do cluster através do apiserver e efetua
+ mudanças tentando mover o estado atual em direção ao estado desejado.
+
+aka:
+tags:
+- architecture
+- fundamental
+---
+No Kubernetes, controladores são ciclos de controlo que observam o estado do seu
+{{< glossary_tooltip term_id="cluster" text="cluster">}}, e então fazer ou requisitar
+mudanças onde necessário.
+Cada controlador tenta mover o estado atual do cluster mais perto do estado desejado.
+
+
+
+Controladores observam o estado partilhado do cluster através do
+{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} (parte do
+{{< glossary_tooltip term_id="control-plane" >}}).
+
+Alguns controladores tambem correm dentro do plano de controlo, fornecendo ciclos
+de controlo que são centrais às operações do Kubernetes. Por exemplo: o controlador
+de *deployments*, o controlador de *daemonsets*, o controlador de *namespaces*, e o
+controlador de volumes persistentes (*persistent volumes*) (e outros) todos correm
+dentro do {{< glossary_tooltip term_id="kube-controller-manager" >}}.
From 8c788d7656d8d8a4b8d958d83ca5d7c8d038b83d Mon Sep 17 00:00:00 2001
From: joao-luna-98
Date: Mon, 23 Mar 2020 15:15:57 +0000
Subject: [PATCH 028/440] Fix some typos.
---
.../docs/concepts/architecture/controller.md | 26 +++++++++----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/content/pt/docs/concepts/architecture/controller.md b/content/pt/docs/concepts/architecture/controller.md
index 02efc70f71..cc696c962d 100644
--- a/content/pt/docs/concepts/architecture/controller.md
+++ b/content/pt/docs/concepts/architecture/controller.md
@@ -6,10 +6,10 @@ weight: 30
{{% capture overview %}}
-Em robótica e automação, um _control loop_ ou em português _ciclo de controlo_ é
+Em robótica e automação um _control loop_, ou em português _ciclo de controlo_, é
um ciclo não terminado que regula o estado de um sistema.
-Um exemplo de um ciclo de controlo é um termostato de uma sala.
+Um exemplo de ciclo de controlo é um termostato de uma sala.
Quando você define a temperatura, isso indica ao termostato
sobre o seu *estado desejado*. A temperatura ambiente real é o
@@ -31,14 +31,14 @@ têm um campo *spec* (especificação) que representa o *estado desejado*.
Os controladores para esse recurso são responsáveis por trazer o *estado atual*
mais perto do *estado desejado*.
-O controlador pode levar ele proprio a cabo a ação; é mais comum, no Kubernetes,
+O controlador pode levar ele próprio a cabo a ação; é mais comum, no Kubernetes,
um controlador enviar uma mensagem para o
{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} que tem
-efeitos colaterais uteis. Você vai ver exemplos disto abaixo.
+efeitos colaterais úteis. Você vai ver exemplos disto abaixo.
{{< comment >}}
Alguns controladores embutidos, como é o caso do controlador *namespace*, atuam em objetos
-que não têm uma especificação (*spec*). Por questões de simplicidade, esta página omite explicar
+que não têm uma especificação (*spec*). Por questões de simplicidade esta página omite explicar
esse detalhe.
{{< /comment >}}
@@ -49,14 +49,14 @@ controlador Kubernetes embutido. Controladores embutidos gerem estados através
interação com o *cluster API server*.
*Job* é um recurso do Kubernetes que corre um
-{{< glossary_tooltip term_id="pod" >}}, ou talvez vários *Pods*, com o objetivo de
+*{{< glossary_tooltip term_id="pod" >}}*, ou talvez vários *Pods*, com o objetivo de
executar uma tarefa e depois parar.
(Uma vez [agendado](/docs/concepts/scheduling/), objetos *Pod* passam a fazer parte objects become part of the
do *estado desejado* para um kubelet.
Quando o controlador *Job* observa uma nova tarefa ele garante que,
-algures no seu *cluster*, os kubelets num conjunto de nós (*Nodes*) estão correndo o numero
+algures no seu *cluster*, os kubelets num conjunto de nós (*Nodes*) estão correndo o número
correto de *Pods* para completar o trabalho.
O controlador *Job* não corre *Pods* ou *containers* ele próprio.
Em vez disso, o controlador *Job* informa o *API server* para criar ou remover *Pods*.
@@ -96,7 +96,7 @@ Veja [Escalamento automático do cluster](/docs/tasks/administer-cluster/cluster
## Estado desejado versus atual {#desired-vs-current}
-Kubernetes leva uma visão *cloud-native* de sistemas, e é capaz de manipular
+Kubernetes leva uma visão *cloud-native* de sistemas e é capaz de manipular
mudanças constantes.
O seu *cluster* pode mudar em qualquer altura à medida que o trabalho acontece e
@@ -104,17 +104,17 @@ os ciclos de controlo corrigem falhas automaticamente. Isto significa que,
potencialmente, o seu *cluster* nunca atinge um estado estável.
Enquanto os controladores no seu *cluster* estiverem a correr e forem capazes de
-fazer alterações uteis, não importa se o estado é estável ou se é instável.
+fazer alterações úteis, não importa se o estado é estável ou se é instável.
## Desenho
-Como um principio do seu desenho, o Kubernetes usa muitos controladores onde cada
+Como um princípio do seu desenho, o Kubernetes usa muitos controladores onde cada
um gere um aspeto particular do estado do *cluster*. Maioritariamente, um particular
ciclo de controlo (controlador) usa uma espécie de recurso como o seu *estado desejado*,
e tem uma espécie diferente de recurso que o mesmo gere para garantir que esse *estado desejado*
é cumprido.
-É util que haja controladores simples em vez de um conjunto monolítico de ciclos de controlo
+É útil que haja controladores simples em vez de um conjunto monolítico de ciclos de controlo
que estão interligados. Controladores podem falhar, então o Kubernetes foi desenhado para
permitir isso.
@@ -140,9 +140,9 @@ O Kubernetes vem com um conjunto de controladores embutidos que correm
dentro do {{< glossary_tooltip term_id="kube-controller-manager" >}}.
Estes controladores embutidos providenciam comportamentos centrais importantes.
-O controlador *Deployment* e o controlador *Job* são exemplods de controladores
+O controlador *Deployment* e o controlador *Job* são exemplos de controladores
que veem como parte do próprio Kubernetes (controladores "embutidos").
-O Kubernetes deixa voce correr o plano de controlo resiliente, para que se qualquer
+O Kubernetes deixa você correr o plano de controlo resiliente, para que se qualquer
um dos controladores embutidos falhar, outra parte do plano de controlo assume
o trabalho.
From 48bff139ee60e21c5fe8407193be1a7a9e917d03 Mon Sep 17 00:00:00 2001
From: James Spurin
Date: Mon, 23 Mar 2020 16:17:29 +0000
Subject: [PATCH 029/440] updated with FR equivalent for PR19774
---
content/fr/docs/concepts/storage/persistent-volumes.md | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/content/fr/docs/concepts/storage/persistent-volumes.md b/content/fr/docs/concepts/storage/persistent-volumes.md
index e62c996ddb..3dca122abe 100644
--- a/content/fr/docs/concepts/storage/persistent-volumes.md
+++ b/content/fr/docs/concepts/storage/persistent-volumes.md
@@ -334,6 +334,10 @@ spec:
server: 172.17.0.2
```
+{{< note >}}
+Des logiciel additionnels supportant un type de montage de volume pourraient être nécessaires afin d'utiliser un PersistentVolume depuis un cluster. Dans l'exemple d'un PersistentVolume de type NFS, le logiciel additionnel `/sbin/mount.nfs` est requis pour permettre de monter des systèmes de fichiers de type NFS.
+{{< /note >}}
+
### Capacité
Généralement, un PV aura une capacité de stockage spécifique.
From 42c06c02f5dd9600af01e4172a5f1559e13aee35 Mon Sep 17 00:00:00 2001
From: Florian Ruynat
Date: Tue, 24 Mar 2020 17:06:18 +0100
Subject: [PATCH 030/440] Update kubespray page on kubernetes website
---
.../production-environment/tools/kubespray.md | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md
index 929ebce5bd..996f588dc7 100644
--- a/content/en/docs/setup/production-environment/tools/kubespray.md
+++ b/content/en/docs/setup/production-environment/tools/kubespray.md
@@ -6,7 +6,7 @@ weight: 30
{{% capture overview %}}
-This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).
+This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).
Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
@@ -33,9 +33,9 @@ To choose a tool which best fits your use case, read [this comparison](https://g
Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements):
-* **Ansible v2.5 (or newer) and python-netaddr is installed on the machine that will run Ansible commands**
+* **Ansible v2.7.8 and python-netaddr is installed on the machine that will run Ansible commands**
* **Jinja 2.9 (or newer) is required to run the Ansible Playbooks**
-* The target servers must have **access to the Internet** in order to pull docker images
+* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/downloads.md#offline-environment))
* The target servers are configured to allow **IPv4 forwarding**
* **Your ssh key must be copied** to all the servers part of your inventory
* The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall
@@ -59,14 +59,14 @@ Kubespray provides the ability to customize many aspects of the deployment:
* Choice deployment mode: kubeadm or non-kubeadm
* CNI (networking) plugins
* DNS configuration
-* Choice of control plane: native/binary or containerized with docker or rkt
+* Choice of control plane: native/binary or containerized
* Component versions
* Calico route reflectors
* Component runtime options
* {{< glossary_tooltip term_id="docker" >}}
- * {{< glossary_tooltip term_id="rkt" >}}
+ * {{< glossary_tooltip term_id="containerd" >}}
* {{< glossary_tooltip term_id="cri-o" >}}
-* Certificate generation methods (**Vault being discontinued**)
+* Certificate generation methods
Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
@@ -110,7 +110,7 @@ When running the reset playbook, be sure not to accidentally target your product
## Feedback
-* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/)
+* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/))
* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
{{% /capture %}}
From 92d63939d3aaf0f422ef71e6709cd125abfa50f4 Mon Sep 17 00:00:00 2001
From: Felipe
Date: Wed, 25 Mar 2020 17:33:02 +0000
Subject: [PATCH 031/440] Adding pt/docs/contribute/_index (#19700)
* Adding contribute/_index
* Adding contribute/_index
* Update content/pt/docs/contribute/_index.md
Co-Authored-By: Jhon Mike
* Update content/pt/docs/contribute/_index.md
Co-Authored-By: Jhon Mike
* Update content/pt/docs/contribute/_index.md
Co-Authored-By: Jhon Mike
* Update content/pt/docs/contribute/_index.md
Co-Authored-By: Jhon Mike
* Update content/pt/docs/contribute/_index.md
Co-Authored-By: Jhon Mike
* Update content/pt/docs/contribute/_index.md
Co-Authored-By: Jhon Mike
Co-authored-by: Jhon Mike
---
content/pt/docs/contribute/_index.md | 61 ++++++++++++++++++++++++++++
1 file changed, 61 insertions(+)
create mode 100644 content/pt/docs/contribute/_index.md
diff --git a/content/pt/docs/contribute/_index.md b/content/pt/docs/contribute/_index.md
new file mode 100644
index 0000000000..0e947a36a2
--- /dev/null
+++ b/content/pt/docs/contribute/_index.md
@@ -0,0 +1,61 @@
+---
+content_template: templates/concept
+title: Contribua com o Kubernetes docs
+linktitle: Contribute
+main_menu: true
+weight: 80
+---
+
+{{% capture overview %}}
+
+Caso você gostaria de contribuir com a documentação ou o site do Kubernetes,
+ficamos felizes em ter sua ajuda! Qualquer pessoa pode contribuir, seja você novo no
+projeto ou se você já esta no mercado há muito tempo. Além disso, Se você se identifica como
+desenvolvedor, usuário final ou alguém que simplesmente não suporta ver erros de digitação.
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Começando
+
+Qualquer pessoa pode abrir uma issue descrevendo o problema ou melhorias desejadas com a documentação ou contribuir com uma alteração e uma solicitação de mudança (Pull Request - PR).
+Algumas tarefas exigem mais confiança e precisam de mais acesso na organização Kubernetes.
+Veja [Participando do SIG Docs](/docs/contribute/participating/) para mais detalhes sobre
+as funções e permissões.
+
+A documentação do Kubernetes reside em um repositório do GitHub. Nós damos as boas-vindas
+a todas as contribuições, mas você vai precisa estar familiarizado com o uso básico de git e GitHub para
+operar efetivamente na comunidade Kubernetes.
+
+Para se envolver com a documentação:
+
+1. Assine o [Contrato de Licença de Colaborador](https://github.com/kubernetes/community/blob/master/CLA.md) do CNCF.
+2. Familiarize-se com o [repositório de documentação](https://github.com/kubernetes/website) e o [gerador de site estático](https://gohugo.io) hugo.
+3. Certifique-se de entender os processos básicos para [melhorar o conteúdo](https://kubernetes.io/docs/contribute/start/#improve-existing-content) e [revisar alterações](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests).
+
+## Melhores Práticas recomendadas para contribuições
+
+- Escreva mensagens GIT claras e significativas.
+- Certifique-se de incluir _Github Special Keywords_ que faz referência a issue e o fecha automaticamente quando o PR é mergeado.
+- Quando você faz uma pequena alteração em um PR, como corrigir um erro de digitação, qualquer alteração de estilo ou gramática, certifique-se de esmagar seus commits (squash) para não obter um grande número de commits por uma alteração relativamente pequena.
+- Certifique-se de incluir uma boa descrição de PR explicando as alterações no código, o motivo de alterar um trecho de código e garantir que haja informações suficientes para o revisor entender seu PR.
+- Leituras adicionais:
+ - [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/)
+ - [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests )
+ - [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git )
+
+## Outras maneiras de contribuir
+
+- Para contribuir com a comunidade Kubernetes por meio de fóruns on-line, como Twitter ou Stack Overflow, ou aprender sobre encontros locais e eventos do Kubernetes, visite o a area de [comunidade Kubernetes](/community/).
+- Para contribuir com o desenvolvimento de novas funções, leia o [cheatsheet do colaborador](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) para começar.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+- Para obter mais informações sobre os conceitos básicos de contribuição para a documentação, leia [Comece a contribuir](/docs/contribute/start/).
+- Siga o [Guia de estilo de documentação do Kubernetes](/docs/contribute/style/style-guide/) ao propor mudanças.
+- Para mais informações sobre o SIG Docs, leia [Participando do SIG Docs](/docs/contribute/participating/).
+- Para mais informações sobre a localização de documentos do Kubernetes, leia [Localização da documentação do Kubernetes](/docs/contribute/localization/).
+
+{{% /capture %}}
From 998fba98d72069a70a8ce5fc2980def92654218d Mon Sep 17 00:00:00 2001
From: Vineeth Pothulapati
Date: Thu, 26 Mar 2020 00:30:25 +0530
Subject: [PATCH 032/440] Official 1.18 Release Docs (#19116)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* Requesting for Approve Permisssions (#18550)
As I will be part of kubernetes 1.18 docs release team. Approve permissions will help me in approving the 1.18 docs enhnacemnts.
Signed-off-by: vineeth
* Change config on dev-1.18 branch to prepare for v1.18 release
(#18557)
* Changed config.toml from v1.17 to v1.18
As a part of kubernetes 1.18 release work.
Signed-off-by: vineeth
* Removed the older prior version
i.e v1.13
Signed-off-by: vineeth
* Added missing v1.17 block into config.toml
Signed-off-by: vineeth
* Requesting for Approve Permisssions (#18550)
As I will be part of kubernetes 1.18 docs release team. Approve permissions will help me in approving the 1.18 docs enhnacemnts.
Signed-off-by: vineeth
* Change config on dev-1.18 branch to prepare for v1.18 release
(#18557)
* Changed config.toml from v1.17 to v1.18
As a part of kubernetes 1.18 release work.
Signed-off-by: vineeth
* Removed the older prior version
i.e v1.13
Signed-off-by: vineeth
* Added missing v1.17 block into config.toml
Signed-off-by: vineeth
* add kubectl diff in common operations (#18665)
* bootstrap-tokens: promote to GA in 1.18 (#18428)
* Updated version for the HPA configurable scaling feature (#18965)
Signed-off-by: Arjun Naik
* kubeadm: add notes about deprecating kube-dns usage in 1.18 (#18851)
* kubeadm: add notes about deprecating kube-dns usage in 1.18
* implementation-details: update notes about DNS
* Sync up between dev-1.18 and master branches (#19055)
* Fixed outdated ECR credential debug message (#18631)
* Fixed outdated ECR credential debug message
The log message for troubleshooting kubelet auto fetching ECR credentils issue has been changed (noticed since 1.14), and the new message reads like this when verbose log level is set to 3:
- `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API`
- `aws_credentials.go:116] Got ECR credentials from ECR API for .dkr.ecr.us-east-1.amazonaws.com`
This is based on the kubelet source code:
https://github.com/kubernetes/kubernetes/blob/release-1.14/pkg/credentialprovider/aws/aws_credentials.go#L91
This PR is to fix this and to avoid confusion for more people who are troubleshooting the kubelet ECR issue.
* Update content/en/docs/concepts/containers/images.md
Co-Authored-By: Tim Bannister
Co-authored-by: Tim Bannister
* Fix deployment name in docs/tasks/administer-cluster/dns-horizontal-autoscaling.md (#18772)
* ru/docs/tutorials/hello-minikube.md: sync with English translation. (#18687)
* content/ru/docs/concepts/_index.md: use English names for kinds. (#18613)
* Fix French typo in "when" section (#18786)
* First Japanese l10n work for release-1.16 (#18790)
* Translate concepts/services-networking/connect-applications-service/ into Japanese (#17710)
* Translate concepts/services-networking/connect-applications-service/ into Japanese
* Apply review
* Translate content/ja/docs/tasks/_index.md into Japanese (#17789)
* add task index
* huge page
* ja-docs: Update kops Installation Steps (#17804)
* Update /ja/docs/tasks/tools/install-minikube/ (#17711)
* Update /ja/docs/tasks/tools/install-minikube/
* Apply review
* Apply review
* Update content/ja/docs/tasks/tools/install-minikube.md
Co-Authored-By: inductor
* Update content/ja/docs/tasks/tools/install-minikube.md
Co-Authored-By: inductor
* Translate tasks/configure-pod-container/assign-cpu-resource/ in Japanese (#16160)
* copy from content/en/docs/tasks/configure-pod-container/ to ja
* translate assign-cpu-resource.md in Japanese
* Update content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md
Co-Authored-By: inductor
* Update content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md
Co-Authored-By: Naoki Oketani
* Update assign-cpu-resource.md
ここの *request* と *limit* はほかの文中の単語とは異なり、YAMLのfieldを表すため、訳さないでおく
* fix translation
"Pod scheduling is based on requests." の箇所。
requestsに基づいているのは事実だが、直訳されたときになにを指すのかあいまいなので、対象を具体的に記述
* Translate concepts/workloads/controllers/deployment/ in Japanese #14848 (#17794)
* ja-trans: Translate concepts/workloads/controllers/deployment/ into Japanese (#14848)
* ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848)
* ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848)
* ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848)
* little fix (#18135)
* update index (#18136)
* Update /ja/docs/setup/_index.md (#18139)
* Update /ja/docs/tasks/tools/install-kubectl/ (#18137)
* update /docs/ja/tasks/tools/install-kubectl/
* fix mongon
* apply reveiw
* Update /ja/docs/reference/command-line-tools-reference/feature-gates/ (#18141)
* Update feature agete
* tidy up feature gates list
* translate new lines
* table caption
* blank
* する -> します
* apply review
* fix broken link
* Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md
Co-Authored-By: Naoki Oketani
* update translation
* remove line
* Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md
Co-Authored-By: Naoki Oketani
* rollpack
* Update /ja/docs/concepts/services-networking/service/ (#18138)
* update /ja/docs/concepts/services-networking/service/
* Update content/ja/docs/concepts/services-networking/service.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/concepts/services-networking/service.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/concepts/services-networking/service.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/concepts/services-networking/service.md
Co-Authored-By: Naoki Oketani
* consider Endpoints as a Kubernetes resource
* full
* Update content/ja/docs/concepts/_index.md (#18145)
* Update concepts
* control plane
* apply review
* fix bold (#18165)
* Update /ja/docs/concepts/overview/components.md (#18153)
* update /ja/docs/concepts/overview/components.md
* some japanese docs are already there
* translate prepend
* apply upstream changes (#18278)
* Translate concepts/services-networking/ingress into Japanese #17741 (#18234)
* ja-trans: Translate concepts/services-networking/ingress into Japanese (#17741)
* ja-trans: Improve Japanese translation in concepts/services-networking/ingress (#17741)
* ja-trans: Improve Japanese translation in concepts/services-networking/ingress (#17741)
* Update pod overview in Japanese (#18277)
* Update pod-overview
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani
* ノード
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani
Co-authored-by: Naoki Oketani
* Translate concepts/scheduling/scheduler-perf-tuning/ in Japanese #17119 (#17796)
* ja-trans: Translate concepts/scheduling/scheduler-perf-tuning/ into Japanese (#17119)
* ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119)
* ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119)
* ja-trans:conetent/ja/casestudies/nav (#18450)
* Translate tasks/debug-application-cluster/debug-service/ in Japanese (#18395)
* Translate tasks/debug-application-cluster/debug-service/ in Japanese
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: inductor
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: inductor
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: inductor
* Change all `Pods` to `Pod` and `Endpoints` to `Endpoint`
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: inductor
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: inductor
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: inductor
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: inductor
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani
* Updated content pointed out in review
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani
* Apply suggestions from code review
Co-Authored-By: inductor
* Apply suggestions from review
* Apply suggestions form review
* Apply suggestions from review
* Apply suggestions from review
* Apply suggestions from code review
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani
Co-authored-by: inductor
Co-authored-by: Naoki Oketani
* Translate concepts/extend-kubernetes/api-extension/custom-resources/ into Japanese (#18200)
* Translate concepts/extend-kubernetes/api-extension/custom-resources/ into Japanese
* Apply suggestions from code review between L1 an L120 by oke-py
Co-Authored-By: Naoki Oketani
* Apply suggestions from code review by oke-py
Co-Authored-By: Naoki Oketani
* Update CustomResourceDefinition not to localize into Japanese
* Revert the link to customresourcedefinitions to English
Co-Authored-By: Naoki Oketani
* Apply suggestions from code review by oke-py and inductor
Co-Authored-By: Naoki Oketani
Co-Authored-By: inductor
* Apply a suggestion from review by inductor
* Apply a suggestion from code review by oke-py
Co-Authored-By: Naoki Oketani
Co-authored-by: Naoki Oketani
Co-authored-by: inductor
* Translate tasks/configure-pod-container/quality-service-pod/ into Japanese (#16173)
* copy from content/en/docs/tasks/configure-pod-container/quality-service-pod.md to Ja
* Translate tasks/configure-pod-container/quality-service-pod/ into Japanese
Guaranteed, Burstable, BestEffortは用語として存在するので訳さない
Signed-off-by: Takuma Hashimoto
* Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md
Co-Authored-By: Naoki Oketani
* Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md
Co-Authored-By: Naoki Oketani
Co-authored-by: Naoki Oketani
* Translate content/ja/docs/reference/kubectl/cheatsheet.md (#17739) (#18285)
* Translate content/ja/docs/reference/kubectl/cheatsheet.md (#17739)
* Translated kubectl cheet sheet.
* Fix typos in content/ja/docs/reference/kubectl/cheatsheet.md (#17739)
* Fix japanese style in content/ja/docs/reference/kubectl/cheatsheet.md
* Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md
* Fix translation in content/ja/docs/reference/kubectl/cheatsheet.md
* Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md
* Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md
* Modify translation for casestudies (#18767)
* modify terminology
* add ten
* update translation
* update
* update
* update
* fix typo (#18769)
* remove english comment (#18770)
* ja-trans:conetent/ja/casestudies/spotify (#18451)
* ja-trans: content/ja/case-studies/spotify
* Update content/ja/case-studies/spotify/index.html
Updated with the proposal from inductor
Co-Authored-By: inductor
* Update content/ja/case-studies/spotify/index.html
Updated with inductor 's proposal
Co-Authored-By: inductor
* ja-trans: content/ja/case-studies/spotify
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor
Co-authored-by: inductor
* Translate Japanese headers (#18776)
* translate headers
* add index for references
* Update content/ja/docs/setup/production-environment/tools/_index.md
Co-Authored-By: Naoki Oketani
* translate controller
Co-authored-by: Naoki Oketani
* ja-docs: translate install-kubeadm into Japanese (#18198)
* ja-docs: translate install-kubeadm into Japanese
* translate table title in install-kubeadm to Japanese
* update kubeadm install doc
* remove extra spaces
* fix translation miss
* translate url title into japanese
* fix translation miss
* remove line break in sentence and translate title
* remove extra line break
* remove extra line break
* fix translation miss
Co-authored-by: Naoki Oketani
Co-authored-by: Samuel Kihahu
Co-authored-by: Takuma Hashimoto
Co-authored-by: Keita Akutsu
Co-authored-by: Masa Taniguchi
Co-authored-by: Soto Sugita
Co-authored-by: Kozzy Hasebe <48105562+hasebe@users.noreply.github.com>
Co-authored-by: kazuaki harada
Co-authored-by: Shunsuke Miyoshi
* delete zh SEE ALSO(51-54) (#18788)
* Added missing brackets in markdown (#18783)
* Fix broken links in api_changes doc (#18743)
* fix jump (#18781)
* fix redundant note (#18780)
* Fix typo: default-manager -> default-scheduler (#18709)
like #18649 #18708
* fix issue #18738 (#18773)
Signed-off-by: Dominic Yin
* Correct description of kubectl (#18172)
* Correct description of kubectl
Given that `kubectl` is not a [command line interface (CLI)](https://en.wikipedia.org/wiki/Command-line_interface), I suggest calling it what it is -- a control utility (ctl = control). The term "tool" is commonly used in place of "utility," including the `kubectl` docs.
A CLI presents the user with a command prompt at which the user can enter multiple command lines that a command-line interpreter interprets and processes. Think of `bash`, `emacs`, or a SQL shell. Since `kubectl` is not run in a shell, it is not a CLI.
Here are related docs that correctly refer to `kubectl` as a "command-line tool":
- https://kubernetes.io/docs/reference/tools/#kubectl
- https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-kubectl
- https://kubernetes.io/docs/tasks/tools/install-kubectl/
- https://kubernetes.io/docs/reference/kubectl/kubectl/
* Update content/en/docs/reference/kubectl/overview.md
Co-Authored-By: Zach Corleissen
Co-authored-by: Zach Corleissen
* Add blog post: Reviewing 2019 in Docs (#18662)
Tiny fix
Feedback from onlydole
Add missing link
Incremental fixes
Revise Jim's job title
Update content/en/blog/_posts/2020-01-17-Docs-Review-2019.md
Co-Authored-By: Celeste Horgan
Feedback from celeste, change date
* Update OWNERS_ALIASES (#18803)
* Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#16869)
* Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-authored-by: Bob Killen
Co-authored-by: Taylor Dolezal
* blog: introduce CSI support for ephemeral inline volumes (#16832)
* csi-ephemeral-inline-volumes: introduce CSI support for ephemeral inline volumes
This was alpha in Kubernetes 1.15 and became beta in 1.16. Several CSI
drivers already support it (soon...).
* csi-ephemeral-inline-volumes: bump date and address feedback (NodeUnpublishVolume)
* csi-ephemeral-inline-volumes: add examples and next steps
* csi-ephemeral-inline-volumes: rename file, minor edits
* csi-ephemeral-inline-volumes: include Docker example
* Create 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md (#18062)
* Create 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md
* Update and rename 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md to 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md
* Update 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md
* Update and rename 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md to 2019-01-22-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md
Co-authored-by: Kaitlyn Barnard
* Revert "Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#16869)" (#18805)
This reverts commit 2c4545e105570f76b74bfb6af35457c7e2c021d2.
* add blog k8s on mips (#18795)
* add blog k8s on mips
* modify english title to chinese
* modify some error
* Remove user-journeys legacy content #18615 (#18779)
* Use monospace for HostFolder and VM in the French Minikube setup guide. (#18749)
* Add French version of persistent volume page concept page (#18706)
* Add French version of persistent volume page concept page
* Fix
* Fix
* Fix
* Fix
* sync content/zh/docs/reference/issues-security/ en zh (#18727)
* update zh-translation: /docs/concepts/storage/volume-snapshots.md (#18650)
* Clean up user journeys content for zh (#18815)
* Followup fixes for: Add resource version section to api-concepts (#18069)
* Followup fixes for: Add resource version section to api-concepts documentation
* Apply feedback
* Apply feedback
* Switch paragraph to active voice
* Add Community and Code of Conduct for ID (#18828)
* Add additional ways to contribute part to update zh doc (#18762)
* Add additional ways to contribute part to update zh doc
* Add original English text
* Update content/zh/docs/contribute/_index.md
Co-Authored-By: chentanjun
Co-authored-by: chentanjun
* Clean up extensions/v1beta1 in docs (#18839)
* fix an example path (#18848)
* Translating network plugins (#17184)
* Fix for a typo (#18822)
* tą instalację -> tę instalację / (https://sjp.pwn.pl/poradnia/haslo/te-czy-ta;1598.html) (#18801)
* Fix typo in Scalability section (#18866)
The phrase `very larger` is not valid, it is supposed to be either `very
large` or `larger`. Propose to have it `very large`.
Signed-off-by: Mariyan Dimitrov
* Add Polish translation of Contribute index page (#18775)
Co-Authored-By: Michał Sochoń
Co-authored-by: Michał Sochoń
* Clean up extensions/v1beta1 in docs (#18838)
* Add Indonesian Manage Compute Resources page (#18468)
* Add Indonesian Manage Compute Resources page
* Updates to id Manage Compute Resources page
* Add DaemonSet docs ID localization (#18632)
Signed-off-by: giovanism
* Fix typo in en/docs/contribute/style/content-guilde.md (#18862)
* partial fix for SEE ALSO section under content/zh/docs/reference/setup-tools/kubeadm/generated/ need to be deleted #18411 (#18875)
* See Also removed file 31
* see also removed file 32
* see also removed file 33
* see also removed file 34
* see also removed file 35
* Modify pod.md (#18818)
website/content/ko/docs/concepts/workloads/pods/pod.md
23 line
쿠버네티스는는 -> 쿠버네티스는
modify
* remove $ following the style guide (#18855)
* Add Hyperlink to Kubernetes API (#18852)
* Drive by copy edit of blog post (#18881)
* Medium copy edit.
* more fixes
* Translate Events Calendar (#18860)
* Adding Bahasa Indonesia translation for Device Plugin page #18676 (#18676)
Co-Authored-By: Gede Wahyu Adi Pramana
Co-authored-by: Gede Wahyu Adi Pramana
* change escaped chars to markdown (#18858)
Helps to keep doc clean for long term
* Fix header layout on Safari (#18888)
* Fix references to sig-docs-l10n-admins (#18661)
* Add French deployment concept page (#18516)
* Add French deployment concept page
* Fix
* Fix
* Fix
* Update content/fr/docs/concepts/workloads/controllers/deployment.md
Co-Authored-By: Tim Bannister
* Fix
* Fix
* Fix
* Update content/fr/docs/concepts/workloads/controllers/deployment.md
Co-Authored-By: Tim Bannister
* Update content/fr/docs/concepts/workloads/controllers/deployment.md
Co-Authored-By: Tim Bannister
* Update content/fr/docs/concepts/workloads/controllers/deployment.md
Co-Authored-By: Tim Bannister
* Update content/fr/docs/concepts/workloads/controllers/deployment.md
Co-Authored-By: Tim Bannister
Co-authored-by: Tim Bannister
* Fix ZH security aliases (#18895)
* disable simplytunde as an approver due to inactivity. (#18899)
Always welcome to come back if able to become active
again
Signed-off-by: Brad Topol
* install container runtimes without prompts (#18893)
In Kubernetes docs, all of the packages that are required to set up the
Kubernetes are installed without requiring any prompts through
the package manager (like apt or yum) except for the container runtimes.
https://kubernetes.io/docs/setup/production-environment/container-runtimes/
So, it would be better to have these installations with prompts (yes) disabled.
* Fix small typos (#18886)
* Fix small typos
Small typos noticed and fixed in:
- configure-upgrade-etcd.md
- reconfigure-kubelet.md
Signed-off-by: Mariyan Dimitrov
* Rephrase a paragraph on etcd upgrade
en\docs\tasks\administer-cluster\configure-upgrade-etcd.md
Following a suggestion in #18886, I've rephrased a sentence on etcd
upgrade prerequisites.
Signed-off-by: Mariyan Dimitrov
* Clean up extensions/v1beta1 in docs (#18841)
* Update _index.md (#18825)
* Run minikube docker-env in a shell-independent way (#18823)
* doc: correct pv status for pv protection example. (#18816)
* Small editorial fixes in glossary entries (#18807)
* Small editorial fixes in glossary entries
* Revert the wording in the glossary term for proxy
* fix doc conflict regarding postStart (#18806)
* kubeadm: improvements to the cert management documentation (#18397)
- move the sections about custom certificates and external CA
to the kubeadm-certs page
- minor cleanups to the kubeadm-certs page, including updated output
for the check-expiration command
- link the implementation details page to the new locations
for custom certs and external CA
* fix doc conflict regarding postStart
* Grammar (#18785)
* grammar: 'to' distributes over 'or'
* grammar: reword
per app.grammarly.com
* grammar: simplify
from app.grammarly.com
* spelling: etc.
* feat: add ephermeral container approach inside pod debug page. (#18754)
* doc: add pod security policy reference link to document. (#18729)
* doc: add pod security policy reference link to document.
* doc: add what's next for pod-security-policy ref.
* Revise version requirements (#18688)
Assume that the reader is running a version of Kubernetes that supports
the Secret resource.
* en: Remove kubectl duplicate example (#18656)
With #16974 and the removal of --include-uninitialized flag, the
second
and third examples of kubectl delete become equal, thus leading to
duplication and being confusing. Suggest to remove the duplicate and
replace it with another example in the future if needed.
Observed in v1.16 and v1.17 documentation.
Signed-off-by: Mariyan Dimitrov
* Fix typo for tasks/access-kubernetes-api/configure-aggregation-layer.md (#18652)
* Unify runtime references (#18493)
- Use the glossary to correctly reference runtimes
- Updated runtime class documentation for CRI-O
- Removed rktlet from runtimes since its EOL
Signed-off-by: Sascha Grunert
* Clean up admission controller deprecation example (#18399)
* sync zh-trans content/zh/docs/concepts/workloads/pods/ephemeral-containers.md (#18883)
* Remove redundant information when deploy flannel on kubernetes include windows node (#18272)
* sync zh-trans content/zh/docs/concepts/workloads/pods/pod-overview.md (#18882)
* partial fix for for SEE ALSO section under content/zh/docs/reference/setup-tools/kubeadm/generated/ need to be deleted (#18879)
* see also removed from file 36
* see also removed from file 37
* see also removed from file 38
* see also removed from file 39
* see also removed from file 40
* update zh content/zh/docs/contribute/style/write-new-topic.md (#18859)
* sync zh-trans /docs/concepts/_index.md and /docs/concepts/example-concept-template.md (#18863)
* See also removed file 56 & 57 (#18912)
* see also removed file 56
* see also removed file 57
* Third Korean L10n Work For Release 1.17 (#18915)
* Changed some words in the IPv4/IPv6 dual-stack korean doc. (#18668)
* Update to Outdated files in dev-1.17-ko.3 branch. (#18580)
* Translate content/ko/docs/concepts/services-networking/service in Korean (#18195)
* Translate docs/tasks/access-application-cluster/port-forward-access-application-cluster.md in Korean (#18721)
* Translate controllers/garbage-collection.md in Korean. (#18595)
Co-Authored-by: Seokho Son
Co-Authored-by: Lawrence Kay
Co-Authored-by: Jesang Myung
Co-Authored-by: Claudia J.Kang
Co-Authored-by: Yuk, Yongsu
Co-Authored-By: June Yi
Co-authored-by: Yuk, Yongsu
Co-authored-by: Seokho Son
Co-authored-by: Lawrence Kay
Co-authored-by: Jesang Myung
Co-authored-by: June Yi
* clean up makefile, config (#18517)
Added target for createversiondirs (shell script) in Makefile.
updates for tagged release
regenerate api ref, rm Makefile_temp
add parens to pip check
* Improve Russian translation of Home page (#17841)
* Improve Russian translation of Home page
* Update i18n/ru.toml
Co-Authored-By: Slava Semushin
* Update content/ru/_index.html
Co-Authored-By: Slava Semushin
* Update content/ru/_index.html
Co-Authored-By: Slava Semushin
Co-authored-by: Slava Semushin
* update ref link for v1.16 (#18837)
Related to issue #18820.
remove links to prev API refs
* Cleanup user journeys related configs and scripts (#18814)
* See also removed file 81 to 85 (#18909)
* see also removed file 81
* see also removed file 82
* see also removed file 83
* see also removed file 84
* see also removed file 85
* See also removed file 65 to 70 (#18908)
* see also removed file 65
* see also removed file 66
* see also removed file 67
* see also removed file 68
* see also removed file 69
* see also removed file 70
* Translate Task index page into Polish (#18876)
Co-Authored-By: Karol Pucyński
Co-Authored-By: Michał Sochoń
Co-authored-by: Karol Pucyński <9209870+kpucynski@users.noreply.github.com>
Co-authored-by: Michał Sochoń
* Document dry-run authorization requirements (#18235)
* Document dry-run write access requirement.
- Add section on dry-run authorization
- Refer to dry-run authorization for diff
- Consistently hyphenate dry-run
* Update content/en/docs/reference/using-api/api-concepts.md
Co-Authored-By: Tim Bannister
Co-authored-by: Tim Bannister
* reword storage release note to match the change in k/k PR #87090 (#18921)
* sync zh-trans content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md (#18868)
* See also removed file 60 to 63 (#18907)
* see also removed file 60
* see also removed file 61
* see also removed file 62
* see also removed file 63
* See also removed file 91 to 95 (#18910)
* see also removed file 91
* see also removed file 93
* see also removed file 94
* see also removed file 95
* content/zh/docs/concepts/workloads/pods/podpreset.md (#18870)
* fix: fixed eating initial 2 spaces inside code. (#18914)
* Update Calico section of kubeadm install guide (#18821)
* Update Calico section of kubeadm install guide
* Address review feedback
* See also removed file 96 to 100 (#18911)
* see also removed file 96
* see also removed file 97
* see also removed file 98
* see also removed file 99
* see also removed file 100
* repair zh docs in kubeadm (#18949)
* repair zh docs about kubeadm (#18950)
* Update apparmor.md (#18951)
* Update basic-stateful-set.md (#18952)
* Add missing hyperlink for pod-overhead (#18936)
* Update service.md (#18480)
make article reads more smoothly
* zh-trans update content/zh/docs/concepts/workloads/controllers/deploy… (#18657)
* zh-trans update content/zh/docs/concepts/workloads/controllers/deployment.md
* zh-trans update content\zh\docs\concepts\workloads\controllers\deployment.md
* Update source-ip documentation (#18760)
* sync zh-trans /docs/concepts/workloads/pods/pod.md (#18880)
* sync zh-trans /docs/concepts/workloads/controllers/cron-jobs.md and /docs/concepts/workloads/controllers/daemonset.md (#18864)
* sync zh-trans content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md (#18867)
* Add a French version of Secret concept page (#18604)
* Add a French version of Secret concept page
* Fix
* Fix
* Update content/fr/docs/concepts/configuration/secret.md
Co-Authored-By: Tim Bannister
* Fix
* Update content/fr/docs/concepts/configuration/secret.md
Co-Authored-By: Aurélien Perrier
* Fix
Co-authored-by: Tim Bannister
Co-authored-by: Aurélien Perrier
* (refactor): Corrections (grammatical) in service.md file (#18944)
* Update service.md
* Fixed the invaild changes
Signed-off-by: Udit Gaurav
* Update container-runtimes.md (#18608)
for debian install of docker, also install gnupg2 for apt-key add to work
* Fix that dual-stack does not require Kubenet specifically (#18924)
* Fix that dual-stack does not require Kubenet specifically
Rather it requires a network plugin that supports dual-stack, and
others are available, including Calico.
* Update content/en/docs/tasks/network/validate-dual-stack.md
Added link to doc about network plugins
Co-Authored-By: Tim Bannister
Co-authored-by: Tim Bannister
* Revert "Configurable Scaling for the HPA (#18157)" (#18963)
This reverts commit 5dbfaafe1ac8875e09ea4ef05390ebc47ad290cb.
* Update horizontal-pod-autoscale-walkthrough.md (#18960)
Update command for creating php-apache deployment due to the following warning: `kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.`
* doc: add link for type=LoadBalancer service in tutorial. (#18916)
* Typo fix (#18830)
* sync zh-trans content/zh/docs/concepts/workloads/controllers/statefulset.md (#18869)
* Revise pull request template (#18744)
* Revise pull request template
* Reference compiled docs in PR template
Refer readers to https://k8s.io/contribute/start/
This keeps the template short, and it lets Hugo use templating for
the current version.
* Update certificates.md (#18970)
* Add web-ui-dashboard to French (#17974)
* Add web-ui-dashboard to French
* Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md
Co-Authored-By: Tim Bannister
* Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md
Co-Authored-By: Tim Bannister
* Fix
* Fix
* Fix
* Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md
Co-Authored-By: Tim Bannister
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
Co-authored-by: Tim Bannister
* Added a translated code of conduct (#18981)
* Added a translated code of conduct
* fixed some minor mistakes and capitalization
* Moved to informal speech
* Translate the contribute advanced page to French (#13425)
* Translate the contribute advanced page to French
* Corrections
* Correction
* Correction
* Correction
* Correction
* Correction
* Fix typo in hello-minikube.md (#18991)
* Add note for LB behaviour for cordoned nodes. (#18784)
* Add note for LB behaviour for cordoned nodes.
See also https://github.com/kubernetes/kubernetes/issues/65013
This is a reasonably common pitfall: `kubectl cordon ` will also drop all LB traffic to the cluster, but this is not documented anywhere but in issues, when found it is usually already too late.
* Update with feedback
* Add KIND as the options for spinning up a test kubernetes environment (#17860)
* fix typo in /ja/docs/concepts/workloads/pods/init-containers (#18997)
* hide some original comments in translate docs (#18986)
* hide original comment
* hide some original comments
* Fix code of conduct title (#19006)
* Added a note about built-in priority-classes (#18979)
* Added a note about build-in priority-classes
* Update content/en/docs/concepts/configuration/pod-priority-preemption.md
Co-Authored-By: Tim Bannister
Co-authored-by: Tim Bannister
* Add description for TTL (#19001)
* Fix whitespace on deployment page (#18990)
* Add details to the API deprecations blog post (#19014)
* Document list/map/structType and listMapKeys (#18977)
These markers where introduced to describe topology of lists, maps,
structs - primarily in support of server-side apply.
Secondarily, a small typo fix:)
* Remove "Unschedulable" pod condition type from the pod lifecycle docs (#18956)
The pod lifecycle documentation erroneously indicated `Unschedulable` as a possible `type` of pod condition. That's not true. Only four condition types exist. The `Unschedulable` value is not a type, but one of the possible reasons of the `PodScheduled` condition type.
* Revise “Encrypting Secret Data at Rest” (#18810)
* Drop reference to old Kubernetes versions
At the time of writing, Kubernetes v1.13 is the oldest supported
version, and encryption-at-rest is no longer alpha.
* Tidy whitespace
* Add table caption
* Set metadata for required Kubernetes version
* maintain the current relative path when switching to other site versions (#18871)
* Update kubectl create configmap section (#18885)
* Add common examples to Service Topology documentation (#18712)
* service topology: add missing 'enabling service topology' page
Signed-off-by: Andrew Sy Kim
* service topology: add common examples
Signed-off-by: Andrew Sy Kim
* updating contrib for ref docs (#18787)
more cleanup
* fix translate docs format (#19018)
* Update nodes.md (#19019)
* Translate Contribute index page into Russian (#19022)
* Added german translation for Addons page (#19010)
* Added german translation for Addons page
* Smaller adjustments
* removed a english leftover-sentence
* consistent spelling of "Add-Ons"
* Removed english entry for CoreDNS
* Update content/de/docs/concepts/cluster-administration/addons.md
Co-Authored-By: Tim Bannister
* Translated a heading
Co-authored-by: Tim Bannister
* (fix) Removed `-n test` from `kubectl get pv` command (#18877)
- PV are cluster scoped rather than namespaced scope
- So, there is no need to list it by namespace
Signed-off-by: Aman Gupta
* Link to setup page about Kind (#18996)
Link from /docs/setup/ to /docs/setup/learning-environment/kind/ now
that the target page exists.
* Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#18808)
* Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update and rename Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md to 2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-authored-by: Bob Killen