---
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]]