Kubernetes разворачивается в кластере. Кластер состоит из одной или нескольких физических, или виртуальных машин, которые в терминологии Kubernetes называются ноды (или иногда встречается термин узлы).
В кластере есть 2 типа нод: управляющие ноды и рабочие ноды. На управляющих нодах запущены компоненты управляющего слоя Kubernetes, отвечающие за координацию и распределение рабочей нагрузки по рабочим нодам. Рабочие ноды — это машины, которые принимают нагрузку и на которых запускаются сервисы. По сути рабочие ноды и управляющие отличаются только типом нагрузки. На управляющих запускаются управляющие компоненты Kubernetes, на рабочих — бизнес-приложения и сервисы, т.е. полезная нагрузка.В тестовых или небольших инсталляциях Kubernetes возможна ситуация, когда управляющие ноды являются также рабочими нодами, т.е. на одних и тех же нодах запущена и управляющая, и рабочая нагрузка.
Компоненты Kubernetes
Управляющий слой (control plane, иногда можно встретить перевод этого термина “панель управления” или “плоскость управления”) представляет собой набор компонентов Kubernetes, которые позволяют управлять кластером, в том числе взаимодействовать с кластером человеку. Минимальный набор таких компонентов: etcd, api-server, kube-scheduler, controller manager. Помимо управляющих компонент, в Kubernetes входят агенты kubelet и kubeproxy, которые запущены на всех нодах кластера. Принципиальная схема взаимодействия компонентов и агентов отражена на схеме.
API Server и etcd
Для управления кластером и взаимодействия внутренних компонент Kubernetes используется API Server. Если мы решили запустить новый инстанс сервиса в кластере, то мы сообщаем о своем намерении через API Server. API Server валидирует наш запрос и производит изменения в конфигурации кластера.
Конфигурация и состояние кластера хранится в хранилище etcd. Это отказоустойчивое, децентрализованное и консистентное хранилище. Etcd может работать в кластерном режиме. Для поддержания отказоустойчивости и консистентности ему требуется как минимум 3 экземпляра. Возможны несколько вариантов инсталляций кластера etcd - разворачивание прямо в кластере Kubernetes, либо в отдельном кластере, на отдельных серверах, вне кластера Kubernetes.
Любые изменения в конфигурации кластера проходят через API Server и сохраняются в etcd. И только API Server напрямую ходит в etcd. Если кто-то хочет получить данные о состоянии кластера или его конфигурации, то он делает запросы в API Server.
В самом API Server-е нет бизнес-логики. API Server не принимает решения, например, за то, на какой ноде запустить тот или иной сервис. В нем есть логика проверки формата запросов, аутентификации, проверки прав и т.д.
Еще одной функцией API Server-а является рассылка изменений конфигураций и состояния кластера. Другие компоненты подписываются на события, слушают их и обрабатывают, либо с какой-то периодичностью перечитывают конфигурацию через API Server.
Kube-scheduler
Решение о том, на какой ноде нужно запустить полезную нагрузку, принимает компонент управляющего слоя kube-scheduler.
Используя механизм оповещения об изменениях API Server-а, kube-scheduler узнает, что нужно запустить экземпляр сервиса и принимает решение о том, на какой ноде он должен быть запущен. И через API server обновляет состояние кластера. Но сам kube-scheduler ничего не запускает.
Kubelet
Для запуска полезной нагрузки на нодах используется агент kubelet. В отличие от компонентов управляющего слоя, он запущен на каждой ноде: и управляющей, и рабочей. kubelet читает событие с помощью API Server-a, что экземпляр сервиса распределен kube-scheduler-ом на ноду, на которой он работает, и запускает экземпляр сервиса.
Для изоляции сервисов друг от друга они запускаются kubelet-ом в контейнерном окружении. Это может быть docker, cri-o или другое контейнерное окружение, которое поддерживает спецификацию Container Runtime Interface. Также в задачи kubelet-а входит следить за работоспособностью контейнеров, которые он запустил, а также некоторые другие.
Kube-proxy
Помимо kubelet-а и контейнерного окружения на каждой рабочей ноде должен еще присутствовать агент kube-proxy. Это агент, который обеспечивает внутреннюю адресацию сервисов, и способы доступа к ним. Подробнее про него и как он работает мы поговорим в разделе, посвященном объекту Service.
Ссылки: связь между нодами и управляющим слоем (плоскостью управления)
Контроллеры
Контроллер (controller) - это процесс, который пытается поддерживать в согласованном состоянии конфигурацию кластера и реальный мир.
При изменении конфигурации кластера контроллер пытается эти изменения отразить в реальном мире. Например, kubelet, когда получает событие, что должен быть запущен экземпляр сервиса, взаимодействует с контейнерным окружением для его запуска.
При изменениях в реальном мире контроллер отражает их в конфигурации кластера и опять-таки пытается, если возможно, привести реальность к требуемому состоянию. Например, если kubelet увидит, что экземпляр сервиса перестал работать, он через API Server обновит его состояние, чтобы другие компоненты могли отреагировать, и попытается его перезапустить, чтобы вернуть к жизни.
Контроллеров может быть много и разных, каждый следит за своей частью конфигурации и соответствующему ей аспекту реального мира. Какие-то контроллеры следят за рабочей нагрузкой, какие-то определяют сетевые конфигурации и т.д.
В стандартной поставке Kubernetes есть ряд контроллеров, которые обеспечивают базовые функции. Работу части этих контроллеров мы разберем чуть дальше в нашем курсе. Все встроенные в Kubernetes контроллеры для простоты упакованы в один бинарный файл. Это и есть компонент управляющего слоя kube-controller-manager.
Также можно реализовать самому контроллеры, архитектура Kubernetes позволяет это делать. Иногда такие пользовательские контроллеры еще называют операторами (operator). Но, конечно, в повседневной деятельности разработчика или архитектора самому писать контроллеры не придется, только использовать либо встроенные, либо сторонние.
Советую ознакомиться с официальной документацией :