Что входит в минимальный набор Kubernetes Cluster?

Минимальный набор компонентов Kubernetes

Минимальный (функциональный) набор Kubernetes Cluster состоит из двух основных логических частей: Control Plane (плоскость управления) и Node (рабочий узел, минимум один). В продакшн-окружении эти компоненты распределены по нескольким физическим или виртуальным машинам для обеспечения отказоустойчивости, но теоретически всё может работать и на одной машине (например, minikube или k3s).

1. Control Plane (Master Node)

Это «мозг» кластера, отвечающий за глобальные решения (оркестрация, планирование, управление состоянием). Его основные компоненты:

• kube-apiserver (API Server): Центральный компонент, который предоставляет REST API для взаимодействия с кластером. Все внутренние компоненты (контроллеры, планировщик, kubelet) и внешние клиенты (kubectl) общаются с кластером исключительно через него. Он валидирует и обрабатывает запросы, читает и записывает состояние в etcd.

  # Например, команда `kubectl get pods` отправляет HTTP-запрос к API Server
  kubectl get pods --v=9 # Флаг -v=9 покажет детали HTTP-запроса
  

• etcd: Высокодоступное распределенное key-value хранилище, в котором хранится ВЕСЬ конфигурационный и текущий состояние кластера (ноды, поды, секреты, конфиги и т.д.). Это единственный stateful-компонент Control Plane. Его целостность критически важна.

  # Это внутренний компонент, но для понимания его данных:
  # Состояние пода, которое хранит etcd, включает его spec, статус, аннотации.
  

• kube-scheduler (Scheduler): Отслеживает вновь созданные поды, у которых не назначен узел, и выбирает для них подходящий Node на основе политик, ограничений ресурсов, анти-аффинити и других критериев. Он не запускает поды на узлах, а лишь принимает решение о размещении.

  // Упрощенная логика планировщика:
  // 1. Фильтрация: Какие узлы подходят по ресурсам (CPU, RAM), taints/tolerations?
  // 2. Скоринг: Какой из подходящих узлов лучший (балансировка нагрузки, affinity)?
  

• kube-controller-manager (Controller Manager): Запускает в себе набор контроллеров, которые в бесконечном цикле следят за текущим состоянием кластера (из etcd через API Server) и приводят его к желаемому.

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

• cloud-controller-manager (опционально, для облачных сред): Отдельный компонент, который выносит логику взаимодействия со специфичным API облачного провайдера (например, создание сетевых балансировщиков нагрузки в AWS или GCP) из kube-controller-manager. В bare-metal или локальных установках (например, kubeadm) может отсутствовать.

2. Node (Worker Node)

Машина (физическая или виртуальная), на которой запускаются рабочие нагрузки (поды). Каждый узел управляется Control Plane.

• kubelet: Агент, который работает на каждом узле. Он получает от kube-apiserver набор PodSpecs (манифесты) и гарантирует, что описанные в них контейнеры запущены и здоровы. Он напрямую управляет контейнерной средой (чаще всего containerd или Docker), но НЕ управляет контейнерами, которые не были созданы Kubernetes.

  # Kubelet постоянно отчитывается API Server о состоянии узла и подов на нём
  kubectl describe node <node-name> # Информация собирается kubelet
  

• kube-proxy: Сетевой прокси, работающий на каждом узле. Реализует концепцию Service в Kubernetes. Поддерживает сетевые правила на узле, которые позволяют сетевым коммуникациям (внутренним и внешним) доходить до подов. Работает в одном из режимов: iptables (по умолчанию), ipvs (более эффективен для большого числа сервисов) или userspace (устаревший).

  # Например, kube-proxy создаёт iptables-правила для сервиса с ClusterIP
  sudo iptables-save | grep <service-name> # Можно увидеть правила маршрутизации
  

• Container Runtime: Программное обеспечение, отвечающее за запуск контейнеров (извлечение образа, создание изолированного процесса). Kubernetes поддерживает несколько рантаймов через интерфейс Container Runtime Interface (CRI): containerd (самый популярный), cri-o, Docker Engine (через dockershim, сейчас устарел).

3. Сеть и аддонны (Addons)

Для полноценного функционирования кластера необходимы дополнительные компоненты, которые часто считаются обязательными:

• CNI Plugin (Container Network Interface): Сетевой плагин, который реализует модель сети Kubernetes: каждому поду присваивается уникальный IP-адрес, и все поды могут общаться друг с другом без NAT. Без него сеть подов не будет работать. Популярные плагины: Calico, Flannel, Cilium, Weave Net.

  # После установки CNI-плагина, поды получают IP из выделенного диапазона
  kubectl get pods -o wide # В столбце IP будет виден адрес от CNI
  

• CoreDNS (или kube-dns): Кластерный DNS-сервер. Автоматически обслуживает DNS-записи для сервисов (<service>.<namespace>.svc.cluster.local) и подов. Сервис kube-dns должен работать всегда.

• Dashboard (опционально, но часто устанавливается): Веб-интерфейс для управления кластером.

Итог: Минимально рабочий кластер — это один Control Plane (с API Server, etcd, Scheduler, Controller Manager) и хотя бы один Node (с kubelet, kube-proxy и Container Runtime), связанные вместе работающей CNI-сетью и имеющие CoreDNS для service discovery. Именно такой набор разворачивают инструменты вроде kubeadm init и kubeadm join. Все остальные компоненты (Ingress Controller, мониторинг, логирование, системы хранения) — это аддонны, расширяющие функциональность.