Создание и настройка кластера Kubernetes

Кластер Kubernetes (K8s кластер) – это группа серверов (нод), объединенных для совместного запуска и управления контейнерными приложениями. Подробнее о том, как устроен кластер, – в статье “Основы Kubernetes”.

Для создания кластера перейдите в раздел “Облако” панели управления, нажмите “Создать сервис” и выберите “Kubernetes-кластер”.

Имя и регион

Укажите название кластера и выберите регион размещения. На данный момент доступен один регион – Россия, Санкт-Петербург.

Управляющий контур (control plane)

Управляющий контур – это компоненты Kubernetes в cloud-инфраструктуре, отвечающие за координацию кластера, которые размещаются на выделенных master-нодах. Вам нужно выбрать количество master-нод и версию Kubernetes.

Количество master-нод (узлов управляющего контура)

Этот параметр определяет отказоустойчивость кластера:

1 master-нода – для разработки и тестирования.

• Минимальная стоимость
• При сбое master-ноды уже запущенные приложения продолжают работать в штатном режиме, но внутренние функции кластера становятся недоступны: нельзя создавать и изменять ресурсы, планировать новые поды (единицы развертывания), выполнять команды kubectl (консольный инструмент для управления Kubernetes)
• Любое обслуживание (обновление, рестарт) приводит к временной недоступности управления кластером

3 master-ноды – для production-окружений (рабочее окружение, где приложение/сервис доступно реальным пользователям).

• При выходе из строя одной master-ноды управление кластером продолжает работать без перерыва
• Обновление и обслуживание возможны без потери управления
• Состояние кластера реплицируется между нодами (etcd quorum – для принятия решений достаточно большинства нод)
• Стоимость выше, но обеспечивается отказоустойчивость управляющего контура

Как выбрать: если вам важна возможность управлять кластером без перерывов (деплоить (от англ. deploy – развертывание), масштабировать, реагировать на инциденты) – выбирайте 3 master-ноды. Для dev/test-окружений, где кратковременная недоступность управления допустима, достаточно одной.

Версия Kubernetes

Выберите версию Kubernetes для кластера.

• По умолчанию предлагается последняя стабильная версия
• Версия определяет доступные API (интерфейс программирования приложения) и поведение компонентов
• Используйте последнюю стабильную версию, если нет специфических требований к совместимости

Обновление версии на более новую доступно после развертывания кластера. Подробнее – в статье “Управление кластером”.

Настройка сети кластера

Сетевые параметры определяют, как будут выделяться IP-адреса (идентификаторы устройства в компьютерной сети) для компонентов кластера. Эти настройки влияют на масштабируемость – сколько подов, нод и сервисов может быть в кластере.

Диапазон адресов сервисов

IP-адреса для внутренних сервисов Kubernetes (kube-dns, API-сервер и другие).

• Начальный адрес по умолчанию: 10.96.0.0
• Допустимые сети: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
• CIDR (бесклассовая междоменная маршрутизация): от /16 до /24

Все внутренние сервисы в кластере получают адрес из этого диапазона.

Диапазон адресов подов (Pod CIDR)

IP-адреса, которые получают поды.

• Начальный адрес по умолчанию: 10.244.0.0
• Допустимые сети: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
• CIDR: от /16 до /24

Каждый под в кластере получает уникальный IP-адрес из этого диапазона.

Маска подсети узлов

Определяет, сколько подов может размещаться на одном узле.

• Значение: от /22 до /28

Каждая worker-нода получает собственный поддиапазон адресов из Pod CIDR. Размер этого поддиапазона определяется маской подсети узлов.

Как параметры связаны между собой

Диапазон подов, маска подсети узлов и максимальное количество подов на узел – связанные параметры. Платформа автоматически рассчитывает:

• Максимальное количество подов на узел – исходя из маски подсети узлов
• Максимальное количество узлов в кластере – исходя из диапазона подов и маски подсети узлов

Пример с параметрами по умолчанию:

• Диапазон подов – 10.244.0.0/16
• Маска подсети узлов – /24
• Максимум подов на узел – 256
• Максимум узлов в кластере – 256

Как выбрать: для большинства задач значения по умолчанию подходят. Расширяйте диапазоны, если планируете крупный кластер (сотни нод) или большое количество подов на ноду. Учитывайте, что эти параметры нельзя изменить после создания. Подробнее об ограничениях при развертывании кластера Kubernetes – в статье “Лимиты, квоты и ограничения”.

Worker-группы

Worker-группа – это набор нод с одинаковой конфигурацией, на которых запускаются ваши приложения. В кластере может быть несколько worker-групп с разными параметрами.

Зачем нужны несколько worker-групп

Разные приложения могут предъявлять разные требования к ресурсам:

• Веб-серверы – много подов с небольшим потреблением CPU (центральный процессор) и RAM (оперативной памяти)
• ML-задачи – мало подов, но с большим объемом RAM или GPU (графический процессор)
• Фоновые задачи – ноды подешевле, без требований к производительности

Под каждый тип нагрузки можно создать отдельную worker-группу и выбрать для нее подходящую конфигурацию. Направить поды на нужную группу можно через метки и селекторы.

Параметры группы

Название группы – произвольное имя. Можно задать вручную или сгенерировать автоматически.

Количество нод – сколько серверов будет в группе. Минимум – 1. Максимум – 500.

Конфигурация ноды – ресурсы каждого сервера (CPU, RAM, диск). Доступны два варианта:

• Конфигуратор для обычных серверов – гибкий выбор параметров
• Готовые конфигурации для высокочастотных серверов

Все ноды в одной группе имеют одинаковую конфигурацию.

Метки (Labels)

Метки (labels) – это пары ключ-значение, которые назначаются нодам. Метки не ограничивают запуск подов, но позволяют:

• Выбирать ноды для размещения подов через селекторы (NodeSelector, affinity)
• Организовывать ноды по ролям, средам или другим критериям

Формат:

node-role.kubernetes.io/<key>=<value>

Пример: вы можете пометить группу меткой workload=gpu и указать в манифесте пода, что он должен запускаться только на нодах с этой меткой:

spec:
  nodeSelector:
    workload: gpu

Ограничения (Taints)

Taints – механизм, который запрещает запуск подов на определенных нодах, если у подов нет соответствующего Toleration (допуска).

Формат:

<key>=<value>:<effect>

Эффекты:

• NoSchedule – поды без Toleration не будут запланированы на эту ноду
• PreferNoSchedule – Kubernetes будет избегать размещения подов без Toleration, но при нехватке ресурсов может разместить
• NoExecute – поды без Toleration будут удалены с ноды, если они уже работают

Пример: вы можете назначить группе нод taint dedicated=critical:NoSchedule, чтобы на них запускались только критичные сервисы. Для этого в манифесте пода укажите соответствующий toleration:

spec:
  tolerations:
    key: dedicated
    value: critical
    effect: NoSchedule

Аутентификация

Для прямого подключения к нодам worker-группы по SSH (от англ. Secure Shell – защищенная оболочка) используются SSH-ключи. Можно выбрать один из существующих ключей или добавить новый.

Проект

Кластер можно привязать к проекту для удобной организации ресурсов. Также доступна опция закрепления кластера в главном меню.

Стоимость и создание

Перед установкой и созданием кластера Kubernetes на странице отображается итоговая стоимость – за день и за месяц. Стоимость складывается из ресурсов master-нод и worker-групп.

Нажмите “Создать Kubernetes-кластер” для запуска создания.

Все статьи раздела

1. Kubernetes (K8s) – обзор сервиса Managed Kubernetes (управляемым Kubernetes)
2. Основы Kubernetes – ключевые понятия: кластер, ноды, поды, сервисы
3. Создание и настройка кластера – вы здесь
4. Подключение к кластеру и работа с kubectl (консольный инструмент для управления Kubernetes) – kubeconfig (конфигурационный файл Kubernetes), подключение и первые команды
5. Управление кластером – управление Kubernetes-кластером: добавление нод, изменение конфигурации, обновление, удаление
6. Сеть и балансировщик нагрузки – сетевая модель, внешние и внутренние балансировщики
7. Лимиты, квоты и ограничения – ограничения платформы, что можно и нельзя изменить

Если возникнут вопросы, напишите нам, пожалуйста, обращение в панели управления аккаунта (раздел “Помощь и поддержка”), а если вы захотите обсудить эту статью или наши продукты с коллегами по цеху и сотрудниками Beget – ждем вас в нашем сообществе в Telegram.