Translate content/ru/docs/concepts/architecture/controller.md to russian (#27564)
* Add description to index file for content/ru/docs/_index.mdi * Add cloud-controller.md file to content/ru/docs/concepts/architecture/cloud-controller.md * Add cloud-controller.md to content/ru/docs/concepts/architecture/cloud-controller.md * Full translate cloud-controller.md file in the content/ru/docs/concepts/architecture/cloud-controller.md * Full translate cloud-controller.md file in the content/ru/docs/concepts/architecture/controller.md * Update controller.md * Update cloud-controller.md * Update cloud-controller.md * Update controller.md * Update cloud-controller.md * Update controller.md * Update controller.md * Edit [ru] community/static/README.md * Full translate control-plane-node-communication.md file in the content/ru/docs/concepts/architecture * Update cloud-controller.md * [ru] Update translate controller.md file in the content/ru/docs/concepts/architecture * Update cloud-controller.md * Update cloud-controller.md * [ru] Add translate cloud-controller-manager.md file in the content/ru/docs/reference/glossary * [ru] Add translate community-values.md file in the content/ru/community/staticpull/28255/head
Marat
GitHub
parent
207ba045e4
commit
b03254526f
|
|
@ -12,8 +12,8 @@ cid: community
|
|||
|
||||
<div class="intro">
|
||||
<br class="mobile">
|
||||
<p>Сообщество Kubernetes — пользователи, участники проекта, и культура, которую мы создаём вместе — одна из главных причин космической скорости роста этого проекта с открытым исходным кодом. Наши культура и ценности продолжают расти и изменяться вместе с проектом. Мы все стремимся к постоянному улучшению проекта и того, как мы над ним работаем.
|
||||
<br><br>Мы — люди которые докладывают о проблемах и вносят изменения, участвуют во встречах, митапах Kubernetes, и KubeCon, продвигают его внедрение и развитие, запускают <code>kubectl get pods</code>, и поддерживают проект ещё множеством способов. Узнайте как стать частью этого прекрасного сообщества.</p>
|
||||
<p>Сообщество Kubernetes — пользователи, участники проекта и культура, которую мы создаём вместе — одна из главных причин космической скорости роста этого проекта с открытым исходным кодом. Наши культура и ценности продолжают расти и изменяются вместе с проектом. Мы все стремимся к постоянному улучшению проекта и того, как мы над ним работаем.
|
||||
<br><br>Мы — люди которые докладывают о проблемах и вносят изменения, участвуют во встречах, митапах Kubernetes, и KubeCon, продвигают его внедрение и развитие, запускают <code>kubectl get pods</code>, поддерживают проект ещё множеством способов. Узнайте как стать частью этого прекрасного сообщества.</p>
|
||||
<br class="mobile">
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,2 +1,2 @@
|
|||
Файлы в этой диркетории было импортированы из других источников.
|
||||
Файлы в этой диркетории были импортированы из других источников.
|
||||
Не редактируйте их напрямую, вместо этого заменяйте их более новыми версиями.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,28 @@
|
|||
<!-- Do not edit this file directly. Get the latest from
|
||||
https://git.k8s.io/community/values.md -->
|
||||
|
||||
# Ценности сообщества Kubernetes
|
||||
|
||||
Культура сообщества Kubernetes часто упоминается как существенный вклад в стремительный рост этого проекта с открытым исходным кодом. Ниже приведены дистиллированные ценности, которые развивались в течение последних многих лет в нашем сообществе, подталкивая наш проект и коллег к постоянному совершенствованию.
|
||||
|
||||
## Распределение лучше, чем централизация
|
||||
|
||||
Масштаб проекта Kubernetes жизнеспособен только благодаря высокому доверию и четкому распределению работ, которое включает делегирование полномочий, принятие решений, техническое проектирование, владение кодом и документацию. Распределенное асинхронное владение, сотрудничество, коммуникация и принятие решений являются краеугольным камнем нашего мирового сообщества.
|
||||
|
||||
## Сообщество над товаром или компанией
|
||||
|
||||
Мы здесь в первую очередь как сообщество, наша преданность заключается в преднамеренном управлении проектом Kubernetes на благо всех его членов и пользователей во всем мире. Мы поддерживаем совместную публичную работу для достижения общей цели создания динамичной взаимодействующей экосистемы, обеспечивающей отличный опыт для наших пользователей. Отдельные лица получают статус благодаря работе, компании получают статус благодаря своим обязательствам поддерживать это сообщество и финансировать ресурсы, необходимые для функционирования проекта.
|
||||
|
||||
## Автоматизация процесса
|
||||
|
||||
У крупных проектов есть много менее захватывающей, но все же тяжелой работы. Мы ценим время, потраченное на автоматизацию повторяющейся работы, больше, чем тяжелый труд. Там, где эта работа не может быть автоматизирована, наша культура заключается в признании и вознаграждении всех видов вклада. Однако героизм не является устойчивым.
|
||||
|
||||
## Inclusive is better than exclusive
|
||||
|
||||
В целом успешная и полезная технология требует различных перспектив и навыков, которые могут быть услышаны только в гостеприимной и уважительной обстановке. Членство в сообществе-это привилегия, а не право. Лидерство в сообществе достигается за счет усилий, объема, качества, количества и продолжительности взносов. Наше сообщество проявляет уважение к времени и усилиям, затраченным на обсуждение, независимо от того, где участник находится на пути своего роста.
|
||||
|
||||
## Эволюция лучше, чем застой
|
||||
|
||||
Открытость новым идеям и изученная технологическая эволюция делают Kubernetes более сильным проектом. Постоянное совершенствование, лидерство слуг, наставничество и уважение-вот основы культуры проекта Kubernetes. Лидеры сообщества Kubernetes обязаны находить, спонсировать и продвигать новых членов сообщества. Лидеры должны ожидать, что они отойдут в сторону. Члены сообщества должны ожидать, что они сделают шаг вперед.
|
||||
|
||||
**"Culture eats strategy for breakfast." --Peter Drucker**
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
title: Community
|
||||
layout: basic
|
||||
cid: community
|
||||
css: /css/community.css
|
||||
---
|
||||
|
||||
<div class="community_main">
|
||||
|
||||
<div class="cncf_coc_container">
|
||||
{{< include "/static/community-values.md" >}}
|
||||
</div>
|
||||
</div>
|
||||
|
|
@ -1,3 +1,6 @@
|
|||
---
|
||||
linktitle: Документация по Kubernetes
|
||||
title: Документация
|
||||
sitemap:
|
||||
priority: 1.0
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: "Кластерная Архитектура"
|
||||
weight: 30
|
||||
description: >
|
||||
The architectural concepts behind Kubernetes.
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,192 @@
|
|||
---
|
||||
title: Диспетчер облочных контроллеров
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
|
||||
|
||||
Технологии облочной инфраструктуры позволяет запускать Kubernetes в общедоступных, частных и гибритных облоках. Kubernetes верит в автоматизированную,управляемую API инфраструктуру без жесткой связи между компонентами.
|
||||
|
||||
{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="Диспетчер облочных контроллеров">}}
|
||||
|
||||
Диспетчер облочных контроллеров структурирован с использованием механизма плагинов, которые позволяют различным облочным провайдерам интегрировать свои платформы с Kubernetes.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Дизайн
|
||||
|
||||
|
||||
|
||||
Диспетчер облочных контроллеров работает в панели управления как реплицированный набот процессов (обычно это контейнер в Pod-ах). Каждый диспетчер облочных контроллеров реализует многоразовые {{< glossary_tooltip text="контроллеры" term_id="controller" >}} в единственном процессе.
|
||||
|
||||
|
||||
{{< note >}}
|
||||
Вы так же можете запустить диспетчер облочных контроллеров как {{< glossary_tooltip text="дополнение" term_id="addons" >}} Kubernetes, а некак часть панели управления.
|
||||
{{< /note >}}
|
||||
|
||||
## Функции диспетчера облочных контроллеров {#functions-of-the-ccm}
|
||||
|
||||
Контроллеры внутри диспетчера облочных контроллеров включают в себя:
|
||||
|
||||
### Контролер узла
|
||||
|
||||
Контроллер узла отвечает за создание объектов {{< glossary_tooltip text="узла" term_id="node" >}} при создании новых серверов в вашей облочной инфраструктуре. Контроллер узла получает информацию
|
||||
о работающих хостах внутри вашего арендуемого облочного провайдера.
|
||||
Контроллер узла выполняет следующие функции:
|
||||
|
||||
1. Инициализация объектов узла для каждого сервера, контроллер которого через API облочного провайдера.
|
||||
2. Аннотирование и маркировка объеко узла специфичной для облока информацией, такой как регион, в котором развернут узел и доступные ему ресурсы (процессор, память и т.д.).
|
||||
3. Получение имени хоста и сетевых адресов.
|
||||
4. Проверка работоспособности ущла. В случае, если узел перестает отвечать на запросы, этот контроллер проверяется с помощью API вашего облочного провайдера, был ли сервер деактевирован / удален / прекращен.
|
||||
Если узел был удален из облока, контроллер удлаяет объект узла из вашего Kubernetes кластера..
|
||||
|
||||
Некоторые облочные провайдеры реализуют его разделение на контроллер узла и отдельный контроллер жизненного цикла узла.
|
||||
|
||||
### Контролер маршрута
|
||||
|
||||
Контролер маршрута отвечае за соответствующую настройку маршрутов облоке, чтобы контейнеры на разных узлах кластера Kubernetes могли взаимодействовать друг с другом.
|
||||
|
||||
В зависимости от облочного провайдера, контроллер маршрута способен также выделять блоки IP адресов для сети Pod.
|
||||
|
||||
### Сервисный контроллер
|
||||
|
||||
{{< glossary_tooltip text="Службы" term_id="service" >}} интегрируются с компонентами облочной инфраструктуры, такими как управляемые балансировщики нагрузки, IP адреса, фильтрация сетевых пакетов и проверка работоспособности целевых объектов. Сервисный контроллер взаимодействует с API вашего облочного провайдера для настройки балансировщиков нагрузки и других компонентов инфраструктуры, когда вы объявляете ресурсные службы которые он требует.
|
||||
|
||||
## Авторизация
|
||||
|
||||
В этом разделе разбирается доступ, который нужен для управления облочным контроллером к различным объектам API для выполнения своих операций.
|
||||
|
||||
### Контроллер узла {#authorization-node-controller}
|
||||
|
||||
Контроллер узла работает только с объектом узла. Он требует полного доступа для и изменения объектов узла.
|
||||
|
||||
`v1/Node`:
|
||||
|
||||
- Get
|
||||
- List
|
||||
- Create
|
||||
- Update
|
||||
- Patch
|
||||
- Watch
|
||||
- Delete
|
||||
|
||||
### Контролер маршрута {#authorization-route-controller}
|
||||
|
||||
Контролер маршрута прослушивает создание объектов узла и соответствующим образом настраивает маршруты. Для этого требуется получить доступ к объектам узла.
|
||||
|
||||
`v1/Node`:
|
||||
|
||||
- Get
|
||||
|
||||
### Сервисный контроллер {#authorization-service-controller}
|
||||
|
||||
Сервисный контроллер прослушивает события Create, Update и Delete объектов службы, а затем соответствующим образом настраивает конечные точки для этих соответствующих сервисов.
|
||||
|
||||
Для доступа к сервисам, требуется доступ к событиям List и Watch. Для обновления сервисов, требуется доступ к событиям Patch и Update.
|
||||
|
||||
Чтобы настроить ресурсы конечных точек для сервисов, требуется доступ к событиям Create, List, Get, Watch, и Update.
|
||||
|
||||
`v1/Service`:
|
||||
|
||||
- List
|
||||
- Get
|
||||
- Watch
|
||||
- Patch
|
||||
- Update
|
||||
|
||||
### Другие {#authorization-miscellaneous}
|
||||
|
||||
Реализация ядра диспетчера облочных контроллеров требует доступ для создания создания объектов события, а для обеспечения безопасной работы требуется доступ для создания учетных записей сервисов (ServiceAccounts).
|
||||
|
||||
`v1/Event`:
|
||||
|
||||
- Create
|
||||
- Patch
|
||||
- Update
|
||||
|
||||
`v1/ServiceAccount`:
|
||||
|
||||
- Create
|
||||
|
||||
The {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole для диспетчера облочных контроллеров выглядить так:
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: cloud-controller-manager
|
||||
rules:
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- events
|
||||
verbs:
|
||||
- create
|
||||
- patch
|
||||
- update
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- nodes
|
||||
verbs:
|
||||
- '*'
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- nodes/status
|
||||
verbs:
|
||||
- patch
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- services
|
||||
verbs:
|
||||
- list
|
||||
- patch
|
||||
- update
|
||||
- watch
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- serviceaccounts
|
||||
verbs:
|
||||
- create
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- persistentvolumes
|
||||
verbs:
|
||||
- get
|
||||
- list
|
||||
- update
|
||||
- watch
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- endpoints
|
||||
verbs:
|
||||
- create
|
||||
- get
|
||||
- list
|
||||
- watch
|
||||
- update
|
||||
```
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
[Администрирование диспетчера облочных контроллеров](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
|
||||
содержить инструкции по запуску и управлению диспетером облочных контроллеров.
|
||||
|
||||
Хотите знать как реализовать свой собственный диспетчер облочных контроллеров или расширить проект?
|
||||
|
||||
Диспетчер облочных контроллеров использует интерфейс Go, который позволяет реализовать подключение из любого облока. В частности, он использует `CloudProvider` интерфейс, который определен в [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62) из [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider).
|
||||
|
||||
Реализация общих контроллеров выделенных в этом документе (Node, Route, и Service),а так же некоторые возведения вместе с общим облочным провайдерским интерфейсом являются частью ядра Kubernetes. особые реализации, для облочных провайдеров находятся вне ядра Kubernetes и реализуют интерфейс `CloudProvider`.
|
||||
|
||||
Дополнительные сведения о разработке плагинов см. в разделе [Разработка диспетчера облочных контроллеров](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
reviewers:
|
||||
- dchen1107
|
||||
- liggitt
|
||||
title: Связь между плоскостью управления и узлом
|
||||
content_type: concept
|
||||
weight: 20
|
||||
aliases:
|
||||
- master-node-communication
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Этот документ каталог связь между плоскостью управления (apiserver) и кластером Kubernetes. Цель состоит в том, чтобы позволить пользователям настраивать свою установку для усиления сетевой конфигурации, чтобы кластер мог работать в ненадежной сети (или на полностью общедоступных IP-адресах облачного провайдера).
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Связь между плоскостью управления и узлом
|
||||
В 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) или [service account tokens](/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.
|
||||
|
||||
pod-ы, которые хотят подключиться к apiserver, могут сделать это безопасно, используя учетную запись службы, чтобы Kubernetes автоматически вводил общедоступный корневой сертификат и действительный токен-носитель в pod при его создании.
|
||||
Служба `kubernetes` (в пространстве имен `default`) is настроен с виртуальным IP-адресом, который перенаправляет (через kube-proxy) к endpoint HTTPS apiserver-а.
|
||||
|
||||
Компоненты уровня управления также взаимодействуют с кластером apiserver-а через защищенный порт.
|
||||
|
||||
В результате режим работы по умолчанию для соединений от узлов и модулей, работающих на узлах, к плоскости управления по умолчанию защищен и может работать в ненадежных и/или общедоступных сетях.
|
||||
|
||||
## Узел к плоскости управления
|
||||
|
||||
Существуют две пути взаимодействия от плоскости управления (apiserver) к узлам. Первый - от apiserver-а до kubelet процесса, который выполняется на каждом узле кластера. Второй - от apiserver к любому узлу, pod-у или службе через промежуточную функциональность apiserver-а.
|
||||
|
||||
### apiserver в kubelet
|
||||
|
||||
Соединение из apiserver-а к kubelet используются для:
|
||||
|
||||
* Извлечения логов с pod-ов.
|
||||
* Прикрепление (через kubectl) к запущенным pod-ам.
|
||||
* Обеспечение функциональности переадресации портов kubelet.
|
||||
|
||||
Эти соединения заверщаются в kubelet в endpoint HTTPS. По умолчанию apiserver не проверяет сертификат обслуживания kubelet-ов, что делает соединение подверженным к атаке человек по середине (man-in-the-middle) и **unsafe** запущенных в ненадежных или общедоступных сетях.
|
||||
|
||||
Для проверки этого соединения, используется флаг `--kubelet-certificate-authority` чтобы предоставить apiserver-у набор корневых (root) сертификатов для проверки сертификата обслуживания kubelet-ов.
|
||||
|
||||
Если это не возможно, используйте [SSH-тунелирование](#ssh-tunnels) между apiserver-ом и kubelet, если это необходимо во избежании подключения по ненадежной или общедоступной сети.
|
||||
|
||||
Наконец, Должны быть включены [пудентификация или авторизация Kubelet](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) для защиты kubelet API.
|
||||
|
||||
### apiserver для узлов, pod-ов, и служб
|
||||
|
||||
Соединение с apiserver-ом к узлу, pod-у или службе по умолчанию осушествяляется по обычному HTTP-соединению и поэтому не проходят проверку подлиности и не шифрование. Они могут быть запущены по защищенному HTTPS-соединению, добавив префикс `https:` к имени узла, pod-а или службы в URL-адресе API, но они не будут проверять сертификат предоставленный HTTPS endpoint, также не будут предоставлять учетные данные клиента. Таким образом, хотя соединение будет зашифровано, оно не обеспечит никаких гарантий целостности. Эти соединения **are not currently safe** запущенных в ненадежных или общедоступных сетях.
|
||||
|
||||
### SSH-тунели
|
||||
|
||||
Kubernetes поддерживает SSH-туннели для защиты плоскости управления узлов от путей связи. В этой конфигурации apiserver инициирует SSH-туннель для каждого узла в кластере (подключается к ssh-серверу, прослушивая порт 22) и передает весь трафикпредназначенный для kubelet, узлу, pod-у или службе через тунель. Этот тунель гарантирует, что трафик не выводиться за пределы сети, в которой работает узел.
|
||||
|
||||
SSH-туннели в настоящее время устарели, поэтому вы не должны использовать их, если не знаете, что делаете. Служба подключения является заменой этого канала связи.
|
||||
|
||||
### Служба подключения
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
В качестве замены SSH-туннелям, служба подключения обеспечивает уровень полномочие TCP для плоскости управления кластерной связи. Служба подключения состоит из двух частей: сервер подключения в сети плоскости управления и агентов подключения в сети узлов. Агенты службы подключения инициируют подключения к серверу подключения и поддерживают сетевое подключение. После включения службы подключения, весь трафик с плоскости управления на узлы проходит через эти соединения.
|
||||
|
||||
Следуйте инструкциям [Задача службы подключения](/docs/tasks/extend-kubernetes/setup-konnectivity/) чтобы настроить службу подключения в кластере.
|
||||
|
|
@ -0,0 +1,116 @@
|
|||
---
|
||||
title: Контроллеры
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
В робототехнике и автоматизации, _цикл управления_ - это непрерывный цикл, который регулирует состояние системы.
|
||||
|
||||
Вот один из примеров контура управления: термостат в помещении.
|
||||
|
||||
Когда вы устанавливаете температуру, это говорит термостату о вашем *желаемом состоянии*. Фактическая температура в помещении - это
|
||||
*текущее состояние*. Термостат действует так, чтобы приблизить текущее состояние к елаемому состоянию, путем включения или выключения оборудования.
|
||||
|
||||
{{< glossary_definition term_id="controller" length="short">}}
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Шаблон контроллера
|
||||
|
||||
Контроллер отслеживает по крайней мере один тип ресурса Kubernetes.
|
||||
Эти [объекты](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)
|
||||
имеют поле спецификации, которое представляет желаемое состояние. Контроллер (ы) для этого ресурса несут ответственность за приближение текущего состояния к желаемому состоянию
|
||||
|
||||
Контроллер может выполнить это действие сам; чаще всего в Kubernetes,
|
||||
контроллер будет отправляет сообщения на
|
||||
{{< glossary_tooltip text="сервер API" term_id="kube-apiserver" >}} которые имеют
|
||||
полезные побочные эффекты. Пример этого вы можете увидеть ниже.
|
||||
|
||||
{{< comment >}}
|
||||
Некоторые встроенные контроллеры, такие как контроллер пространства имен, действуют на объекты, не имеющие спецификации. Для простоты эта страница опускает объяснение этих деталей.
|
||||
{{< /comment >}}
|
||||
|
||||
### Управление с помощью сервера API
|
||||
|
||||
Контроллер {{< glossary_tooltip term_id="job" >}} является примером встроенного контроллера Kubernetes. Встроенные контроллеры управляют состоянием, взаимодействуя с кластером сервера API.
|
||||
|
||||
Задание - это ресурс Kubernetes, который запускает
|
||||
{{< glossary_tooltip term_id="pod" >}}, или возможно несколько Pod-ов, которые выполняют задание и затем останавливаются.
|
||||
|
||||
(После [планирования](/docs/concepts/scheduling-eviction/), Pod объекты становятся частью желаемого состояния для kubelet).
|
||||
|
||||
Когда контроллер задания видить новую задачу, он убеждается что где-то в вашем кластере kubelet-ы на множестве узлов запускают нужное количество Pod-ов для выполнения работы.
|
||||
Контроллер задания сам по себе не запускает никакие Pod-ы или контейнеры. Вместо этого контроллер задания Iсообщает серверу API о создании или удалении Pod-ов.
|
||||
Другие компоненты в
|
||||
{{< glossary_tooltip text="плоскости управления" term_id="control-plane" >}}
|
||||
действуют на основе информации (имеются ли новые заплонированные Pod-ы для запуска), и в итоге работка заверщается.
|
||||
|
||||
После того, как вы создадите новое задание, желаемое состояние для этого задания будет завершено. Контроллер задания приближает текущее состояние этого задания к желаемому состоянию: создает Pod-ы, которые выполняют работу, которую вы хотели для этого задания, чтобы задание было ближе к завершению.
|
||||
|
||||
Контроллеры также обровляют объекты которые их настраивают.
|
||||
Например: как только работа выполнена для задания, контроллер задания обновляет этот объект задание, чтобы пометить его как `Завершенный`.
|
||||
|
||||
(Это немного похоже на то, как некоторые термостаты выключают свет, чтобы указать, что теперь ваша комната имеет установленную вами температуру).
|
||||
|
||||
### Прямое управление
|
||||
|
||||
В отличие от Задания, некоторым контроллерам нужно вносить изменения в вещи за пределами вашего кластера.
|
||||
|
||||
Например, если вы используете контур управления, чтобы убедиться, что в вашем кластере достаточно {{< glossary_tooltip text="Узлов" term_id="node" >}},
|
||||
тогда этому контроллеру нужно что-то вне текущего кластера, чтобы при необъодимости установить новые узлы.
|
||||
|
||||
Контроллеры, которые взаимодействуют с внешним состоянием, находят свое желаемое состояние с сервера API, а затем напрямую взаимодействуют с внешней системой, чтобы приблизить текущее состояние.
|
||||
|
||||
(На самом деле существует [контроллер](https://github.com/kubernetes/autoscaler/)
|
||||
, который горизонтально маштабирует узла в вашем кластере.)
|
||||
|
||||
Важным моментом здесь является то, что контроллер вносит некоторые изменения, чтобы вызвать желаемое состояние, а затем сообщает текущее состояние обратно на сервер API вашего кластера. Другие контуры управления могут наблюдать за этими отчетными данными и предпринимать собственные действия.
|
||||
|
||||
В примере с термостатом, если в помещении очень холодно, тогда другой контроллер может также включить обогреватель для защиты от замерзания. В кластерах Kubernetes, плоскость управления косвенно работает с инструментами управления IP-адресами,службами хранения данных, API облочных провайдеров и другими службами для релизации
|
||||
[расширения Kubernetes](/docs/concepts/extend-kubernetes/).
|
||||
|
||||
## Желаемое против текущего состояния {#desired-vs-current}
|
||||
|
||||
Kubernetes использует систему вида cloud-native и способен справлятся с постоянными изменениями.
|
||||
|
||||
Ваш кластер может изменяться в любой по мере выполнения работы и контуры управления автоматически устранают сбой. Это означает, что потенциально Ваш кластер никогда не достигнет стабильного состояния.
|
||||
|
||||
Пока контроллеры вашего кластера работают и могут вносить полезные изменения, не имеет значения, является ли общее состояние стабильным или нет.
|
||||
|
||||
## Дизайн
|
||||
|
||||
В качестве принципа своей конструкции Kubernetes использует множество контроллеров, каждый из которых управляет определенным аспектом состояния кластера. Чаще всего конкретный контур управления (контроллер) использует один вид ресурса в качестве своего желаемого состояния и имеет другой вид ресурса, которым он управляет, чтобы это случилось. Например, контроллер для заданий отслеживает объекты заданий (для обнаружения новой работы) и объекты модулей (для выполнения заданий, а затем для того, чтобы видеть, когда работа завершена). В этом случае что-то еще создает задания, тогда как контроллер заданий создает Pod-ы.
|
||||
|
||||
Полезно иметь простые контроллеры, а не один монолитный набор взаимосвязанных контуров управления. Контроллеры могут выйти из строя, поэтому Kubernetes предназначен для этого.
|
||||
|
||||
{{< note >}}
|
||||
Существует несколько контроллеров, которые создают или обновляют один и тот же тип объекта. За кулисами контроллеры Kubernetes следят за тем, чтобы обращать внимание только на ресурсы, связанные с их контролирующим ресурсом.
|
||||
|
||||
Например, у вас могут быть развертывания и задания; они оба создают Pod-ы. Контроллер заданий не удаляет Pod-ы созданные вашим развертиыванием, потому что имеется информационные ({{< glossary_tooltip term_id="label" text="метки" >}})
|
||||
которые могут быть использованы контроллерами тем самым показывая отличие Pod-ов.
|
||||
{{< /note >}}
|
||||
|
||||
## Способы запуска контроллеров {#running-controllers}
|
||||
|
||||
Kubernetes поставляется с набором встроенных контроллеров, которые работают внутри {{< glossary_tooltip term_id="kube-controller-manager" >}}. Эти встроенные контроллеры обеспечивают важные основные функции.
|
||||
|
||||
Контроллер развертывания и контроллер заданий - это примеры контроллеров, которые входят в состав самого Kubernetes («встроенные» контроллеры).
|
||||
Kubernetes позволяет вам запускать устойчивую плоскость управления, так что в случае отказа одного из встроенных контроллеров работу берет на себя другая часть плоскости управления.
|
||||
|
||||
Вы можете найти контроллеры, которые работают вне плоскости управления, чтобы расширить Kubernetes.
|
||||
Или, если вы хотите, можете написать новый контроллер самостоятельно. Вы можете запустить свой собственный контроллер виде наборов Pod-ов,
|
||||
или внешнее в 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/)
|
||||
* Если вы хотите написать собственный контроллер, см [Шаблоны расширения](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) в расширении Kubernetes.
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: Диспетчер облачных контроллеров
|
||||
id: cloud-controller-manager
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/architecture/cloud-controller/
|
||||
short_description: >
|
||||
Компонент плоскости управления, который интегрирует Kubernetes со сторонними облачными провайдерами.
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- architecture
|
||||
- operation
|
||||
---
|
||||
Компонент {{< glossary_tooltip text="панель управления" term_id="control-plane" >}} Kubernetes - это встраиваемый в логику управления облочная спецификация. Диспетчер облачных контроллеров позволяет связать кластер с API поставщика облачных услуг и отделить компоненты, взаимодействующие с этой облачной платформой, от компонентов, взаимодействующих только с вашим кластером.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Отделяя логику взаимодействия между Kubernetes и базовой облачной инфраструктурой, компонент cloud-controller-manager позволяет поставщикам облачных услуг выпускать функции в другом темпе по сравнению с основным проектом Kubernetes.
|
||||
|
||||
Loading…
Reference in New Issue