Миграция ресурсов Kubernetes в другую зону доступности

Статья создана

Yandex Cloud

Улучшена

mmerihsesh

Обновлена 10 октября 2026 г.

Открыть в Markdown

Перед началом работы
Необходимые платные ресурсы
Перенесите мастер в другую зону доступности
- Миграция высокодоступного мастера
- Восстановите доступность вебхуков Cilium
Перенесите группу узлов и рабочую нагрузку в подах в другую зону доступности

В кластере Managed Service for Kubernetes вы можете перенести высокодоступный мастер, а также группу узлов и рабочую нагрузку в подах из одной зоны доступности в другую.

Перед началом работы

Если у вас еще нет интерфейса командной строки Yandex Cloud (CLI), установите и инициализируйте его.

По умолчанию используется каталог, указанный при создании профиля CLI. Чтобы изменить каталог по умолчанию, используйте команду yc config set folder-id <идентификатор_каталога>. Также для любой команды вы можете указать другой каталог с помощью параметров --folder-name или --folder-id.

Если вы обращаетесь к ресурсу по имени, поиск будет выполнен в каталоге по умолчанию. Если вы обращаетесь к ресурсу по идентификатору, поиск будет выполнен глобально — во всех каталогах с учетом прав доступа.

Если CLI уже установлен, обновите его до последней версии:

yc components update

Необходимые платные ресурсы

Мастер Managed Service for Kubernetes (тарифы Managed Service for Kubernetes).
Узлы кластера Managed Service for Kubernetes: использование вычислительных ресурсов и хранилища (тарифы Yandex Compute Cloud).
Публичные IP-адреса для мастера и узлов кластера Managed Service for Kubernetes, если для них включен публичный доступ (тарифы Yandex Virtual Private Cloud).

Перенесите мастер в другую зону доступности

В этом разделе описана миграция высокодоступного мастера из зоны ru-central1-b в ru-central1-e. Размещение в зонах ru-central1-a и ru-central1-d сохраняется.

Важно

В кластерах с Cilium после переноса мастера могут стать недоступны вебхуки. Способ устранения проблемы описан в разделе Восстановите доступность вебхуков Cilium.

Миграция высокодоступного мастера

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

Чтобы перенести высокодоступный мастер в другой набор зон доступности:

CLI

Terraform

Если у вас еще нет интерфейса командной строки Yandex Cloud (CLI), установите и инициализируйте его.

Посмотрите описание команды изменения кластера:
```
yc managed-kubernetes cluster update --help
```
Создайте подсеть в зоне доступности ru-central1-e:
```
yc vpc subnet create \
   --folder-id <идентификатор_каталога> \
   --name <название_подсети> \
   --zone ru-central1-e \
   --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=<идентификатор_подсети_a>,zone=ru-central1-a \
   --master-location subnet-id=<идентификатор_подсети_d>,zone=ru-central1-d \
   --master-location subnet-id=<идентификатор_новой_подсети>,zone=ru-central1-e
```
Где:
- --folder-id — идентификатор каталога. Необязательный параметр, если каталог задан в профиле CLI.
- --id — идентификатор кластера. Обязательный параметр.
- --master-location — параметры размещения мастера. Укажите три раза, по одному для каждой зоны:
  - subnet-id — идентификатор подсети.
  - zone — зона доступности.
  Для зон ru-central1-a и ru-central1-d укажите текущие подсети, для ru-central1-e — новую.

Если у вас еще нет Terraform, установите его и настройте провайдер Yandex Cloud.

Чтобы управлять инфраструктурой с помощью Terraform от имени сервисного аккаунта или пользовательских аккаунтов: аккаунта на Яндексе, федеративного аккаунта и локального пользователя, аутентифицируйтесь соответствующим способом.

Внимание

Чтобы убедиться, что кластер и все его группы узлов не будут пересозданы (если вы не делаете это намеренно), изучите вывод команд terraform plan и terraform apply перед применением конфигурации.

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

Если в конфигурации кластера используется блок regional, замените его тремя блоками master_location, сохранив текущие значения зон и подсетей. Если блоки master_location уже используются, переходите к созданию новой подсети.

Ниже показаны фрагменты конфигурации. Сохраните имя ресурса в конфигурации и остальные параметры ресурса yandex_kubernetes_cluster без изменений.

Старый формат:

resource "yandex_kubernetes_cluster" "k8s-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-d.id
            zone      = yandex_vpc_subnet.my-subnet-d.zone
         }
         location {
            subnet_id = yandex_vpc_subnet.my-subnet-b.id
            zone      = yandex_vpc_subnet.my-subnet-b.zone
         }
      }
   }
   ...
}

Новый формат:

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-d.id
         zone      = yandex_vpc_subnet.my-subnet-d.zone
      }
      master_location {
         subnet_id = yandex_vpc_subnet.my-subnet-b.id
         zone      = yandex_vpc_subnet.my-subnet-b.zone
      }
   }
   ...
}

Убедитесь, что изменений в параметрах ресурсов Terraform не обнаружено:
```
terraform plan
```
Если Terraform обнаружил изменения, проверьте значения всех параметров кластера — они должны соответствовать текущему состоянию.
В файл с конфигурацией кластера добавьте манифест новой подсети и измените местоположение кластера:
```
resource "yandex_vpc_subnet" "my-subnet-e" {
   name           = "<название_подсети>"
   zone           = "ru-central1-e"
   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-d.id
         zone      = yandex_vpc_subnet.my-subnet-d.zone
      }
      master_location {
         subnet_id = yandex_vpc_subnet.my-subnet-e.id
         zone      = yandex_vpc_subnet.my-subnet-e.zone
      }
      ...
   }
...
}
```
Для кластера подсеть my-subnet-b заменяется на подсеть my-subnet-e с параметрами:
- name — название подсети.
- zone — зона доступности.
- network_id — идентификатор сети, в которую входит новая подсеть.
- v4_cidr_blocks — список IPv4-адресов, откуда или куда будет поступать трафик. Например, 10.0.0.0/22 или 192.168.0.0/16. Адреса должны быть уникальными внутри сети. Минимальный размер подсети — /28, а максимальный размер подсети — /16. Поддерживается только IPv4.
Проверьте корректность конфигурационного файла.
1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.
2. Выполните команду:
```
terraform validate
```
  Если в файлах конфигурации есть ошибки, Terraform на них укажет.
Подтвердите изменение ресурсов. Перед применением убедитесь, что план не содержит удаления или пересоздания кластера и его групп узлов.
1. Выполните команду для просмотра планируемых изменений:
```
terraform plan
```
  Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
2. Если вас устраивают планируемые изменения, внесите их:
  1. Выполните команду:
```
terraform apply
```
  2. Подтвердите изменение ресурсов.
  3. Дождитесь завершения операции.

Подробная информация о параметрах ресурса yandex_kubernetes_cluster приведена в документации провайдера.

Восстановите доступность вебхуков Cilium

После миграции мастера в кластерах с Cilium могут стать недоступны мутирующие и валидирующие вебхуки (Mutating/Validating Webhook) со стороны перенесенного мастера.

Если вы столкнулись с этой проблемой:

Подключитесь к кластеру с помощью Kubernetes CLI (kubectl).
Получите список объектов CiliumNode:
```
kubectl get ciliumnodes
```
Найдите объект старого мастера из исходной зоны доступности. Например, при переносе из ru-central1-b его имя имеет вид mk8s-master-<идентификатор>-b.
Удалите только объект CiliumNode, который относится к старому мастеру:
```
kubectl delete ciliumnode <имя_объекта_старого_мастера>
```
Проверьте, восстановилась ли доступность вебхуков. Если проблема сохраняется, обратитесь в техническую поддержку.

Перенесите группу узлов и рабочую нагрузку в подах в другую зону доступности

Подготовьте группу узлов, после чего выполните миграцию одним из способов:

Миграция непосредственно группы узлов в новую зону доступности. Зависит от вида рабочей нагрузки в подах:
- Stateless-нагрузка — работа приложений в подах во время миграции зависит от распределения нагрузки между узлами кластера. Если поды находятся в мигрирующей группе узлов и группах, для которых не меняется зона доступности, приложения продолжают работать. Если поды находятся только в мигрирующей группе, поды и приложения в них придется остановить на короткий срок.
  
  Примеры stateless-нагрузки: веб-сервер, Ingress-контроллер Yandex Application Load Balancer, приложение REST API.
- Stateful-нагрузка — независимо от распределения нагрузки между узлами кластера поды и приложения придется остановить на короткий срок.
  
  Примеры stateful-нагрузки: базы данных, хранилища.
Постепенная миграция stateless- и stateful-нагрузки в новую группу узлов. Заключается в создании новой группы узлов в новой зоне доступности и постепенном отключении старых узлов. Так вы можете контролировать перенос нагрузки.

Подготовительные действия

Проверьте, используются ли стратегии nodeSelector, affinity или topology spread constraints для привязки подов к узлам группы. Подробнее о стратегиях смотрите в документации Kubernetes и разделе Высокая доступность и отказоустойчивость. Чтобы проверить привязку пода к узлам и убрать ее:
Консоль управления
1. В консоли управления выберите каталог с вашим кластером Managed Service for Kubernetes.
2. Перейдите в сервис Managed Service for Kubernetes.
3. Выберите кластер Managed Service for Kubernetes.
4. Перейдите на вкладку Рабочая нагрузка, затем Pods.
5. Выберите под и перейдите на вкладку YAML.
6. Проверьте, содержит ли манифест пода указанные параметры и Kubernetes-метки в них:
  - Параметры:
    
    spec.nodeSelector
    
    spec.affinity
    
    spec.topologySpreadConstraints
  - Kubernetes-метки, заданные внутри параметров:
    
    failure-domain.beta.kubernetes.io/zone: <зона_доступности>
    
    topology.kubernetes.io/zone: <зона_доступности>
  Если в конфигурации есть хотя бы один из указанных параметров и он содержит хотя бы одну из перечисленных Kubernetes-меток, такая настройка будет препятствовать миграции группы узлов и рабочей нагрузки.
7. Проверьте, есть ли в манифесте пода зависимости от сущностей:
  - зоны доступности, из которой вы переносите ресурсы;
  - конкретных узлов в группе.
8. Если вы нашли указанные выше настройки, привязки и зависимости, удалите их из конфигурации пода:
  1. Скопируйте YAML-конфигурацию из консоли управления.
  2. Создайте локальный YAML-файл и вставьте в него конфигурацию.
  3. Удалите из нее привязки к зонам доступности. Например, если в параметре spec.affinity указана Kubernetes-метка failure-domain.beta.kubernetes.io/zone, удалите ее.
  4. Примените новую конфигурацию:
    
    kubectl apply -f <путь_до_YAML-файла>
  5. Убедитесь, что под перешел в статус Running:
    
    kubectl get pods
9. Проверьте таким образом каждый под и поправьте его конфигурацию.
Перенесите в новую зону доступности персистентные данные (например, базы данных, очереди сообщений, серверы мониторинга и логов).

Миграция stateless-нагрузки

Создайте подсеть в новой зоне доступности и перенесите группу узлов:
CLI

Terraform
1. Создайте подсеть:
  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.
2. Перенесите группу узлов в новую зону доступности. Ниже приведен пример команды для переноса группы, расположенной в одной зоне:
  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.
1. Внесите следующие изменения в конфигурационный файл:
  - Добавьте манифест новой подсети (ресурс 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 — идентификатор новой подсети.
2. Проверьте корректность конфигурационного файла.
  1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.
  2. Выполните команду:
    
    terraform validate
    
    Если в файлах конфигурации есть ошибки, Terraform на них укажет.
3. Подтвердите изменение ресурсов.
  1. Выполните команду для просмотра планируемых изменений:
    
    terraform plan
    
    Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
  2. Если вас устраивают планируемые изменения, внесите их:
    
    Выполните команду:
    
    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, чтобы предотвратить случайную потерю данных.
1. Получите название объекта PersistentVolume:
```
kubectl get pv
```
2. Отредактируйте объект PersistentVolume:
```
kubectl edit pv <название_PV>
```
Проверьте, содержит ли манифест объекта PersistentVolume параметр spec.nodeAffinity:
```
kubectl get pv <название_PV> --output='yaml'
```
Если манифест содержит параметр spec.nodeAffinity и в нем указана принадлежность к зоне доступности, сохраните этот параметр. Его понадобится указать в новом PersistentVolume.
Создайте снапшот — копию диска PersistentVolume на определенный момент времени. Подробнее о механизме снапшотов смотрите в документации Kubernetes.
1. Получите название объекта PersistentVolumeClaim:
```
kubectl get pvc
```
2. Создайте файл 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 было уникальным для каждого снапшота.
3. Создайте снапшот:
```
kubectl apply -f snapshot.yaml
```
4. Убедитесь, что снапшот создан:
```
kubectl get volumesnapshots.snapshot.storage.k8s.io
```
5. Убедитесь, что создан объект 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 применен этот параметр:
Консоль управления
1. В консоли управления выберите каталог с вашим кластером Managed Service for Kubernetes.
2. Перейдите в сервис Managed Service for Kubernetes.
3. Выберите кластер Managed Service for Kubernetes.
4. Перейдите на вкладку Постоянные тома, затем PersistentVolumes.
5. Найдите объект new-pv-test-<номер>.
  
  У найденного объекта посмотрите значение поля Зона доступности. В нем должна отображаться зона доступности. Прочерк означает, что нет привязки к зоне доступности.
Если в манифесте вы не указали параметр spec.nodeAffinity, вы можете добавить его. Для этого отредактируйте объект PersistentVolume:
```
kubectl edit pv new-pv-test-<номер>
```

Создайте объект PersistentVolumeClaim на основе нового объекта PersistentVolume:
1. Создайте файл 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.
2. Удалите исходный объект PersistentVolumeClaim, чтобы затем заменить его:
```
kubectl delete pvc <название_PVC>
```
3. Создайте объект PersistentVolumeClaim:
```
kubectl apply -f persistent-volume-claim.yaml
```
4. Убедитесь, что PersistentVolumeClaim создан:
```
kubectl get pvc
```
  В выводе команды для PersistentVolumeClaim будет указан размер, который вы задали в YAML-файле.
Создайте подсеть в новой зоне доступности и перенесите группу узлов:
CLI

Terraform
1. Создайте подсеть:
  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.
2. Перенесите группу узлов в новую зону доступности. Ниже приведен пример команды для переноса группы, расположенной в одной зоне:
  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.
1. Внесите следующие изменения в конфигурационный файл:
  - Добавьте манифест новой подсети (ресурс 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 — идентификатор новой подсети.
2. Проверьте корректность конфигурационного файла.
  1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.
  2. Выполните команду:
    
    terraform validate
    
    Если в файлах конфигурации есть ошибки, Terraform на них укажет.
3. Подтвердите изменение ресурсов.
  1. Выполните команду для просмотра планируемых изменений:
    
    terraform plan
    
    Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
  2. Если вас устраивают планируемые изменения, внесите их:
    
    Выполните команду:
    
    terraform apply
    
    Подтвердите изменение ресурсов.
    
    Дождитесь завершения операции.
Узлы группы будут пересозданы в указанной зоне доступности и подсети. При пересоздании учитываются настройки развертывания — максимальное количество узлов, на которое разрешается увеличить или уменьшить размер группы по сравнению с исходным количеством узлов.
Верните прежнее количество подов контроллера StatefulSet:
```
kubectl scale statefulset <название_контроллера> --replicas=<количество_подов>
```
Поды запустятся в перенесенной группе узлов.

В команде укажите параметры:
- Название контроллера StatefulSet. Его можно получить с помощью команды kubectl get statefulsets.
- Количество подов, которое было до масштабирования контроллера.
Убедитесь, что поды запущены в перенесенной группе узлов:
```
kubectl get po --output wide
```
Вывод команды показывает, в каких узлах запущены поды.
Удалите неиспользуемый объект PersistentVolume (в статусе Released).
1. Получите название объекта PersistentVolume:
```
kubectl get pv
```
2. Удалите объект 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
```
Удалите старую группу узлов.

Миграция ресурсов Kubernetes в другую зону доступности

Перед началом работыПеред началом работы

Необходимые платные ресурсыНеобходимые платные ресурсы

Перенесите мастер в другую зону доступностиПеренесите мастер в другую зону доступности

Миграция высокодоступного мастераМиграция высокодоступного мастера

Восстановите доступность вебхуков CiliumВосстановите доступность вебхуков Cilium

Перенесите группу узлов и рабочую нагрузку в подах в другую зону доступностиПеренесите группу узлов и рабочую нагрузку в подах в другую зону доступности

Подготовительные действияПодготовительные действия

Миграция stateless-нагрузкиМиграция stateless-нагрузки

Миграция stateful-нагрузкиМиграция stateful-нагрузки

Постепенная миграция stateless- и stateful-нагрузкиПостепенная миграция stateless- и stateful-нагрузки

Была ли статья полезна?