Из чего состоит control plane

Из чего состоит Control Plane в Kubernetes

Control Plane (Управляющая плоскость) — это мозг и центральная нервная система кластера Kubernetes. Она отвечает за глобальные решения о состоянии кластера, управление рабочими узлами, обработку API-запросов и поддержание желаемого состояния всех объектов (подов, сервисов, развертываний и т.д.). Control Plane работает как распределенная система, компоненты которой могут быть развернуты на нескольких машинах для обеспечения отказоустойчивости и высокой доступности.

Ключевые компоненты Control Plane

1. kube-apiserver (API-сервер)

Это центральный компонент, предоставляющий RESTful API для взаимодействия с кластером. Все внутренние компоненты, инструменты командной строки (kubectl) и внешние системы общаются с кластером исключительно через API-сервер.

• Функции:

    *   Валидация и обработка всех запросов на создание, обновление и удаление объектов.
    *   Аутентификация и авторизация запросов.
    *   Является единственным компонентом, взаимодействующим с хранилищем состояния (**etcd**).
    *   Предоставляет точку входа для веб-интерфейса (Dashboard) и клиентских библиотек.

# Пример манифеста, который отправляется в kube-apiserver
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest

2. etcd

Высокодоступное распределенное key-value хранилище, используемое как единственный источник истины для всего состояния кластера. Все конфигурации, секреты, метаданные и желаемые состояния объектов хранятся здесь.

• Характеристики:

    *   Обеспечивает сильную консистентность данных.
    *   Использует алгоритм консенсуса Raft для координации между репликами.
    *   Регулярно создает снапшоты (снимки) данных для восстановления.
    *   **Важно:** etcd — это критически важный компонент, и его резервное копирование является обязательной практикой для администрирования.

3. kube-scheduler (Планировщик)

Отвечает за распределение подов по рабочим узлам (worker nodes). Он наблюдает за вновь созданными подами, у которых еще не назначен узел, и выбирает для них наиболее подходящий узел на основе ряда критериев.

• Критерии планирования включают:

    *   **Ресурсные требования:** Достаточно ли на узле CPU и RAM.
    *   **Софт/Хард ограничения (taints/tolerations):** Можно ли разместить под на узле с определенными "помехами".
    *   **Аффинити/Анти-аффинити (affinity/anti-affinity):** Правила притяжения или отталкивания подов друг от друга или от узлов.
    *   **Локальность данных:** Размещение пода на узле, где уже есть необходимый образ контейнера.
    *   После выбора узла **kube-scheduler** просто сообщает о своем решении **kube-apiserver**, который, в свою очередь, записывает это в **etcd**.

4. kube-controller-manager (Менеджер контроллеров)

Это процесс, в котором запускаются все контроллеры — фоновые циклы (control loops), которые следят за текущим состоянием кластера и приводят его к желаемому состоянию, описанному в объектах API.

• Основные встроенные контроллеры:

    *   **Node Controller:** Отвечает за обнаружение и реакцию на отказ узлов.
    *   **Replication Controller:** Поддерживает корректное количество реплик подов для каждого объекта ReplicaSet или Deployment.
    *   **Endpoints Controller:** Наполняет объекты Endpoints (связывает сервисы и поды).
    *   **Service Account & Token Controllers:** Создают стандартные учетные записи и API-токены доступа для новых пространств имен.

5. cloud-controller-manager (Облачный менеджер контроллеров)

Специальный компонент, который позволяет связать ваш кластер с API облачного провайдера (AWS, GCP, Azure, OpenStack и др.). Он содержит контроллеры, специфичные для облака.

• Контроллеры внутри него:

    *   **Node Controller:** Для проверки доступности узлов, удаленных из облака.
    *   **Route Controller:** Настройка сетевых маршрутов в облачной инфраструктуре.
    *   **Service Controller:** Создание и управление облачными балансировщиками нагрузки (Load Balancers).
    *   **Volume Controller:** Создание, подключение и монтирование облачных дисков (например, AWS EBS, GCP PD).

Взаимодействие компонентов на примере создания пода

1. Пользователь отправляет команду kubectl apply -f pod.yaml.
2. kubectl отправляет манифест в kube-apiserver.
3. kube-apiserver валидирует запрос, аутентифицирует пользователя и записывает новый объект Pod в etcd.
4. kube-scheduler, наблюдая через API-сервер за новыми "незапланированными" подами, определяет подходящий узел и обновляет объект Pod в etcd через API-сервер, указывая выбранный узел.
5. kube-controller-manager постоянно следит за состоянием объектов. Его контроллеры работают независимо.
6. На выбранном worker node локальный kubelet (который не является частью control plane) опрашивает API-сервер и замечает, что ему назначен новый под.
7. kubelet инструктирует контейнерную среду (например, containerd или Docker) скачать образ и запустить контейнер.
8. kubelet начинает постоянно сообщать API-серверу о статусе пода.

Архитектурные модели развертывания

• Single-Node (Для обучения/разработки): Все компоненты control plane и worker node работают на одной машине (Minikube, kind, k3s).
• Высокодоступный (HA) Control Plane (Продакшен): Критичные компоненты (особенно kube-apiserver и etcd) развертываются в нескольких экземплярах за балансировщиком нагрузки для устранения единой точки отказа. etcd формирует кластер из 3, 5 или 7 узлов.

Таким образом, control plane — это не монолит, а слаженный оркестр из специализированных компонентов, каждый из которых выполняет свою четкую задачу для поддержания жизнеспособности и управляемости всего кластера Kubernetes.