• Архитектура кластера
  • Общая структура кластера
  • Компоненты Master узла
    • API Server (kube-apiserver)
    • etcd
    • Scheduler (kube-scheduler)
    • Controller Manager (kube-controller-manager)
  • Компоненты Worker узла
    • kubelet
    • kube-proxy
    • Container Runtime
  • Взаимодействие компонентов
  • Практика: анализ кластера
    • Проверка здоровья компонентов
    • Анализ размещения Pod
  • Заключение

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

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

Общая структура кластера

Kubernetes кластер состоит из двух основных типов узлов:

• Master узел (Control Plane) — управляет кластером, принимает решения о размещении приложений, следит за состоянием и обрабатывает API-запросы
• Worker узел (Data Plane) — выполняет реальную работу, запускает контейнеры и обрабатывает трафик приложений

Представьте кластер как оркестр. Master узел — это дирижёр, который координирует работу всех музыкантов, отслеживает темп и управляет выступлением. Worker узлы — это музыканты, которые исполняют музыку согласно указаниям дирижёра. Без дирижёра музыканты не знают, когда начинать и как играть согласованно, а без музыкантов дирижёр не может создать музыку.

В production-окружениях обычно используется несколько Master узлов для обеспечения высокой доступности. Worker узлов может быть десятки или сотни, в зависимости от размера кластера.

Компоненты Master узла

Master узел содержит компоненты Control Plane, которые управляют кластером. Давайте разберём каждый из них.

API Server (kube-apiserver)

API Server — это центральный компонент Kubernetes, через который происходит всё взаимодействие с кластером. Когда вы выполняете команду kubectl, она обращается именно к API Server.

# Посмотреть адрес API Server
kubectl cluster-info

# Посмотреть версию API
kubectl version

API Server выполняет несколько ключевых функций:

• Обработка запросов — принимает HTTP/HTTPS запросы от kubectl, других компонентов и приложений
• Аутентификация и авторизация — аутентификация проверяет, кто вы (например, пользователь admin или сервисный аккаунт приложения), а авторизация определяет, что вам разрешено делать (например, создавать Pod, но не удалять Service)
• Валидация — проверяет корректность конфигураций перед их применением. Например, валидация убедится, что в манифесте Pod указан образ контейнера и заданы обязательные поля
• Взаимодействие с etcd — сохраняет и читает состояние кластера

API Server — это единственный компонент, который напрямую работает с etcd. Все остальные компоненты обращаются к данным кластера только через API Server.

# Посмотреть статус компонентов Control Plane
kubectl get componentstatuses

# Посмотреть Pod API Server
kubectl get pods -n kube-system | grep apiserver

etcd

etcd — это распределённое key-value хранилище, которое содержит всё состояние кластера: конфигурации Pod, Service, Secret, статусы и метаданные.

# Посмотреть Pod etcd
kubectl get pods -n kube-system | grep etcd

# Посмотреть логи etcd
kubectl logs -n kube-system <etcd-pod-name>

etcd использует алгоритм Raft для обеспечения консистентности данных между несколькими узлами. Консистентность означает, что все узлы etcd хранят одинаковые данные и согласованы друг с другом. Алгоритм Raft — это протокол, который обеспечивает согласование изменений между узлами путём выбора лидера, который координирует все записи.

В production рекомендуется использовать нечётное количество узлов etcd (3, 5, 7) для обеспечения кворума. Кворум — это минимальное количество узлов, которые должны быть доступны для принятия решений. Например, в кластере из 3 узлов кворум составляет 2 узла — система продолжит работать, даже если один узел выйдет из строя. Нечётное количество узлов выбирается потому, что кластер из 4 узлов выдерживает тот же отказ одного узла, что и кластер из 3 узлов, но потребляет больше ресурсов.

Потеря данных в etcd означает полную потерю состояния кластера — Kubernetes не сможет восстановить информацию о Pod, Service, Secret и других ресурсах. Поэтому регулярное резервное копирование etcd критически важно.

Scheduler (kube-scheduler)

Scheduler отвечает за размещение Pod на узлах кластера. Когда вы создаёте Pod, Scheduler анализирует требования к ресурсам и выбирает оптимальный узел.

# Посмотреть Pod Scheduler
kubectl get pods -n kube-system | grep scheduler

# Посмотреть логи Scheduler
kubectl logs -n kube-system <scheduler-pod-name>

Scheduler работает в несколько этапов:

1. Filtering (фильтрация) — исключает узлы, которые не подходят для размещения Pod. Например, если Pod требует 4 GB памяти, а на узле доступно только 2 GB, этот узел будет исключён. Также фильтруются узлы, которые не соответствуют ограничениям размещения (nodeSelector, taints/tolerations)
2. Scoring (оценка) — оценивает оставшиеся узлы по различным критериям и присваивает им баллы. Учитывается равномерное распределение нагрузки, предпочтения размещения, близость данных и другие факторы
3. Binding (привязка) — назначает Pod на узел с наивысшим баллом и сохраняет это решение через API Server

Если Scheduler не может найти подходящий узел, Pod остаётся в состоянии Pending.

Controller Manager (kube-controller-manager)

Controller Manager содержит множество контроллеров, которые следят за состоянием кластера и приводят его к желаемому состоянию.

# Посмотреть Pod Controller Manager
kubectl get pods -n kube-system | grep controller-manager

# Посмотреть логи Controller Manager
kubectl logs -n kube-system <controller-manager-pod-name>

Основные контроллеры:

• Node Controller — следит за состоянием узлов
• Replication Controller — поддерживает нужное количество реплик Pod
• Deployment Controller — управляет обновлениями Deployment
• Service Controller — создаёт LoadBalancer в облачных провайдерах

Контроллеры работают по принципу "наблюдай и действуй" — постоянно проверяют текущее состояние и выполняют действия для приведения к желаемому.

Компоненты Worker узла

Worker узлы выполняют реальную работу — запускают контейнеры и обрабатывают трафик. Каждый Worker узел содержит несколько компонентов.

kubelet

kubelet — это агент, который работает на каждом узле и управляет Pod. Это единственный компонент, который напрямую взаимодействует с container runtime.

# Посмотреть статус kubelet (на узле)
systemctl status kubelet

# Посмотреть логи kubelet (на узле)
journalctl -u kubelet -f

kubelet выполняет следующие функции:

• Получение инструкций — запрашивает у API Server список Pod для узла
• Управление контейнерами — запускает, останавливает и перезапускает контейнеры
• Мониторинг — проверяет состояние контейнеров и отправляет отчёты
• Управление томами — монтирует и размонтирует тома
• Выполнение проб — запускает Liveness, Readiness и Startup Probe

kubelet работает в режиме "desired state" — постоянно сравнивает текущее состояние с желаемым.

kube-proxy

kube-proxy обеспечивает сетевую связность в кластере. Он реализует концепцию Service, перенаправляя трафик с Service IP на Pod.

# Посмотреть Pod kube-proxy
kubectl get pods -n kube-system | grep kube-proxy

# Посмотреть конфигурацию kube-proxy
kubectl get configmap -n kube-system kube-proxy -o yaml

kube-proxy работает в одном из режимов:

• iptables (по умолчанию) — использует iptables (встроенный Linux firewall) для создания правил перенаправления трафика. Когда приложение обращается к Service, iptables автоматически перенаправляет запрос на один из Pod
• ipvs (IP Virtual Server) — более производительный режим для больших кластеров. ipvs — это балансировщик нагрузки на уровне ядра Linux, который работает быстрее iptables при большом количестве Service
• userspace — устаревший режим, где kube-proxy работает как обычное приложение. Не рекомендуется из-за низкой производительности

kube-proxy следит за изменениями Service и Endpoints и обновляет правила перенаправления соответственно.

Container Runtime

Container Runtime — это программное обеспечение, которое запускает контейнеры. Это слой между Kubernetes и контейнерами, который выполняет низкоуровневые операции: создаёт изолированные процессы, настраивает сеть и файловую систему, ограничивает ресурсы.

Kubernetes поддерживает несколько runtime через Container Runtime Interface (CRI) — стандартный интерфейс, который позволяет использовать разные runtime без изменения кода Kubernetes.

# Посмотреть container runtime на узлах
kubectl get nodes -o wide

Популярные container runtime:

• containerd — современный и быстрый runtime, рекомендуемый для production. Это тот же компонент, который раньше использовался внутри Docker
• CRI-O — лёгковесный runtime, созданный специально для Kubernetes. Поддерживает только функции, необходимые для работы с Kubernetes
• Docker — исторически первый runtime, но считается устаревшим для Kubernetes (с версии 1.24 требуется установка дополнительного адаптера)

Container Runtime отвечает за загрузку образов из registry (например, Docker Hub), создание контейнеров, управление ресурсами (CPU, память) и мониторинг состояния контейнеров.

Взаимодействие компонентов

Давайте проследим жизненный цикл Pod от создания до запуска:

1. Пользователь выполняет kubectl apply -f pod.yaml
2. kubectl отправляет запрос к API Server
3. API Server валидирует запрос и сохраняет конфигурацию в etcd
4. Scheduler замечает новый Pod без назначенного узла
5. Scheduler выбирает подходящий узел и обновляет информацию через API Server
6. kubelet на выбранном узле видит новый Pod для своего узла
7. kubelet запускает контейнеры через Container Runtime
8. kubelet отправляет статус Pod обратно в API Server
9. kube-proxy обновляет сетевые правила для доступа к Pod

Все компоненты взаимодействуют асинхронно через API Server, что обеспечивает гибкость и отказоустойчивость системы.

Практика: анализ кластера

Давайте проанализируем состояние вашего кластера:

# Общая информация о кластере
kubectl cluster-info

# Посмотреть все узлы
kubectl get nodes

# Подробная информация об узле
kubectl describe node <node-name>

# Посмотреть все компоненты Control Plane
kubectl get pods -n kube-system

# Посмотреть состояние компонентов
kubectl get componentstatuses

# События кластера
kubectl get events --all-namespaces --sort-by=.metadata.creationTimestamp

# Использование ресурсов узлов
kubectl top nodes

Эти команды дают полную картину состояния кластера и помогают выявить проблемы.

Проверка здоровья компонентов

Убедимся, что все компоненты работают корректно:

# Проверить статус Pod в kube-system
kubectl get pods -n kube-system

# Проверить логи API Server
kubectl logs -n kube-system <apiserver-pod-name>

# Проверить логи Scheduler
kubectl logs -n kube-system <scheduler-pod-name>

# Проверить логи Controller Manager
kubectl logs -n kube-system <controller-manager-pod-name>

Все Pod в namespace kube-system должны быть в состоянии Running. Если какой-то компонент в состоянии Error или CrashLoopBackOff, это указывает на проблемы с кластером.

Анализ размещения Pod

Посмотрим, как Pod распределены по узлам:

# Посмотреть Pod с информацией об узлах
kubectl get pods -o wide --all-namespaces

# Посмотреть Pod на конкретном узле
kubectl get pods --all-namespaces --field-selector spec.nodeName=<node-name>

# Посмотреть ресурсы, используемые Pod
kubectl top pods --all-namespaces

Равномерное распределение Pod по узлам говорит о хорошей работе Scheduler.

Заключение

Понимание архитектуры Kubernetes — это фундамент для эффективной работы с системой. Master узлы управляют кластером через API Server, Scheduler и Controller Manager, а Worker узлы выполняют реальную работу через kubelet и container runtime. Все компоненты взаимодействуют через API Server, который хранит состояние в etcd.

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