7.6.1. Создание кластера K8s

	https://youtu.be/gzR8lmIDr-0

ВВЕДЕНИЕ

Managed Kubernetes в DevSpace — это полноценный кластер Kubernetes, который разворачивается в вашем пространстве за несколько минут и обслуживается платформой. В отличие от установки на собственных VM или bare-metal-серверах, вам не нужно готовить операционную систему, устанавливать компоненты кластера, настраивать сеть между узлами и следить за управляющим слоем — всё это берёт на себя DevSpace.

Управляющие компоненты кластера (API-сервер, планировщик и другие) работают внутри платформы и не занимают ваши рабочие узлы. Рабочие узлы — это виртуальные машины, которые создаются и удаляются автоматически в заданных вами пределах. Вы получаете адрес кластера, файл доступа (kubeconfig) и работаете с кластером так же, как с любым другим Kubernetes: через kubectl, GitOps-инструменты или графические клиенты.

ПЕРЕД НАЧАЛОМ

У вас уже должно быть создано пространство в сервисе DevSpace и настроен доступ к его к его приложениям (сервисам). Все действия ниже выполняются внутри вашего пространства.

Также понадобится компьютер с доступом в интернет, на который вы установите утилиту kubectl для управления кластером.

ПОШАГОВОЕ РУКОВОДСТВО

ШАГ 1. ОТКРОЙТЕ КАТАЛОГ ПРИЛОЖЕНИЙ И ВЫБЕРИТЕ KUBERNETES

В дашборде перейдите в раздел управления приложениями. Открыть форму создания кластера можно двумя способами:

через Marketplace: выберите карточку Infrastructure, затем Kubernetes;
через меню в левом верхнем углу консоли: выберите Kubernetes и нажмите Deploy.

Оба пути ведут к одной и той же форме создания кластера.

ШАГ 2. ЗАДАЙТЕ ИМЯ КЛАСТЕРА

Имя станет частью идентификатора кластера и его DNS-адреса. По умолчанию API кластера получает адрес вида kubernetes-<имя>.<домен-вашего-пространства> — например, кластер demo в пространстве kzf7us4o5d будет доступен по адресу kubernetes-demo.kzf7us4o5d.devspace.cloupard.io. Выбирайте короткое имя из строчных латинских букв и цифр.

По этому адресу API кластера будет доступен из интернета сразу после создания — он публикуется через входной шлюз платформы, а доступ защищён сертификатами из файла kubeconfig: без файла доступа подключиться к кластеру нельзя.

ШАГ 3. ВЫБЕРИТЕ КЛАСС ХРАНЕНИЯ ДЛЯ ДАННЫХ ПРИЛОЖЕНИЙ

Параметр storageClass определяет, в каком классе хранилища платформы будут создаваться постоянные тома (PVC) — диски, которые ваши приложения запрашивают для хранения данных. Такие тома выделяются из хранилища платформы, подключаются к узлам по мере необходимости и переживают пересоздание и подов, и самих узлов.

Доступны два класса:

replicated (по умолчанию) — данные каждого тома дублируются хранилищем на нескольких серверах. Надёжный выбор для любых данных: отказ одного сервера хранения не приводит к их потере.
local — том без репликации на уровне хранилища: быстрее и экономичнее. Подходит для приложений, которые сами хранят данные в нескольких репликах — кластерных баз данных, брокеров сообщений и т.п.: их данные уже продублированы на уровне приложения, и дублировать их ещё раз средствами хранилища избыточно.

Объём, занятый постоянными томами, тарифицируется в DevSpace по ресурсу «Хранилище».

	Важно: класс хранения кластера нельзя изменить после создания. Если сомневаетесь — оставьте replicated.

ШАГ 4. НАСТРОЙТЕ ГРУППУ РАБОЧИХ УЗЛОВ

Рабочие узлы объединены в группу (по умолчанию она называется md0). В форме для группы задаются четыре ключевых параметра.

Минимальное и максимальное количество реплик (minReplicas / maxReplicas, по умолчанию от 0 до 10) — границы автоматического масштабирования. Это не просто «сколько узлов создать»: кластер сам добавляет узлы, когда приложениям не хватает ресурсов, и убирает лишние, когда нагрузка спадает, — но никогда не выйдет за заданные вами пределы. Нужен стабильный кластер ровно из 5 узлов — задайте минимум 5 и максимум 5; хотите начать с 2 узлов с возможностью дорасти до 10 — задайте минимум 2 и максимум 10.

Тип инстанса (instanceType, по умолчанию u1.medium) — размер виртуальной машины каждого узла: количество CPU и объём памяти. Все узлы группы одинаковы; если нужны узлы разных размеров, добавьте ещё одну группу. Справочник по доступным instanceType

Размер диска узла (diskSize, по умолчанию 20Gi) — временный (ephemeral) диск самой виртуальной машины: на нём хранятся образы контейнеров, логи и временные данные подов. Диск живёт вместе с узлом — при пересоздании узла (масштабирование, обновление) его содержимое теряется, поэтому данные приложений на нём не хранят: для них предназначены постоянные тома из шага 3. Увеличивайте размер, если приложения используют много крупных образов контейнеров.

Роли (roles) — метки назначения узлов группы. Роль ingress-nginx (проставлена по умолчанию) позволяет узлам группы принимать входящий веб-трафик — она нужна для работы аддона Ingress-NGINX из шага 6. Не убирайте её, если планируете публиковать веб-приложения.

ШАГ 5. ВЫБЕРИТЕ ВЕРСИЮ KUBERNETES

Доступны версии с v1.30 по v1.35; по умолчанию предлагается самая свежая — v1.35. Указывается только основная версия (major.minor), платформа сама разворачивает актуальный патч-релиз: например, v1.35 сейчас означает Kubernetes 1.35.1, а v1.32 — 1.32.12.

Важный момент при выборе:

Если вы переносите нагрузки с существующего кластера — выберите ту же версию, что и у него. Между соседними версиями Kubernetes меняются и удаляются API, и при разнице версий часть ваших манифестов придётся переписывать. Совпадающая версия делает переезд предсказуемым.
Если начинаете с нуля — берите версию по умолчанию.

ШАГ 6. ВКЛЮЧИТЕ НУЖНЫЕ АДДОНЫ

Аддоны — это готовые компоненты, которые платформа устанавливает в кластер вместе с его созданием, избавляя вас от ручной установки и настройки. Всё выключенное на этом шаге можно включить позже, изменив конфигурацию кластера.

Приложения, запущенные в кластере, по умолчанию не доступны из интернета. Способ публикации выбирается под вашу задачу:

Публикуете сайты, веб-приложения, HTTP-API — включите аддон Ingress-NGINX: все веб-приложения кластера публикуются через один вход, с маршрутизацией по доменам и автоматическими TLS-сертификатами (в связке с cert-manager). Это рекомендуемый путь для веб-трафика. Если ваши приложения построены на Gateway API — вместо него включите одноимённый аддон.
Публикуете не-веб-сервис — базу данных, брокер сообщений, игровой сервер, что угодно с произвольным TCP/UDP-протоколом — аддоны не нужны: создайте для своего приложения сервис типа LoadBalancer внутри кластера. Приложение получит собственный внешний IP-адрес, и трафик пойдёт напрямую в него, без посредников. Каждый такой IP тарифицируется в DevSpace отдельно.

cert-manager + Ingress-NGINX — рекомендуемая связка для публикации веб-приложений. Ingress-NGINX принимает входящий HTTP/HTTPS-трафик и маршрутизирует его к вашим приложениям, а cert-manager автоматически выпускает и продлевает TLS-сертификаты (в том числе бесплатные от Let’s Encrypt). Компоненты интегрированы между собой из коробки: включив оба, вы получаете рабочую схему «домен → сертификат → приложение» без ручной настройки. Для Ingress-NGINX доступны два способа публикации:

Proxied(по умолчанию) — трафик приходит через общий входной шлюз платформы, отдельный внешний IP не выделяется. Перечислите в поле hosts полные доменные имена ваших приложений — имена записываются как есть, без автоматического дополнения домена. Пока список пуст, внешний трафик к приложениям в кластер не маршрутизируется; дополнить список можно и позже, изменив конфигурацию кластера. Настройка зависит от того, чей домен вы используете:

поддомен вашего пространства (например, app.<домен-пространства>) — уже указывает на шлюз платформы и работает сразу, никаких DNS-настроек не требуется;

собственный домен — создайте у своего DNS-провайдера CNAME-запись, указывающую на домен пространства; для корневого домена, где CNAME недопустим, — A-запись на IP-адрес шлюза (узнать его можно, разрешив домен пространства, например командой dig <домен-пространства>).
LoadBalancer— контроллер Ingress-NGINX получит выделенный балансировщик с собственным внешним IP-адресом: на него вы направляете DNS-записи своих доменов, и трафик идёт в кластер напрямую, минуя общий шлюз. Список hosts при этом не используется. Это по-прежнему один вход для всех веб-приложений кластера — не путайте с сервисом LoadBalancer для отдельного приложения. Выделенный внешний IP тарифицируется в DevSpace отдельно.

Обратите внимание: при способе Proxied список hosts лишь открывает домену дорогу от шлюза платформы до вашего кластера. Куда направить запрос дальше, внутри кластера, решают обычные Ingress-ресурсы, которые вы создаёте рядом со своими приложениями, — без них запрос дойдёт до кластера и получит ответ 404 от контроллера. То есть каждый домен настраивается в двух местах: в hosts кластера и в Ingress-ресурсе приложения. Минимальный пример такого Ingress-ресурса:

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

spec:

ingressClassName: nginx

rules:

- host: app.<домен-пространства> # то же имя, что указано в hosts кластера

http:

paths:

- path: /

pathType: Prefix

backend:

service:

port:

number: 80

Flux CD — GitOps-доставка манифестов. Позволяет хранить конфигурацию ваших приложений в Git-репозитории (GitHub, GitLab или собственном приватном) — Flux сам скачивает манифесты и применяет их в кластере, поддерживая его состояние в соответствии с репозиторием. Включайте, если планируете GitOps-подход. Если предпочитаете Argo CD или другой инструмент — не включайте Flux, чтобы они не конфликтовали за управление ресурсами.

Velero — резервное копирование объектов кластера. Крайне полезный инструмент: сохраняет объекты Kubernetes в S3-совместимое хранилище и позволяет восстановиться после сбоя или ошибочного удаления. Гибко настраивается фильтрами — можно бэкапить как весь кластер, так и отдельные пространства имён или типы объектов.

Остальные аддоны (Gateway API, агенты мониторинга и другие) описаны в разделе «Параметры» ниже. Для первого кластера их можно оставить выключенными.

ШАГ 7. ПРОВЕРЬТЕ ОСТАЛЬНЫЕ ПОЛЯ И СОЗДАЙТЕ КЛАСТЕР

Остальные параметры формы можно оставить по умолчанию — их полное описание есть в разделе «Параметры» ниже. Нажмите Deploy — кластер начнёт создаваться.

ШАГ 8. ДОЖДИТЕСЬ ГОТОВНОСТИ

Создание кластера занимает несколько минут. За процессом можно наблюдать на странице кластера в дашборде: вкладка Workloads показывает поды служебных компонентов кластера и их состояние, вкладка Events — события, происходящие прямо сейчас. Дождитесь, когда статус кластера сменится на Ready, а поды на вкладке Workloads перейдут в состояние Running.

После этого на вкладке Secrets страницы кластера появится секрет kubernetes-<имя>-admin-kubeconfig с файлами доступа. В нём четыре ключа:

admin.conf— тот, что вам нужен: файл kubeconfig с внешним адресом кластера для подключения с вашего компьютера;
admin.svc— тот же доступ, но с внутренним адресом кластера — для подключения из сервисов внутри платформы;

super-admin.conf/ super-admin.svc — аварийный доступ с максимальными правами в обход обычной модели прав; для повседневной работы не используется.
Подсказка: не выделяйте и не копируйте содержимое секрета мышкой из окна просмотра — так легко захватить лишние символы или потерять переносы строк. Используйте кнопку копирования рядом с нужным ключом: она копирует содержимое в точности.
 
ШАГ 9. УСТАНОВИТЕ KUBECTL И ПОДКЛЮЧИТЕСЬ К КЛАСТЕРУ
 
kubectl — стандартная консольная утилита для управления Kubernetes. Установите её по официальной инструкции для вашей операционной системы. Желательно ставить версию, соответствующую версии вашего кластера (например, kubectl 1.35 для кластера v1.35) — допустимо отклонение в один минорный релиз.
 
Затем сохраните kubeconfig:
mkdir -p ~/.kube
 
# если у вас уже есть файл ~/.kube/config от другого кластера — сначала сохраните его копию:
cp ~/.kube/config ~/.kube/config.backup
 
# откройте файл в редакторе и вставьте содержимое ключа admin.conf, скопированное кнопкой копирования:
nano ~/.kube/config
 
После вставки убедитесь, что форматирование не сломалось: файл должен выглядеть как аккуратный YAML с отступами, без «слипшихся» строк. Проверьте подключение:
kubectl get nodes
 
ШАГ 10. ДОЖДИТЕСЬ ГОТОВНОСТИ УЗЛОВ
 
Готовый кластер — это ещё не готовые к работе узлы и поды в нём. Сразу после создания рабочие узлы могут ещё регистрироваться в кластере, а системные компоненты — запускаться. Порядок такой: сначала стартует сеть кластера (в DevSpace по умолчанию используется Cilium), после неё узлы переходят в состояние Ready, затем поднимаются остальные системные компоненты и включённые аддоны (cert-manager, Ingress-NGINX и другие).
 
Подождите несколько минут и проверьте:
kubectl get nodes
kubectl get pods -A
 
Когда все узлы в состоянии Ready, а системные поды — Running, кластер готов к работе. Единичные перезапуски системных подов на этапе старта — это нормально: компоненты ждут друг друга.
 
ШАГ 11 (ПО ЖЕЛАНИЮ). УСТАНОВИТЕ FREELENS — ГРАФИЧЕСКИЙ ОБОЗРЕВАТЕЛЬ КЛАСТЕРА
 
Freelens — бесплатное десктопное приложение с открытым исходным кодом, своеобразный «проводник» по Kubernetes. Оно особенно полезно на первых порах: позволяет изучать кластер визуально, не заучивая команды kubectl.
 
Где взять: скачайте установщик для Windows, macOS или Linux с freelens.app или со страницы релизов на GitHub.
 
Как подключить кластер: Freelens работает с теми же kubeconfig-файлами, что и kubectl. Можно добавить файл конфигурации вручную через меню добавления кластера, а можно настроить автоматическое подхватывание конфигов из нужной директории (например, ~/.kube) — тогда кластер появится в списке сам.
 
Что в нём удобно смотреть:

Nodes — состояние и ресурсы узлов кластера;
Workloads → Pods — запущенные поды; отсюда же можно посмотреть логи пода или удалить его для перезапуска;
Namespaces — пространства имён; здесь же создаются новые;
Config → Secrets / ConfigMaps — секреты и конфигурации с фильтрацией по пространствам имён;
Storage → Storage Classes — доступные классы хранения; пригодятся при написании манифестов с постоянными томами;
Network — сервисы, endpoints и ingress-ресурсы.

Функциональность расширяется плагинами: например, плагин для Flux CD показывает состояние GitOps-объектов прямо в интерфейсе.

ПАРАМЕТРЫ

Полный список параметров кластера. Всё, что не задано явно, платформа заполняет значениями по умолчанию из этой таблицы.

Основные

Параметр	Что делает	Значение по умолчанию	Когда менять
version	Версия Kubernetes (major.minor): v1.30 – v1.35. Платформа разворачивает последний патч-релиз выбранной версии.	v1.35	При переносе нагрузок с существующего кластера — выбрать его версию.
host	Внешнее DNS-имя кластера, по которому доступен его API.	пусто = kubernetes-<имя>. <домен-пространства>	Если хотите использовать собственный домен.
storageClass	Класс хранения для постоянных томов (PVC) приложений в кластере: replicated — данные тома дублируются хранилищем на нескольких серверах; local — без репликации на уровне хранилища, быстрее. Объём томов тарифицируется по ресурсу «Хранилище». Нельзя изменить после создания.	replicated	local — для приложений, которые сами реплицируют свои данные (кластерные БД, брокеры сообщений).

Управляющий слой (control plane)

Компоненты управляющего слоя работают на стороне платформы. Ресурсы каждого компонента задаются либо именованным пресетом (resourcesPreset), либо явными значениями CPU/памяти (resources) — явные значения имеют приоритет. Справочник по пресетам ресурсов

Параметр	Что делает	Значение по умолчанию	Когда менять
controlPlane.replicas	Число реплик управляющего слоя.	2	1 — для экономии на тестовых кластерах; 2+ — отказоустойчивость для production.
controlPlane.apiServer.resourcesPreset	Пресет ресурсов API-сервера	c1.medium	При росте кластера и числа обращений к API.
controlPlane.apiServer.resources	Явные CPU/память API-сервера (переопределяют пресет).	не заданы	Когда пресетов недостаточно и нужны точные значения.
controlPlane.controllerManager.resourcesPreset	Пресет ресурсов controller manager.	t1.micro	Редко; при большом числе объектов в кластере.
controlPlane.controllerManager.resources	Явные CPU/память controller manager.	не заданы	Аналогично.
controlPlane.scheduler.resourcesPreset	Пресет ресурсов планировщика.	t1.micro	Редко.
controlPlane.scheduler.resources	Явные CPU/память планировщика.	не заданы	Редко.
controlPlane.konnectivity.server.resourcesPreset	Пресет ресурсов konnectivity-сервера (туннель между управляющим слоем и узлами).	t1.micro	Редко.
controlPlane.konnectivity.server.resources	Явные CPU/память konnectivity-сервера.	не заданы	Редко.

Группы рабочих узлов (nodeGroups)

Узлы объединяются в именованные группы; по умолчанию создаётся одна группа md0. Групп может быть несколько — например, отдельная группа более крупных узлов под ресурсоёмкие сервисы. Все параметры ниже задаются для каждой группы.

Параметр	Что делает	Значение по умолчанию	Когда менять
minReplicas	Минимальное число узлов в группе — нижняя граница автомасштабирования.	0	Задайте не меньше числа узлов, которое должно работать всегда.
maxReplicas	Максимальное число узлов — верхняя граница автомасштабирования.	10	По потолку бюджета и ожидаемой нагрузке.
instanceType	Тип виртуальной машины узла (CPU и память), например u1.medium. Справочник по типам.	u1.medium	Под требования ваших приложений.
diskSize	Размер временного (ephemeral) диска узла: образы контейнеров, логи, временные данные подов, данные kubelet и containerd. Содержимое теряется при пересоздании узла. Постоянные тома приложений сюда не входят — они выделяются из хранилища платформы (см. storageClass кластера).	20Gi	Если приложения используют много крупных образов или активно пишут во временные тома.
storageClass	Класс хранения для дисков узлов этой группы.	пусто = класс по умолчанию	Если для узлов нужен отдельный класс хранения.
roles	Список ролей узлов группы. Роль ingress-nginx требуется хотя бы у одной группы, чтобы работал одноимённый аддон.	["ingress-nginx"]	Не убирайте роль ingress-nginx, если планируете этот аддон.
resources	Явные CPU/память узла (вместо instanceType).	не заданы	Когда типовые размеры не подходят.
gpus	Список GPU, подключаемых к узлам группы, — для вычислительных и ML-нагрузок.	[]	Пока не используется: узлов с GPU в DevSpace нет.
kubelet.evictionHardMemory	Жёсткий порог памяти, при котором узел начинает вытеснять поды (абсолютное значение или процент).	7%	Тонкая настройка стабильности узлов.
kubelet.evictionSoftMemory	Мягкий порог вытеснения по памяти.	10%	Аналогично.
kubelet.systemReservedMemory / kubelet.systemReservedCpu	Память/CPU, зарезервированные для ОС узла.	пусто = вычисляются из instanceType	Обычно не требуется.
kubelet.kubeReservedMemory / kubelet.kubeReservedCpu	Память/CPU, зарезервированные для kubelet и контейнерного рантайма.	пусто = вычисляются из instanceType	Обычно не требуется.

Аддоны (addons)

У каждого аддона есть поле valuesOverride — расширенная настройка компонента для опытных пользователей; по умолчанию оно пустое, и компонент работает с настройками платформы.

Параметр	Что делает	Значение по умолчанию	Когда менять
certManager.enabled	Автоматический выпуск и продление TLS-сертификатов (включая Let’s Encrypt).	false	Включите вместе с Ingress-NGINX для публикации приложений по HTTPS.
ingressNginx.enabled	Контроллер входящего HTTP/HTTPS-трафика. Требует роли ingress-nginx на узлах (есть по умолчанию).	false	Включите для публикации веб-приложений.
ingressNginx.exposeMethod	Способ публикации контроллера: Proxied — через входной шлюз платформы (без выделенного IP, только домены из hosts), LoadBalancer — через выделенный балансировщик с собственным внешним IP (список hosts не используется, DNS-записи приложений направляются на этот IP; внешний IP тарифицируется отдельно).	Proxied	LoadBalancer — когда нужен отдельный внешний IP и трафик в обход общего шлюза.
ingressNginx.hosts	Полные доменные имена, трафик которых входной шлюз платформы направляет в этот кластер (при exposeMethod: Proxied). Записываются как есть, без автоматического дополнения. Поддомены домена пространства работают без настройки DNS; для собственных доменов настройте CNAME на домен пространства. Wildcard-имена (*.apps.example.com) допустимы, но HTTPS для них терминируется на шлюзе платформы с его сертификатом — для полноценного TLS с собственными сертификатами перечисляйте имена явно. Список открывает домену путь только до кластера; маршрут до приложения задаёт Ingress-ресурс внутри кластера.	[]	Обязательно заполните при публикации приложений через Proxied; можно дополнять после создания кластера.
fluxcd.enabled	GitOps-оператор Flux CD: применяет манифесты из Git-репозитория.	false	Включите для GitOps-подхода; не включайте при использовании Argo CD.
velero.enabled	Резервное копирование и восстановление объектов кластера в S3.	false	Рекомендуется для любых важных сред.
gatewayAPI.enabled	Поддержка Gateway API — современной альтернативы Ingress для маршрутизации трафика.	false	Если ваши приложения используют Gateway API.
gpuOperator.enabled	NVIDIA GPU Operator: драйверы и обвязка для работы с GPU на узлах.	false	Пока не используется: узлов с GPU в DevSpace нет.
hami.enabled	HAMi — виртуализация GPU (разделение одной карты между подами). Требует включённого GPU Operator.	false	Пока не используется: узлов с GPU в DevSpace нет.
monitoringAgents.enabled	Агенты мониторинга (сбор метрик и логов) с отправкой в систему мониторинга пространства.	false	Рекомендуется для production.
ouroboros.enabled	Исправление hairpin-NAT для Ingress-NGINX с PROXY-протоколом. Требует включённого ingressNginx; полезен только при настроенном PROXY-протоколе.	false	Узкий случай; включайте по рекомендации поддержки.
cilium.valuesOverride	Тонкая настройка сети кластера (Cilium — сеть по умолчанию, отключить её нельзя).	{}	Только для опытных пользователей.
coredns.valuesOverride	Тонкая настройка DNS кластера (CoreDNS устанавливается всегда).	{}	Только для опытных пользователей.
verticalPodAutoscaler.valuesOverride	Тонкая настройка Vertical Pod Autoscaler.	{}	Только для опытных пользователей.

Служебные

Параметр	Что делает	Значение по умолчанию	Когда менять
images.waitForKubeconfig	Переопределение служебного образа ожидания kubeconfig — для изолированных сред и реестров с лимитами.	пусто	Практически никогда; по указанию поддержки.

Пример конфигурации

Итоговая конфигурация, соответствующая шагам из руководства: кластер из пяти узлов с фиксированным размером, связка cert-manager + Ingress-NGINX, Flux CD и Velero.

apiVersion: apps.cozystack.io/v1alpha1

kind: Kubernetes

metadata:

spec:

version: v1.35 # свежая версия; при переезде — версия исходного кластера

host: "" # пусто = адрес по умолчанию

storageClass: replicated # класс хранения PVC приложений; неизменяемый после создания!

controlPlane:

replicas: 2 # 2 реплики управляющего слоя — отказоустойчивость

apiServer:

resources: {}

resourcesPreset: c1.medium

controllerManager:

resources: {}

resourcesPreset: t1.micro

scheduler:

resources: {}

resourcesPreset: t1.micro

konnectivity:

server:

resources: {}

resourcesPreset: t1.micro

nodeGroups:

md0:

minReplicas: 5 # ровно пять узлов:

maxReplicas: 5 # min = max отключает автомасштабирование

instanceType: u1.medium

diskSize: 20Gi # временный диск узла: образы, логи, временные данные

storageClass: ""

roles:

- ingress-nginx # роль нужна для аддона Ingress-NGINX

resources: {}

gpus: []

kubelet: {}

addons:

certManager:

enabled: true # автоматические TLS-сертификаты

valuesOverride: {}

ingressNginx:

enabled: true # приём входящего HTTP/HTTPS-трафика

exposeMethod: Proxied

hosts: []

valuesOverride: {}

fluxcd:

enabled: true # GitOps-доставка манифестов

valuesOverride: {}

velero:

enabled: true # резервное копирование объектов кластера

valuesOverride: {}

cilium:

valuesOverride: {}

coredns:

valuesOverride: {}

gatewayAPI:

enabled: false

gpuOperator:

enabled: false

valuesOverride: {}

hami:

enabled: false

valuesOverride: {}

monitoringAgents:

enabled: false

valuesOverride: {}

ouroboros:

enabled: false

valuesOverride: {}

verticalPodAutoscaler:

valuesOverride: {}

ПРОВЕРКА

1. В дашборде: статус кластера — Ready, поды на вкладке Workloads — в состоянии Running, на вкладке Secrets доступен kubeconfig. На вкладке Ingresses должна появиться запись kubernetes-<имя>, адрес которой совпадает с адресом кластера в kubeconfig — это публикация API вашего кластера через входной шлюз платформы; она создаётся вместе с управляющим слоем, и её наличие подтверждает, что он развёрнут и опубликован. Ingress-ресурсы ваших приложений появятся на этой вкладке позже, когда вы начнёте их публиковать.

2. Узлы зарегистрированы и готовы:

kubectl get nodes

Ожидаемый результат — все узлы в состоянии Ready (первые минуты после создания они могут быть NotReady, пока поднимается сеть). Имена узлов складываются из имени кластера, имени группы и случайных суффиксов, а колонка ROLES показывает роли группы:

NAME STATUS ROLES AGE VERSION

kubernetes-demo-md0-stxhx-4k6hh Ready ingress-nginx 5m v1.35.1

kubernetes-demo-md0-stxhx-7zq2m Ready ingress-nginx 5m v1.35.1

...

3.Системные компоненты запущены:

kubectl get pods -A

Все поды в состоянии Running или Completed. Если включали аддоны — в списке будут поды cert-manager, ingress-nginx, flux и velero.

ЧАСТЫЕ ОШИБКИ

Аддон Ingress-NGINX включён, всё в состоянии Running, но приложения снаружи недоступны — при этом нигде нет ни одной ошибки. Причина: способ публикации Proxied с пустым списком hosts. Входному шлюзу платформы некуда маршрутизировать трафик — маршрут для ваших доменов просто не создаётся, и это не считается ошибкой. Что делать: добавьте полные доменные имена приложений в ingressNginx.hosts и сохраните конфигурацию кластера.

Приложения перестали открываться, шлюз отвечает ошибкой 503. Причина: ни в одной группе узлов не осталось роли ingress-nginx — контроллеру входящего трафика негде работать, и запросы упираются в пустоту. Что делать: верните роль ingress-nginx хотя бы одной группе узлов.

Сразу после создания кластера узлы в состоянии NotReady. Причина: сеть кластера ещё запускается, а узлы становятся готовыми только после её старта — это нормальный порядок запуска, а не сбой. Что делать: подождите несколько минут. Если состояние не меняется 10–15 минут — посмотрите вкладку Events на странице кластера.

kubectl не подключается: ошибки соединения или сертификатов. Причина: повреждён kubeconfig — скопирован не тот ключ секрета или при вставке сломалось форматирование YAML. Что делать: скопируйте содержимое ключа admin.conf кнопкой копирования и вставьте заново, проверив отступы.

Не удаётся изменить storageClass кластера. Причина: этот параметр неизменяем после создания кластера. Что делать: создайте новый кластер с нужным классом хранения и перенесите нагрузки.

Кластер в статусе Ready, но поды приложений висят в Pending. Причина: автомасштабирование упёрлось в maxReplicas, либо запросы ресурсов приложений не помещаются на узлы выбранного размера. Что делать: увеличьте maxReplicas группы узлов или выберите более крупный instanceType.

После переключения exposeMethod с Proxied на LoadBalancer приложения перестали открываться по прежним адресам. Причина: при LoadBalancer маршрут через общий шлюз платформы удаляется, а DNS-имена приложений всё ещё указывают на шлюз — тот отвечает 404. Что делать: направьте DNS-записи приложений на внешний IP выделенного балансировщика (виден на вкладке Services страницы кластера).

ЧТО ДАЛЬШЕ

Публикация приложений — настройка Ingress-ресурсов, доменов и сертификатов Let’s Encrypt для доступа к вашим приложениям из интернета.

Справочник по instanceType и resourcesPreset — какие типы инстансов и пресеты ресурсов доступны и как выбрать подходящий.