Как работает Кубернет?

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

Определение кластера

Одна установка Kubernetes называется «кластером». В кластере есть один или несколько узлов, доступных для запуска ваших контейнеров. Узел — это представление физической машины, присоединенной к кластеру.

Kubernetes также имеет поверхность Control Plane. Это работает независимо от рабочих узлов. Плоскость управления — это то, с чем вы взаимодействуете. Он предоставляет Kubernetes API и отвечает за управление рабочими узлами. Обычно вы не манипулируете напрямую узлами и их рабочими нагрузками.

Инструктирование Kubernetes по созданию рабочей нагрузки начинается с вызова API в Control Plane. Затем плоскость управления определяет узлы, на которые должны быть запланированы ваши контейнеры. Независимо от того, сколько у вас узлов, в вашем кластере всегда будет только одна плоскость управления.

Роль плоскости управления

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

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

Ядром уровня управления является kube-apiserver. Этот компонент предоставляет HTTP API Kubernetes, который вы используете с помощью таких инструментов, как Kubectl и Helm. API — это то, как вы взаимодействуете со своим кластером. Он также используется другими компонентами кластера, такими как рабочие процессы узла, для передачи информации обратно в плоскость управления.

Ресурсы в вашем кластере, такие как модули, службы и задания, управляются отдельными «контроллерами». Контроллеры контролируют свои ресурсы на предмет работоспособности и готовности. Они также идентифицируют запрошенные изменения, а затем предпринимают шаги для перевода текущего состояния в новое желаемое состояние.

Контроллеры управляются в совокупности с помощью kube-controller-manager. Этот компонент Control Plane запускает и запускает отдельные контроллеры. Этот процесс будет работать всегда. Если бы он когда-либо останавливался, изменения, сделанные через сервер API, не были бы идентифицированы, и никакие изменения состояния никогда не происходили бы.

Еще одним важным компонентом Control Plane является kube-scheduler. Планировщик отвечает за назначение подов узлам. Планирование обычно требует учета нескольких различных параметров, таких как текущее использование ресурсов каждым узлом и любые ограничения, которые вы установили в своем манифесте.

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

Вся плоскость управления обычно выполняется на одном узле внутри кластера. Технически возможно распространить плоскость управления на несколько узлов. Это помогает максимально увеличить его доступность.

Обычно при потере Control Plane вы не можете управлять своим кластером, поскольку функции API и планирования отключаются. Тем не менее, поды на рабочих узлах будут продолжать работать — они будут периодически пытаться переподключиться к плоскости управления.

Связь между узлами и плоскостью управления

Kubernetes поддерживает двусторонний канал связи между узлами и плоскостью управления.

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

Все рабочие узлы запускают экземпляр kubelet. Это утилита агента, отвечающая за поддержание связи с плоскостью управления Kubernetes. Kubelet также постоянно отслеживает контейнеры, на которых работает Node. Он уведомит Control Plane, если контейнер перейдет в неработоспособное состояние.

Когда узлу необходимо отправить данные в Control Plane, Kubelet подключается к API-серверу Control Plane. При этом используется тот же интерфейс HTTPS, к которому вы подключаетесь с помощью таких инструментов, как kubectl. Kubelet предварительно настроен с учетными данными, которые позволяют ему проходить аутентификацию в Kubernetes.

Трафик от Control Plane к узлам снова обрабатывается с помощью kubelet. Kubelet предоставляет собственную конечную точку HTTPS, к которой может получить доступ Control Plane. Эта конечная точка принимает новые манифесты контейнеров, которые kubelet затем использует для настройки запущенных контейнеров.

Что еще делают узлы?

Kubelet — не единственный двоичный файл, который должен запускаться на узле Kubernetes. Вы также найдете экземпляр kube-proxy на каждом узле. Он отвечает за настройку сетевой системы узла в соответствии с требованиями рабочих нагрузок вашего контейнера.

В Kubernetes есть концепция «сервисов», которые представляют несколько подов как единую сетевую идентификацию. Это kube-proxy, который преобразует определения службы в сетевые правила, обеспечивающие запрошенный вами доступ.

kube-proxy настраивает сетевую инфраструктуру операционной системы для предоставления услуг, созданных kubelet. Переадресация трафика обрабатывается либо уровнем фильтрации пакетов на уровне ОС, либо самим kube-proxy.

Помимо kubelet и kube-proxy, на узлах также должна быть доступна среда выполнения контейнера. Среда выполнения контейнера отвечает за извлечение образов и фактический запуск ваших контейнеров. Kubernetes поддерживает любую среду выполнения, реализующую спецификацию Container Runtime Interface. Примеры включают containerd и CRI-O.

Заключение

Kubernetes включает в себя множество терминов. Разбивка кластеров на составные части поможет вам понять, как взаимосвязаны отдельные компоненты.

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

Таким образом, Control Plane является центром вашего кластера. Обычно вы не взаимодействуете с узлами напрямую. Вместо этого вы отправляете инструкции плоскости управления, которая затем создает соответствующие расписания для выполнения вашего запроса. Рабочие нагрузки планируются для узлов только тогда, когда Control Plane отправляет манифест контейнера одному из доступных экземпляров kubelet.

Когда узел получает новый манифест, он будет использовать свою среду выполнения контейнера для извлечения соответствующего образа и запуска нового экземпляра контейнера. Затем kube-proxy изменит сетевую конфигурацию, чтобы настроить службы и сделать вашу рабочую нагрузку доступной. Kubelet передает данные о работоспособности узла обратно в Kubernetes, позволяя ему принять меры для изменения расписания подов, если ресурсы узла становятся ограниченными.