☸️ Первое знакомство с Kubernetes: что под капотом у системы оркестрации?

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

Что под капотом у оркестратора?

Любой ИТ-дирижер позволяет развертывать приложения, управлять ими и реагировать в реальном времени на происходящие в них изменения. Типичные, задачи которые стоят перед оркестратором:

• Развертывание (deploy);
• Масштабирование (scale);
• Мониторинг состояния (self-check);
• Обеспечение нулевого просто/ при обновлениях (zero downtime updates);
• Балансировка ресурсов (scheduler resource).

Примеры оркестраторов

Apache Mesos

Apache Mesos – централизованная система управления кластером. Она объединяет в группы отдельные узлы согласно требованиям, а также обеспечивает их изоляцию от остальных IT-ресурсов. Разработанный в университете Беркли продукт вышел в 2009 г. и имеет нестандартный подход к архитектуре. Apache Mesos отлично подходит для создания очень больших систем и реализации масштабных проектов.

Kubernetes

Самый модный оркестратор основан на разработках Google. В 2014 г. корпорация открыла код Kubernetes и стала распространять систему под лицензией Apache 2.0. В результате началось быстрое развитие продукта сообществом, и на данный момент он используется как в небольших проектах, так и в сегменте Enterprise.

Docker Swarm

Компания Docker (в девичестве dotCloud) одной из первых предложила реализацию контейнеров и систему управления ими. Kubernetes внутри себя обычно использует Docker как среду исполнения контейнеров (Container runtimes). Docker swarm позволяет объединять хосты Docker в общий виртуальный хост. Обычно это решение используют в относительно небольших проектах.

Что под капотом у Kubernetes?

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

На схеме видно, что внутри кластера есть некоторое количество нод (от англ. node – узел), на которых запущена среда исполнения контейнеров (Container runtimes). В Conteiner runtime живет контейнер, а в нем – наше приложение. Вот такая матрешка получается. Kubernetes управляет этими матрешками, отслеживает их состояние, планирует ресурсы (CPU, RAM, HDD) и осуществляет при необходимости масштабирование.

Control Plane

Мозгом Kubernetes кластера является набор компонентов, которые обычно устанавливаются на Master node (мастер-узел). В разных конфигурациях k8s мастеров может быть несколько – это необходимо, если требуется высокая доступность кластера. На схеме показан набор компонентов мастер-ноды.

Познакомимся поближе с каждым из них.

API server

Этот компонент является endpoint, т.е. точкой контакта, на которую приходят запросы на создание объектов Kubernetes. API Server – единственный компонент, который общается с Сluster store напрямую.

Основные функции:

• Авторизация и проверка подлинности. API Server реализует механизмы проверки подлинности пользователей и авторизации для выдачи им ресурсов.
• Входной контроль (admission controllers) – ряд политик, которые валидируют все потоки входящих данных.
• Наблюдение. Когда один компонент пишет в API Server ресурс, за которым другой компонент ведет наблюдение, второй имеет возможность отреагировать на изменение практически мгновенно.

Scheduler

Компонент, который отслеживает созданные поды без привязанного узла и выбирает узел, на котором они должны работать с учетом запрошенных ресурсов и фактических ресурсов ноды.

Основные функции:

• Подбирает ноду, на которой есть свободное место и которая удовлетворяет другим требованиям (политикам, пиритизации и т.д.).
• Привязывает Pod к ноде.
• Находит не привязанные к нодам поды.

Cluster store (etcd)

Этот компонент реализует распределенное и высоконадежное хранилище данных в формате key-value, которое используется как основное для данных кластера Kubernetes. Рекомендуется делать его резервные копии, поскольку если Cluster store разрушится, под угрозой весь кластер k8s.

Controllers

Компонент, осуществляющий контроль на всех уровнях кластера Kubernetes.

Основные функции:

• Контроллер узла (Node Controller) уведомляет и реагирует на сбои узла.
• Контроллер репликации (Replication Controller) поддерживает правильное количество подов для каждого объекта.
• Контроллер конечных точек (Endpoints Controller) заполняет объект конечных точек (Endpoints), а также связывает сервисы (Services) и поды (Pods).
• Контроллеры учетных записей и токенов (Account & Token Controllers) создает стандартные учетные записи и токены доступа API для новых пространств имен.

Node

Мы разобрали на верхнем уровне, что из себя представляет Control plane. Это своего рода серверная часть, обслуживающая очередь клиентов. Клиентами являются Worker node (рабочие ноды), на которых мы и развертываем наши приложения.

Основные функции:

1. Слушать API-сервер на предмет новых рабочих заданий.
2. Выполнять задания.
3. Отчитываться API-серверу о состояниях заданий.

На каждой Worker node есть определенный набор компонентов, представленный на схеме.

Познакомимся с ними.

Kubelet

Самый главный компонент Worker node. Через него происходит обмен данными с API-сервером. Основная функция – слушать сервер на предмет появления новых заданий и выполнять их при необходимости. Также Kubelet отчитывается серверу о проделанной работе.

Container runtime

Для выполнения задач на ноде необходима некая среда исполнения, внутри которой запускаются контейнеры с приложениями: обычно это Docker, но Kubernetes поддерживает и другие варианты. Например containerd, реализующий модель Container Runtime Interface (CRI). Выбор среды исполнения остается за вами.

Kube proxy

Последний компонент Worker node отвечает за локальную сеть. Он гарантирует, что каждый узел получит свой уникальный IP, реализует правила IPTABLES или IPVS для управления маршрутизацией и балансировкой нагрузки трафика во внутренней сети k8s.

Подведем итог. Если соединить компоненты Control Plan и компоненты Worker nodes, получится следующая схема.

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