# Изучение компонентов управления Kubernetes (Control Plane)

## Введение в Control Plane

* **Роль:** Control Plane является "мозгом" кластера Kubernetes. Он отвечает за принятие глобальных решений о кластере (например, планирование Pod'ов) и за обнаружение и реагирование на события в кластере (например, запуск нового Pod'а при сбое).
* **Ключевые компоненты:** kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager.
* **Взаимодействие:** Эти компоненты работают вместе, чтобы поддерживать желаемое состояние кластера, определенное пользователем через API Kubernetes.

## 1. kube-apiserver

* **Функция:** API-сервер Kubernetes. Предоставляет HTTP/REST API для взаимодействия с кластером.
* **Роль:**
    * **Единственная точка входа:** Все взаимодействия с кластером (от пользователей, CLI `kubectl`, других компонентов) проходят через kube-apiserver.
    * **Аутентификация и авторизация:** Проверяет подлинность запросов и разрешает выполнение действий на основе настроенных политик.
    * **Валидация:** Проверяет корректность объектов Kubernetes (например, Deployment, Pod) перед их сохранением.
    * **Хранение:** Взаимодействует с etcd для сохранения и извлечения состояния кластера.
    * **Интерфейс:** Предоставляет RESTful API, который используется `kubectl` и другими клиентами.
* **Принцип работы:**
    1. Пользователь (через `kubectl` или API-клиент) отправляет запрос на создание, изменение или удаление объекта Kubernetes.
    2. kube-apiserver аутентифицирует и авторизует запрос.
    3. Запрос валидируется.
    4. kube-apiserver сохраняет или обновляет состояние объекта в etcd.
    5. Другие компоненты Control Plane (например, kube-scheduler, kube-controller-manager) наблюдают за изменениями в etcd и предпринимают необходимые действия.

## 2. etcd

* **Функция:** Распределенное, консистентное хранилище key-value, используемое Kubernetes для хранения всех данных кластера, включая конфигурацию, состояние и метаданные.
* **Роль:**
    * **Основной источник истины:** etcd хранит текущее и желаемое состояние кластера.
    * **Консистентность:** Обеспечивает согласованность данных между всеми узлами Control Plane (в отказоустойчивых конфигурациях).
    * **Надежность:** Разработан для высокой доступности и отказоустойчивости.
    * **Наблюдение (Watch):** Предоставляет механизм для других компонентов Kubernetes отслеживать изменения в хранимых данных.
* **Важность:** Потеря данных etcd может привести к потере состояния кластера и его неработоспособности. Требует тщательной настройки резервного копирования.

## 3. kube-scheduler

* **Функция:** Планировщик Kubernetes. Отвечает за назначение новых Pod'ов на подходящие узлы в кластере.
* **Роль:**
    * **Отслеживание новых Pod'ов:** Наблюдает за kube-apiserver на предмет создания новых Pod'ов без назначенного узла.
    * **Фильтрация узлов:** Определяет список подходящих узлов для запуска Pod'а на основе различных критериев (доступные ресурсы, требования Pod'а, политики affinity/anti-affinity, taint'ы и toleration'ы, node selector и др.).
    * **Ранжирование узлов:** Оценивает подходящие узлы по определенным правилам (например, использование ресурсов, распределение Pod'ов) и выбирает наиболее подходящий узел.
    * **Назначение узла:** Обновляет объект Pod'а в kube-apiserver, указывая, на какой узел он должен быть запущен. Kubelet на этом узле затем запускает контейнеры Pod'а.
* **Принцип работы:**
    1. kube-scheduler получает информацию о новом Pod'е без назначенного узла от kube-apiserver.
    2. Он фильтрует все доступные узлы, чтобы найти те, которые удовлетворяют требованиям Pod'а.
    3. Отфильтрованные узлы ранжируются на основе заданных политик.
    4. Узел с наивысшим рейтингом выбирается, и информация об этом записывается в объект Pod'а через kube-apiserver.

## 4. kube-controller-manager

* **Функция:** Запускает набор контроллеров Kubernetes. Каждый контроллер отвечает за определенный аспект управления состоянием кластера.
* **Роль:**
    * **Реализация желаемого состояния:** Контроллеры непрерывно следят за текущим состоянием кластера и предпринимают действия для приведения его к желаемому состоянию, определенному в объектах Kubernetes.
    * **Примеры контроллеров:**
        * **Node Controller:** Отвечает за мониторинг состояния узлов и обработку их выхода из строя.
        * **Replication Controller / ReplicaSet Controller / Deployment Controller:** Управляют количеством реплик Pod'ов.
        * **StatefulSet Controller:** Управляет StatefulSet'ами (Pod'ами с постоянным идентификатором и хранилищем).
        * **Service Controller:** Управляет балансировщиками нагрузки и IP-адресами для сервисов.
        * **Volume Controller:** Управляет созданием и подключением томов.
        * **Namespace Controller:** Управляет жизненным циклом Namespace'ов.
        * **Endpoint Controller:** Заполняет объект Endpoints информацией о Pod'ах, принадлежащих Service'у.
* **Принцип работы:**
    1. Контроллеры наблюдают за состоянием объектов Kubernetes через kube-apiserver.
    2. Они сравнивают текущее состояние с желаемым состоянием, определенным в спецификации объекта.
    3. Если текущее состояние не соответствует желаемому, контроллер предпринимает действия для его изменения (например, создает новые Pod'ы, удаляет лишние, обновляет конфигурацию).

## 5. cloud-controller-manager

* **Функция:** Компонент, специфичный для облачных провайдеров (AWS, Azure, GCP и др.). Интегрирует Kubernetes с инфраструктурой облачного провайдера.
* **Роль:**
    * **Управление облачными ресурсами:** Отвечает за создание и управление ресурсами облачного провайдера, такими как балансировщики нагрузки, диски хранения, сетевые интерфейсы.
    * **Абстракция от облачного провайдера:** Позволяет Kubernetes работать с различными облачными платформами, предоставляя единый интерфейс.
    * **Примеры контроллеров (в составе cloud-controller-manager):**
        * **Node Controller (cloud-specific):** Получает информацию об узлах от облачного провайдера.
        * **Service Controller (cloud-specific):** Создает облачные балансировщики нагрузки при создании Service типа LoadBalancer.
        * **Volume Controller (cloud-specific):** Управляет созданием и подключением облачных томов PersistentVolume.
* **Запуск:** Может запускаться как отдельный набор бинарных файлов, а не как часть kube-controller-manager в современных версиях Kubernetes.

## Взаимодействие компонентов Control Plane:

1. Пользователь взаимодействует с кластером через `kubectl`, который отправляет запросы к **kube-apiserver**.
2. **kube-apiserver** аутентифицирует, авторизует и валидирует запрос, затем сохраняет состояние в **etcd**.
3. **kube-scheduler** наблюдает за созданием новых Pod'ов без назначенного узла и выбирает подходящий узел, обновляя информацию в **kube-apiserver**.
4. **kube-controller-manager** (и его контроллеры) наблюдает за состоянием объектов и предпринимает действия для достижения желаемого состояния (например, создание новых ReplicaSet'ов или Service'ов), взаимодействуя с **kube-apiserver**.
5. **cloud-controller-manager** (при использовании облачного провайдера) взаимодействует с API облачного провайдера для управления облачными ресурсами на основе запросов от **kube-apiserver** (например, создание облачного LoadBalancer для Service типа LoadBalancer).
6. Узлы (через **kubelet**) наблюдают за назначенными им Pod'ами через **kube-apiserver** и управляют контейнерами (запускают, останавливают).

## Отказоустойчивость Control Plane:

* Для обеспечения высокой доступности Control Plane ключевые компоненты (kube-apiserver, etcd, kube-scheduler, kube-controller-manager) обычно запускаются в нескольких экземплярах.
* **etcd** использует протокол Raft для обеспечения консистентности между репликами.
* **kube-apiserver** работает за балансировщиком нагрузки.
* **kube-scheduler** и **kube-controller-manager** работают в режиме leader election (выбирается один активный экземпляр).

## Заключение:

Понимание компонентов Control Plane Kubernetes и их взаимодействия является ключевым для эффективного управления кластером и устранения неполадок. Эти компоненты совместно обеспечивают автоматическую оркестрацию контейнеризированных приложений, поддерживая желаемое состояние кластера и реагируя на изменения.