Как работать с CAPY

Средний

16 мин

383

Блог компании Т-БанкKubernetes*DevOps*Виртуализация*Open source*

Туториал

Привет, Хабр! Я Данил Трещев, работаю в 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, чтобы сэкономить время, когда результат нужен «еще вчера». Но вектор развития остается прежним — максимальная независимость и контроль над архитектурой.

Как мы управляли нашими кластерами до того, как написали свое решение (CAPY), и как — после

Подготовка к работе

Нам понадобятся инструменты:

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

Хабы: