Продолжение. Kubernetes (1) — здесь.

Компоненты Kubernetes

При развёртывании Kubernetes, возникает кластер, состоящий из набора рабочих машин (worker machines), которые называются узлами (nodes, будем называть их в английской транскрипции – «ноды»). В нодах работают контейнеризованные приложения. Каждый кластер содержит одну или больше нод.

Рабочие ноды служат основной для хостинга «подов» (Pods), которые являются компонентами рабочих приложений. Плоскость управления (control plane) управляет рабочими нодами пользователя и подами в кластере. В рабочей среде (production) плоскость управления обычно охватывает область из нескольких компьютеров и в кластере обычно работают несколько нод, при этом обеспечивается устойчивость к отказам (fault-tolerance) и высокая доступность (high availability).

Компоненты плоскости управления Control Plane

Компоненты плоскости управления отвечают за глобальные действия внутри кластера (например, планирование задач, scheduling), а также обнаружение и реагирование на события в кластере (например, запуск нового pod , когда значение поле replicas в deployment’е не корректно).

Компоненты Control plane могут быть запущены на любой машине в кластере. Но, для простоты, все компоненты control plane обычно запускаются на одной машине. Пример установки control plane, которая работает на нескольких машинах можно посмотреть в документе Creating Highly Available clusters with kubeadm.

kube-apiserver

Kubernetes API может быть считан с сервера API, компонента плоскости управления control plane.

Реализация сервера Kubernetes API – kube-apiserver. Он предназначен для горизонтального масштабирования, то есть, запуска большего числа экземпляров (instances) kube-apiserver внутри кластера. Таким образом можно перераспределить трафик между экземплярами kube-apiserver.

etcd

Полное хранилище ключевых величин с высокой доступностью etcd используется для резервного хранения для всех данных кластера Kubernetes.

Если кластер Kubernetes использует etcd как резервное хранилище, то нужен также план резервирования (back up) для этих данных.

Документацию по etcd можно найти здесь.

kube-scheduler

Компонент плоскости управления kube-scheduler (планировщик), наблюдает за вновь создаваемыми подами (Pods) без предписанных ему узлов и выбирает узел для запуска подов. Факторы, которые нужно принимать во внимание включают: требование к индивидуальным и коллективным ресурсам, ограничения политик, ПО и оборудования, сходимость и анти-сходимость спецификаций affinity and anti-affinity specifications, локальность данных (data locality) и взаимное влияние нагрузок, а также конечные сроки исполнения (deadlines).

kube-controller-manager

Менеджер контроллеров c-m (controller manager) запускает процессы контроллера. Каждый controller представляет собой отдельный процесс, однако, чтобы снизить сложность, они все компилируются в единый бинарный файл (single binary), и выполняются как отдельный процесс.

Некоторые типы этих контроллеров:

• Контроллер нод (Node controller): следит за работой ноды и реагирует, когда она отказывает.
• Контроллер задач (Job controller): наблюдает за объектами Job, которые представляют собой одноразовые задачи, затем создаёт поды для выполнения этих задач.
• Контроллер конечных точек (Endpoints controller): распространяет объекты Endpoints, то есть объединяет сервисы и поды Services & Pods).
• Контроллеры сервисных аккаунтов и токенов (Service Account & Token): создаёт исходные аккаунты (default accounts) и токены доступа к API для новых пространств имён (namespaces).

cloud-controller-manager

Облачный менеджер контроллеров (c-c-m) – компонент плоскости управления, который вмещает в себя логику управления для облачных сред. Он позволяет соединять кластер с API провайдера облачных услуг, и отделять компоненты, которые взаимодействуют с этим облаком, от компонентов, которые взаимодействуют только с кластером.

В менеджере cloud-controller-manager работают только контроллеры, которые специфичны для данного облачного провайдера. Если нужно запустить Kubernetes в собственной ИТ-системе пользователя (on-premises), или на компьютере с целью изучения, то в кластере не будет облачного менеджера контроллеров.

Как и в случае с менеджером контроллеров (kube-controller-manager), облачный   менеджер контроллеров (cloud-controller-manager) объединяет несколько логически независимых управляющих процессов (control loops) в единый бинарный файл, который выполняется как единый процесс. Его можно горизонтально масштабировать (то есть запускать более одной его копии) для повышения производительности или для повышения устойчивости в случае отказов.

Следующие контроллеры могут зависеть от облачного провайдера:

• Контроллер нод (Node controller): для проверки того, что нода была удалена из облака после того, как перестала отвечать.  
• Контроллер маршрутов (Route controller): для установки маршрутов в нижележащей облачной инфраструктуре.
• Контроллер сервисов (Service controller): для создания модификации и удаления балансировщиков нагрузки у облачного провайдера.  

Основные концепции архитектуры Kubernetes

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

Основные термины Kubernetes представлены в лабораторной работе Lab 1 на сайте Learning.kasten.io.

Плоскость управления (Control Plane): основа Kubernetes

API для K8s и желаемое состояние (Desired State): краткий обзор

Под (Pod): наименьший развёртываемый объект в Kubernetes

Набор репликаций (Replica Set): управляет количеством работающих реплик подов.

Среда развертывания (Deployment): управляет подами Pods и наборами ReplicaSets

Сервисы (Services): абстрактный набор подовPods

Пространства имён (Namespaces): разделяют кластер на несколько частей

Том (Volume): каталог, к которому могут получать доступ поды Pods

Задача (Job): создаёт один или больше подов Pods и продолжает их создание до достижения заданного числа подов

DaemonSet: запускает Pod на всех или некоторых нодах Nodes

StatefulSet: используется для управления приложениями с сохранением состояния (stateful applications )

Расширенные определения приведены здесь: https://kubernetes.io/docs/concepts/

Строительные блоки инфраструктуры

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

Кластер (1) можно представить в виде пула ресурсов, которым управляет Kubernetes. Обычно, запускают относительно небольшое число кластеров, предпочитая увеличивать размер кластеров для увеличения емкости, а не добавлять для этого новые кластеры. Это один из способов повышения эффективности использования ресурсов в Kubernetes, поскольку один кластер может управлять многими разными нагрузками с изменяющимися характеристиками.

Ноды (2) внутри кластера являются абстракцией сервера. Контейнеры (3) работают на нодах, поскольку Kubernetes содержит уровень абстракции для сервера, а также уровень абстракции для контейнеров. Такой абстракцией являются поды Pods (4) – наименьшие объекты для вычислений, которыми управляет Kubernetes. Поды обычно содержат один контейнер, или первичный контейнер и дополнительные контейнеры для сервисов, таких как аутентификация и мониторинг. Если в поде запущено несколько контейнеров, то они жёстко связаны (tightly coupled) и имеют одно время жизни.

Kubernetes использует декларативную модель для описания состояния кластера и сервисов, работающих в нём. То есть, можно определять, что сервис должен быть развёрнут, например, не менее, чем в четырёх и не более чем в десяти подах. Причем, число подов может изменяться в зависимости от задействованной мощности процессора (CPU utilization). Если использование CPU превышает порог, то Kubernetes добавляет ещё одну ноду. Аналогично, если использование CPU падает, то ноды удаляются. Заметим, что мы не должны определять, как Kubernetes должен поддерживать текущее состояние, мы должны определять только желаемое состояние. Детали реализации остаются на усмотрение Kubernetes.

Плоскость управления (Control Plane)

Плоскость управления в Kubernetes предназначена для принятия одного решение из многих возможных. Это набор сервисов, которые используют политики, которые определяются пользователем, и направлены на поддержание кластера и его сервисов в желаемом состоянии. Плоскость управления содержит четыре основных компонента: сервер API, etcd, scheduler, и controller manager (см. рисунок ниже).

1. Сервер API обеспечивает доступ к Kubernetes API, через который осуществляется работа с Kubernetes, то есть, это в основном, интерфейс с плоскость управления control plane. Сервис API – это один или более экземпляр (instance) сервиса kube-apiserver.
2. Etcd – это высоко доступное хранилище основных параметров величин, которое используется Kubernetes для хранения данных о кластере и его состоянии.
3. Планировщик (Scheduler) – это сервис плоскости управления, который назначает поды для нод. От того, как под предписан ноду, зависит эффективность и безопасность сервиса. Планировщик при назначении рассматривает множество атрибутов подов и нод включая ресурсы, требуемые для пода, ресурсы доступные на ноде, и любые ограничения политик, например, такое, что под может работать только на нодах с определёнными характеристиками.
4. Controller manager запускает набор процессов контроллера. Контролеры управляют объектами Kubernetes: нодами (nodes), задачами (jobs), конечными точками (endpoints), и сервисными аккаунтами (service accounts). В облаке используется cloud controller manager для выполнения функций, характерных для облака.

Плоскость управления control plane общается рабочими узлами (worker nodes) для координации операций в кластере. Также плоскость управления может общаться с kubelet, работающим на каждой ноде, но также может связываться с каждой нодой, подом, или сервисом.

Продолжение раздела «Компоненты Kubernetes» см. здесь.