Kubernetes для профессионалов: от архитектуры до промышленной эксплуатации

Архитектура Control Plane и обеспечение High Availability компонентов кластера

Когда кластер Kubernetes выходит за пределы тестового контура и начинает обслуживать критический трафик, вопрос «как это работает» сменяется вопросом «почему это может упасть». В промышленной эксплуатации Kubernetes — это не просто оркестратор, а распределенная система с жесткими требованиями к консистентности и доступности данных. Понимание внутренней механики Control Plane является фундаментом для построения отказоустойчивых систем (High Availability, HA). Ошибка в конфигурации одного компонента управления может привести не просто к деградации сервиса, а к полной потере управления инфраструктурой.

Анатомия мозга: Взаимодействие компонентов Control Plane

Control Plane (узел управления) — это коллективный разум кластера. Его задача — поддерживать желаемое состояние (Desired State) объектов, описанных в манифестах. Однако Control Plane не является монолитом; это набор слабосвязанных компонентов, которые общаются между собой исключительно через API-сервер.

kube-apiserver: Единственная точка входа

Все запросы — от команд kubectl до внутренних вызовов Kubelet — проходят через kube-apiserver. Это единственный компонент, который имеет прямой доступ к хранилищу etcd. Его архитектура построена по принципу RESTful API, где каждый запрос проходит через цепочку этапов: аутентификация, авторизация и Admission Control (контроллеры допуска).

Критическая особенность kube-apiserver заключается в том, что он не хранит состояние (stateless). Это делает его самым простым кандидатом для горизонтального масштабирования. Вы можете запустить любое количество экземпляров API-сервера за балансировщиком нагрузки (L4 или L7), и они будут работать параллельно, распределяя входящий трафик.

etcd: Хранитель истины

Если API-сервер — это интерфейс, то etcd — это память кластера. Это распределенное key-value хранилище, использующее алгоритм консенсуса Raft. В Kubernetes etcd хранит всё: конфигурации, секреты, состояние подов и события.

Обеспечение HA для etcd — самая сложная и ответственная задача. В отличие от API-сервера, etcd чувствителен к задержкам сети (latency) и производительности дисковой подсистемы. Потеря консенсуса в кластере etcd означает «заморозку» Control Plane: вы не сможете создавать новые поды, обновлять конфигурации или реагировать на сбои узлов.

kube-scheduler и kube-controller-manager

Эти компоненты отвечают за логику управления. kube-scheduler ищет узлы для новых подов, а kube-controller-manager следит за тем, чтобы текущее состояние (например, количество реплик в Deployment) соответствовало заявленному.

В отличие от API-сервера, эти компоненты не могут работать в режиме «активный-активный» одновременно. Представьте, что два планировщика одновременно решили разместить один и тот же под на разные узлы, или два контроллера узлов пытаются одновременно удалить «зависший» узел. Чтобы избежать конфликтов, используется механизм Leader Election. В каждый момент времени только один экземпляр является активным лидером, а остальные находятся в режиме ожидания (Standby), постоянно проверяя статус блокировки (Lease) в API-сервере.

Алгоритм консенсуса Raft и кворум в etcd

Для понимания высокой доступности etcd необходимо разобрать понятие кворума. В распределенных системах кворум — это минимальное количество узлов, которые должны подтвердить операцию записи, чтобы она считалась успешной.

Формула кворума для etcd:

где — общее количество узлов в кластере etcd, а — необходимое число работоспособных узлов.

Рассмотрим таблицу зависимости отказоустойчивости от количества узлов:

| Количество узлов () | Кворум () | Допустимое число отказов | | :--- | :--- | :--- | | 1 | 1 | 0 | | 2 | 2 | 0 | | 3 | 2 | 1 | | 4 | 3 | 1 | | 5 | 3 | 2 | | 7 | 4 | 3 |

Почему мы всегда выбираем нечетное число узлов? Обратите внимание на переход от 3 к 4 узлам. При добавлении четвертого узла кворум увеличивается с 2 до 3, но допустимое число отказов остается прежним (1 узел). Четвертый узел лишь увеличивает нагрузку на сеть для синхронизации, не повышая надежности. Более того, при 4 узлах вероятность выхода из строя 2 узлов (что приведет к потере кворума) выше, чем при 3 узлах.

Проблема Split-Brain

Если сетевая связность между узлами etcd нарушается, кластер может разделиться на две изолированные части. Благодаря алгоритму Raft, только та часть, которая сохранила кворум (большинство), сможет продолжать операции записи. Меньшинство перейдет в режим «только чтение» или будет отклонять запросы, предотвращая рассогласование данных (split-brain).

Проектирование топологии High Availability

Существует две основные стратегии развертывания высокодоступного Control Plane: с совмещенным (Stacked) etcd и с внешним (External) кластером etcd.

Стек-топология (Stacked etcd)

В этой схеме каждый узел Control Plane запускает локальный экземпляр etcd, API-сервер, контроллер и планировщик.

Плюсы: Простота развертывания (стандарт для kubeadm), меньше виртуальных машин, автоматическое управление жизненным циклом etcd через статические поды.

Минусы: Риск потери данных выше. Если узел Control Plane выходит из строя из-за аппаратной ошибки, вы теряете и вычислительную мощность API-сервера, и членство в кластере etcd.

Внешняя топология (External etcd)

Здесь кластер etcd выносится на отдельные узлы (минимум 3), а компоненты Control Plane (API-сервер и др.) работают на других узлах.

Плюсы: Максимальная изоляция. Нагрузка на диск от etcd не аффектит API-сервер. Выход из строя всех узлов Control Plane не уничтожает данные в etcd.

Минусы: Требуется в два раза больше узлов, усложняется настройка сертификатов и сетевого взаимодействия.

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

Балансировка нагрузки и Service Discovery для API-сервера

Поскольку kube-apiserver масштабируется горизонтально, перед ним необходимо поставить балансировщик. Есть три основных подхода:

Внешний Load Balancer (Cloud/Hardware): Самый надежный вариант. Облачный провайдер предоставляет DNS или IP, который перенаправляет трафик на здоровые узлы Control Plane.

Keepalived + HAProxy: Классический On-premise подход. На узлах Control Plane запускается пара keepalived, которая управляет виртуальным IP (VIP). Трафик идет на VIP, затем через HAProxy распределяется по локальным или удаленным API-серверам.

Локальный балансировщик на рабочих узлах: На каждом Worker Node запускается легковесный прокси (например, Nginx или тот же HAProxy), который знает адреса всех мастеров. Kubelet обращается к localhost, а прокси перекидывает запрос на живой мастер. Это избавляет от единой точки отказа в виде центрального балансировщика.

Жизненный цикл запроса и Admission Controllers

Высокая доступность — это не только работающие процессы, но и корректность данных. API-сервер использует цепочку Admission Controllers для валидации и мутации объектов перед их сохранением в etcd.

Когда вы отправляете запрос на создание Пода, происходит следующее:

Mutating Admission: Контроллеры могут изменить объект (например, добавить Sidecar-контейнер или проставить дефолтные лимиты ресурсов).

Object Schema Validation: Проверка структуры YAML.

Validating Admission: Контроллеры проверяют политики безопасности (например, запрет на запуск от root). Если проверка не пройдена, запрос отклоняется.

Для HA-кластера критически важно следить за состоянием ValidatingWebhookConfiguration. Если ваш внешний вебхук проверки безопасности недоступен, API-сервер может заблокировать создание любых ресурсов в кластере (в зависимости от настройки failurePolicy).

Обеспечение надежности на уровне etcd: Практические аспекты

Администрирование etcd в HA-режиме требует внимания к трем параметрам: диску, сети и памяти.

Дисковая подсистема

etcd записывает данные в лог (WAL — Write Ahead Log) и периодически делает снимки (snapshots). Каждая операция записи требует подтверждения от диска (fsync). Если диск медленный, время подтверждения записи увеличивается, что приводит к задержкам в работе всего Kubernetes.

> Важное правило: Для промышленного использования etcd требуются SSD/NVMe накопители. В облаках (AWS, GCP) рекомендуется использовать типы дисков с гарантированным IOPS (например, io2 в AWS).

Если задержка записи (fdatasync latency) превышает 10-20 мс, etcd начнет генерировать предупреждения "Apply entries took too long". Это первый признак того, что кластер скоро станет нестабильным.

Сетевые задержки и таймауты

По умолчанию etcd настроен на работу в локальных сетях с низкой задержкой. Если вы распределяете узлы Control Plane между разными дата-центрами (Multi-AZ), необходимо подстроить параметры:

--heartbeat-interval: Частота, с которой лидер отправляет сигналы узлам (по умолчанию 100 мс).

--election-timeout: Время, через которое узлы начнут перевыборы, если лидер молчит (по умолчанию 1000 мс).

Для Multi-AZ инсталляций эти значения часто увеличивают до 250 мс и 2500 мс соответственно, чтобы избежать ложных перевыборов из-за кратковременных сетевых всплесков.

Резервное копирование и восстановление (Disaster Recovery)

HA не заменяет бэкапы. В случае логической ошибки (например, случайное удаление важного Namespace) ошибка мгновенно реплицируется на все узлы etcd.

Процесс создания бэкапа:

Восстановление из снимка — это процедура, требующая остановки всех компонентов Control Plane. Вы не можете просто «подложить» файл данных в работающий кластер. Необходимо инициализировать новый кластер etcd из снимка на каждом узле, обновив параметры --initial-cluster-token.

Самодиагностика: Как понять, что Control Plane нездоров?

Для мониторинга HA-кластера недостаточно проверять статус процесса systemctl status kubelet. Ключевые метрики здоровья Control Plane:

apiserver_request_duration_seconds: Время обработки запросов API-сервером. Рост 99-го перцентиля выше 1 секунды говорит о проблемах.

etcd_server_has_leader: Если значение равно 0, кластер etcd не работает.

etcd_server_leader_changes_seen_total: Частая смена лидера указывает на проблемы с сетью или диском.

etcd_disk_wal_fsync_duration_seconds_bucket: Прямой показатель производительности диска.

В случае сбоя одного из узлов Control Plane в HA-конфигурации, кластер продолжает работу. Однако, если вы используете Stacked-топологию, вы работаете в режиме пониженной отказоустойчивости. Восстановление узла должно быть автоматизировано (например, через Infrastructure as Code и автоскейлинг-группы), но с сохранением идентификаторов узлов etcd.

Тонкая настройка Leader Election

Как упоминалось, kube-scheduler и kube-controller-manager используют механизм выбора лидера. В Kubernetes это реализовано через объект Lease в неймспейсе kube-system.

Параметры управления:

--leader-elect-lease-duration: Длительность владения лидерством (обычно 15с).

--leader-elect-renew-deadline: Время, за которое лидер должен успеть обновить свою аренду (обычно 10с).

--leader-elect-retry-period: Интервал между попытками обновления (обычно 2с).

Уменьшение этих значений ускоряет реакцию на сбой (Failover), но создает дополнительную нагрузку на API-сервер и повышает риск «мигания» лидера при малейших сетевых задержках. В промышленных кластерах рекомендуется оставлять дефолтные значения, если нет специфических требований к скорости восстановления.

Безопасность взаимодействия компонентов

Высокая доступность невозможна без доверенной среды. В HA-кластере каждый компонент должен иметь валидный TLS-сертификат для общения с другими. Особое внимание стоит уделить Certificate Authority (CA). В распределенном Control Plane все узлы должны использовать один и тот же корневой сертификат CA, чтобы API-сервер на узле №1 мог доверять Kubelet на узле №100.

При ротации сертификатов в HA-кластере важно делать это поэтапно. Сначала обновляется CA (если нужно), затем сертификаты API-серверов по очереди, чтобы не разорвать связь между компонентами.

Граничные случаи и «подводные камни»

Проблема "Zombie" Лидера

Иногда процесс контроллера может зависнуть, но при этом продолжать удерживать блокировку в etcd. Современные реализации Kubernetes используют механизм ResourceVersion и Lease API, чтобы минимизировать это время, но в старых версиях это могло приводить к тому, что новые лидеры не могли вступить в права в течение нескольких минут.

Переполнение etcd

etcd имеет лимит на размер базы данных (по умолчанию 2 ГБ, рекомендуется увеличивать до 8 ГБ). Если лимит достигнут, etcd переходит в режим "alarm" и перестает принимать записи. В HA-кластере это выглядит как внезапный отказ всего Control Plane. Причиной часто становятся события (Events), которые не вычищаются вовремя, или злоупотребление Custom Resource Definitions (CRD).

Для предотвращения этого необходимо:

Настроить --quota-backend-bytes в параметрах etcd.

Включить автоматическую дефрагментацию (хотя Kubernetes делает compaction каждые 5 минут, физическое место на диске освобождается только при дефрагментации).

Резюме архитектурного подхода

Создание отказоустойчивого Control Plane — это баланс между сложностью и надежностью. Для большинства корпоративных задач оптимальным является использование трех узлов управления с балансировкой через VIP или внешний Load Balancer. При этом критически важным остается мониторинг состояния etcd, так как именно это звено является наиболее хрупким в архитектуре Kubernetes.

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