Что такое CAPI?
Cluster API (CAPI) — открытый подпроект Kubernetes. Его цель — перенести привычный для Kubernetes декларативный подход (API и контроллеры) на задачи начальной загрузки, настройки, обновления и эксплуатации целых кластеров Kubernetes, рассматривая сами кластеры (и входящие в них машины) как полноправные ресурсы Kubernetes, а не как внешнюю инфраструктуру, требующую ручной подготовки.
CAPI разворачивается в кластере Kubernetes и использует привычный инструментарий (kubectl, CRD, манифесты) для управления кластерами в масштабе. Когда вы запрашиваете новый кластер — создавая кастомный ресурс Cluster — контроллер, специфичный для провайдера, выделяет необходимые ресурсы в целевой инфраструктуре. Если требования к кластеру меняются или подходит время обновления, достаточно изменить Kubernetes-манифесты и применить их заново: это запускает скользящие обновления или операции масштабирования, которыми управляют те же самые циклы согласования (reconciliation loops), что регулируют стандартные рабочие нагрузки Kubernetes.
Использование CAPI обеспечивает единообразие и повторяемость операций с кластерами. Операторы кластеров могут описывать эталонные образы, сетевые топологии и политики масштабирования в версионируемых манифестах. Подход, основанный на согласовании, автоматически исправляет расхождения между желаемым и фактическим состоянием, а стратегии обновления (например, обновление плоскости управления на месте с последующей скользящей перезагрузкой рабочих узлов) можно закодировать и использовать повторно. Это делает Cluster API особенно ценным для организаций, управляющих сотнями кластеров в разных командах, регионах или у различных провайдеров инфраструктуры — будь то публичные облака или собственные дата-центры.
Как работает CAPI?
CAPI строится на нескольких ключевых абстракциях и компонентах, которые совместно моделируют кластеры Kubernetes и управляют ими декларативно. На верхнем уровне выделяются следующие составляющие:
Управляющий и рабочие кластеры
Управляющий кластер (management cluster) — это обычная плоскость управления Kubernetes, в которой работают контроллеры CAPI. Он хранит все кастомные ресурсы (Custom Resources, CR) Cluster API и управляет жизненным циклом одного или нескольких рабочих кластеров (workload clusters) — тех самых кластеров Kubernetes, на которых вы будете запускать свои приложения.
Определения кастомных ресурсов (CRD)
CAPI вводит собственные CRD для представления кластеров и входящих в них машин:
-
Cluster: Объект верхнего уровня, описывающий кластер Kubernetes (сеть, версия Kubernetes и т.д.). -
Machine,MachineSetиMachineDeployment: Машины соответствуют отдельным виртуальным машинам или серверам без гипервизора. MachineSet поддерживает стабильное количество Machine, а MachineDeployment предоставляет семантику скользящего обновления поверх MachineSets (аналогично Deployment для Pod-ов). -
ControlPlane: Инкапсулирует настройки, специфичные для плоскости управления (управление сертификатами, высокая доступность, обновления версий), и управляет созданием и масштабированием машин плоскости управления (по умолчанию используется провайдерKubeadmControlPlane). -
MachineHealthCheck: Определяет критерии выявления неработоспособных узлов и инициирует автоматическую замену соответствующих Machine.
Компоненты провайдеров
Логика согласования разделена, абстрагирована и делегирована трём подключаемым (pluggable) типам провайдеров, каждый из которых реализован в виде отдельного менеджера контроллеров:
Провайдер инфраструктуры (Infrastructure provider): Взаимодействует с API целевого облака или платформы виртуализации (AWS, Azure, GCP, OpenStack, Proxmox, VMware и др.) для создания и удаления виртуальных машин, сетей, балансировщиков нагрузки и связанных ресурсов.
Неполный, но показательный список наиболее распространённых провайдеров доступен здесь:
Провайдер начальной загрузки (Bootstrap provider): Подготавливает только что выделенную виртуальную машину к роли узла Kubernetes: генерирует сертификаты, инициализирует плоскость управления на первой машине и выполняет kubeadm join на последующих машинах плоскости управления и рабочих узлах.
Провайдер плоскости управления (ControlPlane provider): Управляет жизненным циклом машин плоскости управления (реализует скользящие обновления API-серверов, например через KubeadmControlPlane).
Контроллеры и согласование
Для каждого CRD существует соответствующий контроллер, который следит за объявленным вами .spec, сравнивает его с реальным состоянием в облаке и в Kubernetes, а затем предпринимает действия для их сближения. Если вы увеличиваете количество реплик у MachineDeployment, контроллер MachineDeployment создаст новый MachineSet (или обновит существующий), который в свою очередь позволит провайдерам инфраструктуры и начальной загрузки выделить новые виртуальные машины и подключить их к кластеру. Если кто-то вручную удалит виртуальную машину, следующий цикл согласования обнаружит отсутствующий объект Machine и автоматически восстановит его. Финализаторы (finalizers) гарантируют, что при удалении ресурса Cluster машины и облачные ресурсы будут уничтожены в правильном порядке — прежде чем будет удалён сам объект Cluster.
Предварительные требования
Для работы в этой лабораторной среде вам понадобятся:
-
Установленный Proxmox (одноузловой или, что предпочтительнее, многоузловой кластер). Установка и настройка Proxmox выходят за рамки данной статьи.
-
Практический опыт работы с Proxmox и Kubernetes.
-
Рабочая станция с установленными homebrew, kubectl, clusterctl и kind.
-
Виртуальная машина с k3s для реализации управляющего кластера.
В данной лабораторной работе мы покажем, как создать собственный управляемый сервис Kubernetes с помощью CAPI, используя Proxmox в роли провайдера инфраструктуры, kubeadm — в роли провайдера начальной загрузки и kubeadm — в роли провайдера плоскости управления.
Подготовка пользователей и API-токенов Proxmox
Прежде чем приступить к сборке образов, инструменту image-builder нужны права для взаимодействия с Proxmox через его API. Эти права позволяют запустить виртуальную машину, выполнить процесс сборки, а затем превратить эту виртуальную машину в многократно используемый шаблон. Выполните следующие команды на одном из узлов Proxmox:
pveum user add image-builder@pve
pveum aclmod / -user image-builder@pve -role PVEAdmin
pveum user token add image-builder@pve capi -privsep 0
pveum user add capmox@pve
pveum aclmod / -user capmox@pve -role PVEAdmin
pveum user token add capmox@pve capi -privsep 0Сборка образов для Proxmox с помощью image-builder
С помощью image-builder мы стараемся стандартизировать и автоматизировать создание образов виртуальных машин, предварительно настроенных для Kubernetes и Cluster API, обеспечивая согласованность, безопасность и скорость при подготовке кластеров. Вместо того чтобы опираться на непроверенные или собранные вручную снимки операционной системы, image-builder использует декларативные «рецепты» (построенные на таких инструментах, как Packer и Ansible), чтобы включить в единый базовый образ все необходимые компоненты: настройки ядра, контейнерную среду выполнения, бинарные файлы kubeadm, сетевые плагины и любые пользовательские настройки безопасности. Эти образы затем служат неизменяемой основой для всех узлов плоскости управления и рабочих узлов, исключая изменчивость и расхождения между средами.
Создавая артефакты, специфичные для каждого провайдера, image-builder отделяет жизненный цикл создания образов от жизненного цикла создания кластеров. Результат — более быстрая начальная загрузка кластеров, воспроизводимые обновления, привязанные к версиям Kubernetes, и рабочий процесс, дружественный к GitOps: обновления образов распространяются по конвейерам так же, как и код приложений.
Выполним следующие шаги для установки, настройки и создания базового образа с помощью image-builder:
1️⃣ Клонируйте (или форкните и клонируйте) репозиторий на свою рабочую станцию:
git clone git@github.com:kubernetes-sigs/image-builder.git
cd image-builder/images/capi2️⃣ Установите зависимости:
Для автоматической установки зависимостей выполните следующую команду:
make depsЗависимости будут установлены в папку image-builder/images/capi/.bin (если они ещё не присутствуют в вашей системе). Затем добавьте эту папку в переменную окружения PATH, чтобы инструменты стали доступны:
export PATH=$PWD/.bin:$PATH3️⃣ Настройте для Proxmox
Создайте файл image-builder/images/capi/packer/proxmox/.env и укажите в нём необходимые переменные окружения, заменив заполнители своими значениями:
export PROXMOX_URL="https://<PROXMOX_NODE_IP>:8006/api2/json"
export PROXMOX_USERNAME=image-builder@pve!capi
export PROXMOX_TOKEN=<IMAGE_BUILD_API_TOKEN>
export PROXMOX_NODE="<PROXMOX_NODE_NAME>"
export PROXMOX_ISO_POOL="local"
export PROXMOX_STORAGE_POOL="<PROXMOX_STORAGE_POOL>"
export DISK_FORMAT="<DISK_FORMAT>"
export PROXMOX_BRIDGE="vmbr0"
export PROXMOX_NIC_MODEL="virtio"
# If you are working with OPNSense, image-builder is not
# assigning a Proxmox MAC address to the VM, and this seems
# to be an issue with DHCP in VXLANs controlled by OPNSense!
# In theory you can configure your MTU and VLAN tag with the
# following variables. For the time being leave them commented.
# export PROXMOX_MTU="1450"
# export PROXMOX_VLAN="23"
export PACKER_FLAGS="--var memory=2048 --var 'kubernetes_rpm_version=1.32.5' --var 'kubernetes_semver=v1.32.5' --var 'kubernetes_series=v1.32' --var 'kubernetes_deb_version=1.32.5-1.1'"Обязательно добавьте файл .env в .gitignore, чтобы не допустить утечки API-токенов при коммите изменений в репозиторий (если вы его форкнули).
Переменные окружения PROXMOX_ISO_POOL, PROXMOX_BRIDGE и PROXMOX_STORAGE_POOL здесь опциональны — они лишь демонстрируют, как переопределить значения по умолчанию, поскольку некоторые из них может понадобиться изменить в сценарии с многоузловым кластером Proxmox.
Если вы хотите собрать образ для конкретной версии Kubernetes (или передать специфичные переменные для параметризации базового образа), используйте переменную PACKER_FLAGS. Её можно опустить, но я не рекомендую это делать до тех пор, пока вы не разберётесь в том, как image-builder использует Packer под капотом.
4️⃣ Настройте PROXMOX_STORAGE_POOL и DISK_FORMAT
⚠️ Очень важно:
Если вы используете одноузловую установку Proxmox, задайте переменной PROXMOX_STORAGE_POOL значение local-lvm. Поскольку local-lvm не поддерживает формат диска qcow2, переменной DISK_FORMAT нужно присвоить значение raw.
Если же вы используете многоузловой кластер Proxmox, задайте переменной PROXMOX_STORAGE_POOL имя хранилища, доступного всем узлам совместно, — иначе вы не сможете запускать узлы плоскости управления и рабочие узлы на других узлах, кроме того, куда был загружен базовый образ. Кроме того, необходимо настроить это хранилище на поддержку формата qcow2 и установить переменной DISK_FORMAT значение qcow2.
📓 Небольшое отступление:
В моём случае сервер TrueNAS работает как виртуальная машина на одном из узлов Proxmox и предоставляет NFS-шару, которую я добавляю как хранилище в Proxmox (да, это забавный круговорот, и производительность оставляет желать лучшего — так что при наличии бюджета рекомендую выделить отдельный физический NAS).
Тем не менее установка отдельного TrueNAS оправдывает себя: она позволяет вынести все потребности в хранилище всех кластеров Kubernetes на TrueNAS, используя democratic-csi в качестве CSI-драйвера (хотя это далеко выходит за рамки данной статьи — возможно, я напишу об этом отдельно).
5️⃣ Скорректируйте шаблон Packer
Внесём несколько изменений в файл, который Packer использует для создания базового образа, — в нём отсутствуют некоторые детали, очень полезные при работе с Proxmox.
Часть из них попросту отсутствует, другие регулируют аппаратные характеристики, которые мы зададим для шаблона базового образа. Откройте файл image-builder/images/capi/packer/proxmox/packer.json.tmpl:
Добавьте в network_adapters новое свойство model, как показано в фрагменте ниже:
"network_adapters": [
{
"model": "{{user `nic_model`}}",
"bridge": "{{user `bridge`}}",
"mtu": "{{ user `mtu` }}",
"vlan_tag": "{{user `vlan_tag`}}"
}
],В раздел variables добавьте:
"nic_model": "{{env `PROXMOX_NIC_MODEL`}}",Внесите следующие изменения (удалите строки с префиксом -, добавьте строки с префиксом +):
- "disk_format": "qcow2",
+ "disk_format": "{{env `DISK_FORMAT`}}",
- "sockets": "2",
+ "sockets": "1",6️⃣ Соберите образ
Выполните следующие команды:
source packer/proxmox/.env
make build-proxmox-ubuntu-2204Это создаст базовый образ для узлов плоскости управления и рабочих узлов на основе Ubuntu 22.04. Процесс занимает довольно много времени (~25–35 минут в зависимости от характеристик вашей рабочей станции, скорости внутренней и внешней сети), поэтому запаситесь терпением. Тем временем можно открыть консоль Proxmox и наблюдать, как создаётся новая виртуальная машина: она получает сетевую конфигурацию, устанавливает обновления пакетов и в итоге — посредством Ansible — получает все необходимые бинарные файлы для работы в роли узла Kubernetes. После завершения всех настроек виртуальная машина автоматически преобразуется в шаблон.
Установка необходимых инструментов
Чтобы руководство одинаково подходило и для macOS, и для Linux, для установки бинарных файлов, необходимых для управления кластером, мы будем использовать Homebrew.
1️⃣ Установите Homebrew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"Следуйте инструкциям установщика, чтобы завершить установку.
2️⃣ Установите KiND
brew install kind3️⃣ Установите kubectl
brew install kubectl4️⃣ Установите clusterctl
brew install clusterctlИнтерфейс командной строки clusterctl упрощает первоначальную настройку CAPI, автоматически загружая и устанавливая необходимые манифесты провайдеров. В нём зашиты рекомендуемые практики управления провайдерами, что помогает избежать ошибок конфигурации и упрощает такие задачи, как обновления.
Построенный поверх clusterctl, оператор Cluster API — это Kubernetes-оператор, который привносит полностью декларативный рабочий процесс управления жизненным циклом провайдеров внутри управляющего кластера. Он улучшает развёртывание и повседневную эксплуатацию Cluster API, делая рутинные задачи и автоматизацию на основе GitOps простыми и удобными.
Создание конфигурации для Proxmox
Перед созданием рабочего кластера необходимо выполнить определённые настройки на управляющем кластере. Для этого задаются переменные окружения для Cluster API Provider for Proxmox VE (CAPMOX), после чего генерируется манифест кластера.
Создайте файл с именем capmox.env и заполните его следующим содержимым:
## -- Controller settings -- ##
export PROXMOX_URL="https://<PROXMOX_NODE_IP>:8006"
export PROXMOX_TOKEN='capmox@pve!capi'
export PROXMOX_SECRET="<CAPMOX_API_TOKEN_SECRET>"
## -- Required workload cluster default settings -- ##
export PROXMOX_SOURCENODE="<PROXMOX_SOURCENODE_NAME>"
export TEMPLATE_VMID="<PROXMOX_BASE_IMAGE_TEMPLATE_ID>"
export ALLOWED_NODES="[<PROXMOX_NODE1_NAME>,<PROXMOX_NODE2_NAME>...]"
export VM_SSH_KEYS="ssh-rsa AAAAB..."
## -- networking configuration-- ##
export CONTROL_PLANE_ENDPOINT_IP="192.168.1.230"
export NODE_IP_RANGES="[192.168.1.220-192.168.1.229]"
export GATEWAY="192.168.1.1"
export IP_PREFIX="24"
export DNS_SERVERS="[192.168.1.1]"
export BRIDGE="vmbr0"
export NETWORK_MODEL="virtio"
## -- xl nodes -- ##
export BOOT_VOLUME_DEVICE="scsi0"
export BOOT_VOLUME_SIZE="20"
export NUM_SOCKETS="1"
export NUM_CORES="2"
export MEMORY_MIB="2048"
export FILE_STORAGE_FORMAT="raw"
export STORAGE_NODE="local-lvm"
export NODE_REPLICAS=1
export CLOUD_INIT_CONFIG="#cloud-config package_update=true packages=- net-tools"
## -- Controller settings -- ##Замените все значения 192.168.1.0/24 на CIDR, соответствующий вашему интерфейсу моста vmbr0 (или любому другому мосту, который вы используете). Замените все значения в заполнителях на соответствующие значения вашей лабораторной среды.
Настройка управляющего кластера
Это кластер, в котором работают один или несколько провайдеров инфраструктуры и хранятся ресурсы (например, Machines) при подготовке нескольких рабочих кластеров.
1️⃣ Создайте кластер
Создайте файл конфигурации kind с именем kind-management-cluster.yaml, с дополнительными монтированиями, позволяющими провайдеру Docker получить доступ к Docker на хосте:
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
ipFamily: dual
nodes:
- role: control-plane
extraMounts:
- hostPath: /var/run/docker.sock
containerPath: /var/run/docker.sockи выполните следующую команду:
kind create cluster --name=mgmt-capmox --config=kind-management-cluster.yamlKubeconfig только что созданного кластера автоматически добавляется в ваш KUBECONFIG, и kubectl начинает использовать его контекст.
Если вы планируете попробовать Kamaji в роли провайдера плоскости управления, установите управляющий кластер с помощью K3s на новой виртуальной машине (используя тот же мост vmbr0, что и в предыдущем шаге, или другой мост, имеющий связность с vmbr0), выполнив следующую команду:
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable=traefik --disable=servicelb" sh -Kubeconfig нового кластера находится по пути /etc/rancher/k3s/k3s.yaml. Скопируйте его на рабочую станцию (предпочтительно в ~/.kube/k3s.yaml) и выполните:
export KUBECONFIG=~/.kube/k3s.yamlНе забудьте изменить значение параметра server с https://127.0.0.1:6443 на IP-адрес, назначенный сетевому интерфейсу моста vmbr0.
2️⃣ Превратите кластер в управляющий
Установив clusterctl и выполнив все предварительные условия, запустите clusterctl init, чтобы преобразовать ваш кластер Kubernetes в управляющий.
source capmox.env
clusterctl init --infrastructure proxmox --ipam in-clusterПриведённая команда установит Cluster API Provider for Proxmox VE (CAPMOX) в качестве провайдера инфраструктуры, а Kubeadm — в качестве провайдера плоскости управления и провайдера начальной загрузки.
Создание кластера с провайдером плоскости управления Kubeadm
Провайдер плоскости управления kubeadm следит за ресурсами KubeadmControlPlane в управляющем кластере и управляет жизненным циклом узлов плоскости управления. Когда вы создаёте или обновляете KubeadmControlPlane, провайдер формирует соответствующий набор объектов Machine (используя ваш MachineTemplate) и организует выполнение kubeadm init на первом узле, а затем kubeadm join для дополнительных реплик.
Провайдер управляет генерацией и ротацией сертификатов, выполняет скользящие обновления, заменяя по одному узлу плоскости управления за раз, и обеспечивает доступность API-серверов Kubernetes на протяжении всего процесса. Вся конфигурация (версия Kubernetes, настройки компонентов, топология высокой доступности) описывается декларативно в спецификации KubeadmControlPlane, а цикл согласования провайдера приводит фактическое состояние в соответствие с желаемым.
При совместном использовании провайдера плоскости управления kubeadm с провайдером инфраструктуры Proxmox (CAPMOX) контроллер плоскости управления создаёт объекты Machine, базовые виртуальные машины которых выделяются в Proxmox в соответствии с вашим MachineTemplate. По мере готовности каждой виртуальной машины провайдер kubeadm выполняет kubeadm init на первом узле и kubeadm join на последующих репликах, тогда как Proxmox управляет жизненным циклом виртуальных машин, их загрузкой, сетью и хранилищем. Эта интеграция позволяет декларативно управлять высокодоступными плоскостями управления в кластере Proxmox, используя привычные рабочие процессы CAPI.
Узлы плоскости управления и рабочие узлы работают как виртуальные машины в Proxmox.
1️⃣ Сгенерируйте манифесты
Команда clusterctl generate cluster возвращает YAML-манифест для создания рабочего кластера.
source capmox.env
clusterctl generate cluster capi-quickstart \
--kubernetes-version v1.33.0 \
--control-plane-machine-count=1 \
--worker-machine-count=1 > capi-quickstart.yamlЭто создаст манифест capi-quickstart.yaml с заранее определённым набором ресурсов CAPI: Cluster, Machines, MachineDeployments и т.д. В сгенерированном файле есть ряд недочётов при использовании Proxmox в качестве целевой инфраструктуры, поэтому необходимо внести несколько ручных правок.
2️⃣ Измените блок CIDR объекта Cluster ⚠️
Необходимо изменить значение cidrBlock на такое, которое не пересекается с CIDR-блоком вашего моста vmbr0 (в вашем случае он может отличаться), иначе Pod-ы начнут захватывать IP-адреса из этого сетевого сегмента. Замените значение — я выбрал CIDR 10.44.0.0/16, который точно не используется нигде в моей физической или виртуальной сети.
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: capi-quickstart
namespace: default
spec:
clusterNetwork:
pods:
cidrBlocks:
- 10.44.0.0/16
controlPlaneRef:
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
name: capi-quickstart-control-plane
infrastructureRef:
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha1
kind: ProxmoxCluster
name: capi-quickstart3️⃣ Разрешите CAPMOX переподписку памяти ⚠️
Когда контроллер инфраструктуры выделяет новую виртуальную машину в Proxmox — будь то узел плоскости управления или рабочий узел — он сначала суммирует уже выделенную оперативную память на целевом хосте, чтобы проверить, поместится ли туда ваш MachineTemplate. Если переподписка памяти не включена явно, эта проверка не позволит разместить ни одной новой виртуальной машины, как только сумма выделенной памяти достигнет номинальной ёмкости узла, — и новые виртуальные машины будут зависать, хотя Proxmox на практике вполне мог бы безопасно переподписать память.
Для решения этой проблемы добавьте следующие свойства в ресурс ProxmoxCluster:
schedulerHints:
memoryAdjustment: 0В итоге ресурс должен выглядеть так:
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha1
kind: ProxmoxCluster
metadata:
name: capi-quickstart
namespace: default
spec:
allowedNodes:
- pve-am06
controlPlaneEndpoint:
host: 192.168.1.230
port: 6443
dnsServers:
- 192.168.1.1
ipv4Config:
addresses:
- 192.168.1.220-192.168.1.229
gateway: 192.168.1.1
prefix: 24
schedulerHints:
memoryAdjustment: 04️⃣ Создайте кластер
Выполните команду:
kubectl apply -f capi-quickstart.yamlЗатем наблюдайте, как Proxmox клонирует шаблон и начинает подготавливать узлы плоскости управления и рабочие узлы — этот процесс займёт несколько минут.
Когда всё будет готово, получите файл kubeconfig нового кластера, выполнив:
clusterctl get kubeconfig capi-quickstart > capi-quickstart.kubeconfig5️⃣ Разверните CNI
В демонстрационных целях мы развернём Calico в качестве CNI-решения для нашего нового кластера. В своей лабораторной среде вы можете выбрать любой предпочтительный CNI. Выполните следующую команду:
kubectl --kubeconfig=./capi-quickstart.kubeconfig \
apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yamlПри возникновении проблем можно обратиться к любому узлу напрямую, открыв SSH-сессию под пользователем root. Это позволит изучить системные журналы, просмотреть файлы конфигурации и выполнить диагностические команды на каждой машине.
Дальнейшие шаги
В следующей статье мы рассмотрим, как с помощью Kamaji контейнеризировать плоскость управления клиентских кластеров внутри управляющего кластера, оставив только рабочие узлы в виде виртуальных машин в Proxmox.
Kamaji — это оператор с открытым исходным кодом, разработанный компанией Clastix, который реализует концепцию плоскости управления Kubernetes как размещённого сервиса, работающего целиком на самом Kubernetes. Вместо того чтобы выделять отдельные виртуальные машины или серверы для etcd, kube-apiserver, менеджера контроллеров и планировщика, Kamaji разворачивает эти компоненты в виде Pod-ов внутри управляющего кластера и предоставляет к ним доступ клиентским кластерам через лёгкий API. Этот паттерн «размещённой плоскости управления» (Hosted Control Plane) отделяет жизненный цикл плоскости управления от базовой инфраструктуры и существенно снижает как операционные издержки, так и дублирование ресурсов.
Если эта статья оказалась вам полезной, поставьте 👏 и подпишитесь, чтобы не пропустить новые материалы по Kubernetes и облачным нативным технологиям. Впереди ещё много интересного!