Files
SecondBrain/90 Library/Containers/Kubernetes/Control Plane - Плоскость управления.md
T
2026-05-31 10:18:48 +03:00

120 lines
8.7 KiB
Markdown

---
status: processing
type: concept
tags:
- devops
- kubernetes
created: 2025-12-17
updated: 2026-05-07
aliases:
- Control Plane - Плоскость управления
---
# Control Plane - Плоскость управления
В k8s плоскостью управления выступают master-узлы, они контролируют работу worker-узлов и следят за здоровьем системы, в целом.
К основным компонентам Control plane относятся:
1) Etcd
2) Kube-api-server
3) Kube-scheduler
4) Kube-controller-manager
5) Cloud-controller-manager
![[Pasted image 20260429090040.png|400]]
## Etcd
**Etcd** — Opensource *key-value* хранилище, использующее алгоритм консенсуса [[Алгоритм консенсуса raft|raft]] для обеспечения надежного способа хранения данных.
- Рекомендуемое Kubernetes хранилище конфигурации кластера.
- Единственный *Stateful*-компонент кластера Kubernetes.
- Инсталлируется на каждую Master node.
- Для выбора лидера используется алгоритм Raft.
## Kube-api-server
**Kube-api-server** — основной компонент для взаимодействия с кластером и обязательный посредник между всеми компонентами Kubernetes в Data и Control plane.
- Использует REST API интерфейс.
- Является точкой входа в кластер.
- Обязательный участник любого взаимодействия между компонентами кластера.
- Обеспечивает разграничение прав доступа к содержимому кластера (авторизация и аутентификация).
- *Stateless*-компонент.
- Инсталлируется на *каждую* Master node.
- Выбор лидера происходит по алгоритму [[Алгоритм выбора лидера Lease|lease]].
## Kube-controller-manager
**Kube-controller-manager** — компонент, ответственный за работу множества kube-controllers.
- Является *связующим* звеном при взаимодействии Kube-controllers и отвечает за их работу.
- Отвечает за *сборку мусора* (Garbage collecting) в кластере Kubernetes.
- *Stateless*-компонент.
- Инсталлируется на каждую Master node.
- Выбор лидера происходит по алгоритму [[Алгоритм выбора лидера Lease|lease]].
### Распространенные kube-controllers
- **Node-controller** (поддерживает связь с узлами кластера Kubernetes, инициирует перенаправление рабочих нагрузок с вышедших из строя узлов.
- **Replicaset-controller** (инициирует процедуру создания и функционирования сущности Replicaset).
- **Endpoint-controller** (выполняет создание endpoint - связи между Pod и его Service).
- **Token-controller** (обеспечивает создание и работу токенов для доступа к API кластера Kubernetes).
- **Account-controller** (обеспечивает функциональность учетных записей в Kubernetes).
### Garbage collecting
Обязанности за сборку мусора (Garbage collecting) в кластере Kubernetes также возложены на компонент *Kube-controller-manager*.
Примером сборки мусора может выступать отслеживание и удаление старых версий наборов репликаций развертываний (Replicaset).
Если в кластере превышен лимит старых ревизий Replicaset — наиболее старая ревизия становится *мусором* и ее нужно удалить.
## Cloud-controller-manadger
**Cloud-controller-manager** — компонент, ответственный за работу множества Cloud-controllers.
> Не реализован в Kubernetes по умолчанию. Самостоятельная реализация привлекательна для вендоров, желающих предоставлять Kubernetes как облачную услугу.
- Является связующим звеном при взаимодействии Cloud-controllers и отвечает за их работу.
- Cloud-controller-manager, как и сами Cloud-controllers не реализованы по умолчанию.
## Kube-scheduler
**Kube-scheduler** — компонент, ответственный за выбор подходящих узлов Data plane для запуска рабочих нагрузок.
При принятии решения руководствуется следующими факторами: *Requests/Limits*, *QoS*, *Affinity/Anti-affinity rules*, *Priority class/Preemption policy*
- Отвечает за распределение рабочих нагрузок на узлы Data plane с учетом *определенных факторов*.
- *Stateless*-компонент.
- Инсталлируется на каждую Master node.
- Выбор лидера происходит по алгоритму [[Алгоритм выбора лидера Lease|lease]].
Kube-scheduler принимает к сведению имеющиеся у развертываний указания по минимальным и максимальным требованиям к вычислительным ресурсам (*Requests* и *Limits*).
**Requests:** Минимальный объем вычислительной мощности (Cpu, Ram), необходимый для функционирования рабочей нагрузки.
**Limits:** Максимальный объем вычислительных ресурсов, выделяемый рабочей нагрузке.
![[Pasted image 20260429090719.png|200]]
Kube-scheduler руководствуется присвоенным рабочей нагрузке значением QoS (Quality of Service).
**В зависимости от указанных в развертывании Requests и Limits,** **уровень обслуживания (QoS) может принимать следующие** **значения:**
- *BestEffort* (Requests и Limits не указаны вовсе).
- *Burstable* (хотя бы для одного контейнера в Pod указаны requests по Cpu или Ram).
- *Guaranteed* (все контейнеры в Pod имеют одинаковые Requests и Limits).
**Affinity/Anti-affinity rules:**
Kube-scheduler также руководствуется применяемыми к рабочей нагрузке Affinity/Anti-affinity rules.
Правила Affinity и Anti-affinity описываются в спецификации развертывания и позволяют влиять на решение Kube-scheduler о направлении рабочих нагрузок на узлы кластера за счет расширения типов возможных ограничений.
![[Pasted image 20260429090816.png|400]]
**Политика вытеснения:**
В критических ситуациях Kube-scheduler может прибегнуть к процедуре вынужденного *выселения* (*переселения*) рабочих нагрузок с низким приоритетом (Priority class) в пользу рабочих нагрузок с *высоким* приоритетом, руководствуясь "*политикой вытеснения*" (Preemption policy).
Данное поведение характерно для ситуаций, при которых узел с рабочей нагрузкой высокого приоритета выходит из строя — в таком случае, во избежание Downtime *высокоприоритетного* развертывания, оно будет отправлено на узел, имеющий низко приоритетную нагрузку (и она будет выселена принудительно).
![[Pasted image 20260429090930.png]]