Обновить кластер

Обновите кластер Stackland до новой версии с помощью ресурса Kubernetes TargetInstallationState. Обновление выполняется постепенно с эвакуацией нагрузки и перезагрузкой узлов.

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

1. Убедитесь, что у вас есть доступ к кластеру с правами администратора.

2. Проверьте текущую версию кластера:

   kubectl get targetinstallationstate main -o jsonpath='{.status.currentVersion}'
   

3. Узнайте, какие версии доступны для обновления. Список доступных версий зависит от того, подключен ли ваш кластер к интернету:

   • Кластер с доступом в интернет — доступные версии загружаются автоматически из реестра контейнеров Stackland.
   • Изолированный кластер — доступные версии определяются образами, загруженными в локальный реестр.

Выбрать релизный каналВыбрать релизный канал

Релизный канал определяет, какие версии Stackland доступны для обновления. По умолчанию используется канал stable.

Доступные каналы:

• stable — стабильные релизы для production-использования. Доступен всем клиентам по умолчанию.
• alpha — ранние релизы для тестирования новых функций. Доступ предоставляется по запросу.

Чтобы изменить релизный канал, отредактируйте ресурс PlatformConfig:

kubectl edit platformconfig main

В спецификации укажите нужный канал:

spec:
  releaseChannel: "stable"  # или "alpha"

Перед обновлением на 27.xПеред обновлением на 27.x

В Stackland 26.2 добавлена новая реализация Ingress-контроллера на основе Contour: предыдущая реализация на базе ingress-nginx больше не поддерживается. В Stackland 27 ingress-nginx будет исключен из поставки, поэтому мы предупреждаем вас об этих планах заранее. В релизах Stackland 26 ingress-nginx по-прежнему доступен для пользовательской нагрузки, но переход на новую реализацию нужно запланировать и осуществить до обновления на Stackland 27.

В большинстве случаев пользовательские манифесты Ingress с классом stackland-default продолжают работать, но специфичные для ingress-nginx аннотации nginx.ingress.kubernetes.io/* новый контроллер не поддерживает — их нужно убрать или заменить. Подробнее см. в разделе Проверить пользовательские ресурсы Ingress.

При этом действие оператора обязательно: без явного отключения предыдущей реализации Ingress-контроллера обновление на версию >= 27.0.0 не начнется.

Проверить пользовательские ресурсы IngressПроверить пользовательские ресурсы Ingress

Если в кластере есть пользовательские ресурсы Ingress:

1. Найдите пользовательские ресурсы Ingress:

   kubectl get ingress -A
   

2. Убедитесь, что у них указан spec.ingressClassName: stackland-default или поле отсутствует. В последнем случае используется класс по умолчанию.

3. Проверьте, что в аннотациях не используются ключи вида nginx.ingress.kubernetes.io/*, специфичные для nginx. Если такие аннотации есть, уберите их или замените на эквиваленты нового Ingress-контроллера платформы — иначе после обновления соответствующие правила не применятся.

Проверить работу приложения заранееПроверить работу приложения заранее

Пока кластер работает на 26.x, вы можете заранее убедиться, что пользовательский Ingress совместим с новым Ingress-контроллером платформы.

1. Во временной копии манифеста замените spec.ingressClassName: stackland-default на spec.ingressClassName: stackland-system и примените манифест:

   kubectl apply -f <имя_файла>.yaml
   

2. Проверьте доступность приложения. Есть два способа:

   • Проверка напрямую через IP, без DNS. Этот способ не зависит от DNS-пропагации и от размещения DNS-зоны домена приложения.

     1. Получите внешний IP LoadBalancer, обслуживающего класс stackland-system:

        kubectl get svc -A \
          -l app.kubernetes.io/name=contour,app.kubernetes.io/component=envoy
        

        Если селектор не подходит для вашей установки, найдите сервис типа LoadBalancer в неймспейсе Contour вручную.

     2. Выполните запрос к приложению, подставив полученный IP:

        curl --resolve <домен>:443:<внешний_IP_Envoy> https://<домен>/
        

   • Проверка по домену. Работает, только если DNS-зона делегирована — тогда запись домена переместится на LoadBalancer класса stackland-system автоматически. Учитывайте задержку DNS. Если вы используете свой DNS, домен продолжит указывать на предыдущий LoadBalancer, и такая проверка даст ложно-отрицательный результат — используйте способ с curl --resolve.

3. После проверки верните значение spec.ingressClassName обратно на stackland-default или удалите поле.

На 27.x этот шаг не нужен: класс stackland-default автоматически обслуживается новым Ingress-контроллером платформы.

Отключить предыдущую реализацию IngressОтключить предыдущую реализацию Ingress

1. Отключите предыдущую реализацию Ingress в ресурсе IngressConfig:

   kubectl patch ingressconfig main --type=merge \
     -p '{"spec":{"settings":{"nginx":{"enabled":false}}}}'
   

После отключения ingress-nginx существующие Ingress-контроллеры будут автоматически перезапущены поверх Contour.

1. Дождитесь, пока платформа переключится на единый Ingress-контроллер. Проверьте текущее состояние:

   kubectl get ingressconfig main -o jsonpath='{.status.ingress.observedIngress}'
   

kubectl get availablereleases main -o yaml

apiVersion: stackland.yandex.cloud/v1alpha1
kind: AvailableReleases
metadata:
  name: main
status:
  releases:
    - version: "26.1.0"
      ready: true
    - version: "26.1.1"
      ready: true

sladm pull --image-bundle full

sladm push --local-registry --kubeconfig=<путь_к_kubeconfig> --image-bundle-folder <имя_папки>-oci

kubectl get availablereleases main -o yaml

Проверить статус обновленияПроверить статус обновления

После применения манифеста вы можете отслеживать статус обновления:

kubectl get targetinstallationstate main

Пример вывода:

NAME   TARGET VERSION   CURRENT VERSION   PHASE     MESSAGE                           AGE
main   26.1.1           26.1.0            Running   Running upgrade to version 26.1.1 5m

Получить подробную информациюПолучить подробную информацию

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

kubectl describe targetinstallationstate main

В поле status отображается:

• currentVersion — текущая установленная версия.
• phase — фаза обновления:
  • Pending — обновление ожидает запуска.
  • Running — обновление выполняется.
  • Completed — обновление выполнено.
  • Failed — обновление завершилось с ошибкой.
• message — сообщение о текущем состоянии.
• jobName — имя задания Kubernetes, выполняющего обновление.
• lastUpdateTime — время последнего обновления статуса.

Просмотреть логи обновленияПросмотреть логи обновления

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

kubectl logs -n stackland-install job/<имя_задания>

Имя задания можно получить из поля status.jobName ресурса TargetInstallationState.