diff --git a/content/ru/docs/concepts/_index.md b/content/ru/docs/concepts/_index.md index 19e42ed49e..8687e9ba21 100644 --- a/content/ru/docs/concepts/_index.md +++ b/content/ru/docs/concepts/_index.md @@ -17,7 +17,7 @@ weight: 40 Чтобы работать с Kubernetes, вы используете *объекты API Kubernetes* для описания *желаемого состояния вашего кластера*: какие приложения или другие рабочие нагрузки вы хотите запустить, какие образы контейнеров они используют, количество реплик, какие сетевые и дисковые ресурсы вы хотите использовать и сделать доступными и многое другое. Вы устанавливаете желаемое состояние, создавая объекты с помощью API Kubernetes, обычно через интерфейс командной строки `kubectl`. Вы также можете напрямую использовать API Kubernetes для взаимодействия с кластером и установки или изменения желаемого состояния. -После того, как вы установили желаемое состояние, *Плоскость управления Kubernetes* заставляет текущее состояние кластера соответствовать желаемому состоянию с помощью генератора событий жизненного цикла подов ([Pod Lifecycle Event Generator, PLEG](https://github.com/kubernetes/design-proposals-archive/blob/main/node/pod-lifecycle-event-generator.md)). Для этого Kubernetes автоматически выполняет множество задач, таких как запуск или перезапуск контейнеров, масштабирование количества реплик данного приложения и многое другое. Плоскость управления Kubernetes состоит из набора процессов, запущенных в вашем кластере: +После того, как вы установили желаемое состояние, *Управляющий слой Kubernetes* (control plane) заставляет текущее состояние кластера соответствовать желаемому состоянию с помощью генератора событий жизненного цикла подов ([Pod Lifecycle Event Generator, PLEG](https://github.com/kubernetes/design-proposals-archive/blob/main/node/pod-lifecycle-event-generator.md)). Для этого Kubernetes автоматически выполняет множество задач, таких как запуск или перезапуск контейнеров, масштабирование количества реплик данного приложения и многое другое. Управляющий слой Kubernetes состоит из набора процессов, запущенных в вашем кластере: * **Мастер Kubernetes** — это коллекция из трех процессов, которые выполняются на одном узле в вашем кластере, который обозначен как главный узел. Это процессы: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) и [kube-scheduler](/docs/admin/kube-scheduler/). * Каждый отдельный неосновной узел в вашем кластере выполняет два процесса: @@ -43,11 +43,11 @@ Kubernetes также содержит абстракции более высо * [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) -## Плоскость управления Kubernetes +## Управляющий слой Kubernetes -Различные части панели управления Kubernetes, такие как мастер Kubernetes и процессы kubelet, определяют, как Kubernetes взаимодействует с кластером. Плоскость управления поддерживает запись всех объектов Kubernetes в системе и запускает непрерывные циклы управления для обработки состояния этих объектов. В любое время циклы управления панели управления будут реагировать на изменения в кластере и работать, чтобы фактическое состояние всех объектов в системе соответствовало желаемому состоянию, которое вы указали. +Различные части управляющего слоя Kubernetes (control plane), такие как мастер Kubernetes и процессы kubelet, определяют, как Kubernetes взаимодействует с кластером. Управляющий слой поддерживает запись всех объектов Kubernetes в системе и запускает непрерывные циклы управления для обработки состояния этих объектов. В любое время циклы управления управляющего слоя будут реагировать на изменения в кластере и работать, чтобы фактическое состояние всех объектов в системе соответствовало желаемому состоянию, которое вы указали. -Например, когда вы используете API Kubernetes для создания развертывания, вы предоставляете новое желаемое состояние для системы. Плоскость управления Kubernetes записывает создание этого объекта и выполняет ваши инструкции, запуская необходимые приложения и планируя их на узлы кластера, чтобы фактическое состояние кластера соответствовало желаемому состоянию. +Например, когда вы используете API Kubernetes для создания развертывания, вы предоставляете новое желаемое состояние для системы. Управляющий слой Kubernetes записывает создание этого объекта и выполняет ваши инструкции, запуская необходимые приложения и планируя их на узлы кластера, чтобы фактическое состояние кластера соответствовало желаемому состоянию. ### Мастер Kubernetes diff --git a/content/ru/docs/concepts/architecture/cloud-controller.md b/content/ru/docs/concepts/architecture/cloud-controller.md index 8c51bbcb0a..a8a5370493 100644 --- a/content/ru/docs/concepts/architecture/cloud-controller.md +++ b/content/ru/docs/concepts/architecture/cloud-controller.md @@ -22,11 +22,11 @@ weight: 40 ![Kubernetes components](/images/docs/components-of-kubernetes.svg) -Диспетчер облачных контроллеров работает в панели управления как реплицированный набор процессов (обычно это контейнер в Pod-ах). Каждый диспетчер облачных контроллеров реализует множество {{< glossary_tooltip text="контроллеров" term_id="controller" >}} в единственном процессе. +Диспетчер облачных контроллеров работает в управляющем слое (control plane) как реплицированный набор процессов (обычно это контейнер в Pod-ах). Каждый диспетчер облачных контроллеров реализует множество {{< glossary_tooltip text="контроллеров" term_id="controller" >}} в единственном процессе. {{< note >}} -Вы также можете запустить диспетчер облачных контроллеров как {{< glossary_tooltip text="дополнение" term_id="addons" >}} Kubernetes, а не как часть панели управления. +Вы также можете запустить диспетчер облачных контроллеров как {{< glossary_tooltip text="дополнение" term_id="addons" >}} Kubernetes, а не как часть управляющего слоя. {{< /note >}} ## Функции диспетчера облачных контроллеров {#functions-of-the-ccm} 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 7b2f43991f..93f9f6c0d6 100644 --- a/content/ru/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ru/docs/concepts/architecture/control-plane-node-communication.md @@ -2,7 +2,7 @@ reviewers: - dchen1107 - liggitt -title: Связь между плоскостью управления и узлом +title: Связь между управляющим слоем и узлом content_type: concept weight: 20 aliases: @@ -11,13 +11,13 @@ aliases: -Этот документ описывает связь между плоскостью управления (apiserver) и кластером Kubernetes. Цель состоит в том, чтобы позволить пользователям настраивать свою установку для усиления сетевой конфигурации, чтобы кластер мог работать в ненадежной сети (или на полностью общедоступных IP-адресах облачного провайдера). +Этот документ описывает связь между API-сервером и кластером Kubernetes. Цель состоит в том, чтобы позволить пользователям настраивать свою установку для усиления сетевой конфигурации, чтобы кластер мог работать в ненадежной сети (или на полностью общедоступных IP-адресах облачного провайдера). -## Связь между плоскостью управления и узлом +## От узла к управляющему слою -В Kubernetes имеется API шаблон «ступица и спица» (hub-and-spoke). Все используемые API из узлов (или которые запускают pod-ы) завершает apiserver. Ни один из других компонентов плоскости управления не предназначен для предоставления удаленных сервисов. Apiserver настроен на прослушивание удаленных подключений через безопасный порт HTTPS (обычно 443) с одной или несколькими включенными формами [аутентификации](/docs/reference/access-authn-authz/authentication/) клиента. +В 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). @@ -28,11 +28,11 @@ Pod-ы, которые хотят подключиться к apiserver, мог Компоненты уровня управления также взаимодействуют с кластером apiserver-а через защищенный порт. -В результате режим работы по умолчанию для соединений от узлов и модулей, работающих на узлах, к плоскости управления по умолчанию защищен и может работать в ненадежных и/или общедоступных сетях. +В результате режим работы по умолчанию для соединений от узлов и модулей, работающих на узлах, к управляющему слою по умолчанию защищен и может работать в ненадежных и/или общедоступных сетях. -## Узел к плоскости управления +## От управляющего слоя к узлу -Существуют два пути связи плоскости управления (apiserver) с узлами. Первый - от apiserver-а до kubelet процесса, который выполняется на каждом узле кластера. Второй - от apiserver к любому узлу, pod-у или службе через промежуточную функциональность apiserver-а. +Существуют два пути связи управляющего слоя (API-сервера) с узлами. Первый - от apiserver-а до kubelet процесса, который выполняется на каждом узле кластера. Второй - от apiserver к любому узлу, pod-у или службе через промежуточную функциональность apiserver-а. ### apiserver в kubelet @@ -56,7 +56,7 @@ Pod-ы, которые хотят подключиться к apiserver, мог ### SSH-туннели -Kubernetes поддерживает SSH-туннели для защиты плоскости управления узлов от путей связи. В этой конфигурации apiserver инициирует SSH-туннель для каждого узла в кластере (подключается к ssh-серверу, прослушивая порт 22) и передает весь трафик предназначенный для kubelet, узлу, pod-у или службе через туннель. Этот туннель гарантирует, что трафик не выводится за пределы сети, в которой работает узел. +Kubernetes поддерживает SSH-туннели для защиты путей связи от управляющего слоя к узлам. В этой конфигурации apiserver инициирует SSH-туннель для каждого узла в кластере (подключается к ssh-серверу, прослушивая порт 22) и передает весь трафик предназначенный для kubelet, узлу, pod-у или службе через туннель. Этот туннель гарантирует, что трафик не выводится за пределы сети, в которой работает узел. SSH-туннели в настоящее время устарели, поэтому вы не должны использовать их, если не знаете, что делаете. Служба подключения является заменой этого канала связи. @@ -64,6 +64,6 @@ SSH-туннели в настоящее время устарели, поэто {{< feature-state for_k8s_version="v1.18" state="beta" >}} -В качестве замены SSH-туннелям, служба подключения обеспечивает уровень полномочия TCP для плоскости управления кластерной связи. Служба подключения состоит из двух частей: сервер подключения к сети плоскости управления и агентов подключения в сети узлов. Агенты службы подключения инициируют подключения к серверу подключения и поддерживают сетевое подключение. После включения службы подключения, весь трафик с плоскости управления на узлы проходит через эти соединения. +В качестве замены SSH-туннелям, служба подключения обеспечивает прокси TCP-уровня для взаимодействия управляющего слоя с кластером. Служба подключения состоит из двух частей: сервер подключения к сети управляющего слоя и агентов подключения в сети узлов. Агенты службы подключения инициируют подключения к серверу подключения и поддерживают сетевое подключение. После включения службы подключения, весь трафик с управляющего слоя на узлы проходит через эти соединения. Следуйте инструкциям [Задача службы подключения,](/docs/tasks/extend-kubernetes/setup-konnectivity/) чтобы настроить службу подключения в кластере. diff --git a/content/ru/docs/concepts/architecture/controller.md b/content/ru/docs/concepts/architecture/controller.md index e46fbb022b..122f8abf2e 100644 --- a/content/ru/docs/concepts/architecture/controller.md +++ b/content/ru/docs/concepts/architecture/controller.md @@ -47,7 +47,7 @@ weight: 30 Когда контроллер задания видит новую задачу, он убеждается что где-то в вашем кластере kubelet-ы на множестве узлов запускают нужное количество Pod-ов для выполнения работы. Контроллер задания сам по себе не запускает никакие Pod-ы или контейнеры. Вместо этого контроллер задания сообщает серверу API о создании или удалении Pod-ов. Другие компоненты в -{{< glossary_tooltip text="плоскости управления" term_id="control-plane" >}} +{{< glossary_tooltip text="управляющем слое" term_id="control-plane" >}} действуют на основе информации (имеются ли новые запланированные Pod-ы для запуска), и в итоге работа завершается. После того как вы создадите новое задание, желаемое состояние для этого задания будет завершено. Контроллер задания приближает текущее состояние этой задачи к желаемому состоянию: создает Pod-ы, выполняющие работу, которую вы хотели для этой задачи, чтобы задание было ближе к завершению. @@ -70,7 +70,7 @@ weight: 30 Важным моментом здесь является то, что контроллер вносит некоторые изменения, чтобы вызвать желаемое состояние, а затем сообщает текущее состояние обратно на сервер API вашего кластера. Другие контуры управления могут наблюдать за этими отчетными данными и предпринимать собственные действия. -В примере с термостатом, если в помещении очень холодно, тогда другой контроллер может также включить обогреватель для защиты от замерзания. В кластерах Kubernetes, плоскость управления косвенно работает с инструментами управления IP-адресами, службами хранения данных, API облачных провайдеров и другими службами для реализации +В примере с термостатом, если в помещении очень холодно, тогда другой контроллер может также включить обогреватель для защиты от замерзания. В кластерах Kubernetes управляющий слой косвенно работает с инструментами управления IP-адресами, службами хранения данных, API облачных провайдеров и другими службами для реализации [расширения Kubernetes](/docs/concepts/extend-kubernetes/). ## Желаемое против текущего состояния {#desired-vs-current} @@ -99,9 +99,9 @@ Kubernetes использует систему вида cloud-native и спос Kubernetes поставляется с набором встроенных контроллеров, которые работают внутри {{< glossary_tooltip term_id="kube-controller-manager" >}}. Эти встроенные контроллеры обеспечивают важные основные функции. Контроллер развертывания и контроллер заданий - это примеры контроллеров, которые входят в состав самого Kubernetes («встроенные» контроллеры). -Kubernetes позволяет вам запускать устойчивую плоскость управления, так что в случае отказа одного из встроенных контроллеров работу берет на себя другая часть плоскости управления. +Kubernetes позволяет вам запускать устойчивый управляющий слой (control plane), так что в случае отказа одного из встроенных контроллеров работу берет на себя другая часть управляющего слоя. -Вы можете найти контроллеры, которые работают вне плоскости управления, чтобы расширить Kubernetes. +Вы можете найти контроллеры, которые работают вне управляющего слоя, чтобы расширить Kubernetes. Или, если вы хотите, можете написать новый контроллер самостоятельно. Вы можете запустить свой собственный контроллер в виде наборов Pod-ов, или внешнее в Kubernetes. Что подойдет лучше всего, будет зависеть от того, что делает этот конкретный контроллер. @@ -109,7 +109,7 @@ Kubernetes позволяет вам запускать устойчивую п ## {{% heading "whatsnext" %}} -* Прочтите о [плоскости управления Kubernetes ](/docs/concepts/overview/components/#control-plane-components) -* Откройте для себя некоторые из основных [объектов Kubernetes ](/docs/concepts/overview/working-with-objects/kubernetes-objects/) -* Узнайте больше о [Kubernetes API](/docs/concepts/overview/kubernetes-api/) +* Прочтите об [управляющем слое Kubernetes ](/ru/docs/concepts/overview/components/#компоненты-управляющего-слоя) +* Откройте для себя некоторые из основных [объектов Kubernetes](/ru/docs/concepts/overview/working-with-objects/kubernetes-objects/) +* Узнайте больше о [Kubernetes API](/ru/docs/concepts/overview/kubernetes-api/) * Если вы хотите написать собственный контроллер, см [Шаблоны расширения](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) в расширении Kubernetes. diff --git a/content/ru/docs/concepts/architecture/nodes.md b/content/ru/docs/concepts/architecture/nodes.md index 613155f012..da2969d789 100644 --- a/content/ru/docs/concepts/architecture/nodes.md +++ b/content/ru/docs/concepts/architecture/nodes.md @@ -13,7 +13,7 @@ Kubernetes запускает ваши приложения, помещая ко В зависимости от кластера, узел может быть виртуальной или физической машиной. Каждый узел содержит сервисы, необходимые для запуска {{< glossary_tooltip text="Подов" term_id="pod" >}}, управляемых -{{< glossary_tooltip text="плоскостью управления" term_id="control-plane" >}}. +{{< glossary_tooltip text="control plane (управляющим слоем)" term_id="control-plane" >}}. Обычно у вас есть несколько узлов в кластере; однако в среде обучения или среде с ограниченными ресурсами у вас может быть только один. @@ -29,11 +29,11 @@ Kubernetes запускает ваши приложения, помещая ко Существует два основных способа добавления Узлов в {{< glossary_tooltip text="API сервер" term_id="kube-apiserver" >}}: -1. Kubelet на узле саморегистрируется в плоскости управления +1. Kubelet на узле саморегистрируется в управляющем слое 2. Вы или другой пользователь вручную добавляете объект Узла После того как вы создадите объект Узла или kubelet на узле самозарегистируется, -плоскость управления проверяет, является ли новый объект Узла валидным (правильным). Например, если вы +управляющий слой проверяет, является ли новый объект Узла валидным (правильным). Например, если вы попробуете создать Узел при помощи следующего JSON манифеста: ```json @@ -217,7 +217,7 @@ kubectl describe node ### Контроллер узла {{< glossary_tooltip text="Контроллер " term_id="controller" >}} узла является компонентом -плоскости управления Kubernetes, который управляет различными аспектами узлов. +управляющего слоя Kubernetes, который управляет различными аспектами узлов. Контроллер узла играет различные роли в жизни узла. Первая - назначение CIDR-блока узлу при его регистрации (если включено назначение CIDR). diff --git a/content/ru/docs/concepts/cluster-administration/_index.md b/content/ru/docs/concepts/cluster-administration/_index.md index 77f610bf18..c8e750d2c8 100644 --- a/content/ru/docs/concepts/cluster-administration/_index.md +++ b/content/ru/docs/concepts/cluster-administration/_index.md @@ -59,7 +59,7 @@ no_list: true * [Аудит](/docs/tasks/debug-application-cluster/audit/) описывает, как взаимодействовать с журналами аудита Kubernetes. ### Обеспечение безопасности kubelet - * [Связь между плоскостью управления и узлом](/docs/concepts/architecture/control-plane-node-communication/) + * [Связь между управляющим слоем и узлом](/ru/docs/concepts/architecture/control-plane-node-communication/) * [Загрузка TLS](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) * [Аутентификация/авторизация Kubelet](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) diff --git a/content/ru/docs/concepts/overview/components.md b/content/ru/docs/concepts/overview/components.md index fdff4ef9aa..86a6df5a73 100644 --- a/content/ru/docs/concepts/overview/components.md +++ b/content/ru/docs/concepts/overview/components.md @@ -23,11 +23,11 @@ card: -## Плоскость управления компонентами +## Компоненты управляющего слоя -Компоненты панели управления отвечают за основные операции кластера (например, планирование), а также обрабатывают события кластера (например, запускают новый {{< glossary_tooltip text="под" term_id="pod">}}, когда поле `replicas` развертывания не соответствует требуемому количеству реплик). +Компоненты управляющего слоя (control plane) отвечают за основные операции кластера (например, планирование), а также обрабатывают события кластера (например, запускают новый {{< glossary_tooltip text="под" term_id="pod">}}, когда поле `replicas` развертывания не соответствует требуемому количеству реплик). -Компоненты панели управления могут быть запущены на любой машине в кластере. Однако для простоты сценарии настройки обычно запускают все компоненты панели управления на одном компьютере и в то же время не позволяют запускать пользовательские контейнеры на этом компьютере. Смотрите страницу [Создание высоконадёжных кластеров](/docs/admin/high-availability/) для примера настройки нескольких ведущих виртуальных машин. +Компоненты управляющего слоя могут быть запущены на любой машине в кластере. Однако для простоты сценарии настройки обычно запускают все компоненты управляющего слоя на одном компьютере и в то же время не позволяют запускать пользовательские контейнеры на этом компьютере. Смотрите страницу [Создание высоконадёжных кластеров](/docs/admin/high-availability/) для примера настройки нескольких ведущих виртуальных машин. ### kube-apiserver diff --git a/content/ru/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ru/docs/concepts/overview/working-with-objects/kubernetes-objects.md index cc4ba312f1..5acc024a18 100644 --- a/content/ru/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ru/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -32,7 +32,7 @@ card: Почти в каждом объекте Kubernetes есть два вложенных поля-объекта, которые управляют конфигурацией объекта: *`spec`* и *`status`*. При создании объекта в поле `spec` указывается _требуемое состояние_ (описание характеристик, которые должны быть у объекта). -Поле `status` описывает _текущее состояние_ объекта, которое создаётся и обновляется самим Kubernetes и его компонентами. {{< glossary_tooltip text="Плоскость управления" term_id="control-plane" >}} Kubernetes непрерывно управляет фактическим состоянием каждого объекта, чтобы оно соответствовало требуемому состоянию, которое было задано пользователем. +Поле `status` описывает _текущее состояние_ объекта, которое создаётся и обновляется самим Kubernetes и его компонентами. {{< glossary_tooltip text="Управляющий слой" term_id="control-plane" >}} Kubernetes непрерывно управляет фактическим состоянием каждого объекта, чтобы оно соответствовало требуемому состоянию, которое было задано пользователем. Например: Deployment — это объект Kubernetes, представляющий работающее приложение в кластере. При создании объекта Deployment вы можете указать в его поле `spec`, что хотите иметь три реплики приложения. Система Kubernetes получит спецификацию объекта Deployment и запустит три экземпляра приложения, таким образом обновит статус (состояние) объекта, чтобы он соответствовал заданной спецификации. В случае сбоя одного из экземпляров (это влечет за собой изменение состояние), Kubernetes обнаружит несоответствие между спецификацией и статусом и исправит его, т.е. активирует новый экземпляр вместо того, который вышел из строя. diff --git a/content/ru/docs/contribute/style/style-guide.md b/content/ru/docs/contribute/style/style-guide.md index c2d464f790..bac94470d1 100644 --- a/content/ru/docs/contribute/style/style-guide.md +++ b/content/ru/docs/contribute/style/style-guide.md @@ -74,7 +74,7 @@ PodList — это список Pod. | Pod List — это список подо Можно | Нельзя :--| :----- _Кластер_ — это набор узлов ... | "Кластер" — это набор узлов ... -Эти компоненты формируют _плоскость управления_. | Эти компоненты формируют **плоскость управления**. +Эти компоненты формируют _управляющий слой_. | Эти компоненты формируют **управляющий слой**. {{< /table >}} ### Оформляйте как код имена файлов, директории и пути diff --git a/content/ru/docs/reference/glossary/cloud-controller-manager.md b/content/ru/docs/reference/glossary/cloud-controller-manager.md index d8f0615778..c12c8db992 100644 --- a/content/ru/docs/reference/glossary/cloud-controller-manager.md +++ b/content/ru/docs/reference/glossary/cloud-controller-manager.md @@ -11,7 +11,7 @@ tags: - architecture - operation --- -Компонент {{< glossary_tooltip text="панель управления" term_id="control-plane" >}} Kubernetes - это встраиваемый в логику управления облочная спецификация. Диспетчер облачных контроллеров позволяет связать кластер с API поставщика облачных услуг и отделить компоненты, взаимодействующие с этой облачной платформой, от компонентов, взаимодействующих только с вашим кластером. +Компонент {{< glossary_tooltip text="управляющего слоя" term_id="control-plane" >}} Kubernetes, встраивающий специфику облака в логику управления. Диспетчер облачных контроллеров позволяет связать кластер с API поставщика облачных услуг и отделить компоненты, взаимодействующие с этой облачной платформой, от компонентов, взаимодействующих только с вашим кластером. diff --git a/content/ru/docs/reference/glossary/cloud-provider.md b/content/ru/docs/reference/glossary/cloud-provider.md index 55414a63ee..696c9116b7 100644 --- a/content/ru/docs/reference/glossary/cloud-provider.md +++ b/content/ru/docs/reference/glossary/cloud-provider.md @@ -27,6 +27,6 @@ tags: Вы также можете найти Kubernetes в качестве управляемого сервиса; иногда его называют Платформа как Услуга (Platform as a Service) или PaaS. С упарвляемым Kubernetes ваш облачный провайдер отвечает за -{{< glossary_tooltip term_id="control-plane" text="плоскость управления" >}} Kubernetes, а также за +{{< glossary_tooltip term_id="control-plane" text="управляющий слой" >}} Kubernetes, а также за {{< glossary_tooltip term_id="node" text="узлы" >}} и инфраструктуру, на которую они полагаются: сеть, хранилище и, возможно, другие элементы, такие как балансировщики нагрузки. diff --git a/content/ru/docs/reference/glossary/cluster.md b/content/ru/docs/reference/glossary/cluster.md index 00c5609b48..365ceb277b 100644 --- a/content/ru/docs/reference/glossary/cluster.md +++ b/content/ru/docs/reference/glossary/cluster.md @@ -14,4 +14,4 @@ tags: Набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел. -В рабочих узлах размещены поды, являющиеся компонентами приложения. Плоскость управления управляет рабочими узлами и подами в кластере. В промышленных средах плоскость управления обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность. +В рабочих узлах размещены поды, являющиеся компонентами приложения. Управляющий слой (control plane) управляет рабочими узлами и подами в кластере. В промышленных средах управляющий слой обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность. diff --git a/content/ru/docs/reference/glossary/control-plane.md b/content/ru/docs/reference/glossary/control-plane.md index a4565af381..98653864c3 100644 --- a/content/ru/docs/reference/glossary/control-plane.md +++ b/content/ru/docs/reference/glossary/control-plane.md @@ -1,5 +1,5 @@ --- -title: Плоскость управления (Control Plane) +title: Управляющий слой (Control Plane) id: control-plane date: 2019-05-12 full_link: diff --git a/content/ru/docs/reference/glossary/node.md b/content/ru/docs/reference/glossary/node.md index 34f68b99b0..f359bc4227 100644 --- a/content/ru/docs/reference/glossary/node.md +++ b/content/ru/docs/reference/glossary/node.md @@ -14,4 +14,4 @@ tags: -Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< glossary_tooltip text="подов" term_id="pod" >}}, а сам он управляется плоскостью управления. Демоны на узле включают в себя {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} и среду выполнения контейнера, основанную на {{< glossary_tooltip text="CRI" term_id="cri" >}}, например {{< glossary_tooltip term_id="docker" >}}. +Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< glossary_tooltip text="подов" term_id="pod" >}}, а сам он управляется управляющим слоем (control plane). Демоны на узле включают в себя {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} и среду выполнения контейнера, основанную на {{< glossary_tooltip text="CRI" term_id="cri" >}}, например {{< glossary_tooltip term_id="docker" >}}.