Из чего состоит кластер k8s

Архитектура кластера Kubernetes

Кластер Kubernetes (k8s) — это сложная распределённая система, состоящая из набора узлов (нод), которые вместе обеспечивают оркестрацию контейнеризированных приложений. Основное разделение происходит между плоскостью управления (Control Plane) и узлами данных (Data Plane / Worker Nodes). Давайте разберём каждый компонент детально.

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

Это "мозг" кластера, отвечающий за глобальные решения (например, планирование) и обнаружение/реагирование на события. Обычно работает на выделенных мастер-узлах.

• kube-apiserver: Центральный и единственный компонент, через который взаимодействуют все остальные части системы и внешние клиенты (например, kubectl). Предоставляет REST API, валидирует и обрабатывает запросы. Для высокой доступности (HA) запускается в нескольких экземплярах за балансировщиком нагрузки.

  # Пример манифеста для Pod с kube-apiserver (упрощённо)
  apiVersion: v1
  kind: Pod
  metadata:
    name: kube-apiserver
    namespace: kube-system
  spec:
    containers:
    - name: kube-apiserver
      image: k8s.gcr.io/kube-apiserver:v1.27.0
      command:
      - kube-apiserver
      - --etcd-servers=https://etcd-cluster:2379
      - --service-cluster-ip-range=10.96.0.0/12
  

• etcd: Высокодоступное распределённое key-value хранилище, в котором Kubernetes хранит ВСЕ данные кластера (состояние конфигураций, секреты, метаданные объектов). Это единственный компонент с состоянием (stateful) в Control Plane. Для отказоустойчивости требуется кластер из нечётного числа узлов (3, 5).

  # Пример команды для проверки здоровья etcd-кластера
  etcdctl --endpoints=https://etcd1:2379,https://etcd2:2379 --cert=/etc/kubernetes/pki/etcd/peer.crt --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt endpoint health
  

• kube-scheduler: Отслеживает создание Pod'ов, у которых нет назначенного узла, и выбирает оптимальный worker node для их запуска на основе политик, требований к ресурсам, affinity/anti-affinity правил.

• kube-controller-manager: Запускает в себе циклы управления (controller loops), которые следят за текущим состоянием кластера и приводят его к желаемому. Включает в себя контроллеры нод, реплик, endpoints, сервис-аккаунтов и другие.

• cloud-controller-manager (опционально): Позволяет "привязать" кластер к API облачного провайдера (AWS, GCP, Azure). Управляет облачными ресурсами: балансировщиками нагрузки, нодами, дисками.

Узлы данных (Data Plane / Worker Nodes)

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

• Kubelet: Агент, работающий на каждой worker node. Он получает спецификации Pod'ов (через API-сервер) и обеспечивает, чтобы описанные в них контейнеры были запущены и здоровы. Отчитывается о состоянии ноды и подов обратно в Control Plane.

  # Пример systemd-юнита для Kubelet (часть конфигурации)
  # /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
  [Service]
  Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
  Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
  ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS
  

• Container Runtime: Программное обеспечение, которое запускает и управляет контейнерами (извлекает образ, запускает процесс, обеспечивает изоляцию). Стандартными являются containerd и CRI-O. Docker, как runtime, устарел в Kubernetes.

• Kube-proxy: Сетевой прокси-агент на каждой ноде. Отвечает за реализацию концепции Service — предоставляет механизмы для доступа к группам Pod'ов по сети. Работает через iptables/ipvs режимы, управляя правилами балансировки нагрузки и маршрутизацией трафика.

Аддитивы (Addons)

Дополнительные компоненты, расширяющие функциональность кластера. Часто работают как Pod'ы в пространстве имён kube-system.

• CNI Plugin (Container Network Interface): Обеспечивает сетевое взаимодействие между подами на разных узлах. Создаёт "плоскую" виртуальную сеть поверх физической. Популярные реализации: Calico, Cilium, Flannel, Weave Net.

  # Пример установки Calico через манифест
  kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml
  

• DNS-сервис: CoreDNS (по умолчанию с K8s 1.13+) предоставляет механизм обнаружения сервисов по именам. Каждому Service и Pod присваивается DNS-имя.

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

• Ingress Controller: (Например, nginx-ingress, traefik) — реализует Ingress API для управления внешним доступом к сервисам по HTTP/HTTPS.

Ключевые абстракции и ресурсы

Помимо компонентов, кластер состоит из логических объектов, описывающих желаемое состояние:

• Pod: Наименьшая и простейшая единица. Группа из одного или нескольких контейнеров с общим сетевым пространством и хранилищем.
• Service, Ingress: Абстракции для сетевого доступа к приложениям.
• PersistentVolume, PersistentVolumeClaim: Абстракции для хранения данных.
• ConfigMap, Secret: Управление конфигурацией и чувствительными данными.
• Deployment, StatefulSet, DaemonSet: Контроллеры для управления жизненным циклом приложений.

Резюме: Кластер Kubernetes — это высокодоступная, отказоустойчивая система, где Control Plane (мастер-узлы) управляет и контролирует состояние через etcd, API-сервер, scheduler и контроллеры, а Worker Nodes выполняют пользовательскую нагрузку, используя Kubelet, container runtime и kube-proxy. Сетевое взаимодействие и дополнительные сервисы (DNS) обеспечиваются аддитивами. Такая архитектура позволяет эффективно оркестрировать сотни и тысячи контейнеризированных приложений.