From 67a570cd0b0cc84bcd5fabed4bd5cd65f3c0c77c Mon Sep 17 00:00:00 2001 From: Michael Date: Sun, 10 Jul 2022 21:25:02 +0800 Subject: [PATCH] [ru] fix broken links on /control-plane-node-communication.md --- .../architecture/control-plane-node-communication.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/content/ru/docs/concepts/architecture/control-plane-node-communication.md b/content/ru/docs/concepts/architecture/control-plane-node-communication.md index fa0db524af..7b2f43991f 100644 --- a/content/ru/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ru/docs/concepts/architecture/control-plane-node-communication.md @@ -13,16 +13,15 @@ aliases: Этот документ описывает связь между плоскостью управления (apiserver) и кластером Kubernetes. Цель состоит в том, чтобы позволить пользователям настраивать свою установку для усиления сетевой конфигурации, чтобы кластер мог работать в ненадежной сети (или на полностью общедоступных IP-адресах облачного провайдера). - - ## Связь между плоскостью управления и узлом + В Kubernetes имеется API шаблон «ступица и спица» (hub-and-spoke). Все используемые API из узлов (или которые запускают pod-ы) завершает apiserver. Ни один из других компонентов плоскости управления не предназначен для предоставления удаленных сервисов. Apiserver настроен на прослушивание удаленных подключений через безопасный порт HTTPS (обычно 443) с одной или несколькими включенными формами [аутентификации](/docs/reference/access-authn-authz/authentication/) клиента. Должна быть включена одна или несколько форм [авторизации](/docs/reference/access-authn-authz/authorization/), особенно, если разрешены [анонимные запросы](/docs/reference/access-authn-authz/authentication/#anonymous-requests) или [ServiceAccount токены](/docs/reference/access-authn-authz/authentication/#service-account-tokens). -Узлы должны быть снабжены публичным корневым сертификатом для кластера, чтобы они могли безопасно подключаться к apiserver-у вместе с действительными учетными данными клиента. Хороший подход заключается в том, чтобы учетные данные клиента, предоставляемые kubelet-у, имели форму клиентского сертификата. См. Информацию о загрузке kubelet TLS [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) для автоматической подготовки клиентских сертификатов kubelet. +Узлы должны быть снабжены публичным корневым сертификатом для кластера, чтобы они могли безопасно подключаться к apiserver-у вместе с действительными учетными данными клиента. Хороший подход заключается в том, чтобы учетные данные клиента, предоставляемые kubelet-у, имели форму клиентского сертификата. См. Информацию о загрузке [kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) для автоматической подготовки клиентских сертификатов kubelet. Pod-ы, которые хотят подключиться к apiserver, могут сделать это безопасно, используя ServiceAccount, чтобы Kubernetes автоматически вводил общедоступный корневой сертификат и действительный токен-носитель в pod при его создании. Служба `kubernetes` (в пространстве имен `default`) настроена с виртуальным IP-адресом, который перенаправляет (через kube-proxy) на HTTPS эндпоинт apiserver-а. @@ -49,7 +48,7 @@ Pod-ы, которые хотят подключиться к apiserver, мог Если это не возможно, используйте [SSH-тунелирование](#ssh-tunnels) между apiserver-ом и kubelet, если это необходимо, чтобы избежать подключения по ненадежной или общедоступной сети. -Наконец, должны быть включены [аутентификация или авторизация kubelet](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) для защиты kubelet API. +Наконец, должны быть включены [аутентификация или авторизация kubelet](/docs/reference/access-authn-authz/kubelet-authn-authz/) для защиты kubelet API. ### apiserver для узлов, pod-ов, и служб