Привет, Хабр! Я Данил Трещев, работаю в T-Банке в команде Spirit Compute, которая отвечает за runtime-инфраструктуру. Сегодня я хочу рассказать, как работать с Cluster API Provider Yandex (CAPY). Мы разработали собственное решение, которое позволяет разворачивать k8s-кластеры в инфраструктуре Yandex Cloud.
Разберем, как развернуть Management Cluster и Workload Cluster с помощью инструментов управления кластерами. Материал подходит для обучения и тестирования. Итоговое окружение не будет готово к продакшену — для этого понадобятся дополнительные настройки безопасности и отказоустойчивости.
Добро пожаловать под кат все, кому интересно познакомиться с темой!
Основные понятия
Чтобы быть в одном контексте, введем основные понятия.
Management Cluster (управляющий кластер) — это кластер Kubernetes, который управляет жизненным циклом других кластеров Kubernetes: отвечает за их создание, обновление, масштабирование и удаление.
В Management Cluster развернуты:
Cluster API (CAPI) — инструмент для автоматизированного управления кластерами Kubernetes в облаке и on-premise. В данной статье не будет рассказано о принципах работы CAPI, более подробно вы можете прочитать это в документации.
Cluster-api-provider-yandex (CAPY) — провайдер для развертывания кластера Kubernetes в облачной инфраструктуре Yandex Cloud.
Workload Cluster (рабочий кластер) — это кластер Kubernetes, в котором развернуты приложения (нагрузка, workloads). За весь жизненный цикл workload cluster отвечают CAPI-/CAPY-контроллеры.
Зачем мы разработали свое решение
Мы используем подход к развертыванию кластеров с помощью CAPI. И мы не нашли open-source-решения для Yandex Cloud, которое позволяло бы управлять кластерами как в on-premise инфраструктуре. Мы стремимся избежать vendor lock, поэтому изначально хотели опубликовать решение в open-source, чтобы сформировать альтернативу существующим решениям.
Мы рассматриваем CAPI как стратегическое направление и намерены развивать его, поскольку нам нужен infrastructure provider как часть собственной платформы, а не интеграция с чужой экосистемой.
Иногда мы временно идем на компромисс и используем решения вроде deckhouse, чтобы сэкономить время, когда результат нужен «еще вчера». Но вектор развития остается прежним — максимальная независимость и контроль над архитектурой.
Подготовка к работе
Нам понадобятся инструменты:
Go версии 1.22.0 и выше;
Kubectl версии 1.11.3 и выше;
Clusterctl версии 1.5.0 и выше;
YC актуальной версии.
Команды, которые будут выполнены с локальной машины:
$ COMMAND
Настройка YC:
$ curl -sSL https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bash $ yc init yc init Welcome! This command will take you through the configuration process. Please go to https://oauth.yandex.ru/authorize?response_type= in order to obtain OAuth token. Please enter OAuth token: TOKEN You have one cloud available: 'cloud-daniltreshchev' (id = b1gbhh2a1pmra4btp1um). It is going to be used by default. Please choose folder to use: [1] default (id = b1gn632om9rumce9tabc) [2] Create a new folder Please enter your numeric choice: 1 Your current folder has been set to 'default' (id = b1gn632om9rumce9tabc). Do you want to configure a default Compute zone? [Y/n] Y Which zone do you want to use as a profile default? [1] ru-central1-a [2] ru-central1-b [3] ru-central1-d [4] Don't set default zone Please enter your numeric choice: 4
Готовим инфраструктуру.
1. Настраиваем сервисный аккаунт Yandex Cloud. Создаем сервисный аккаунт, от имени которого будут создаваться ресурсы кластеры.
$ yc iam service-account create --name capy-service-account --description "service account for CAPY"
Назначаем сервисному аккаунту роли compute.editor и alb.editor на каталог.
$ yc iam service-account list +----------------------+----------------------+--------+---------------------+-----------------------+ | ID | NAME | LABELS | CREATED AT | LAST AUTHENTICATED AT | +----------------------+----------------------+--------+---------------------+-----------------------+ | aje6gad4ev79dfms8i6h | capy-service-account | | 2025-02-18 20:27:17 | | +----------------------+----------------------+--------+---------------------+-----------------------+ $ yc resource-manager folder add-access-binding default \ --role compute.editor \ --subject serviceAccount:aje6gad4ev79dfms8i6h $ yc resource-manager folder add-access-binding default \ --role alb.editor \ --subject serviceAccount:aje6gad4ev79dfms8i6h
Получаем авторизованный ключ для сервисного аккаунта в формате JSON.
$ yc iam key create --service-account-name capy-service-account -o capy-sa-key.json
2. Если в нашем каталоге еще нет облачной сети Virtual Private Cloud, создаем ее и подсеть. В статье используем сеть default, которая создается автоматически при создании облака.
3. Инфраструктуре создаваемого кластера в Virtual Private Cloud назначается группа безопасности по умолчанию. Добавим в эту группу правила для входящего трафика:
Протокол | Диапазон портов | Тип источника | Источник | Описание |
TCP | 0-65535 | Группа безопасности | Balancer | Проверки состояния L7-балансировщиком |
Any | 8443 | CIDR | 0.0.0.0/0 | Доступ к Kubernetes API |
$ yc vpc security-group list +----------------------+---------------------------------+--------------------------------+----------------------+ | ID | NAME | DESCRIPTION | NETWORK-ID | +----------------------+---------------------------------+--------------------------------+----------------------+ | enpjob28k16saao6ooum | default-sg-enpe888420gefk9d6r47 | Default security group for | enpe888420gefk9d6r47 | | | | network | | +----------------------+---------------------------------+--------------------------------+----------------------+ $ yc vpc security-group update-rules --id enpjob28k16saao6ooum --add-rule description="Доступ к Kubernetes API",direction=ingress,port=8443,protocol=any,v4-cidrs=0.0.0.0/0 \ --add-rule description="Проверки состояния L7-балансировщиком",direction=ingress,from-port=0,to-port=65535,protocol=tcp,predefined=loadbalancer_healthchecks id: enppv4bf655np8p7gjm4 folder_id: b1gsflehga67etlh2ibf created_at: "2025-02-23T02:01:09Z" name: default-sg-enps0m3n749aelfdh5sc description: Default security group for network network_id: enps0m3n749aelfdh5sc status: ACTIVE rules: - id: enpsv7m2tsd5alnhcl77 direction: INGRESS protocol_name: ANY protocol_number: "-1" cidr_blocks: v4_cidr_blocks: - 0.0.0.0/0 - id: enpc3fob9g4i4dcu6op1 direction: EGRESS protocol_name: ANY protocol_number: "-1" cidr_blocks: v4_cidr_blocks: - 0.0.0.0/0 - id: enp54dgl0k880j8gkdf6 description: Доступ к Kubernetes API direction: INGRESS ports: from_port: "8443" to_port: "8443" protocol_name: ANY protocol_number: "-1" cidr_blocks: v4_cidr_blocks: - 0.0.0.0/0 - id: enpnqmfppbfn6u7oqbsg description: Проверки состояния L7-балансировщиком direction: INGRESS ports: to_port: "65535" protocol_name: TCP protocol_number: "6" predefined_target: loadbalancer_healthchecks default_for_network: true
4. Создаваемый workload-кластер будет доступен в облачной сети по внутреннему IP-адресу. Чтобы обеспечить удаленный доступ в кластер, создадим вспомогательный jumphost в той же сети, в которой будет развернут кластер, и с той же группой безопасности. Установим на jumphost kubectl.
$ yc compute instance create \ --name jumphost \ --zone ru-central1-b \ --network-interface subnet-name=default-ru-central1-b,nat-ip-version=ipv4 \ --create-boot-disk image-folder-id=standard-images,image-family=ubuntu-2004-lts \ --ssh-key ~/.ssh/id_rsa.pub $ yc compute instance list +----------------------+----------------+---------------+---------+--------------+------------- | ID | NAME | ZONE ID | STATUS | EXTERNAL IP | INTERNAL IP +----------------------+----------------+---------------+---------+--------------+------------- | epd2et0u39bn48g30qtf | jumphost | ru-central1-b | RUNNING | 84.252.139.3 | 10.129.0.21 +----------------------+----------------+---------------+---------+--------------+------------- $ ssh yc-user@84.252.139.3
Примечание:
SSH User всегда будет yc-user, вне зависимости от username в облаке.
Команды, которые будут выполнены с вспомогательного jumphost`а, будут выглядеть так:
$ (jumohost) COMMAND
5. Создадим управляющий кластер и группу узлов. Из этого кластера будет разворачиваться новый кластер с помощью Cluster API и управление кластерной инфраструктурой.
Пример создания управляющего кластера:
$ yc iam service-account create k8s-cluster-management-sa done (1s) id: ajegobpbgfiq42c3cl6m folder_id: b1gn632om9rumce9tabc created_at: "2025-02-18T21:11:37.936353688Z" name: k8s-cluster-management-sa $ yc resource-manager folder add-access-binding default \ --role editor \ --subject serviceAccount:ajegobpbgfiq42c3cl6m $ yc resource-manager folder add-access-binding default \ --role container-registry.images.puller \ --subject serviceAccount:ajegobpbgfiq42c3cl6m $ yc resource-manager folder add-access-binding default \ --role vpc.publicAdmin \ --subject serviceAccount:ajegobpbgfiq42c3cl6m $ yc managed-kubernetes cluster create \ --name capy-management-cluster \ --network-name default \ --zone ru-central1-b \ --subnet-name default-ru-central1-b \ --public-ip \ --release-channel regular \ --version 1.31 \ --service-account-name k8s-cluster-management-sa \ --node-service-account-name k8s-cluster-management-sa $ yc managed-kubernetes node-group create \ --cluster-name capy-management-cluster \ --fixed-size 1
6. Настраиваем для kubectl доступ к управляющему кластеру Kubernetes.
$ yc managed-kubernetes cluster list +----------------------+-------------------------+---------------------+---------+---------+------------------------+---------------------+ | ID | NAME | CREATED AT | HEALTH | STATUS | EXTERNAL ENDPOINT | INTERNAL ENDPOINT | +----------------------+-------------------------+---------------------+---------+---------+------------------------+---------------------+ | catrpi1s5kq9pib1ltii | capy-management-cluster | 2025-02-14 03:01:24 | HEALTHY | RUNNING | https://158.160.167.10 | https://10.130.0.32 | +----------------------+-------------------------+---------------------+---------+---------+------------------------+---------------------+ $ yc managed-kubernetes cluster get-credentials --id catrpi1s5kq9pib1ltii --external Context 'yc-capy-management-cluster' was added as default to kubeconfig '/Users/username/.kube/config'. Check connection to cluster using 'kubectl cluster-info --kubeconfig /Users/username/.kube/config'. Note, that authentication depends on 'yc' and its config profile 'default'. To access clusters using the Kubernetes API, please use Kubernetes Service Account. $ kubectl cluster-info Kubernetes control plane is running at https://51.250.107.4 CoreDNS is running at https://51.250.107.4/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. $ kubectl get nodes NAME STATUS ROLES AGE VERSION cl13s99dfd2q0u1jkrg0-yrap Ready <none> 16m v1.31.2
Установка CAPI-/CAPY-контроллеров в управляющий кластер
Установка CAPI- и CAPY-контроллеров в управляющий кластер необходима для того, чтобы он мог управлять жизненным циклом Kubernetes-кластеров в Yandex Cloud.
Установим CAPI- и CAPY-контроллеры и проверим их работу. Клонируем репозиторий cluster-api-provider-yandex и переходим в директорию с проектом:
$ git clone https://github.com/yandex-cloud/cluster-api-provider-yandex.git $ cd cluster-api-provider-yandex
Устанавливаем основные CAPI-компоненты:
$ clusterctl init Fetching providers Installing cert-manager version="v1.16.2" Waiting for cert-manager to be available... Installing provider="cluster-api" version="v1.9.5" targetNamespace="capi-system" Installing provider="bootstrap-kubeadm" version="v1.9.5" targetNamespace="capi-kubeadm-bootstrap-system" Installing provider="control-plane-kubeadm" version="v1.9.5" targetNamespace="capi-kubeadm-control-plane-system" Your management cluster has been initialized successfully!
Создадим в управляющем кластере CustomResourceDefinitions для создаваемого кластера: это необходимо, чтобы Kubernetes понимал, как работать с новыми типами ресурсов, которые приносят CAPY/CAPI:
$ make install
Создадим пространство имен для провайдера Yandex Cloud, это нужно для размещения контроллеров CAPY:
$ kubectl create namespace capy-system
Создадим секрет с авторизованным ключом сервисного аккаунта Yandex Cloud, чтобы контроллеры CAPY могли аутентифицироваться в Yandex Cloud и управлять ресурсами:
$ kubectl create secret generic yc-sa-key \ --from-file=key=<путь_к_файлу_с_авторизованным_ключом> \ --namespace capy-system
Установим CAPY:
$ make deploy
Проверим установленные компоненты:
$ kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE capi-kubeadm-bootstrap-system capi-kubeadm-bootstrap-controller-manager-67dc888b6d-9tqv5 1/1 Running 0 15s capi-kubeadm-control-plane-system capi-kubeadm-control-plane-controller-manager-c497bb7df-zqfwl 1/1 Running 0 13s capi-system capi-controller-manager-66986b964b-ng7cm 1/1 Running 0 18s cert-manager cert-manager-74b56b6655-tttgm 1/1 Running 0 42s cert-manager cert-manager-cainjector-55d94dc4cc-c5szh 1/1 Running 0 43s cert-manager cert-manager-webhook-564f647c66-r5qbf 1/1 Running 0 42s kube-system coredns-6c58946d99-hbjwf 1/1 Running 0 5m14s kube-system ip-masq-agent-5b6tf 1/1 Running 0 3m2s kube-system kube-dns-autoscaler-8574ff8cd7-8dmfk 1/1 Running 0 5m10s kube-system kube-proxy-8m7ct 1/1 Running 0 3m2s kube-system metrics-server-7f749774cd-wpm7n 2/2 Running 0 2m53s kube-system npd-v0.8.0-pzhcq 1/1 Running 0 3m2s kube-system yc-disk-csi-node-v2-r5gwm 6/6 Running 0 3m2s
Создание workload-кластера
Когда управляющий кластер настроен и все необходимые контроллеры установлены, мы можем приступить к созданию workload-кластера, то есть кластера, в котором будут запускаться реальные приложения. Это основной сценарий использования Cluster API: мы описываем желаемую конфигурацию нового кластера, а управляющий кластер автоматически создает всю нужную инфраструктуру в Yandex Cloud и разворачивает Kubernetes.
Выберем зону доступности, в которой хотим развернуть кластер. У нас выбрана зона доступности ru-central1-b, но можно выбрать любую.
Создадим NAT для доступа из workload-кластера в интернет:
$ yc vpc gateway create \ --name gateway id: enpkq1s3bfif04ur9fea folder_id: b1gsflehga67etlh2ibf created_at: "2025-02-23T02:44:51Z" name: gateway shared_egress_gateway: {} $ yc vpc route-table create \ --name=test-route-table \ --network-name=default \ --route destination=0.0.0.0/0,gateway-id=enpkq1r8j59f8liic1c7
Получим идентификаторы ресурсов Yandex Cloud для развертывания кластера.
Для упрощения демонстрации CAPY используем образ fd8a3kknu25826s8hbq3. Он создан исключительно в ознакомительных целях, применять его в промышленной эксплуатации не рекомендуется.
Можно собрать свой по инструкции.
export YANDEX_CONTROL_PLANE_MACHINE_IMAGE_ID=fd8a3kknu25826s8hbq3
$ yc resource-manager folder list +----------------------+---------+--------+--------+ | ID | NAME | LABELS | STATUS | +----------------------+---------+--------+--------+ | b1gn632om9rumce9tabc | default | | ACTIVE | +----------------------+---------+--------+--------+ $ export YANDEX_FOLDER_ID=b1gn632om9rumce9tabc
Если используем каталог, отличный от default, нужно выбрать соответствующий ID.
$ yc vpc network list +----------------------+---------+ | ID | NAME | +----------------------+---------+ | enpe888420gefk9d6r47 | default | +----------------------+---------+ $ export YANDEX_NETWORK_ID=enpe888420gefk9d6r47
Если используем сеть, отличную от default, нужно выбрать соответствующий ID.
$ yc vpc subnet list +----------------------+-----------------------------------------------------------+----------------------+----------------------+---------------+-----------------+ | ID | NAME | NETWORK ID | ROUTE TABLE ID | ZONE | RANGE | +----------------------+-----------------------------------------------------------+----------------------+----------------------+---------------+-----------------+ | e2lqmecfk68jek7ibbtd | default-ru-central1-b | enpe888420gefk9d6r47 | | ru-central1-b | [10.129.0.0/24] | | e9b7dr33rs111b14miu5 | default-ru-central1-a | enpe888420gefk9d6r47 | | ru-central1-a | [10.128.0.0/24] | | e9bjngd1uqlra97c5liv | k8s-cluster-catrpi1s5kq9pib1ltii-service-cidr-reservation | enpe888420gefk9d6r47 | | ru-central1-a | [10.96.0.0/16] | | e9bmc08qhj61su95e6pk | k8s-cluster-catrpi1s5kq9pib1ltii-pod-cidr-reservation | enpe888420gefk9d6r47 | | ru-central1-a | [10.112.0.0/16] | | fl8f5nrktjd0tqdkbe9k | default-ru-central1-d | enpe888420gefk9d6r47 | | ru-central1-d | [10.130.0.0/24] | +----------------------+-----------------------------------------------------------+----------------------+----------------------+---------------+-----------------+ $ export YANDEX_SUBNET_ID=e2lqmecfk68jek7ibbtd
Если используем подсеть, отличную от ru-central1-b, нужно выбрать соответствующий ID. Сформируем манифесты кластера:
clusterctl generate cluster <имя_создаваемого_кластера> \ --from templates/cluster-template.yaml > /tmp/capy-cluster.yaml
Наш кластер называется capy-workload-cluster. По умолчанию для доступа в кластер будет развернут L7-балансировщик Application Load Balancer c динамическим внутренним IP-адресом.
По сгенерированному манифесту будут развернуты три узла с Control Plane. Если хотим сразу развернуть узлы для рабочей нагрузки, выполним команду:
clusterctl generate cluster <имя_создаваемого_кластера> \ --worker-machine-count <количество_узлов_для_рабочей_нагрузки> \ --from templates/cluster-template.yaml > /tmp/capy-cluster.yaml
Развернем кластер:
$ kubectl apply -f /tmp/capy-cluster.yaml
За процессом развертывания кластера можно следить в консоли управления Yandex Cloud или в логах пода capy-controller-manager:
$ kubectl logs <имя_пода_с_capy-controller-manager> \ --namespace capy-system \ --follow
Подключитесь к кластеру
Нам нужно убедиться, что кластер успешно запущен, работает корректно и готов к размещению нагрузок. Для подключения мы используем kubeconfig с правами cluster-admin, автоматически созданный управляющим кластером (CAPI).
Подключение к кластеру необходимо для установки дополнительных компонентов, таких как Cloud Controller Manager (CCM) и Container Network Interface (CNI), которые обеспечивают интеграцию кластера с облачной инфраструктурой и сетевое взаимодействие между подами.
Реквизиты для подключения к новому кластеру будут созданы в управляющем кластере в секрете <имя_создаваемого_кластера>-kubeconfig.
Получаем данные из секрета:
$ kubectl get secret <имя_создаваемого_кластера>-kubeconfig \ --output yaml | yq -r '.data.value' | base64 \ --decode > capy-cluster-config
Передаем на jumphost, находящуюся в той же сети, в которой расположен новый кластер, файл с конфигурацией для kubectl:
$ scp <путь_к_файлу_capy-cluster-config_на_локальном_компьютере> \ <имя_пользователя>@<публичный_IP-адрес_jumphost>:/home/<имя_пользователя>/.kube/config
Подключимся к ранее созданной jumphost по SSH, а потом к новому кластеру:
$ (jumphost) kubectl cluster-info Kubernetes control plane is running at https://10.129.0.100:8443 CoreDNS is running at https://10.129.0.100:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
Установка CNI в созданный кластер
CNI нужен для обеспечения сетевого взаимодействия между подами. Установка Cilium:
$ (jumphost) wget https://github.com/cilium/cilium-cli/releases/download/v0.16.24/cilium-linux-amd64.tar.gz $ (jumphost) tar xf cilium-linux-amd64.tar.gz $ (jumphost) ./cilium install
Проверим связь управляющего кластера с созданным. Убедимся, что все поды с необходимыми системными компонентами развернуты в кластере:
$ (jumphost) kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system cilium-2xbm8 1/1 Running 0 8m9s kube-system cilium-envoy-6wzgh 1/1 Running 0 8m9s kube-system cilium-operator-7658c5585d-4skfr 1/1 Running 0 8m8s kube-system coredns-7c65d6cfc9-5cqlv 1/1 Running 0 2d16h kube-system coredns-7c65d6cfc9-whl5d 1/1 Running 0 2d16h kube-system etcd-capy-workload-cluster-control-plane-mc5st 1/1 Running 1 (71m ago) 2d16h kube-system kube-apiserver-capy-workload-cluster-control-plane-mc5st 1/1 Running 2 (71m ago) 2d16h kube-system kube-controller-manager-capy-workload-cluster-control-plane-mc5st 1/1 Running 1 (71m ago) 2d16h kube-system kube-proxy-vzmhq 1/1 Running 1 (71m ago) 2d16h kube-system kube-scheduler-capy-workload-cluster-control-plane-mc5st 1/1 Running 1 (71m ago) 2d16h kube-system yandex-cloud-controller-manager-6pd7x 1/1 Running 0 7s
На локальном компьютере проверим связь управляющего кластера с созданным. После установки CNI и CCM кластер начнет разворачиваться до того количества нод, которое указывалось при создании манифестов кластера:
$ clusterctl describe cluster capy-workload-cluster NAME READY SEVERITY REASON SINCE MESSAGE Cluster/capy-workload-cluster False Warning ScalingUp 112s Scaling up control plane to 3 replicas (actual 2) ├─ClusterInfrastructure - YandexCluster/capy-workload-cluster └─ControlPlane - KubeadmControlPlane/capy-workload-cluster-control-plane False Warning ScalingUp 112s Scaling up control plane to 3 replicas (actual 2) ├─Machine/capy-workload-cluster-control-plane-mc5st True 2d16h │ └─MachineInfrastructure - YandexMachine/capy-workload-cluster-control-plane-mc5st └─Machine/capy-workload-cluster-control-plane-qw9hz False Info WaitingForInfrastructure 112s 1 of 2 completed └─MachineInfrastructure - YandexMachine/capy-workload-cluster-control-plane-qw9hz
Установка ССМ в созданный кластер
Для обеспечения связи между ресурсами кластера и ресурсами Yandex Cloud установите в созданный кластер Cloud Controller Manager, например Kubernetes Cloud Controller Manager for Yandex Cloud.
$ (jumphost) cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Secret metadata: labels: k8s-app: yandex-cloud-controller-manager name: yandex-cloud namespace: kube-system stringData: service-account-json: | <Содержимое json файла созданного сервисного аккаунта> folder-id: "b1gn632om9rumce9tabc" EOF
folder-id соответствует переменной YANDEX_FOLDER_ID:
$ (jumphost) wget https://raw.githubusercontent.com/deckhouse/yandex-cloud-controller-manager/refs/heads/master/manifests/yandex-cloud-controller-manager.yaml $ (jumphost) wget https://raw.githubusercontent.com/deckhouse/yandex-cloud-controller-manager/refs/heads/master/manifests/yandex-cloud-controller-manager-rbac.yaml
В скачанный yandex-cloud-controller-manager.yaml yaml файл нужно добавить env YANDEX_CLUSTER_NAME:
--- apiVersion: v1 kind: ServiceAccount metadata: name: cloud-controller-manager namespace: kube-system --- apiVersion: apps/v1 kind: DaemonSet metadata: name: yandex-cloud-controller-manager labels: k8s-app: yandex-cloud-controller-manager namespace: kube-system spec: selector: matchLabels: k8s-app: yandex-cloud-controller-manager template: metadata: labels: k8s-app: yandex-cloud-controller-manager spec: hostNetwork: true dnsPolicy: Default serviceAccountName: cloud-controller-manager nodeSelector: # The CCM will only run on masters node-role.kubernetes.io/control-plane: "" tolerations: # this taint is set on all nodes when an external CCM is used # so we should tolerate it to schedule our CCM - key: "node.cloudprovider.kubernetes.io/uninitialized" value: "true" effect: "NoSchedule" # CCM should be able to run on masters - key: "node-role.kubernetes.io/control-plane" effect: "NoSchedule" - key: "CriticalAddonsOnly" operator: "Exists" containers: - image: registry.deckhouse.io/yandex-cloud-controller-manager/yandex-cloud-controller-manager:v0.21.3 name: yandex-cloud-controller-manager command: - /bin/yandex-cloud-controller-manager - --cloud-provider=yandex - --v=3 resources: requests: cpu: 100m memory: 50Mi env: - name: YANDEX_CLOUD_SERVICE_ACCOUNT_JSON valueFrom: secretKeyRef: name: yandex-cloud key: service-account-json - name: YANDEX_CLOUD_FOLDER_ID valueFrom: secretKeyRef: name: yandex-cloud key: folder-id - name: YANDEX_CLUSTER_NAME value: capy-workload-cluster
Что получилось
Workload Cluster успешно развернут и готов к работе. Теперь можно устанавливать в него рабочие нагрузки, управлять сетевыми настройками и обеспечивать масштабирование под свои задачи.
Преимущества использования CAPY. Раньше в Yandex Cloud не было нативного способа создавать и управлять кластерами Kubernetes с использованием Cluster API. Теперь благодаря CAPY можно:
Управлять кластерами декларативно — создавать и обновлять кластеры с помощью YAML-манифестов и kubectl apply.
Автоматизировать управление инфраструктурой — используя clusterctl и CRD, можно интегрировать развертывание кластера в CI/CD-процессы.
Гибко масштабировать кластер — добавлять и удалять ноды по необходимости, управляя этим через стандартные Kubernetes-механизмы.
Использовать MachineHealthCheck (MHC) — автоматически обнаруживать и заменять проблемные ноды.
Благодаря CAPY создание и управление Kubernetes-кластерами в Yandex Cloud теперь полностью совместимо с Cluster API, что открывает новые возможности для автоматизации и унификации работы с Kubernetes в облаке.
На прощание оставлю заметки, как удалить созданные ресурсы.
Удаление workload-кластера:
$ kubectl delete -f /tmp/capy-cluster.yaml
Удаление CAPY из management-кластера:
$ make uninstall $ make undeploy
Удаление вспомогательного jumphost:
$ yc compute instance delete jumphost
Удаление management-кластера:
$ yc managed-kubernetes cluster delete capy-management-cluster
