тренажёр собеседований
← Маршрут обучения
модуль 10 / 12 · Провайдер KaaS · 18 часов

Cluster API и OpenStack: от шаблона к кластеру

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

Ещё не начат
практика · через терминал портала

Где выполнять задания

Через портал подключаемся к отдельной машине и отдельному проекту OpenStack. Подготовка обязательна. Эти команды не рассчитаны на существующий общий кластер.

Открыть практикум и терминал ↗

Читай урок в этой вкладке, команды выполняй в соседней. Подстановки в угловых скобках сначала замени своими значениями. Ctrl+C останавливает наблюдение или учебный сервер.

Сокращения этого модуля: расшифровки и смысл
API
Application Programming Interface — программный интерфейс
BOM
Bill of Materials — перечень компонентов и версий
CAPI
Cluster API — интерфейсы и контроллеры управления жизненным циклом кластеров Kubernetes
CAPO
Cluster API Provider OpenStack — провайдер Cluster API для OpenStack
CCM
Cloud Controller Manager — облачный управляющий компонент
CNI
Container Network Interface — интерфейс подключения контейнеров к сети
CSI
Container Storage Interface — интерфейс подключения хранилищ контейнеров
KaaS
Kubernetes as a Service — Kubernetes как услуга
VM
Virtual Machine — виртуальная машина
YAML
YAML Ain’t Markup Language — язык описания данных

В командах сохраняется точное написание параметров и имён. В тексте сокращения раскрываются в скобках.

Результат модуля

  • Разделить доступы management и workload кластеров.
  • Проверить облачный проект, образ, сеть, квоты и совместимость.
  • На выделенном проекте создать, проверить, изменить и удалить клиентский кластер.

Перед началом: Контроллеры: как автоматизация доводит дело до конца.

1. Какой кластер кем управляет

CAPI (Cluster API (Application Programming Interface — программный интерфейс) — программные интерфейсы и контроллеры управления жизненным циклом кластеров Kubernetes) описывает кластеры, машины и их группы как ресурсы. CAPO (Cluster API Provider OpenStack — провайдер Cluster API для OpenStack) переводит это намерение в облачные ресурсы.

Management cluster — управляющий кластер: в нём работают контроллеры и хранится описание создаваемых кластеров. Workload cluster — клиентский кластер: в нём запускаются пользовательские приложения. Не путай их kubeconfig и не выдавай клиенту управляющий доступ.

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

Management cluster
Управляющий кластер с описаниями и контроллерами клиентских кластеров.
Workload cluster
Клиентский кластер, где работают приложения пользователя.
ProviderID
Связь ноды Kubernetes с конкретной облачной машиной.
Application credential
Ограниченные полномочия автоматизации в OpenStack.

По шагам

  1. В управляющем кластере записано намерение создать lesson-one.
  2. Провайдер создаёт облачные ресурсы и получает их состояние.
  3. В клиентском кластере проверяем ноды, приложение, сеть и том — каждый результат отдельно.

2. Что проверить в облаке заранее

Сначала проверь аутентификацию, проект и квоты. Затем — образ с подходящими kubeadm, kubelet и runtime, размер машины, сеть, подсеть, маршрутизацию и внешний доступ. Обычный облачный образ без подготовки не обязательно подходит для Cluster API (Application Programming Interface — программный интерфейс).

Application credential — отдельные ограниченные полномочия OpenStack для автоматизации. Храни их в закрытом clouds.yaml на отдельной машине и затем по инструкции передавай нужному контроллеру. Не используй личный административный пароль как конфигурацию продукта и не выводи файл в журнал.

Наличие Nova и Neutron не доказывает готовность Cinder и Octavia. В нашей домашней лабе последние две функции требуют отдельной проверки. Ошибка облачной квоты или отсутствующего балансировщика должна появиться как конкретная причина ожидания, а не маскироваться перезапуском контроллера.

3. Когда кластер действительно полезен

CCM (Cloud Controller Manager — облачный управляющий компонент) связывает ноды и сервисы Kubernetes с облаком. ProviderID связывает ноду с конкретной машиной. CSI (Container Storage Interface — интерфейс подключения хранилищ контейнеров) и драйвер Cinder позволяют выдавать тома, если соответствующая облачная служба работает.

Готовый программный интерфейс Kubernetes — ещё не вся услуга. Нужны рабочая сеть Pod, разрешение имён, публикация приложения и проверенный том. CNI (Container Network Interface — интерфейс подключения контейнеров к сети) и его плагин устанавливаются совместимым способом.

Составь BOM (Bill of Materials — перечень компонентов и версий): Kubernetes, CAPI (Cluster API — интерфейсы и контроллеры управления жизненным циклом кластеров Kubernetes), CAPO (Cluster API Provider OpenStack — провайдер Cluster API для OpenStack), образ, сеть, CCM (Cloud Controller Manager — облачный управляющий компонент) и CSI (Container Storage Interface — интерфейс подключения хранилищ контейнеров). Укажи точные версии и ссылки на совместимость. В новых версиях CAPO меняется также набор зависимостей, поэтому команды clusterctl init берутся из руководства выбранного выпуска.

4. Создание — только начало

После создания проверь Conditions и фактические ресурсы OpenStack. Для масштабирования изменяется поддерживаемый ресурс группы машин, а не вручную добавляется случайная виртуальная машина. Обновление проверяют на отдельном малом кластере.

Удаление может остановиться на внешнем диске, порте или балансировщике. Сравни инвентарь до создания, после создания и после удаления. Сохранённый по политике диск должен иметь владельца и понятную стоимость.

Для KaaS (Kubernetes as a Service — Kubernetes как услуга) автоматизация обязана переживать временную недоступность облака и рестарт контроллера. Нельзя считать услугу готовой по одному удачному create: повтор, изменение и удаление входят в тот же контракт.

практика · 18 часов вместе с теорией и тестом

Практика через терминал портала

  1. Проверь доступные инструменты

    Портальный терминал — точка входа. Облачный клиент и clusterctl устанавливаются на отдельной машине из инструкции. Ничего не устанавливай автоматически на существующий control plane.

    command -v kubectl
command -v openstack || true
command -v clusterctl || true

    Что должно получиться. Есть честный список доступного и отсутствующего. Отсутствующий инструмент — подготовка, а не ошибка Kubernetes.

    Если результат отличается

    Не подменяй реальное выполнение выдуманным выводом. Сохрани статус «не запускалось», если стенд не готов.

  2. Заполни карту проекта

    На отдельной машине настрой clouds.yaml с правами 600. Переменная OS_CLOUD выбирает уже настроенный профиль. Команды ниже не печатают токен.

    export OS_CLOUD=kaas-lab
openstack project show -f value -c id <PROJECT_ID>
openstack quota show <PROJECT_ID>
openstack image list
openstack flavor list
openstack network list

    Что должно получиться. Выбран именно учебный проект, известны квоты и подходящие образы. Значение PROJECT_ID нужно заменить.

    Если результат отличается

    Если профиль не работает, сначала исправь доступ. Не расширяй его до администратора всего облака.

  3. Проверь нужные службы

    В учебном проекте проверь типы служб и доступ к томам и балансировщикам. Права списка каталога и наличие endpoint ещё не доказывают успешное создание.

    openstack catalog list
openstack volume type list
openstack loadbalancer list

    Что должно получиться. Есть отдельные результаты проверки Cinder и Octavia. Отсутствующая команда loadbalancer может означать отсутствие клиентского расширения, а не сервиса.

    Если результат отличается

    До проверки реального создания и удаления не помечай LoadBalancer и CSI (Container Storage Interface — интерфейс подключения хранилищ контейнеров) как готовые.

  4. Зафиксируй совместимый выпуск

    Открой официальную таблицу CAPO (Cluster API Provider OpenStack — провайдер Cluster API для OpenStack), выбери поддерживаемую пару с CAPI (Cluster API — интерфейсы и контроллеры управления жизненным циклом кластеров Kubernetes) и версию Kubernetes. По руководству этого выпуска установи clusterctl и обязательные зависимости в отдельный management cluster.

    kubectl --context kind-kaas-lab get nodes
clusterctl version

    Что должно получиться. В журнале есть точные версии, контрольные суммы скачанных инструментов и официальный порядок установки.

    Если результат отличается

    Не используй бесконтрольное latest и не копируй устаревшую пару версий из примера.

  5. Сгенерируй и проверь намерение

    На отдельной машине после настройки переменных по руководству CAPO (Cluster API Provider OpenStack — провайдер Cluster API для OpenStack) сгенерируй файл. Он может содержать чувствительную конфигурацию: umask обязателен, в заметки файл целиком не вставляется.

    umask 077
clusterctl generate cluster lesson-one --infrastructure openstack --kubernetes-version <VERSION> --control-plane-machine-count=1 --worker-machine-count=1 > lesson-one.yaml
kubectl --context kind-kaas-lab apply --dry-run=server -f lesson-one.yaml

    Что должно получиться. Конфигурация проходит серверную проверку выбранного management cluster. VERSION заменена на проверенную версию.

    Если результат отличается

    Шаблон требует облачных параметров из официального руководства; ошибка генерации означает незавершённую подготовку, а не повод удалить поля.

  6. Создай и наблюдай

    Только в согласованном учебном проекте примени проверенный файл. Следи за причинами Conditions и облачными машинами. Реальные ресурсы расходуют квоту.

    kubectl --context kind-kaas-lab apply -f lesson-one.yaml
clusterctl describe cluster lesson-one
openstack server list

    Что должно получиться. Есть наблюдаемый прогресс и однозначная связь каждого ресурса с учебным кластером.

    Если результат отличается

    Если зависло, читай конкретные Conditions и события контроллера. Не создавай второй кластер под новым именем для обхода ошибки.

  7. Проверь клиентский результат

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

    umask 077
clusterctl --kubeconfig <MANAGEMENT_KUBECONFIG> get kubeconfig lesson-one > lesson-one.kubeconfig
kubectl --kubeconfig lesson-one.kubeconfig get nodes -o wide
kubectl --kubeconfig lesson-one.kubeconfig get storageclass
kubectl --kubeconfig lesson-one.kubeconfig get services -A

    Что должно получиться. Ноды Ready; отдельно подтверждены сеть, providerID, том и внешний запрос. Это разные доказательства.

    Если результат отличается

    Не выдавай Ready ноды за проверенный Cinder. Если функция облака недоступна, зафиксируй ограничение.

  8. Пройди масштабирование и очистку

    На отдельном кластере измени replicas выбранного MachineDeployment по руководству, проверь новые ноды и возврат размера. Обновление сначала прогони на canary. Удаляй через управляющий ресурс, затем сравни облачный инвентарь.

    kubectl --context kind-kaas-lab get machinedeployments
kubectl --context kind-kaas-lab delete cluster lesson-one
openstack server list
openstack port list
openstack volume list
openstack floating ip list
openstack loadbalancer list

    Что должно получиться. Отмечены только реально выполненные операции. Все остатки объяснены: ошибка либо осознанное сохранение с владельцем.

    Если результат отличается

    Не удаляй весь облачный проект и чужие ресурсы. Если очистка зависла, исследуй finalizer и внешнюю зависимость.

Открыть терминал ↗ · Скачать файлы лаборатории →

Файлы и подготовка к этой работе

Критерии готовности

Отмечай только то, что проверил на указанном стенде. Эти галочки сохраняются в браузере. Для готовых упражнений зачёт выдаёт отдельная серверная проверка практикума; остальные задания подтверждай журналом и доказательствами. Учебная модель не заменяет реальный облачный опыт.

Что сохранить в портфолио

  • Журнал: исходное состояние → команда или действие → ожидаемый результат → фактическое наблюдение.
  • Доказательства по критериям ниже: очищенный от секретов вывод, схема или ссылка на проверенный коммит.
  • Отдельный список: что пока не запускалось, почему и какой стенд нужен для продолжения.
закрепление

Проверь понимание

8 вопросов по этому модулю. Проходной результат — 7 из 8. После ответа — объяснения и ссылки на разделы, к которым стоит вернуться.

Пройти тест модуля

Официальные источники

Чек-листы уроков, заметки к ним и результаты тестов хранятся в этом браузере; для переноса используй экспорт. Автоматические проверки и журнал практикума сохраняются отдельно на сервере.