Kubernetes кластер: из чего состоит и как создать свой первый

Kubernetes кластер складывается из серверов двух ролей. Мастер-узлы принимают решения: на них работает API-сервер, через который проходят все команды кластеру, планировщик и база состояния кластера. Worker-узлы выполняют работу, на них запускаются ваши контейнеры. В управляемом кластере VK Cloud (сервис Managed Containers) мастер-узлы и виртуальные машины worker-узлов обслуживает платформа, вам остаются группы worker-узлов, их размер и масштабирование, и сами приложения. Первый кластер создаётся из личного кабинета за один проход мастера настройки.

Слово «кластер» звучит внушительно, но для старта достаточно трёх виртуальных машин: один мастер и два worker-узла. Такой Kubernetes кластер уже умеет главное: пересоздавать контейнеры после сбоя, распределять нагрузку между узлами и обновлять приложения без остановки.

Устройство кластера проще его репутации.

Из чего состоит кластер

1. Мастер-узлы. Центральный компонент здесь API-сервер. Через него проходят все команды к кластеру, он проверяет права и сохраняет состояние объектов (документация Kubernetes API). Рядом работает планировщик, который выбирает, на каком узле запустить под (единицу запуска из одного или нескольких контейнеров). Там же работают контроллеры, которые следят за узлами и числом копий.

2. Worker-узлы. Виртуальные машины той же облачной платформы, что и остальные ваши ВМ, на каждой работает агент kubelet: он получает команды от управляющего слоя, то есть мастер-узлов, и запускает контейнеры.

3. Группы узлов. Worker-узлы объединяются в группы с одинаковой конфигурацией. Масштабируются группы независимо друг от друга. Под веб-приложения и API одна группа, под сборки, аналитику и другие задачи с большим потреблением памяти и процессора другая, с большим числом ядер и памяти на машину.

На схеме ниже устройство кластера: управляющий слой с API-сервером, планировщиком и базой состояния, под ним три worker-узла с агентом kubelet и подами, стрелки команд идут от мастера к узлам. Узлов на схеме три для наглядности, первому кластеру хватит двух.

Как создать первый кластер в VK Cloud

1. Откройте в личном кабинете раздел «Кластеры Kubernetes», задайте имя кластера и версию Kubernetes (пошаговая инструкция). Перед этим проверьте квоты проекта (лимиты на число машин, ядер и памяти) в выбранном регионе. Без запаса по квотам расширение группы узлов и автомасштабирование упрутся в лимиты. Проверка квот описана в той же инструкции.

2. Выберите тип кластера (стандартный или отказоустойчивый) и число мастеров по назначению. По архитектуре сервиса сочетаний три. Кластер с одним мастером годится для знакомства и тестов, при его недоступности кластер теряет управление. Стандартный кластер с 3 или 5 мастерами в одной зоне доступности (независимой площадке региона со своим питанием и сетью) остаётся управляемым, пока работает больше половины мастеров. Отказоустойчивый кластер разносит те же 3 или 5 мастеров по разным зонам доступности региона и переживает недоступность целой зоны. Под рабочую нагрузку берут один из двух последних.

3. Настройте сеть сразу по инструкции: сеть и подсеть узлов, подсеть подов, отдельная сеть для балансировщиков (облачных точек входа трафика) и CNI задаются при создании кластера. CNI это сетевой плагин, который соединяет поды, выбирайте его сразу, на работающем кластере плагин не меняют. Там же решается, нужен ли внешний IP-адрес у API кластера.

4. Добавьте группу worker-узлов. Для первого кластера хватит одной группы из двух узлов.

5. Подключитесь. Файл kubeconfig с адресом кластера и реквизитами доступа скачивается из личного кабинета через меню кластера, дальше ставите kubectl (консольную утилиту для команд кластеру) вместе с плагином аутентификации client-keystone-auth, указываете путь к файлу в переменной KUBECONFIG и проверяете связь командой kubectl cluster-info (подключение через kubectl).

Как кластер переживает недоступность узла

1. Агент kubelet на узле перестаёт отвечать, после чего управляющий слой помечает узел как недоступный. Решение принимает мастер, вручную ничего делать не нужно.
2. Поды под управлением Deployment (объекта, который держит заданное число копий пода) или другого контроллера пересоздаются на других worker-узлах, по умолчанию через пять минут после пометки узла недоступным, столько держит допуск tolerationSeconds 300, который кластер добавляет каждому поду. Одиночные поды без контроллера не пересоздаются. Планировщик выбирает узел по свободным ресурсам и ограничениям размещения, группа узлов сама по себе роли не играет. Здесь и срабатывает запас из двух узлов, второму есть куда принять нагрузку.
3. После возвращения узла в строй он снова принимает новые поды от планировщика. Уже работающие поды остаются там, где были пересозданы, автоматического переезда обратно нет. Если копий приложения две и они стоят на разных узлах, часть запросов может сорваться, пока управляющий слой не пометит узел недоступным (по умолчанию 40 секунд без ответа kubelet) и не уберёт адрес копии из Service, затем вторая копия тянет всё одна, и посетители видят задержку вместо простоя.

Короче говоря для заметки:

1. Кластер складывается из мастер-узлов с API-сервером и планировщиком и worker-узлов с вашими контейнерами.

2. В управляемом сервисе мастер на стороне облака, ваша зона ответственности начинается с групп worker-узлов.

3. Начинайте с одной группы из двух узлов: вырасти можно в любой момент, масштабирование не требует пересоздания кластера.

4. Сеть кластера настраивайте при создании: подсети узлов и подов, сеть балансировщиков и CNI задаются один раз, на работающем кластере CNI не меняют.