Связаться с намиПодключиться

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

Статья создана
Обновлена 15 ноября 2024 г.

Примечание

Зона доступности ru-central1-c поэтапно выводится из эксплуатации. Подробнее о планах по развитию зон доступности и возможностях миграции см. пост в блоге Yandex Cloud.

Чтобы перенести ресурсы Managed Service for Kubernetes из одной зоны в другую:

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

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

Если у вас еще нет интерфейса командной строки 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.

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

  1. Создайте подсеть в зоне доступности 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.

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

    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.

  1. В файле с конфигурацией кластера обновите формат блока с параметрами расположения кластера (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"
      }
   }
   ...
}

  2. Убедитесь, что изменений в параметрах ресурсов Terraform не обнаружено:

    terraform plan

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

  3. В файл с конфигурацией кластера добавьте манифест новой сети и измените местоположение кластера:

    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.

  4. Проверьте корректность конфигурационного файла.

    1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

    2. Выполните команду:

      terraform validate

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

  5. Подтвердите изменение ресурсов.

    1. Выполните команду для просмотра планируемых изменений:

      terraform plan

      Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.

    2. Если вас устраивают планируемые изменения, внесите их:

      1. Выполните команду:

        terraform apply

      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

Миграция регионального мастера

Региональный мастер создается распределенно в трех подсетях в разных зонах доступности. Для регионального мастера вы можете изменить только одну зону доступности: с ru-central1-c на ru-central1-d. Для миграции указываются три подсети и зоны доступности. Во время миграции работа мастера не прерывается, кластер и группа узлов не пересоздаются.

Внутренний IP-адрес для регионального мастера назначается автоматически в одной из трех подсетей размещения. После миграции внутренний IP-адрес мастера сохраняется. Если этот IP-адрес был выделен в подсети зоны ru-central1-c, то мастер переносится в зону ru-central1-d с прежним IP-адресом, зарезервированным в старой подсети. Такую подсеть нельзя удалить, но в дальнейшем вы сможете перенести ее в новую зону доступности, либо она будет перенесена автоматически в зону ru-central1-d после закрытия зоны ru-central1-c.

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

  1. Создайте подсеть в зоне доступности 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.

  2. Переместите мастер в другой набор зон доступности:

    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.

  1. В файле с конфигурацией кластера обновите формат блока с параметрами расположения кластера (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
      }
   }
   ...
}

  2. Убедитесь, что изменений в параметрах ресурсов Terraform не обнаружено:

    terraform plan

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

  3. В файл с конфигурацией кластера добавьте манифест новой подсети и измените местоположение кластера:

    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.

  4. Проверьте корректность конфигурационного файла.

    1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

    2. Выполните команду:

      terraform validate

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

  5. Подтвердите изменение ресурсов.

    1. Выполните команду для просмотра планируемых изменений:

      terraform plan

      Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.

    2. Если вас устраивают планируемые изменения, внесите их:

      1. Выполните команду:

        terraform apply

      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

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

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

  • Миграция непосредственно группы узлов в новую зону доступности. Зависит от вида рабочей нагрузки в подах:

    • Stateless-нагрузка — работа приложений в подах во время миграции зависит от распределения нагрузки между узлами кластера. Если поды находятся в мигрирующей группе узлов и группах, для которых не меняется зона доступности, приложения продолжают работать. Если поды находятся только в мигрирующей группе, поды и приложения в них придется остановить на короткий срок.

      Примеры stateless-нагрузки: веб-сервер, Ingress-контроллер Yandex Application Load Balancer, приложение REST API.

    • Stateful-нагрузка — независимо от распределения нагрузки между узлами кластера поды и приложения придется остановить на короткий срок.

      Примеры stateful-нагрузки: базы данных, хранилища.

  • Постепенная миграция stateless- и stateful-нагрузки в новую группу узлов. Заключается в создании новой группы узлов в новой зоне доступности и постепенном отключении старых узлов. Так вы можете контролировать перенос нагрузки.

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

  1. Проверьте, используются ли стратегии nodeSelector, affinity или topology spread constraints для привязки подов к узлам группы. Подробнее о стратегиях см. в документации Kubernetes и разделе Высокая доступность и отказоустойчивость. Чтобы проверить привязку пода к узлам и убрать ее:

    1. В консоли управления выберите каталог с вашим кластером Managed Service for Kubernetes.

    2. В списке сервисов выберите Managed Service for Kubernetes.

    3. Перейдите на страницу кластера, затем — в раздел Рабочая нагрузка.

    4. На вкладке Поды откройте страницу пода.

    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. Проверьте таким образом каждый под и поправьте его конфигурацию.

  2. Перенесите в новую зону доступности персистентные данные (например, базы данных, очереди сообщений, серверы мониторинга и логов).

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

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

    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. Если вас устраивают планируемые изменения, внесите их:

        1. Выполните команду:

          terraform apply

        2. Подтвердите изменение ресурсов.

        3. Дождитесь завершения операции.

    Узлы группы будут пересозданы в указанной зоне доступности и подсети. При пересоздании учитываются настройки развертывания — максимальное количество узлов, на которое разрешается увеличить или уменьшить размер группы по сравнению с исходным количеством узлов.

  2. Убедитесь, что поды запущены в перенесенной группе узлов:

    kubectl get po --output wide

    Вывод команды показывает, в каких узлах запущены поды.

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

Миграция основана на масштабировании контроллера StatefulSet. Чтобы перенести рабочую stateful-нагрузку:

  1. Получите список контроллеров StatefulSet, чтобы узнать название нужного контроллера:

    kubectl get statefulsets

  2. Узнайте количество подов контроллера:

    kubectl get statefulsets <название_контроллера> \
   -n default -o=jsonpath='{.status.replicas}'

    Сохраните полученное значение. Оно понадобится в конце миграции stateful-нагрузки для масштабирования контроллера StatefulSet.

  3. Уменьшите количество подов до нуля:

    kubectl scale statefulset <название_контроллера> --replicas=0

    Так вы выключите поды, которые используют диски. При этом сохранится объект API Kubernetes PersistentVolumeClaim (PVC).

  4. Для объекта PersistentVolume (PV), связанного с PersistentVolumeClaim, измените значение параметра persistentVolumeReclaimPolicy с Delete на Retain, чтобы предотвратить случайную потерю данных.

    1. Получите название объекта PersistentVolume:

      kubectl get pv

    2. Отредактируйте объект PersistentVolume:

      kubectl edit pv <название_PV>

  5. Проверьте, содержит ли манифест объекта PersistentVolume параметр spec.nodeAffinity:

    kubectl get pv <название_PV> --output='yaml'

    Если манифест содержит параметр spec.nodeAffinity и в нем указана принадлежность к зоне доступности, сохраните этот параметр. Его понадобится указать в новом PersistentVolume.

  6. Создайте снапшот — копию диска 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

  7. Получите идентификатор снапшота:

    yc compute snapshot list

  8. Создайте диск виртуальной машины из снапшота:

    yc compute disk create \
   --source-snapshot-id <идентификатор_снапшота> \
   --zone <зона_доступности>

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

    Сохраните следующие параметры из вывода команды:

    • идентификатор диска в поле id;
    • тип диска в поле type_id;
    • размер диска в поле size.

  9. Создайте объект API Kubernetes PersistentVolume на основе нового диска:

    1. Создайте файл 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

    2. Создайте объект PersistentVolume:

      kubectl apply -f persistent-volume.yaml

    3. Убедитесь, что PersistentVolume создан:

      kubectl get pv

      В выводе команды появится объект new-pv-test-<номер>.

    4. Если в манифесте вы указали параметр spec.nodeAffinity, убедитесь, что для PersistentVolume применен этот параметр:

      1. В консоли управления выберите каталог с вашим кластером Managed Service for Kubernetes.
      2. В списке сервисов выберите Managed Service for Kubernetes.
      3. Перейдите на страницу кластера, затем — в раздел Хранилища.
      4. На вкладке Persistent Volumes найдите объект new-pv-test-<номер> и посмотрите значение поля Зона доступности. В нем должна отображаться зона доступности. Прочерк означает, что нет привязки к зоне доступности.

    5. Если в манифесте вы не указали параметр spec.nodeAffinity, вы можете добавить его. Для этого отредактируйте объект PersistentVolume:

      kubectl edit pv new-pv-test-<номер>

  10. Создайте объект 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-файле.

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

    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. Если вас устраивают планируемые изменения, внесите их:

        1. Выполните команду:

          terraform apply

        2. Подтвердите изменение ресурсов.

        3. Дождитесь завершения операции.

    Узлы группы будут пересозданы в указанной зоне доступности и подсети. При пересоздании учитываются настройки развертывания — максимальное количество узлов, на которое разрешается увеличить или уменьшить размер группы по сравнению с исходным количеством узлов.

  12. Верните прежнее количество подов контроллера StatefulSet:

    kubectl scale statefulset <название_контроллера> --replicas=<количество_подов>

    Поды запустятся в перенесенной группе узлов.

    В команде укажите параметры:

    • Название контроллера StatefulSet. Его можно получить с помощью команды kubectl get statefulsets.
    • Количество подов, которое было до масштабирования контроллера.

  13. Убедитесь, что поды запущены в перенесенной группе узлов:

    kubectl get po --output wide

    Вывод команды показывает, в каких узлах запущены поды.

  14. Удалите неиспользуемый объект PersistentVolume (в статусе Released).

    1. Получите название объекта PersistentVolume:

      kubectl get pv

    2. Удалите объект PersistentVolume:

      kubectl delete pv <название_PV>

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

Ниже представлена инструкция по постепенной миграции нагрузки из старой группы узлов в новую. Инструкцию по миграции объектов PersistentVolume и PersistentVolumeClaim см. в подразделе Миграция stateful-нагрузки.

  1. Создайте новую группу узлов Managed Service for Kubernetes в новой зоне доступности.

  2. Запретите запуск новых подов в старой группе узлов:

    kubectl cordon -l yandex.cloud/node-group-id=<идентификатор_старой_группы_узлов>

  3. Для каждого узла из старой группы узлов выполните команду:

    kubectl drain <имя_узла> --ignore-daemonsets --delete-emptydir-data

    Поды постепенно переместятся в новую группу узлов.

  4. Убедитесь, что поды запущены в новой группе узлов:

    kubectl get po --output wide

  5. Удалите старую группу узлов.

Предыдущая
Установка Time-Slicing GPUs
Следующая
Использование модулей Yandex Cloud в Terraform