Первое знакомство с Kubernetes базовые конструкции кластера

Первое знакомство с Kubernetes базовые конструкции кластера

В чем же различие между подом и контейнером? Под может включать в себя несколько контейнеров. Такая конфигурация позволяет реализовать паттерн Side Car, чтобы добавить к поду, например, особый сетевой proxy, сетевую телеметрию и т.д. Под – это своего рода среда выполнения одного или нескольких контейнеров. Использование Side Car диктует паттерны проектирования микросервисов, которые в одной ситуации могут эффективно решать задачи, а в другой станут избыточными.

Изучим жизненный цикл пода в кластере k8s. Процесс появления нового пода показан на схеме.

Рис 1. Жизненный цикл подаРис 1. Жизненный цикл пода

На первом этапе мы описываем под в манифесте на языке YAML. Туда включаются такие параметры как версия API, имя пода, необходимые ресурсы (CPU, RAM, HDD), исполняемый контейнер (image) и многое другое. Подробнее с манифестами мы познакомимся в следующих статьях. В итоге должен получится файл YAML, где декларативно описано будущее приложение или сервис.

Следующий этап – это обработка манифеста сервером API. Если валидация проходит успешно, сервер передает инструкций в Sheduller. В зависимости от запрошенных в поде ресурсов тот подбирает подходящую ноду (узел кластера) для размещения. Можно провести аналогию с заселением в отель и распределением на ресепшене – в какой именно номер вас распределят.

Deployment

Пока мы не видим особо разницы между Docker compose и k8s. Есть контейнеры в Docker, есть поды в k8s – просто одни и те же объекты называются по-разному. Чем же крут k8s? В нем есть Deployment, что дает нам следующие преимущества:

  • надежность за счет автоматического процесса поддержки заданного количества подов для приложения;
  • масштабируемость;
  • нулевой простой приложения при обновлениях.

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

Функциональность объекта Deployment позволяет выстроить процесс контролируемого изменения и свести к минимуму нужное для него время. Как и любой объект кластера K8s, Deployment описывается декларативно в файле YAML (примеры разберем в следующих статьях).

Service

Работает это через т.н. Labels. У каждого пода или группы подов есть своя уникальная метка, и создавая объект Service, мы указываем, какую метку он обслуживает. Тем самым за сервисом мы закрепляем определенных подов.

Service бывают:

  • ClusterIP – стандартный тип, который назначается по умолчанию. Необходим для взаимодействия по сети внутри кластера.
  • NodePort необходим для внешнего взаимодействия.
  • LoadBalanser необходим для интеграции с облачными балансировщиками нагрузки.

Допустим у вас есть текущая (v0.1) версия приложения (2 пода, разбросанных по разным нодам). Мы развернули и протестировали следующую версию (v0.2). Стоит задача переключить нее входящий трафик.

Рис 2. Текущая версия приложения v0.1Рис 2. Текущая версия приложения v0.1

Теперь переключаем входящий трафик на новую версию приложения, изменив Label Selector в Service. В результате трафик будут обрабатывать поды новой версии приложения.

Рис 3. Переключение трафика на версию v0.2Рис 3. Переключение трафика на версию v0.2

Мы познакомились с основными объектами кластера Kubernetes – это Pod, Deployment и Service. На самом деле объектов гораздо больше, но для развертывания первого приложения в кластере этих будет достаточно. В следующей статье мы напишем Deployment и Service для первого приложения и развернем его в кластере.