Merge pull request #45673 from shurup/ru-control-plane-rename
[ru] Update the translation of "control plane" in Russianpull/45730/head^2
commit
c4a54db02f
|
@ -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
|
||||
|
||||
|
|
|
@ -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}
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
reviewers:
|
||||
- dchen1107
|
||||
- liggitt
|
||||
title: Связь между плоскостью управления и узлом
|
||||
title: Связь между управляющим слоем и узлом
|
||||
content_type: concept
|
||||
weight: 20
|
||||
aliases:
|
||||
|
@ -11,13 +11,13 @@ aliases:
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
Этот документ описывает связь между плоскостью управления (apiserver) и кластером Kubernetes. Цель состоит в том, чтобы позволить пользователям настраивать свою установку для усиления сетевой конфигурации, чтобы кластер мог работать в ненадежной сети (или на полностью общедоступных IP-адресах облачного провайдера).
|
||||
Этот документ описывает связь между API-сервером и кластером Kubernetes. Цель состоит в том, чтобы позволить пользователям настраивать свою установку для усиления сетевой конфигурации, чтобы кластер мог работать в ненадежной сети (или на полностью общедоступных IP-адресах облачного провайдера).
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Связь между плоскостью управления и узлом
|
||||
## От узла к управляющему слою
|
||||
|
||||
В 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/) чтобы настроить службу подключения в кластере.
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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 <insert-node-name-here>
|
|||
### Контроллер узла
|
||||
|
||||
{{< glossary_tooltip text="Контроллер " term_id="controller" >}} узла является компонентом
|
||||
плоскости управления Kubernetes, который управляет различными аспектами узлов.
|
||||
управляющего слоя Kubernetes, который управляет различными аспектами узлов.
|
||||
|
||||
Контроллер узла играет различные роли в жизни узла. Первая - назначение CIDR-блока узлу
|
||||
при его регистрации (если включено назначение CIDR).
|
||||
|
|
|
@ -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/)
|
||||
|
||||
|
|
|
@ -23,11 +23,11 @@ card:
|
|||
|
||||
<!-- body -->
|
||||
|
||||
## Плоскость управления компонентами
|
||||
## Компоненты управляющего слоя
|
||||
|
||||
Компоненты панели управления отвечают за основные операции кластера (например, планирование), а также обрабатывают события кластера (например, запускают новый {{< 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
|
||||
|
||||
|
|
|
@ -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 обнаружит несоответствие между спецификацией и статусом и исправит его, т.е. активирует новый экземпляр вместо того, который вышел из строя.
|
||||
|
||||
|
|
|
@ -74,7 +74,7 @@ PodList — это список Pod. | Pod List — это список подо
|
|||
Можно | Нельзя
|
||||
:--| :-----
|
||||
_Кластер_ — это набор узлов ... | "Кластер" — это набор узлов ...
|
||||
Эти компоненты формируют _плоскость управления_. | Эти компоненты формируют **плоскость управления**.
|
||||
Эти компоненты формируют _управляющий слой_. | Эти компоненты формируют **управляющий слой**.
|
||||
{{< /table >}}
|
||||
|
||||
### Оформляйте как код имена файлов, директории и пути
|
||||
|
|
|
@ -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 поставщика облачных услуг и отделить компоненты, взаимодействующие с этой облачной платформой, от компонентов, взаимодействующих только с вашим кластером.
|
||||
|
||||
<!--more-->
|
||||
|
||||
|
|
|
@ -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="узлы" >}} и инфраструктуру, на которую они полагаются:
|
||||
сеть, хранилище и, возможно, другие элементы, такие как балансировщики нагрузки.
|
||||
|
|
|
@ -14,4 +14,4 @@ tags:
|
|||
Набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел.
|
||||
|
||||
<!--more-->
|
||||
В рабочих узлах размещены поды, являющиеся компонентами приложения. Плоскость управления управляет рабочими узлами и подами в кластере. В промышленных средах плоскость управления обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность.
|
||||
В рабочих узлах размещены поды, являющиеся компонентами приложения. Управляющий слой (control plane) управляет рабочими узлами и подами в кластере. В промышленных средах управляющий слой обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Плоскость управления (Control Plane)
|
||||
title: Управляющий слой (Control Plane)
|
||||
id: control-plane
|
||||
date: 2019-05-12
|
||||
full_link:
|
||||
|
|
|
@ -14,4 +14,4 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< 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" >}}.
|
||||
|
|
Loading…
Reference in New Issue