Поделиться через


Практическое руководство по обновлению кластера Службы Azure Kubernetes (AKS)

В рамках жизненного цикла кластера AKS выполняется периодическое обновление до последней версии Kubernetes. Важно применить последние выпуски и обновления системы безопасности, чтобы получить последние возможности. В этой статье показано, как проверить и применить обновления к кластеру AKS.

Обновления версий Kubernetes

При обновлении поддерживаемого кластера AKS нельзя пропустить дополнительные версии Kubernetes. Необходимо выполнить все обновления последовательно по номеру младшей версии. Например, разрешены обновления между 1.14.x ->1.15.x или 1.15.x ->. 1.14.x -> не разрешено. При обновлении с неподдерживаемой версии можно пропустить только несколько версий. Например, можно выполнить обновление с неподдерживаемой версии 1.10.x до поддерживаемой версии 1.12.x при наличии.

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

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

  • Если вы используете Azure CLI, для этой статьи требуется Azure CLI версии 2.34.1 или более поздней. Чтобы узнать версию, выполните команду az --version. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.
  • Если вы используете Azure PowerShell, для этой статьи требуется Azure PowerShell версии 5.9.0 или более поздней. Чтобы узнать версию, выполните команду Get-InstalledModule -Name Az. Если вам необходимо выполнить установку или обновление, см. статью об установке Azure PowerShell.
  • Для выполнения операций обновления требуется роль RBAC Microsoft.ContainerService/managedClusters/agentPools/write. Дополнительные сведения о ролях Azure RBAC см. в операциях поставщика ресурсов Azure.
  • Начиная с версии 1.30 kubernetes и версии 1.27 LTS бета-интерфейсы API будут отключены по умолчанию при обновлении до них.

Предупреждение

Обновление кластера AKS активирует изоляцию и освобождение узлов. Если ваша доступная квота вычислений низкая, обновление может завершиться ошибкой. Дополнительные сведения см. в разделе Запросы на увеличение квоты.

Проверка доступных обновлений кластера AKS

Примечание.

Чтобы получать актуальную информацию об исправлениях, выпусках и обновлениях AKS, см. Средство отслеживания выпуска AKS.

  • Проверьте, какие выпуски Kubernetes доступны для кластера с помощью az aks get-upgrades команды.

    az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table
    

    В следующем примере выходных данных показана текущая версия как 1.26.6 и перечислены доступные версии в разделе upgrades:

    {
      "agentPoolProfiles": null,
      "controlPlaneProfile": {
        "kubernetesVersion": "1.26.6",
        ...
        "upgrades": [
          {
            "isPreview": null,
            "kubernetesVersion": "1.27.1"
          },
          {
            "isPreview": null,
            "kubernetesVersion": "1.27.3"
          }
        ]
      },
      ...
    }
    

Устранение проблем с сообщениями об ошибках при обновлении кластера AKS

Пример вывода данных ниже указывает на то, что расширение appservice-kube несовместимо с вашей версией Azure CLI. Для работы требуется версия не ниже 2.34.1.

The 'appservice-kube' extension is not compatible with this version of the CLI.
You have CLI core version 2.0.81 and this extension requires a min of 2.34.1.
Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.

Если вы получите эти выходные данные, необходимо обновить версию Azure CLI. Команда az upgrade добавлена в версии 2.11.0 и не работает с предыдущими версиями. Вы можете обновить старые версии, переустановив Azure CLI, как описано в разделе "Установка Azure CLI". Если ваша версия Azure CLI 2.11.0 или более поздняя, выполните команду az upgrade, чтобы обновить Azure CLI до последней версии.

Если Azure CLI обновлен и вы получите следующий пример выходных данных, это означает, что обновления недоступны:

ERROR: Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.

Если обновления недоступны, создайте кластер с поддерживаемой версией Kubernetes и перенесите рабочие нагрузки из существующего кластера в новый. AKS не поддерживает обновление кластера до новой версии Kubernetes, когда az aks get-upgrades показывает, что обновления недоступны.

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

Во время процесса обновления кластера AKS выполняет следующие операции:

  • Добавит новый узел буфера (или столько узлов, сколько указано в параметре max_surge) в кластер, на котором запущена указанная версия Kubernetes.
  • Изолируйте и разгрузите один из старых узлов, чтобы свести к минимуму дискомфорт для работающих приложений. Если вы используете максимальный всплеск, он кордонирует и очищает столько узлов одновременно, сколько указанных буферных узлов.
  • Для длительно работающих капсул можно настроить тайм-аут на завершение работы узлов, который позволяет задать пользовательское время ожидания для вытеснения капсул и корректного завершения работы на каждом узле. Если значение не указано, значение по умолчанию — 30 минут. Минимально допустимое время ожидания — 5 минут. Максимальное время ожидания завершения сброса — 24 часа.
  • Когда старый узел полностью освобождён, его переустанавливают для получения новой версии, и он становится буферным узлом для следующего узла, подлежащего обновлению.
  • При необходимости можно задать длительность ожидания между очисткой узла и продолжением его повторного создания и перехода к следующему узлу. Короткий интервал позволяет выполнять другие задачи, такие как проверка работоспособности приложений с панели мониторинга Grafana во время процесса обновления. Мы рекомендуем короткий интервал времени для процесса обновления, как можно ближе к 0 минутам. В противном случае увеличенное время ожидания узла влияет на время, которое пройдет до обнаружения проблемы. Минимальное значение времени замачивания — 0 минут, максимальное — 30 минут. Если значение не указано, значение по умолчанию — 0 минут.
  • Этот процесс повторяется до обновления всех узлов в кластере.
  • В конце процесса удаляется последний буферный узел, поддерживая существующее число узлов агента и баланс зоны.

Примечание.

Если исправление не указано, кластер автоматически обновляется до последнего общедоступного исправления указанной младшей версии. Например, установка --kubernetes-version на 1.28 приводит к обновлению кластера до 1.28.9.

Дополнительные сведения см. в разделе Поддерживаемые обновления минорных версий Kubernetes в AKS.

  1. Обновите кластер с помощью az aks upgrade команды.

    az aks upgrade \
        --resource-group myResourceGroup \
        --name myAKSCluster \
        --kubernetes-version <KUBERNETES_VERSION>
    
  2. Убедитесь, что обновление выполнено успешно с помощью az aks show команды.

    az aks show --resource-group myResourceGroup --name myAKSCluster --output table
    

    В следующем примере выходных данных показано, что кластер теперь работает 1.27.3:

    Name          Location    ResourceGroup    KubernetesVersion    ProvisioningState    Fqdn
    ------------  ----------  ---------------  -------------------  -------------------  ----------------------------------------------
    myAKSCluster  eastus      myResourceGroup  1.27.3               Succeeded            myakscluster-dns-379cbbb9.hcp.eastus.azmk8s.io
    

Настройка канала автоматического обновления

Канал автоматического обновления можно задать в кластере. Дополнительные сведения см. в статье Автоматическое обновление кластера службы AKS.

Настройка обновления со всплеском активности узлов

Внимание

  • При всплеске активности узлов для каждой операции обновления требуется квота подписки, соответствующая запрошенному максимальному числу всплесков. Например, кластер с пятью пулами узлов, каждый из которых имеет количество четырех узлов, имеет в общей сложности 20 узлов. Если для каждого пула узлов задано максимальное значение всплеска активности в 50 %, то для завершения обновления потребуется дополнительная квота вычислений и IP-адресов, равная 10 узлам (2 узла * 5 пулов).

  • Параметр максимального всплеска активности для пула узлов является постоянным. Этот параметр будет использоваться для последующих обновлений Kubernetes или обновлений версии узлов. Максимальное значение всплеска для пулов узлов можно изменить в любое время. Для рабочих пулов узлов рекомендуется использовать значение max_surge, равное 33 %.

  • Если вы используете Azure CNI, проверьте наличие доступных IP-адресов в подсети для удовлетворения требований к IP-адресам Azure CNI.

AKS настраивает обновления для всплеска с одним дополнительным узлом по умолчанию. Значение one по умолчанию для параметра максимального всплеска позволяет AKS свести к минимуму прерывание рабочей нагрузки путем создания дополнительного узла до изоляции и очистки существующих приложений для замены узла с более старой версией. Можно настроить максимальное значение всплеска для каждого пула узлов. При увеличении максимального значения всплеска процесс обновления завершается быстрее, и во время процесса обновления могут возникнуть сбои.

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

AKS принимает целочисленные значения и процентное значение для параметра максимального всплеска активности. Например, целочисленное значение 5 указывает на пять дополнительных узлов для увеличения нагрузки. Процентное значение 50% означает увеличение в половину количества узлов в пуле. Минимальное значение процента всплеска может быть 1%, а максимальное — 100%. Процентное значение округляется до ближайшего числа узлов. Если максимальное значение всплеска превышает требуемое количество узлов, которое необходимо обновить, количество узлов, которые необходимо обновить, используется для максимального значения всплеска. Во время обновления максимальное значение всплеска может быть минимальным 0 и максимальным значением, равным количеству узлов в пуле узлов. Вы можете задать более крупные значения, но не можете установить максимальное количество узлов, используемых в процессе масштабирования, превышающее число узлов в пуле на момент обновления.

Установка максимального значения всплеска

  • Задайте максимальные значения всплеска для новых или существующих пулов узлов с помощью az aks nodepool add команды или az aks nodepool update команды.

    # Set max surge for a new node pool
    az aks nodepool add --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33%
    
    # Update max surge for an existing node pool 
    az aks nodepool update --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 5
    

Настройка недоступных узлов во время обновления (предварительная версия)

Внимание

  • Для задания maxUnavailable, необходимо установить maxSurge в 0. Два значения не могут быть активными одновременно.
  • maxUnavailable не будет создавать узлы всплеска во время процесса обновления. Вместо этого AKS помечает nmaxUnavailable узлов за раз и перемещает поды на другие узлы в пуле агентов. Это может привести к сбоям рабочей нагрузки, если модули pod не могут быть запланированы.
  • maxUnavailable Может привести к большим сбоям из-за несоответствия PodDisruptionBudgets (PDBS), так как для запланированных модулей pod будет меньше ресурсов. Если вы столкнулись с ошибками при использовании этой функции, пожалуйста, ознакомьтесь с инструкциями по устранению неполадок для PodDisruptionBudgets, чтобы найти рекомендации по их устранению.
  • Невозможно установить maxUnavailable на пул системных узлов.

AKS также может настроить обновления, чтобы не использовать узел всплеска и обновить узлы на месте. Это maxUnavailable значение можно использовать для определения количества узлов, которые можно объединять и удалять из существующих узлов пула узлов.

AKS принимает как целочисленные значения, так и процентное значение для maxUnavailable. Например, целочисленное значение 5 указывает, что пять узлов будут изолированы от существующих в пуле узлов. Процентное значение 50% указывает значение maxUnavailable, равное половине текущего количества узлов в пуле. maxUnavailable Проценты значений могут быть минимальными 1% и максимальными 100%. Процентное значение округляется до ближайшего числа узлов. Во время обновления значение maxUnavailable может быть не меньше 0 и не больше количества узлов в пуле узлов.

Задать значение maxUnavailable

  • Задайте maxUnvailable значения для новых или существующих пулов узлов с помощью az aks nodepool add команды или az aks nodepool update команды.

    # Set maxUnavailable for a new node pool
    az aks nodepool add --name mynodepool --resource-group myResourceGroup --cluster-name myManagedCluster --max-surge 0 --max-unavailable 5
    # Update maxUnavailable for an existing node pool 
    az aks nodepool update --name mynodepool --resource-group myResourceGroup --cluster-name myManagedCluster --max-surge 0 --max-unavailable 5
    # Set maxUnavailable at upgrade time for an existing node pool
    az aks nodepool upgrade --name mynodepool --resource-group myResourceGroup --cluster-name myManagedCluster --max-surge 0 --max-unavailable 5
    

Установка времени ожидания завершения операций на узле

Иногда у вас может быть длительная рабочая нагрузка на определенном pod, и её невозможно перенести на другой узел во время выполнения, например, рабочая нагрузка с интенсивным использованием памяти, которая должна завершиться. В этих случаях вы можете настроить время ожидания завершения обработки узлов, которое AKS будет учитывать при выполнении обновления. Если значение времени ожидания очистки узлов не указано, значение по умолчанию составляет 30 минут. Минимально допустимое время ожидания слива составляет 5 минут, а максимальный предел времени ожидания слива составляет 24 часа.

Если истекает время ожидания завершения работы модулей, и они продолжают выполняться, то операция обновления останавливается. Любая последующая операция PUT возобновляет остановленное обновление. Для длительных подов также рекомендуется настроить [terminationGracePeriodSeconds][https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/].

  • Установите тайм-аут очистки узлов для новых или существующих пулов узлов с помощью команды az aks nodepool add или команды az aks nodepool update.

    # Set drain time-out for a new node pool
    az aks nodepool add --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster  --drain-time-out 100
    
    # Update drain time-out for an existing node pool
    az aks nodepool update --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --drain-time-out 45
    

Установка значения времени пропитки узла

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

  • Установите время ожидания для новых или существующих пулов узлов, используя команду az aks nodepool add, az aks nodepool update или az aks nodepool upgrade.

    # Set node soak time for a new node pool
    az aks nodepool add --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --node-soak-duration 10
    
    # Update node soak time for an existing node pool
    az aks nodepool update --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% --node-soak-duration 5
    
    # Set node soak time when upgrading an existing node pool
    az aks nodepool upgrade --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% --node-soak-duration 20
    

Обновление через значительное изменение версий

При обновлении с неподдерживаемой версии Kubernetes до поддерживаемой версии важно протестировать рабочие нагрузки в целевой версии. Хотя AKS будет прилагать все усилия для обновления контрольной и пользовательской плоскостей, нет гарантии, что ваши рабочие нагрузки будут функционировать и дальше. Если ваши рабочие нагрузки зависят от устаревших API Kubernetes, платформа внесла изменения, которые могут привести к сбоям или изменению поведения (подробности задокументированы в заметках о выпуске AKS), их следует устранить.

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

Распространенный шаблон в этой ситуации заключается в том, чтобы выполнить синее или зеленое развертывание измененных рабочих нагрузок в новый кластер, который находится в поддерживаемой версии Kubernetes, и перенаправить запросы к новому кластеру.

Просмотр событий обновления

  • Просмотр событий обновления с помощью kubectl get events команды.

    kubectl get events 
    

    В следующем примере выходных данных показаны некоторые из перечисленных выше событий во время обновления:

    ...
    default 2m1s Normal Drain node/aks-nodepool1-96663640-vmss000001 Draining node: [aks-nodepool1-96663640-vmss000001]
    ...
    default 1m45s Normal Upgrade node/aks-nodepool1-96663640-vmss000001   Soak duration 5m0s after draining node: aks-nodepool1-96663640-vmss000001
    ...
    default 9m22s Normal Surge node/aks-nodepool1-96663640-vmss000002 Created a surge node [aks-nodepool1-96663640-vmss000002 nodepool1] for agentpool nodepool1
    ...
    

Следующие шаги

Сведения о настройке автоматического обновления см. в статье "Настройка автоматических обновлений" для кластера AKS.

Подробное обсуждение рекомендаций по улучшению и других факторов см. в руководстве по исправлению и обновлению AKS.