Kubernetes: вводная заметка

Данным материалом я начну маленький цикл заметок по мере моего знакомства с Kubernetes или, как его ещё называют, k8s. Зачем всё это надо? Это современный и востребованный продукт, а потому лучше с ним познакомиться немного поближе для расширения кругозора. Да и вообще, всегда стоит идти в ногу со временем и быть в курсе всех последних технологий.

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

Я составил для себя следующий план освоения k8s :

• пройти 7 кругов ада почитать документацию для общего понимания что, зачем и для чего, ознакомиться с архитектурой;
• освоить сущности k8s;
• подготовить окружение;
• развернуть свой кластер;
• установить dashboard для удобства управления и визуализации;
• задеплоить тестовое приложение а-ля hello-world;
• настроить доступ к приложению из внешней сети (ingress).

Ниже опишу по первым двум пунктам из плана.

Что такое Kubernetes простыми словами

Kubernetes – опенсорсная разработка компании Google на языке Go с 2014 года, также именуемая, как k8s. Данная платформа нужна для централизованного размещения, взаимодействия и управлением контейнеров (например, Docker).

Что умеет Kubernetes

• Поднимать упавшие контейнеры;
• Балансировать трафик в зависимости от нагрузки;
• Мониторить СХД;
• Проверять работоспособность приложений;
• Реплицировать ноды с приложениями;
• Мониторить ресурсы;
• Предоставлять аутентификацию и авторизацию;
• И многое другое…

Оркестрация контейнеров

Для гибкости и масштабирования используется координация взаимодействия двух и более контейнеров, называемая оркестрация. Kubernetes лишь один из инструментов по оркестрированию. Имеются также и другие: нативный Docker Swarm или Mesos.

Схема архитектуры

Основные составные и сущности k8s

Master Server (ведущий узел, head)

Основной сервер, через который происходит всё управление Kubernetes. Таких серверов может быть несколько для разделения нагрузки и отказоустойчивости. На нём располагаются такие основные компоненты, как kube-apiserver, etcd, kube-controller-manager, kube-scheduler, разного рода addons (провайдеры DNS, kube-ui, fluentd-elasticsearch и система мониторинга cluster-monitoring). Эти компоненты также могут быть разнесены по узлам, но, как правило, располагаются на одном мастер сервере.

etcd (распределённое отслеживаемое хранилище)

Является хранилищем конфигурации, взаимодействует с компонентами.

API Server

Один из ключевых составных механизмов. Предоставляется REST API, позволяет клиентам управлять контейнерами и нагрузкой.

Планировщик (scheduler)

Используется для для назначения узлов (nodes) подам. При создании пода планировщик понимает, что у новосозданного пода нет узла и назначает его (но не запускает под!).

kube-controller-manager

Является отдельным процессом , который проверяет состояние кластера (в т.ч. и узлов) через API, выполняет необходимые изменения, работает с пространством имён (namespace), отвечает за поддержание правильного количества модулей для каждого объекта контроллера репликации в системе – в общем, функций достаточно много и в начале для понимания пока хватит этого.

kubectl

Управляет кластером k8s, является интерфейсом командной строки.

Node (узел)

Сервер, на котором будут располагаться контейнеры с приложениями. Также бывает обычно несколько экземпляров.

А далее начинается самое интересное. Так называемые сущности или абстракции, расположенные на нодах.

Pod (под)

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

Services

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

У сервисов есть несколько типов:

• ClusterIP – используется по умолчанию для доступа только внутри кластера. Чтобы попадать на ресурсы извне, запускается прокси (kubectl proxy) . Такой вариант подходит обычно для траблшутинга или разового доступа. На проде так лучше не делать;
• NodePort. Название говорит за себя. На ноде открывается порт (есть ограниченный диапазон: 30000-32767), и через открытый порт трафик идёт сначала до сервиса, а потом уже попадает в нужный под. Идея использования такая: один порт – один сервис. Для прода также не особо подходит, т.к. у нод может меняться IP-адрес.

Ingress

По сути своей не является сервисом, а скорее как точка входа или маршрутизатор для трафика. Используется обычно для работы с L7 (http). После его объявления\создания в кластере, ingress сам по себе бесполезен. Для дальнейшей работы должен применяться Ingress Controller. Например, nginx controller.

Namespaces

Предоставляет своё пространство имён для сущностей k8s. Используется для логического разделения окружения . Также задаёт ограничения на использование ресурсов.

ReplicaSet

k8s позволяет оркестрировать контейнеры. Для этого изначального использовалась сущность Replication Controller, а сейчас – ReplicaSet, который позволяет создавать несколько экземпляров подов, масштабировать по горизонтали, а также отслеживать их состояние.

Deployment

Данная сущность определяет кол-во реплик, которое будет создано, а планировщик смотрит за тем, чтобы в случае возникновения проблем новые поды создавались согласно описания Deployment.

Простыми словами можно сказать, что ReplicaSet – набор подов, а Deployment – набор ReplicaSet с более высоким уровнем абстракции.

Labels\Selectors

Для идентификации приложений и взаимодействия между ними используются метки и селекторы. Используются при создании объектов кластера, далее могут идентифицироваться как набор объектов с одной общей меткой.

Для дальнейшего понимания, надо будет пробовать уже на практике создавать свои поды, сервисы, деплойменты и посмотреть, как всё это взаимодействует. Поэтому следующий шаг – подготовка к созданию кластера.