Как взаимодействуют компоненты Kubernetes

Архитектура взаимодействия компонентов Kubernetes

Kubernetes представляет собой оркестратор контейнеров, построенный по модульной архитектуре "клиент-сервер". Все компоненты взаимодействуют через API-сервер, который выступает центральной точкой управления. Рассмотрим детализацию этого взаимодействия.

Основные компоненты и их роли

Control Plane (Плоскость управления):

• API Server (kube-apiserver): Центральный управляющий компонент, предоставляющий REST API для всех операций.
• etcd: Высокодоступное хранилище "ключ-значение", хранящее всю конфигурацию и состояние кластера.
• Scheduler (kube-scheduler): Отвечает за размещение подов на узлах на основе политик и доступных ресурсов.
• Controller Manager (kube-controller-manager): Запускает контроллеры (ноды, репликаций, endpoints), которые следят за текущим состоянием и приводят его к желаемому.

Data Plane (Плоскость данных / Узлы):

• Kubelet: Агент на каждом узле, отвечающий за запуск, поддержание и мониторинг контейнеров в подах.
• Container Runtime (Docker, containerd): Непосредственно запускает контейнеры.
• Kube-proxy: Обеспечивает сетевое взаимодействие между подами, реализуя абстракцию Service.

Последовательность типичного взаимодействия (на примере создания пода)

1. Запрос от пользователя или CI/CD системы

   kubectl apply -f pod.yaml
   

    Клиент `kubectl` отправляет YAML-манифест в **API Server** по HTTPS.

1. Аутентификация и авторизация в API Server

    *   API Server проверяет подлинность запроса (сертификаты, токены).
    *   Затем проверяет права доступа (RBAC).
    *   Валидирует манифест на соответствие схеме.

1. Сохранение состояния в etcd

    После успешных проверок API Server записывает объект Pod (в состоянии "Pending") в распределенное хранилище **etcd**. Только после этой записи состояние считается сохраненным.

1. Работа Scheduler

    **Scheduler**, наблюдая за API Server (через механизм watch), обнаруживает новый Pod без назначенного узла. Он выполняет алгоритм фильтрации и оценки:

```go
// Упрощенная логика (псевдокод)
filteredNodes = FilterNodesByResources(podSpec, allNodes)
prioritizedNodes = ScoreNodes(filteredNodes, podSpec)
bestNode = SelectHighestScore(prioritizedNodes)
```

    Выбрав подходящий узел, Scheduler обновляет объект Pod в API Server, присваивая ему поле `nodeName`.

1. Работа Kubelet на целевом узле

    **Kubelet** на назначенном узле также наблюдает за API Server. Обнаружив Pod с `nodeName`, равным его имени узла, он:
    *   Скачивает образы контейнеров через **Container Runtime**.
    *   Создает и монтирует volumes.
    *   Запускает контейнеры через runtime (например, **containerd**).
    *   Отправляет периодические отчеты о состоянии (liveness) обратно в API Server.

1. Обновление состояния в etcd

    API Server получает статус от Kubelet и обновляет состояние Pod (например, на "Running") в **etcd**.

1. Сетевая настройка Kube-proxy

    Если Pod становится частью **Service**, **Controller Manager** создает/обновляет объекты Endpoints. **Kube-proxy** на каждом узле наблюдает за этими изменениями и переконфигурирует правила iptables или IPVS, чтобы трафик на ClusterIP сервиса перенаправлялся на IP-адреса готовых подов.

Ключевые принципы взаимодействия

• Единый источник истины: Состояние всей системы хранится в etcd. Все компоненты действуют, чтобы привести реальное состояние к задекларированному в etcd.
• Реактивная модель (watch-loops): Почти все компоненты (Scheduler, Controller Manager, Kubelet) непрерывно наблюдают за изменениями в API Server, а не полагаются на периодический опрос. Это делает систему отзывчивой.
• Разделение ответственности: Компоненты узко специализированы. Например, Scheduler только выбирает узел, но никогда не запускает контейнеры.
• Идемпотентность: Контроллеры спроектированы так, что многократное выполнение одной операции (например, создание пода) приводит к одинаковому результату. Это обеспечивает устойчивость к сбоям.
• Декларативный подход: Пользователь описывает желаемое состояние (в манифестах). Kubernetes через свои контроллеры непрерывно работает для достижения и поддержания этого состояния.

Таким образом, взаимодействие компонентов Kubernetes представляет собой слабо связанную, событийно-ориентированную систему, где API Server и etcd выступают в роли шины данных и координатора, обеспечивая согласованность, масштабируемость и отказоустойчивость всей платформы.