Merge branch 'kubernetes:main' into pod-configmap-env-var-valueFrom

Author: my-git9

content/en/docs/concepts/architecture/garbage-collection.md

@@ -13,7 +13,7 @@ allows the clean up of resources like the following:
   * [Objects without owner references](#owners-dependents)
   * [Unused containers and container images](#containers-images)
   * [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete)
-  * [Stale or expired CertificateSigningRequests (CSRs)](/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
+  * [Stale or expired CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
   * {{<glossary_tooltip text="Nodes" term_id="node">}} deleted in the following scenarios:
     * On a cloud when the cluster uses a [cloud controller manager](/docs/concepts/architecture/cloud-controller/)
     * On-premises when the cluster uses an addon similar to a cloud controller

content/en/docs/concepts/configuration/manage-resources-containers.md

@@ -134,7 +134,7 @@ Mi, Ki. For example, the following represent roughly the same value:
 128974848, 129e6, 129M,  128974848000m, 123Mi
 ```
 
-Take care about case for suffixes. If you request `400m` of memory, this is a request
+Pay attention to the case of the suffixes. If you request `400m` of memory, this is a request
 for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`)
 or 400 megabytes (`400M`).
 

content/en/docs/reference/command-line-tools-reference/feature-gates.md

@@ -126,7 +126,6 @@ of provisioning.
 2. [Token authentication file](#token-authentication-file)
 
 Bootstrap tokens are a simpler and more easily managed method to authenticate kubelets, and do not require any additional flags when starting kube-apiserver.
-Using bootstrap tokens is currently __beta__ as of Kubernetes version 1.12.
 
 Whichever method you choose, the requirement is that the kubelet be able to authenticate as a user with the rights to:
 

content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md

@@ -337,9 +337,9 @@ APIs, cluster administrators must ensure that:
    * For external metrics, this is the `external.metrics.k8s.io` API.  It may be provided by the custom metrics adapters provided above.
 
 For more information on these different metrics paths and how they differ please see the relevant design proposals for
-[the HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md),
-[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md)
-and [external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md).
+[the HPA V2](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md),
+[custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md)
+and [external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md).
 
 For examples of how to use them see [the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
 and [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects).

content/en/docs/tasks/run-application/horizontal-pod-autoscale.md

@@ -149,6 +149,7 @@ volumeMounts:
 最後に`hostPath`を設定します:
 ```yaml
 ...
+volumes:
 - name: audit
   hostPath:
     path: /etc/kubernetes/audit-policy.yaml
@@ -158,7 +159,6 @@ volumeMounts:
   hostPath:
     path: /var/log/audit.log
     type: FileOrCreate
-
 ```
 
 ### Webhookバックエンド

content/ja/docs/tasks/debug-application-cluster/audit.md

@@ -3,7 +3,6 @@ layout: blog
 title: "Atualizado: Perguntas frequentes (FAQ) sobre a remoção do Dockershim"
 date: 2022-02-17
 slug: dockershim-faq
-aliases: [ '/dockershim' ]
 ---
 
 **Esta é uma atualização do artigo original [FAQ sobre a depreciação do Dockershim](/blog/2020/12/02/dockershim-faq/),

content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md

@@ -25,4 +25,4 @@
 
 Открытость новым идеям и изученная технологическая эволюция делают Kubernetes более сильным проектом. Постоянное совершенствование, лидерство слуг, наставничество и уважение-вот основы культуры проекта Kubernetes. Лидеры сообщества Kubernetes обязаны находить, спонсировать и продвигать новых членов сообщества. Лидеры должны ожидать, что они отойдут в сторону. Члены сообщества должны ожидать, что они сделают шаг вперед.
 
-**"Culture eats strategy for breakfast."   --Peter Drucker**
+**"Культура съедает стратегию на завтрак" — Питер Друкер**

content/ru/community/static/community-values.md

@@ -2,6 +2,5 @@
 title: "Кластерная Архитектура"
 weight: 30
 description: >
-  The architectural concepts behind Kubernetes.
----
-
+  Архитектурные концепции, лежащие в основе Kubernetes.
+---

content/ru/docs/concepts/architecture/_index.md

@@ -8,7 +8,7 @@ weight: 40
 
 {{< feature-state state="beta" for_k8s_version="v1.11" >}}
 
-Технологии облачной инфраструктуры позволяет запускать Kubernetes в общедоступных, частных и гибридных облаках. Kubernetes верит в автоматизированную, управляемую API инфраструктуру без жесткой связи между компонентами.
+Технологии облачной инфраструктуры позволяют запускать Kubernetes в общедоступных, частных и гибридных облаках. Kubernetes верит в автоматизированную, управляемую API инфраструктуру без жесткой связи между компонентами.
 
 {{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="Диспетчер облачных контроллеров">}} 
 
@@ -33,21 +33,21 @@ weight: 40
 
 Контроллеры внутри диспетчера облачных контроллеров включают в себя:
 
-### Контролер узла
+### Контроллер узла
 
 Контроллер узла отвечает за создание объектов {{< glossary_tooltip text="узла" term_id="node" >}} при создании новых серверов в вашей облачной инфраструктуре. Контроллер узла получает информацию о работающих хостах внутри вашей арендуемой инфраструктуры облачного провайдера.
 Контроллер узла выполняет следующие функции:
 
 1. Инициализация объектов узла для каждого сервера, которые контроллер получает через API облачного провайдера.
 2. Аннотирование и маркировка объектов узла специфичной для облака информацией, такой как регион узла и доступные ему ресурсы (процессор, память и т.д.).
 3. Получение имени хоста и сетевых адресов.
-4. Проверка работоспособности узла. В случае, если узел перестает отвечать на запросы, этот контроллер проверяет с помощью API вашего облачного провайдера, был ли сервер деактивирован / удален / прекращен. Если узел был удален из облака, контроллер удлаяет объект узла из вашего Kubernetes кластера.
+4. Проверка работоспособности узла. В случае, если узел перестает отвечать на запросы, этот контроллер проверяет с помощью API вашего облачного провайдера, был ли сервер деактивирован / удален / прекращен. Если узел был удален из облака, контроллер удаляет объект узла из вашего Kubernetes кластера.
 
 Некоторые облачные провайдеры реализуют его разделение на контроллер узла и отдельный контроллер жизненного цикла узла.
 
-### Контролер маршрута
+### Контроллер маршрута
 
-Контролер маршрута отвечает за соответствующую настройку маршрутов в облаке, чтобы контейнеры на разных узлах кластера Kubernetes могли взаимодействовать друг с другом.
+Контроллер маршрута отвечает за соответствующую настройку маршрутов в облаке, чтобы контейнеры на разных узлах кластера Kubernetes могли взаимодействовать друг с другом.
 
 В зависимости от облачного провайдера, контроллер маршрута способен также выделять блоки IP-адресов для сети Pod-ов.
 
@@ -61,7 +61,7 @@ weight: 40
 
 ### Контроллер узла {#authorization-node-controller}
 
-Контроллер узла работает только с объектом узла. Он требует полного доступа для и изменения объектов узла.
+Контроллер узла работает только с объектом узла. Он требует полного доступа на чтение и изменение объектов узла.
 
 `v1/Node`:
 
@@ -73,9 +73,9 @@ weight: 40
 - Watch
 - Delete
 
-### Контролер маршрута {#authorization-route-controller}
+### Контроллер маршрута {#authorization-route-controller}
 
-Контролер маршрута прослушивает создание объектов узла и соответствующим образом настраивает маршруты. Для этого требуется получить доступ к объектам узла.
+Контроллер маршрута прослушивает создание объектов узла и соответствующим образом настраивает маршруты. Для этого требуется получить доступ к объектам узла.
 
 `v1/Node`:
 
@@ -99,7 +99,7 @@ weight: 40
 
 ### Другие {#authorization-miscellaneous}
 
-Реализация ядра диспетчера облачных контроллеров требует доступ для создания создания объектов событий, а для обеспечения безопасной работы требуется доступ к созданию сервисных учетных записей (ServiceAccounts).
+Реализация ядра диспетчера облачных контроллеров требует доступ для создания объектов событий, а для обеспечения безопасной работы требуется доступ к созданию сервисных учетных записей (ServiceAccounts).
 
 `v1/Event`:
 
@@ -111,7 +111,7 @@ weight: 40
 
 - Create
 
-The {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole для диспетчера облачных контроллеров выглядит так:
+{{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole для диспетчера облачных контроллеров выглядит так:
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
@@ -179,7 +179,7 @@ rules:
 ## {{% heading "whatsnext" %}}
 
 [Администрирование диспетчера облачных контроллеров](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
-содержит инструкции по запуску и управлению диспетером облачных контроллеров.
+содержит инструкции по запуску и управлению диспетчером облачных контроллеров.
 
 Хотите знать, как реализовать свой собственный диспетчер облачных контроллеров или расширить проект?