Устройство Kubernetes кластера
Kubernetes (часто называют K8s) — это система для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями. В основе её работы лежит архитектура «главный-подчиненный» (master-worker). Чтобы понять, как работает Kubernetes, нужно разобраться, из каких компонентов состоит его кластер и как они взаимодействуют.Кластер Kubernetes — это группа машин (физических или виртуальных), объединенных для выполнения общей задачи. Он состоит из двух основных частей: управляющего слоя (Control Plane) и рабочих узлов (Worker Nodes) .
Проще говоря, Control Plane — это «мозг» и «командный центр», который управляет всем кластером, а рабочие узлы — это «руки», которые выполняют работу и запускают ваши приложения .
Управляющий слой: Командный центр
Управляющий слой принимает глобальные решения о состоянии кластера и реагирует на события. В production-среде он обычно распределяется по нескольким машинам для обеспечения отказоустойчивости и высокой доступности . Основные компоненты Control Plane:1. API Server (kube-apiserver)
Это «лицо» Kubernetes, его шлюз и самый важный компонент . API-сервер — это центральная точка управления, которая предоставляет Kubernetes API. Все взаимодействия с кластером, будь то через утилиту командной строки kubectl, REST-запросы или другие инструменты, проходят именно через него .Он обрабатывает REST-запросы от пользователей и других компонентов, проверяет их и обновляет состояние кластера в хранилище etcd . Ключевая особенность kube-apiserver— способность масштабироваться горизонтально, создавая дополнительные реплики для обработки возросшей нагрузки .
2. Хранилище данных (etcd)
etcd — это высокодоступная и распределенная база данных типа «ключ-значение» . Она служит единственным источником достоверных данных (source of truth) для всего кластера . Здесь хранится абсолютно всё: информация о состоянии кластера, конфигурации, секреты, данные о подах, сервисах и других объектах . Можно сказать, что etcd — это «личный дневник» Kubernetes, куда записывается каждое событие . Наличие резервной копии данных из etcd критически важно для восстановления кластера .3. Планировщик (kube-scheduler)
Планировщик следит за новыми подами (Pod — минимальный неделимый объект в Kubernetes), у которых еще нет назначенного узла, и выбирает для них самый подходящий . Принятие решения основывается на множестве факторов: требования к ресурсам (CPU, память), ограничения (аффинити, анти-аффинити, taints/tolerations), доступность железа и даже «внешние» политики . Его задача — распределить нагрузку оптимальным образом .4. Менеджер контроллеров (kube-controller-manager)
Это набор контроллеров, которые работают как отдельные процессы, но объединены в одном бинарном файле для уменьшения сложности . Их основная работа — приводить желаемое состояние кластера к фактическому. Это бесконечный цикл наблюдения и коррекции .Например:
- Контроллер узлов (Node Controller) отслеживает состояние узлов и реагирует на их выход из строя .
- Контроллер репликации (Replication Controller) следит за тем, чтобы для пода всегда работало нужное количество реплик .
- Контроллер заданий (Job Controller) создает поды для выполнения разовых задач .
- Контроллер учетных записей и токенов создает учетные записи для новых пространств имен .
5. Менеджер контроллеров облака (cloud-controller-manager)
Это необязательный компонент, который интегрирует кластер с API облачного провайдера (например, AWS, GCP, Azure) . Он позволяет управлять облачными ресурсами, такими как балансировщики нагрузки или маршруты, отделяя логику, специфичную для облака, от основного кода Kubernetes . Если вы разворачиваете кластер "на голом железе", этот компонент вам не нуженРабочие узлы: «Руки» кластера
На рабочих узлах (Worker Nodes) выполняются ваши приложения. Каждый узел должен иметь три ключевых компонента .1. Агент узла (kubelet)
Это самый важный агент на каждом узле. Он является «глазами и ушами» Control Plane на ноде. kubelet получает от API-сервера манифесты (спецификации) подов и обеспечивает, чтобы все контейнеры, описанные в этих спецификациях, были запущены и работали . Кроме того, он постоянно следит за состоянием подов, выполняя различные проверки их жизнеспособности (probes) .2. Сетевой прокси (kube-proxy)
Компонент, отвечающий за сеть. kube-proxy поддерживает сетевые правила на узле, которые позволяют вашим подам общаться друг с другом, а также с внешним миром . Он реализует механизм Service и работает как внутренний балансировщик нагрузки, распределяя трафик между подами . В некоторых современных сетевых решениях (CNI-плагинах), этот компонент может не использоваться, так как его функции берет на себя плагин .3. Среда выполнения контейнеров (Container Runtime)
Это фундаментальный компонент, который непосредственно запускает контейнеры на узле. Kubernetes поддерживает любые рантаймы, реализующие интерфейс CRI (Container Runtime Interface), например, containerd и CRI-O .Сеть в Kubernetes
Сеть — одна из самых сложных и важных частей Kubernetes. Она подчиняется строгим правилам:- Все поды могут общаться друг с другом напрямую без использования NAT.
- Все узлы могут общаться со всеми подами без NAT.
- IP-адрес, который видит под, — это его реальный IP-адрес .
Для доступа к приложениям извне используется несколько механизмов:
- Service — абстракция, которая предоставляет стабильный доступ к группе подов через их метки .
- Ingress — объект, который управляет внешним HTTP/HTTPS-доступом к сервисам внутри кластера, позволяя гибко настраивать маршрутизацию .