Ключевые компоненты архитектуры Kubernetes

Введение

Kubernetes — это платформа для автоматизации развертывания (deployment), масштабирования (scaling) и управления контейнеризированными приложениями. Если вы когда-либо пытались управлять большим количеством контейнеров вручную, то оцените масштаб задач, которые Kubernetes берет на себя. Чтобы делать это эффективно, Kubernetes строится как модульная система с разными, но тесно взаимодействующими компонентами.

В этой статье я подробно расскажу, какие ключевые узлы и процессы входят в типичную архитектуру Kubernetes, как они взаимодействуют друг с другом и за что каждый отвечает. На каждом этапе объяснений вы увидите не только базовую теорию, но и практические примеры с YAML-манифестами и командами для CLI. Это поможет вам реально понять, как компоненты живут и работают в настоящем кластере.

Архитектура Kubernetes – взгляд с высоты

Прежде, чем углубиться в детали, коротко опишу общую архитектуру Kubernetes. Система строится на основе двух логических уровней:

• Control Plane (Управляющая плоскость) — отвечает за принятие всех ключевых решений о кластере: планирование задач, отслеживание состояния и реакции на изменения.
• Worker Nodes (Рабочие узлы) — непосредственно запускают контейнеры пользовательских приложений и сервисов.

Каждая из этих частей состоит из своих компонентов, которые общаются друг с другом через стандартизированные API и протоколы.

Вот наглядная схема (описание словами):

• Control Plane: kube-apiserver, etcd, kube-controller-manager, kube-scheduler, cloud-controller-manager
• Worker Node: kubelet, kube-proxy, контейнерный runtime (например, containerd или cri-o)
• Общение между управляющей плоскостью и рабочими узлами — через kube-apiserver

Теперь перейдем к разбору всех этих частей детально.

Компоненты управляющей плоскости (Control Plane)

kube-apiserver — входная точка управления кластером

kube-apiserver — это центральный компонент, через который происходит абсолютно все взаимодействие с Kubernetes. Любые команды и операции отправляются сюда, будь то действия пользователя через kubectl, внешних систем, других компонентов или внутренних контроллеров.

• Поддерживает безопасное соединение, аутентификацию и авторизацию
• Принимает JSON/YAML манифесты, валидирует и сохраняет их состояние в etcd
• Все остальные компоненты Control Plane, а также пользователи и внешние сервисы, общаются исключительно через API-сервер

Пример запроса к API-серверу

Смотрите, вы можете получить список подов командой:

kubectl get pods

В этот момент kubectl обращается к kube-apiserver, который возвращает описание всех подов, сохраненных в etcd. Вот пример http-запроса (если бы вы делали это с помощью curl):

curl --header "Authorization: Bearer <your-token>" https://<master-ip>:6443/api/v1/pods

etcd — надежное распределенное хранилище

etcd — это распределенная key-value база данных, на которую опирается всё состояние кластера. Здесь хранятся все сведения о объектах Kubernetes: подах, сервисах, namespaces, настройках и так далее.

• Позволяет гарантировать консистентность данных
• Обеспечивает механизмы резервного копирования и восстановления
• Используется только управляющей плоскостью (worker-узлы напрямую не обращаются к etcd)

Пример резервации и восстановления и резервных копий

Чтобы сделать резервную копию etcd, используйте команду:

ETCDCTL_API=3 etcdctl snapshot save snapshot.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=<path-to-cafile> \
  --cert=<path-to-certfile> \
  --key=<path-to-keyfile>

А восстановить можно так:

ETCDCTL_API=3 etcdctl snapshot restore snapshot.db

kube-controller-manager — мозг автоматизации

kube-controller-manager запускает контроллеры, которые анализируют текущее и желаемое состояние объектов в кластере и “доводят” их до совпадения друг с другом.

Каждый контроллер отвечает за свой тип объектов (Pods, Replicasets, Deployments, Namespaces и другие).

• Периодически опрашивает состояние через API-сервер
• При возникновении расхождений запускает нужные действия (например, создает новые Pods, если их стало меньше запланированного)
• Позволяет реализовать автоматическое восстановление

Пример работы контроллера ReplicaSet

Допустим, у вас запланировано 3 пода:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest

Если один из подов "падает", контроллер автоматически создаст новый.

kube-scheduler — планирование запуска подов

kube-scheduler определяет, на каких именно worker-нодах должны запускаться новые или перемещаться существующие поды.

• Оценивает доступные ресурсы (CPU, память, теги)
• Принимает во внимание policy (например, affinity/anti-affinity, taints/tolerations, ограничения по размещению)
• После выбора ноды обновляет объект Pod через API-сервер

Пример – назначение пода на отдельный node

В спецификации пода можно указать nodeSelector:

spec:
  nodeSelector:
    disktype: ssd

В этом случае kube-scheduler будет искать подходящие ноды с лейблом disktype=ssd.

cloud-controller-manager — интеграция с облачными платформами

Этот компонент необходим, если ваш кластер работает в облаке (например, AWS, GCP, Azure). Он взаимодействует с облачной инфраструктурой для автоматизации:

• создания и настройки балансировщиков нагрузки (LoadBalancer)
• управления хранилищем (PersistentVolumes)
• отслеживания состояния узлов облачной платформы

Этот компонент можно не запускать, если кластер чисто локальный.

Компоненты рабочих узлов (Worker Nodes)

kubelet — агент управления на каждом узле

kubelet устанавливается на каждый рабочий узел и выполняет основную работу по запуску контейнеров, мониторингу их статуса и поддержанию заданного состояния.

• Получает команды от kube-apiserver, в том числе спецификации для запуска подов
• Осуществляет “health check” контейнеров, перезапускает при необходимости
• Отправляет информацию о статусе подов и узла обратно в API-сервер

Пример описания Probe для Pod'а

Чтобы kubelet мог отслеживать “живость” контейнера, вы в манифесте указываете параметры healthcheck:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 10

Если сервис перестанет отвечать — контейнер будет перезапущен автоматически.

kube-proxy — сетевой маршрутизатор на уровне узла

kube-proxy отвечает за сетевую связанность между подами и сервисами как внутри одного узла, так и между разными нодами. Он может реализовываться на основе iptables или IPVS.

• Настраивает маршрутизацию входящего и исходящего трафика к нужным подам
• Обеспечивает реализацию сервисов типа ClusterIP / NodePort / LoadBalancer

Пример создания ClusterIP сервиса

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

kube-proxy будет направлять трафик на нужные поды с лейблом app=MyApp.

Контейнерный runtime — запуск и управление контейнерами

Основная задача — фактический запуск и менеджмент контейнеров. Kubernetes поддерживает несколько runtime (docker, containerd, cri-o).

• kubelet общается с runtime через Container Runtime Interface (CRI)
• Возможен выбор runtime при инициализации кластера

Пример переключения Runtime в kubeadm-кластере

В kubeadm-конфиге можно явно указать runtime:

apiVersion: kubeadm.k8s.io/v1beta2
kind: InitConfiguration
nodeRegistration:
  criSocket: /run/containerd/containerd.sock

Подключение дополнительных компонентов

Почти всегда вам потребуется установить дополнительные сервисы:

• CoreDNS или kube-dns — обеспечение работы внутреннего DNS
• Ingress Controller — управление HTTP-трафиком извне кластера
• monitoring и logging системы (например, Prometheus, Grafana, ELK stack)
• Network policy engine (например, Calico, Cilium)

Большинство из этих систем тоже “живут” как поды внутри вашего кластера и общаются через стандартные механизмы.

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

Посмотрим более наглядно:

1. Вы выполняете команду (kubectl create -f pod.yaml). Запрос идет к kube-apiserver.
2. kube-apiserver валидирует и сохраняет объект Pod в базе etcd.
3. Контроллеры в kube-controller-manager узнают, что появился новый Pod, и обрабатывают его.
4. kube-scheduler выбирает, на каком вузле запустить Pod.
5. Изменение статуса Pod сохраняется снова через API-сервер.
6. На нужной ноде действующий kubelet получает задачу запустить контейнеры.
7. Контейнеры стартуют с помощью runtime (containerd, cri-o, и т.д.).
8. kube-proxy обновляет сетевые правила, чтобы поды были доступны по сервису.

Это всё работает в тесной связи и держится на взаимодействии через API-сервер.

Резервирование и отказоустойчивость

• Управляющая плоскость (Control Plane) требует высокой доступности — ноды можно реплицировать и балансировать нагрузку.
• Мастер-компоненты, такие как etcd и kube-apiserver, могут быть запущены в кластере с failover и replica.
• Worker-узлы горизонтально масштабируются: больше нод — выше надежность и доступность.

Заключение

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

Частозадаваемые технические вопросы по теме статьи и ответы на них

Как посмотреть логи управления компонентами Control Plane?

Для того чтобы посмотреть логи kube-apiserver, kube-controller-manager, kube-scheduler, обычно используются системные журналы или команды управления сервисами на сервере управления (Control Plane):

journalctl -u kube-apiserver
journalctl -u kube-controller-manager
journalctl -u kube-scheduler

Если компоненты запущены как контейнеры (например, через static pod), используйте:

docker logs <container-name>
# или
crictl logs <container-id>

Как вручную восстанавливать кластер из резервной копии etcd?

Для восстановления etcd выполните:

1. Остановите текущий etcd.
2. Используйте команду snapshot restore (см. пример выше).
3. Перезапустите etcd и убедитесь, что путь к восстановленной базе указан верно.
4. Проверьте совместимость версий etcd и Kubernetes.

Как принудительно удалить зависший Pod или Node?

Если под или узел "завис" и не удаляется обычным способом, используйте флаг --force и --grace-period=0:

kubectl delete pod <pod-name> --grace-period=0 --force
kubectl delete node <node-name> --grace-period=0 --force

Как проверить текущий Runtime на worker-ноде?

Подключитесь к нужной ноде и выполните:

ps aux | grep containerd
ps aux | grep cri-o

Также можно посмотреть в настройках kubelet (параметр --container-runtime или используемый socket CRI).

Как обновлять компоненты управляющей плоскости без простоев?

Рекомендуется:

• Использовать несколько нод управления (high-availability).
• Обновлять поочередно каждый компонент, проверяя готовность после каждого обновления.
• Не обновляйте сразу все управляющие узлы, чтобы не потерять кворум etcd и работоспособность API-сервера.