Миграция ресурсов Managed Service for Kubernetes в другую зону доступности
Примечание
Зона доступности ru-central1-c
поэтапно выводится из эксплуатации. Подробнее о планах по развитию зон доступности и возможностях миграции см. пост в блоге Yandex Cloud.
Чтобы перенести ресурсы Managed Service for Kubernetes из одной зоны в другую:
Перед началом работы
Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name
или --folder-id
.
Если CLI уже установлен, обновите его до последней версии:
yc components update
Перенесите мастер в другую зону доступности
Миграция мастера зависит от его типа: зональный или региональный.
Миграция зонального мастера
Зональный мастер находится в одной зоне доступности. Вы можете перенести мастер только из зоны ru-central1-c
в ru-central1-d
. Во время миграции мастер перезапускается, а Kubernetes API кратковременно недоступен. После миграции публичный и внутренний IP-адреса мастера сохраняются, кластер и группа узлов не пересоздаются.
Зональный мастер переносится в новую подсеть с тем же внутренним IP-адресом, который был в старой подсети. Этот IP-адрес также остается зарезервирован в старой подсети, поэтому ее нельзя удалить. В дальнейшем вы сможете перенести такую подсеть в новую зону доступности, либо она будет перенесена автоматически в зону ru-central1-d
после закрытия зоны ru-central1-c
.
Чтобы перенести зональный мастер в другую зону доступности:
-
Создайте подсеть в зоне доступности
ru-central1-d
:yc vpc subnet create \ --folder-id <идентификатор_каталога> \ --name <название_подсети> \ --zone ru-central1-d \ --network-id <идентификатор_сети> \ --range <CIDR_подсети>
В команде укажите параметры подсети:
--folder-id
— идентификатор каталога.--name
— название подсети.--zone
— зона доступности.--network-id
— идентификатор сети, в которую входит новая подсеть.--range
— список IPv4-адресов, откуда или куда будет поступать трафик. Например,10.0.0.0/22
или192.168.0.0/16
. Адреса должны быть уникальными внутри сети. Минимальный размер подсети —/28
, а максимальный размер подсети —/16
. Поддерживается только IPv4.
-
Перенесите мастер в другую зону доступности:
yc managed-kubernetes cluster update \ --folder-id <идентификатор_каталога> \ --id <идентификатор_кластера> \ --master-location subnet-id=<идентификатор_новой_подсети>,zone=ru-central1-d
Где:
--folder-id
— идентификатор каталога.--id
— идентификатор кластера.--master-location
— параметры размещения мастера:subnet-id
— идентификатор новой подсети.zone
— зона доступности.
Внимание
Чтобы убедиться, что кластер и все его группы узлов не будут пересозданы (если вы не делаете это намеренно), изучите вывод команд terraform plan
и terraform apply
перед применением конфигурации.
Перенести мастер в другую зону доступности без пересоздания кластера можно только при наличии в конфигурационном файле блока master_location
.
-
В файле с конфигурацией кластера обновите формат блока с параметрами расположения кластера (
zonal
) без изменения значений параметров:Старый формат:
resource "yandex_kubernetes_cluster" "<название_кластера>" { ... master { ... zonal { subnet_id = yandex_vpc_subnet.my-old-subnet.id zone = "ru-central1-c" } } ... }
Новый формат:
resource "yandex_kubernetes_cluster" "<название_кластера>" { ... master { ... master_location { subnet_id = yandex_vpc_subnet.my-old-subnet.id zone = "ru-central1-c" } } ... }
-
Убедитесь, что изменений в параметрах ресурсов Terraform не обнаружено:
terraform plan
Если Terraform обнаружил изменения, проверьте значения всех параметров кластера — они должны соответствовать текущему состоянию.
-
В файл с конфигурацией кластера добавьте манифест новой сети и измените местоположение кластера:
resource "yandex_vpc_subnet" "my-new-subnet" { name = "<название_сети>" zone = "ru-central1-d" network_id = yandex_vpc_network.k8s-network.id v4_cidr_blocks = ["<CIDR_подсети>"] } ... resource "yandex_kubernetes_cluster" "<название_кластера>" { ... master { ... master_location { subnet_id = yandex_vpc_subnet.my-new-subnet.id zone = "ru-central1-d" } } ... }
Для кластера старая подсеть
my-old-subnet
заменяется на подсетьmy-new-subnet
с параметрами:name
— название подсети.zone
— зона доступностиru-central1-d
.network_id
— идентификатор сети, в которую входит новая подсеть.v4_cidr_blocks
— список IPv4-адресов, откуда или куда будет поступать трафик. Например,10.0.0.0/22
или192.168.0.0/16
. Адреса должны быть уникальными внутри сети. Минимальный размер подсети —/28
, а максимальный размер подсети —/16
. Поддерживается только IPv4.
-
Проверьте корректность конфигурационного файла.
-
В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.
-
Выполните команду:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
-
Миграция регионального мастера
Региональный мастер создается распределенно в трех подсетях в разных зонах доступности. Для регионального мастера вы можете изменить только одну зону доступности: с ru-central1-c
на ru-central1-d
. Для миграции указываются три подсети и зоны доступности. Во время миграции работа мастера не прерывается, кластер и группа узлов не пересоздаются.
Внутренний IP-адрес для регионального мастера назначается автоматически в одной из трех подсетей размещения. После миграции внутренний IP-адрес мастера сохраняется. Если этот IP-адрес был выделен в подсети зоны ru-central1-c
, то мастер переносится в зону ru-central1-d
с прежним IP-адресом, зарезервированным в старой подсети. Такую подсеть нельзя удалить, но в дальнейшем вы сможете перенести ее в новую зону доступности, либо она будет перенесена автоматически в зону ru-central1-d
после закрытия зоны ru-central1-c
.
Чтобы перенести региональный мастер в другой набор зон доступности:
-
Создайте подсеть в зоне доступности
ru-central1-d
:yc vpc subnet create \ --folder-id <идентификатор_каталога> \ --name <название_подсети> \ --zone ru-central1-d \ --network-id <идентификатор_сети> \ --range <CIDR_подсети>
В команде укажите параметры подсети:
--folder-id
— идентификатор каталога.--name
— название подсети.--zone
— зона доступности.--network-id
— идентификатор сети, в которую входит новая подсеть.--range
— список IPv4-адресов, откуда или куда будет поступать трафик. Например,10.0.0.0/22
или192.168.0.0/16
. Адреса должны быть уникальными внутри сети. Минимальный размер подсети —/28
, а максимальный размер подсети —/16
. Поддерживается только IPv4.
-
Переместите мастер в другой набор зон доступности:
yc managed-kubernetes cluster update \ --folder-id <идентификатор_каталога> \ --id <идентификатор_кластера> \ --master-location subnet-id=<идентификатор_подсети>,zone=ru-central1-a \ --master-location subnet-id=<идентификатор_подсети>,zone=ru-central1-b \ --master-location subnet-id=<идентификатор_новой_подсети>,zone=ru-central1-d
Где:
-
--folder-id
— идентификатор каталога. -
--id
— идентификатор кластера. -
--master-location
— параметры размещения мастера:subnet-id
— идентификатор подсети.zone
— зона доступности.
Для каждой зоны доступности укажите соответствующую подсеть.
-
Внимание
Чтобы убедиться, что кластер и все его группы узлов не будут пересозданы (если вы не делаете это намеренно), изучите вывод команд terraform plan
и terraform apply
перед применением конфигурации.
Перенести мастер в другую зону доступности без пересоздания кластера можно только при наличии в конфигурационном файле блока master_location
.
-
В файле с конфигурацией кластера обновите формат блока с параметрами расположения кластера (
regional
) без изменения значений параметров:Старый формат:
resource "yandex_kubernetes_cluster" "<название_кластера>" { ... master { ... regional { region = "ru-central1" location { subnet_id = yandex_vpc_subnet.my-subnet-a.id zone = yandex_vpc_subnet.my-subnet-a.zone } location { subnet_id = yandex_vpc_subnet.my-subnet-b.id zone = yandex_vpc_subnet.my-subnet-b.zone } location { subnet_id = yandex_vpc_subnet.my-subnet-c.id zone = yandex_vpc_subnet.my-subnet-c.zone } } } ... }
Новый формат:
resource "yandex_kubernetes_cluster" "<название_кластера>" { ... master { ... master_location { subnet_id = yandex_vpc_subnet.my-subnet-a.id zone = yandex_vpc_subnet.my-subnet-a.zone } master_location { subnet_id = yandex_vpc_subnet.my-subnet-b.id zone = yandex_vpc_subnet.my-subnet-b.zone } master_location { subnet_id = yandex_vpc_subnet.my-subnet-c.id zone = yandex_vpc_subnet.my-subnet-c.zone } } ... }
-
Убедитесь, что изменений в параметрах ресурсов Terraform не обнаружено:
terraform plan
Если Terraform обнаружил изменения, проверьте значения всех параметров кластера — они должны соответствовать текущему состоянию.
-
В файл с конфигурацией кластера добавьте манифест новой подсети и измените местоположение кластера:
resource "yandex_vpc_subnet" "my-subnet-d" { name = "<название_сети>" zone = "ru-central1-d" network_id = yandex_vpc_network.k8s-network.id v4_cidr_blocks = ["<CIDR_подсети>"] } ... resource "yandex_kubernetes_cluster" "k8s-cluster" { ... master { ... master_location { subnet_id = yandex_vpc_subnet.my-subnet-a.id zone = yandex_vpc_subnet.my-subnet-a.zone } master_location { subnet_id = yandex_vpc_subnet.my-subnet-b.id zone = yandex_vpc_subnet.my-subnet-b.zone } master_location { subnet_id = yandex_vpc_subnet.my-subnet-d.id zone = yandex_vpc_subnet.my-subnet-d.zone } ... } ... }
Для кластера подсеть
my-subnet-c
заменяется на подсетьmy-subnet-d
с параметрами:name
— название подсети.zone
— зона доступности.network_id
— идентификатор сети, в которую входит новая подсеть.v4_cidr_blocks
— список IPv4-адресов, откуда или куда будет поступать трафик. Например,10.0.0.0/22
или192.168.0.0/16
. Адреса должны быть уникальными внутри сети. Минимальный размер подсети —/28
, а максимальный размер подсети —/16
. Поддерживается только IPv4.
-
Проверьте корректность конфигурационного файла.
-
В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.
-
Выполните команду:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
-
Перенесите группу узлов и рабочую нагрузку в подах в другую зону доступности
Подготовьте группу узлов, после чего выполните миграцию одним из способов:
-
Миграция непосредственно группы узлов в новую зону доступности. Зависит от вида рабочей нагрузки в подах:
-
Stateless-нагрузка — работа приложений в подах во время миграции зависит от распределения нагрузки между узлами кластера. Если поды находятся в мигрирующей группе узлов и группах, для которых не меняется зона доступности, приложения продолжают работать. Если поды находятся только в мигрирующей группе, поды и приложения в них придется остановить на короткий срок.
Примеры stateless-нагрузки: веб-сервер, Ingress-контроллер Yandex Application Load Balancer, приложение REST API.
-
Stateful-нагрузка — независимо от распределения нагрузки между узлами кластера поды и приложения придется остановить на короткий срок.
Примеры stateful-нагрузки: базы данных, хранилища.
-
-
Постепенная миграция stateless- и stateful-нагрузки в новую группу узлов. Заключается в создании новой группы узлов в новой зоне доступности и постепенном отключении старых узлов. Так вы можете контролировать перенос нагрузки.
Подготовительные действия
-
Проверьте, используются ли стратегии
nodeSelector
,affinity
илиtopology spread constraints
для привязки подов к узлам группы. Подробнее о стратегиях см. в документации Kubernetes и разделе Высокая доступность и отказоустойчивость. Чтобы проверить привязку пода к узлам и убрать ее:Консоль управления-
В консоли управления
выберите каталог с вашим кластером Managed Service for Kubernetes. -
В списке сервисов выберите Managed Service for Kubernetes.
-
Перейдите на страницу кластера, затем — в раздел Рабочая нагрузка.
-
На вкладке Поды откройте страницу пода.
-
Перейдите на вкладку YAML.
-
Проверьте, содержит ли манифест пода указанные параметры и Kubernetes-метки в них:
-
Параметры:
spec.nodeSelector
spec.affinity
spec.topologySpreadConstraints
-
Kubernetes-метки, заданные внутри параметров:
failure-domain.beta.kubernetes.io/zone
:<зона_доступности>
topology.kubernetes.io/zone
:<зона_доступности>
Если в конфигурации есть хотя бы один из указанных параметров и он содержит хотя бы одну из перечисленных Kubernetes-меток, такая настройка будет препятствовать миграции группы узлов и рабочей нагрузки.
-
-
Проверьте, есть ли в манифесте пода зависимости от сущностей:
- зоны доступности, из которой вы переносите ресурсы;
- конкретных узлов в группе.
-
Если вы нашли указанные выше настройки, привязки и зависимости, удалите их из конфигурации пода:
-
Скопируйте YAML-конфигурацию из консоли управления.
-
Создайте локальный YAML-файл и вставьте в него конфигурацию.
-
Удалите из нее привязки к зонам доступности. Например, если в параметре
spec.affinity
указана Kubernetes-меткаfailure-domain.beta.kubernetes.io/zone
, удалите ее. -
Примените новую конфигурацию:
kubectl apply -f <путь_до_YAML-файла>
-
Убедитесь, что под перешел в статус
Running
:kubectl get pods
-
-
Проверьте таким образом каждый под и поправьте его конфигурацию.
-
-
Перенесите в новую зону доступности персистентные данные (например, базы данных, очереди сообщений, серверы мониторинга и логов).
Миграция stateless-нагрузки
-
Создайте подсеть в новой зоне доступности и перенесите группу узлов:
CLITerraform-
Создайте подсеть:
yc vpc subnet create \ --name <название_подсети> \ --zone <зона_доступности> \ --network-id <идентификатор_сети> \ --range <CIDR_подсети>
Где:
--name
— название подсети.--zone
— зона доступности:ru-central1-a
,ru-central1-b
илиru-central1-d
.--network-id
— идентификатор сети, в которую входит новая подсеть.--range
— список IPv4-адресов, откуда или куда будет поступать трафик. Например,10.0.0.0/22
или192.168.0.0/16
. Адреса должны быть уникальными внутри сети. Минимальный размер подсети —/28
, а максимальный размер подсети —/16
. Поддерживается только IPv4.
-
Перенесите группу узлов в новую зону доступности. Ниже приведен пример команды для переноса группы, расположенной в одной зоне:
yc managed-kubernetes node-group update \ --id <идентификатор_группы_узлов> \ --location zone=<зона_доступности>,subnet-id=<идентификатор_подсети> \ --network-interface subnets=<идентификатор_подсети>,` `ipv4-address=nat,` `security-group-ids=[<идентификаторы_групп_безопасности>]
Где:
id
— идентификатор группы узлов, которую вы переносите в другую зону доступности.zone
— зона доступности, в которую вы переносите группу узлов:ru-central1-a
,ru-central1-b
илиru-central1-d
.subnet-id
иsubnets
— идентификатор новой подсети, созданной ранее.ipv4-address
— способ назначения IPv4-адреса. Значениеnat
позволяет присвоить узлам публичные и внутренние IP-адреса.security-group-ids
— список идентификаторов групп безопасности.
Важно
Если вы хотите сохранить для группы узлов значения других параметров сети, также укажите их в параметре
network-interface
. Иначе группа может быть пересоздана со значениями по умолчанию. Подробнее см. Изменение группы узлов Managed Service for Kubernetes.Важно передать параметры
ipv4-address
иsecurity-group-ids
в команде — это позволит назначить группе узлов публичные IP-адреса и сохранить в ней группы безопасности.Команда пересоздает узлы внутри их группы в указанной зоне доступности и подсети. При пересоздании учитываются настройки развертывания — максимальное количество узлов, на которое разрешается увеличить или уменьшить размер группы по сравнению с исходным количеством узлов.
Как перенести группу узлов, расположенную в разных зонах доступности
В этом случае используйте команду:
yc managed-kubernetes node-group update \ --id <идентификатор_группы_узлов> \ --location zone=<зона_доступности>,subnet-id=<идентификатор_подсети> \ ... --location zone=<зона_доступности>,subnet-id=<идентификатор_подсети> \ --network-interface subnets=[<идентификаторы_подсетей>],` `ipv4-address=nat,` `security-group-ids=[<идентификаторы_групп_безопасности>]
Где:
id
— идентификатор группы узлов, которую вы переносите в другую зону доступности.zone
— зона доступности:ru-central1-a
,ru-central1-b
илиru-central1-d
. Укажите параметрыlocation
для каждой зоны доступности, в которой будет располагаться группа узлов.subnet-id
иsubnets
— идентификаторы подсетей для указанных зон доступности.ipv4-address
— способ назначения IPv4-адреса. Значениеnat
позволяет присвоить узлам публичные и внутренние IP-адреса.security-group-ids
— список идентификаторов групп безопасности.
Внимание
Чтобы убедиться, что группа узлов не будет пересоздана (если вы не делаете это намеренно), изучите вывод команд
terraform plan
иterraform apply
перед применением конфигурации.Перенести группу узлов в другую зону доступности без пересоздания можно только при наличии в конфигурационном файле блока
allocation_policy
.-
Внесите следующие изменения в конфигурационный файл:
- Добавьте манифест новой подсети (ресурс
yandex_vpc_subnet
) в зоне доступности, в которую вы хотите перенести группу узлов. - Измените параметры местоположения группы узлов (ресурс
yandex_kubernetes_node_group
):allocation_policy.location.subnet_id
— удалите этот параметр, если он есть в манифесте.allocation_policy.location.zone
— укажите зону доступности, в которую вы хотите перенести группу узлов.instance_template.network_interface.subnet_ids
— укажите идентификатор новой подсети. Добавьте этот параметр, если его нет в манифесте.
resource "yandex_vpc_subnet" "my-new-subnet" { name = "<название_подсети>" zone = "<зона_доступности>" network_id = "<идентификатор_сети>" v4_cidr_blocks = ["<CIDR_подсети>"] } ... resource "yandex_kubernetes_node_group" "k8s-node-group" { allocation_policy { location { zone = "<зона_доступности>" } } ... instance_template { network_interface { subnet_ids = [yandex_vpc_subnet.my-new-subnet.id] ... } ... } ... }
Где:
name
— имя подсети.zone
— зона доступности, в которую вы переносите группу узлов:ru-central1-a
,ru-central1-b
илиru-central1-d
.network_id
— идентификатор сети, в которую входит новая подсеть.v4_cidr_blocks
— список IPv4-адресов, откуда или куда будет поступать трафик. Например,10.0.0.0/22
или192.168.0.0/16
. Адреса должны быть уникальными внутри сети. Минимальный размер подсети —/28
, а максимальный размер подсети —/16
. Поддерживается только IPv4.subnet_ids
— идентификатор новой подсети.
- Добавьте манифест новой подсети (ресурс
-
Проверьте корректность конфигурационного файла.
-
В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.
-
Выполните команду:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
-
Узлы группы будут пересозданы в указанной зоне доступности и подсети. При пересоздании учитываются настройки развертывания — максимальное количество узлов, на которое разрешается увеличить или уменьшить размер группы по сравнению с исходным количеством узлов.
-
-
Убедитесь, что поды запущены в перенесенной группе узлов:
kubectl get po --output wide
Вывод команды показывает, в каких узлах запущены поды.
Миграция stateful-нагрузки
Миграция основана на масштабировании контроллера StatefulSet
. Чтобы перенести рабочую stateful-нагрузку:
-
Получите список контроллеров
StatefulSet
, чтобы узнать название нужного контроллера:kubectl get statefulsets
-
Узнайте количество подов контроллера:
kubectl get statefulsets <название_контроллера> \ -n default -o=jsonpath='{.status.replicas}'
Сохраните полученное значение. Оно понадобится в конце миграции stateful-нагрузки для масштабирования контроллера StatefulSet.
-
Уменьшите количество подов до нуля:
kubectl scale statefulset <название_контроллера> --replicas=0
Так вы выключите поды, которые используют диски. При этом сохранится объект API Kubernetes PersistentVolumeClaim (PVC).
-
Для объекта PersistentVolume (PV), связанного с
PersistentVolumeClaim
, измените значение параметраpersistentVolumeReclaimPolicy
сDelete
наRetain
, чтобы предотвратить случайную потерю данных.-
Получите название объекта
PersistentVolume
:kubectl get pv
-
Отредактируйте объект
PersistentVolume
:kubectl edit pv <название_PV>
-
-
Проверьте, содержит ли манифест объекта
PersistentVolume
параметрspec.nodeAffinity
:kubectl get pv <название_PV> --output='yaml'
Если манифест содержит параметр
spec.nodeAffinity
и в нем указана принадлежность к зоне доступности, сохраните этот параметр. Его понадобится указать в новомPersistentVolume
. -
Создайте снапшот — копию диска
PersistentVolume
на определенный момент времени. Подробнее о механизме снапшотов см. в документации Kubernetes .-
Получите название объекта
PersistentVolumeClaim
:kubectl get pvc
-
Создайте файл
snapshot.yaml
с манифестом снапшота и укажите в нем названиеPersistentVolumeClaim
:apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: new-snapshot-test-<номер> spec: volumeSnapshotClassName: yc-csi-snapclass source: persistentVolumeClaimName: <название_PVC>
Если вы создаете несколько снапшотов для разных
PersistentVolumeClaim
, укажите<номер>
(номер по порядку), чтобы значениеmetadata.name
было уникальным для каждого снапшота. -
Создайте снапшот:
kubectl apply -f snapshot.yaml
-
Убедитесь, что снапшот создан:
kubectl get volumesnapshots.snapshot.storage.k8s.io
-
Убедитесь, что создан объект API Kubernetes VolumeSnapshotContent
:kubectl get volumesnapshotcontents.snapshot.storage.k8s.io
-
-
Получите идентификатор снапшота:
yc compute snapshot list
-
Создайте диск виртуальной машины из снапшота:
yc compute disk create \ --source-snapshot-id <идентификатор_снапшота> \ --zone <зона_доступности>
В команде укажите зону доступности, в которую переносится группа узлов Managed Service for Kubernetes.
Сохраните следующие параметры из вывода команды:
- идентификатор диска в поле
id
; - тип диска в поле
type_id
; - размер диска в поле
size
.
- идентификатор диска в поле
-
Создайте объект API Kubernetes
PersistentVolume
на основе нового диска:-
Создайте файл
persistent-volume.yaml
с манифестомPersistentVolume
:apiVersion: v1 kind: PersistentVolume metadata: name: new-pv-test-<номер> spec: capacity: storage: <размер_PersistentVolume> accessModes: - ReadWriteOnce csi: driver: disk-csi-driver.mks.ycloud.io fsType: ext4 volumeHandle: <идентификатор_диска> storageClassName: <тип_диска>
В файле укажите параметры диска, созданного на основе снапшота:
-
spec.capacity.storage
— размер диска. -
spec.csi.volumeHandle
— идентификатор диска. -
spec.storageClassName
— тип диска. Укажите его в соответствии с таблицей:Тип диска на основе снапшота Тип диска для YAML-файла network-ssd
yc-network-ssd
network-ssd-nonreplicated
yc-network-ssd-nonreplicated
network-nvme
yc-network-nvme
network-hdd
yc-network-hdd
Если вы создаете несколько объектов
PersistentVolume
, укажите<номер>
(номер по порядку), чтобы значениеmetadata.name
было уникальным.Если ранее вы сохранили параметр
spec.nodeAffinity
, добавьте его в манифест и укажите зону доступности, в которую переносится группа узлов Managed Service for Kubernetes. Если параметр не указан, рабочая нагрузка может запуститься в другой зоне доступности, в которой недоступенPersistentVolume
. Это приведет к ошибке запуска.Пример параметра
spec.nodeAffinity
:spec: ... nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: failure-domain.beta.kubernetes.io/zone operator: In values: - ru-central1-d
-
-
Создайте объект
PersistentVolume
:kubectl apply -f persistent-volume.yaml
-
Убедитесь, что
PersistentVolume
создан:kubectl get pv
В выводе команды появится объект
new-pv-test-<номер>
. -
Если в манифесте вы указали параметр
spec.nodeAffinity
, убедитесь, что дляPersistentVolume
применен этот параметр:Консоль управления- В консоли управления
выберите каталог с вашим кластером Managed Service for Kubernetes. - В списке сервисов выберите Managed Service for Kubernetes.
- Перейдите на страницу кластера, затем — в раздел Хранилища.
- На вкладке Persistent Volumes найдите объект
new-pv-test-<номер>
и посмотрите значение поля Зона доступности. В нем должна отображаться зона доступности. Прочерк означает, что нет привязки к зоне доступности.
- В консоли управления
-
Если в манифесте вы не указали параметр
spec.nodeAffinity
, вы можете добавить его. Для этого отредактируйте объектPersistentVolume
:kubectl edit pv new-pv-test-<номер>
-
-
Создайте объект
PersistentVolumeClaim
на основе нового объектаPersistentVolume
:-
Создайте файл
persistent-volume-claim.yaml
с манифестомPersistentVolumeClaim
:apiVersion: v1 kind: PersistentVolumeClaim metadata: name: <название_PVC> spec: accessModes: - ReadWriteOnce resources: requests: storage: <размер_PV> storageClassName: <тип_диска> volumeName: new-pv-test-<номер>
В файле задайте параметры:
metadata.name
— название объектаPersistentVolumeClaim
, который вы использовали для создания снапшота. Название можно получить с помощью командыkubectl get pvc
.spec.resources.requests.storage
— размерPersistentVolume
, совпадает с размером созданного диска.spec.storageClassName
— тип дискаPersistentVolume
, совпадает с типом диска у нового объектаPersistentVolume
.spec.volumeName
— название объектаPersistentVolume
, на основе которого создаетсяPersistentVolumeClaim
. Название можно получить с помощью командыkubectl get pv
.
-
Удалите исходный объект
PersistentVolumeClaim
, чтобы затем заменить его:kubectl delete pvc <название_PVC>
-
Создайте объект
PersistentVolumeClaim
:kubectl apply -f persistent-volume-claim.yaml
-
Убедитесь, что
PersistentVolumeClaim
создан:kubectl get pvc
В выводе команды для
PersistentVolumeClaim
будет указан размер, который вы задали в YAML-файле.
-
-
Создайте подсеть в новой зоне доступности и перенесите группу узлов:
CLITerraform-
Создайте подсеть:
yc vpc subnet create \ --name <название_подсети> \ --zone <зона_доступности> \ --network-id <идентификатор_сети> \ --range <CIDR_подсети>
Где:
--name
— название подсети.--zone
— зона доступности:ru-central1-a
,ru-central1-b
илиru-central1-d
.--network-id
— идентификатор сети, в которую входит новая подсеть.--range
— список IPv4-адресов, откуда или куда будет поступать трафик. Например,10.0.0.0/22
или192.168.0.0/16
. Адреса должны быть уникальными внутри сети. Минимальный размер подсети —/28
, а максимальный размер подсети —/16
. Поддерживается только IPv4.
-
Перенесите группу узлов в новую зону доступности. Ниже приведен пример команды для переноса группы, расположенной в одной зоне:
yc managed-kubernetes node-group update \ --id <идентификатор_группы_узлов> \ --location zone=<зона_доступности>,subnet-id=<идентификатор_подсети> \ --network-interface subnets=<идентификатор_подсети>,` `ipv4-address=nat,` `security-group-ids=[<идентификаторы_групп_безопасности>]
Где:
id
— идентификатор группы узлов, которую вы переносите в другую зону доступности.zone
— зона доступности, в которую вы переносите группу узлов:ru-central1-a
,ru-central1-b
илиru-central1-d
.subnet-id
иsubnets
— идентификатор новой подсети, созданной ранее.ipv4-address
— способ назначения IPv4-адреса. Значениеnat
позволяет присвоить узлам публичные и внутренние IP-адреса.security-group-ids
— список идентификаторов групп безопасности.
Важно
Если вы хотите сохранить для группы узлов значения других параметров сети, также укажите их в параметре
network-interface
. Иначе группа может быть пересоздана со значениями по умолчанию. Подробнее см. Изменение группы узлов Managed Service for Kubernetes.Важно передать параметры
ipv4-address
иsecurity-group-ids
в команде — это позволит назначить группе узлов публичные IP-адреса и сохранить в ней группы безопасности.Команда пересоздает узлы внутри их группы в указанной зоне доступности и подсети. При пересоздании учитываются настройки развертывания — максимальное количество узлов, на которое разрешается увеличить или уменьшить размер группы по сравнению с исходным количеством узлов.
Как перенести группу узлов, расположенную в разных зонах доступности
В этом случае используйте команду:
yc managed-kubernetes node-group update \ --id <идентификатор_группы_узлов> \ --location zone=<зона_доступности>,subnet-id=<идентификатор_подсети> \ ... --location zone=<зона_доступности>,subnet-id=<идентификатор_подсети> \ --network-interface subnets=[<идентификаторы_подсетей>],` `ipv4-address=nat,` `security-group-ids=[<идентификаторы_групп_безопасности>]
Где:
id
— идентификатор группы узлов, которую вы переносите в другую зону доступности.zone
— зона доступности:ru-central1-a
,ru-central1-b
илиru-central1-d
. Укажите параметрыlocation
для каждой зоны доступности, в которой будет располагаться группа узлов.subnet-id
иsubnets
— идентификаторы подсетей для указанных зон доступности.ipv4-address
— способ назначения IPv4-адреса. Значениеnat
позволяет присвоить узлам публичные и внутренние IP-адреса.security-group-ids
— список идентификаторов групп безопасности.
Внимание
Чтобы убедиться, что группа узлов не будет пересоздана (если вы не делаете это намеренно), изучите вывод команд
terraform plan
иterraform apply
перед применением конфигурации.Перенести группу узлов в другую зону доступности без пересоздания можно только при наличии в конфигурационном файле блока
allocation_policy
.-
Внесите следующие изменения в конфигурационный файл:
- Добавьте манифест новой подсети (ресурс
yandex_vpc_subnet
) в зоне доступности, в которую вы хотите перенести группу узлов. - Измените параметры местоположения группы узлов (ресурс
yandex_kubernetes_node_group
):allocation_policy.location.subnet_id
— удалите этот параметр, если он есть в манифесте.allocation_policy.location.zone
— укажите зону доступности, в которую вы хотите перенести группу узлов.instance_template.network_interface.subnet_ids
— укажите идентификатор новой подсети. Добавьте этот параметр, если его нет в манифесте.
resource "yandex_vpc_subnet" "my-new-subnet" { name = "<название_подсети>" zone = "<зона_доступности>" network_id = "<идентификатор_сети>" v4_cidr_blocks = ["<CIDR_подсети>"] } ... resource "yandex_kubernetes_node_group" "k8s-node-group" { allocation_policy { location { zone = "<зона_доступности>" } } ... instance_template { network_interface { subnet_ids = [yandex_vpc_subnet.my-new-subnet.id] ... } ... } ... }
Где:
name
— имя подсети.zone
— зона доступности, в которую вы переносите группу узлов:ru-central1-a
,ru-central1-b
илиru-central1-d
.network_id
— идентификатор сети, в которую входит новая подсеть.v4_cidr_blocks
— список IPv4-адресов, откуда или куда будет поступать трафик. Например,10.0.0.0/22
или192.168.0.0/16
. Адреса должны быть уникальными внутри сети. Минимальный размер подсети —/28
, а максимальный размер подсети —/16
. Поддерживается только IPv4.subnet_ids
— идентификатор новой подсети.
- Добавьте манифест новой подсети (ресурс
-
Проверьте корректность конфигурационного файла.
-
В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.
-
Выполните команду:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
-
Узлы группы будут пересозданы в указанной зоне доступности и подсети. При пересоздании учитываются настройки развертывания — максимальное количество узлов, на которое разрешается увеличить или уменьшить размер группы по сравнению с исходным количеством узлов.
-
-
Верните прежнее количество подов контроллера
StatefulSet
:kubectl scale statefulset <название_контроллера> --replicas=<количество_подов>
Поды запустятся в перенесенной группе узлов.
В команде укажите параметры:
- Название контроллера
StatefulSet
. Его можно получить с помощью командыkubectl get statefulsets
. - Количество подов, которое было до масштабирования контроллера.
- Название контроллера
-
Убедитесь, что поды запущены в перенесенной группе узлов:
kubectl get po --output wide
Вывод команды показывает, в каких узлах запущены поды.
-
Удалите неиспользуемый объект
PersistentVolume
(в статусеReleased
).-
Получите название объекта
PersistentVolume
:kubectl get pv
-
Удалите объект
PersistentVolume
:kubectl delete pv <название_PV>
-
Постепенная миграция stateless- и stateful-нагрузки
Ниже представлена инструкция по постепенной миграции нагрузки из старой группы узлов в новую. Инструкцию по миграции объектов PersistentVolume
и PersistentVolumeClaim
см. в подразделе Миграция stateful-нагрузки.
-
Создайте новую группу узлов Managed Service for Kubernetes в новой зоне доступности.
-
Запретите запуск новых подов в старой группе узлов:
kubectl cordon -l yandex.cloud/node-group-id=<идентификатор_старой_группы_узлов>
-
Для каждого узла из старой группы узлов выполните команду:
kubectl drain <имя_узла> --ignore-daemonsets --delete-emptydir-data
Поды постепенно переместятся в новую группу узлов.
-
Убедитесь, что поды запущены в новой группе узлов:
kubectl get po --output wide