Варианты обновления кластеров Службы Azure Kubernetes (AKS)

Статья
2025-04-03

В этой статье рассматриваются различные варианты обновления кластеров AKS. Сведения об обновлении базовой версии Kubernetes см. в статье Об обновлении кластера AKS.

Обновление кластеров AKS, использующих несколько пулов узлов или узлов Windows Server, описано в разделе Обновление пула узлов в AKS. Сведения об обновлении определенного пула узлов без обновления кластера Kubernetes см. в статье Об обновлении определенного пула узлов.

Выполнение обновлений вручную

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

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

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

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

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

Особые рекомендации по пулам узлов, охватывающим несколько зон доступности

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

Утверждения сохраняемого тома (PVCs), поддерживаемые локально избыточными дисками хранилища Azure (LRS), привязаны к определенной зоне и могут не восстановиться немедленно, если узел всплеска не соответствует зоне ПВХ. Если зоны не соответствуют, это может привести к простою вашего приложения, когда операция обновления продолжает освобождать узлы, но PV привязаны к зоне. Чтобы справиться с этим случаем и обеспечить высокий уровень доступности, настройте бюджет прерываний Pod в приложении, чтобы разрешить Kubernetes соблюдать требования к доступности во время процесса освобождения.

Оптимизация для неуправляемого поведения узлов (предварительная версия)

Вы можете настроить поведение процесса обновления в случае сбоев дренажа. Поведение обновления по умолчанию Schedule состоит в сбое очистки узлов, что приводит к сбою операции обновления, оставляя неочищенные узлы в состоянии, в котором они могут быть распределены для задач. В качестве альтернативы, можно выбрать вариант поведения Cordon, который пропускает узлы, которые не удается освободить, помещая их в карантинное состояние, помечает их kubernetes.azure.com/upgrade-status:Quarantined и продолжает обновление оставшихся узлов. Это поведение гарантирует, что все узлы будут обновлены или помещены в карантин. Этот подход позволяет устранять сбои очистки и корректно управлять карантинными узлами.

Установить новое поведение кордона

Чтобы задать новое поведение кордона, необходимо использовать aks-preview расширение 9.0.0b3 или более поздней версии.

Установите или обновите aks-preview расширение с помощью команды [az extension add][az-extension-add] или [az extension update][az-extension-update]:
```
# Install the aks-preview extension
az extension add --name aks-preview

# Update the aks-preview extension to the latest version
az extension update --name aks-preview
```
Обновите поведение неудаляемого узла в пуле узлов на Cordon, используя команду [az aks nodepool update][az-aks-nodepool-update].
```
az aks nodepool update --cluster-name $CLUSTER_NAME --name $NODE_POOL_NAME --resource-group $RESOURCE_GROUP --max-surge 1 --undrainable-node-behavior Cordon
```
В следующем примере выходных данных показано, как обновлено поведение неуправляемого узла:
```
"upgradeSettings": {
    "drainTimeoutInMinutes": null,
    "maxSurge": "1",
    "nodeSoakDurationInMinutes": null,
    "undrainableNodeBehavior": "Cordon"
  }
```
Проверьте метку на любом из заблокированных узлов при сбое узла дренажа во время обновления, используя команду kubectl get.
```
kubectl get nodes --show-labels=true
```
Заблокированные узлы незапланированы для модулей pod и помечены меткой "kubernetes.azure.com/upgrade-status: Quarantined". Максимальное количество узлов, которые можно оставить заблокированными, не может превышать Max-Surge значение.

Устранение неудаляемых узлов

Сначала устраните основную проблему, вызывающую слив. В следующем примере удаляется ответственный PDB:
```
kubectl delete pdb nginx-pdb
poddisruptionbudget.policy "nginx-pdb" deleted.
```
Если вы уверены, что проблема устранена, вы можете удалить "kubernetes.azure.com/upgrade-status: Quarantined" метку, размещенную на неуправляемых узлах с помощью kubectl label команды.
```
kubectl label nodes <node-name> <label-key>-
```
Любые последующие операции PUT будут сначала пытаться согласовать Failed Provisioning Status с кластером Success. Узлы, помещенные в карантин, не будут рассматриваться для последующего добавления или согласования. Необходимо явно удалить метки, чтобы заблокированные узлы могли быть рассмотрены, как упоминалось ранее.
Вы также можете удалить заблокированный узел с помощью команды [az aks nodepool delete-machines][az-aks-nodepool-delete-machines]. Эта команда полезна, если вы планируете сократить объем ресурсов пула узлов, удалив узлы, оставленные в более ранних версиях.
```
az aks nodepool delete-machines --cluster-name $CLUSTER_NAME --machine-names aks-$NODE_POOL_NAME-test123-vmss000000 --name $NODE_POOL_NAME --resource-group $RESOURCE_GROUP
```
После выполнения этого шага можно выполнить согласование состояния кластера, выполнив любую операцию обновления без необязательных полей, как описано здесь. Кроме того, можно масштабировать пул узлов до того же количества узлов, что и количество обновленных узлов. Это действие гарантирует, что пул узлов получает свой исходный размер. AKS уделяет приоритетное внимание удалению заблокированных узлов. Эта команда также восстанавливает состояние подготовки кластера на Succeeded. В приведенном 2 примере — общее количество обновленных узлов.
```
# Update the cluster to restore the provisioning status
az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME

# Scale the node pool to restore the original size
az aks nodepool scale --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME --name $NODE_POOL_NAME --node-count 2 
```

Оптимизация обновлений для повышения производительности и минимизации сбоев

Сочетание запланированного периода обслуживания, максимального увеличения нагрузки, бюджета сбоя pod, времени ожидания очистки узлов и времени ожидания узла может значительно увеличить вероятность успешного завершения обновления узла к концу периода обслуживания, а также минимизируя сбои.

Период планового обслуживания позволяет группам служб запланировать автоматическое обновление во время предопределенного окна, как правило, период низкого трафика, чтобы свести к минимуму влияние рабочей нагрузки. Рекомендуемая длительность окна составляет по крайней мере четыре часа.
Максимальное увеличение нагрузки в пуле узлов позволяет запрашивать дополнительную квоту во время процесса обновления и ограничивает количество узлов, выбранных для одновременного обновления. Более высокий максимальный всплеск приводит к более быстрому обновлению. Не рекомендуется устанавливать его на 100 %, так как он обновляет все узлы одновременно, что может привести к сбоям в работе приложений. Рекомендуем установить максимальную квоту на всплеск в 33% для производственных пулов узлов.
Максимальная недоступность (предварительная версия) в пуле узлов позволяет выполнять обновления путем оцепления существующих узлов и очистки без добавления узлов всплеска. Более высокий максимальный уровень недоступности приводит к более быстрому обновлению, но также приводит к большему нарушению рабочей нагрузки для пула узлов. Эта функция рекомендуется для клиентов, сталкивающихся с ограничениями емкости, из-за нехватки дополнительной емкости SKU в регионе или квоте.
Pod Disruption Budget устанавливается для сервисных приложений и ограничивает количество pod, которые могут быть неактивны во время добровольных прерываний, таких как обновления узлов, управляемых AKS. Его можно настроить как minAvailable реплик, указывая минимальное количество под, которые должны быть активными, или как maxUnavailable реплик, указывая максимальное количество под, которые могут быть завершены, обеспечивая высокий уровень доступности для приложения. См. руководство по настройке бюджетов нарушений Pod. Значения PDB должны быть проверены, чтобы определить параметры, которые лучше всего работают для конкретной службы.
Таймаут очистки узлов в пуле узлов позволяет настроить продолжительность ожидания для завершения подов и корректного завершения работы на каждом узле во время обновления. Этот параметр полезен при работе с длительными рабочими нагрузками. Если указано время ожидания очистки узла (в минутах), AKS учитывает бюджет нарушения работоспособности подов. Если это не указано, время ожидания по умолчанию — 30 минут.
Время проверки узла помогает распределять обновления узлов по времени в контролируемом порядке и может свести к минимуму время простоя приложения во время обновления. Вы можете указать время ожидания, желательно как можно ближе к 0 минутам, чтобы проверить готовность приложения между обновлениями узлов. Если значение не указано, значение по умолчанию — 0 минут. Время ожидания узла работает вместе с свойствами максимального времени ожидания всплеска и истечения времени ожидания узла, доступными в пуле узлов, чтобы обеспечить правильные результаты с точки зрения скорости обновления и доступности приложений.

настройки обновления	Доступные ресурсы для увеличения мощности	Ожидаемое поведение
`maxSurge` = `5` `maxUnavailable` = `0`	5 узлов, доступных для очистки	Для обновления пула узлов потребуется 5 узлов.
`maxSurge` = `5` `maxUnavailable` = `0`	0-4 узла, доступных для расширения	Операция обновления завершается ошибкой из-за отсутствия достаточного количества узлов для удовлетворения `maxSurge`.
`maxSurge` = `0` `maxUnavailable` = `5`	N/A, так как не требуются узлы всплеска	Операция использует 5 узлов из существующего пула узлов, не добавляя новые узлы для обновления пула узлов.

Проверки, используемые в процессе обновления сегодня

При запуске операции обновления с помощью API, Azure CLI или портала Azure Служба Azure Kubernetes (AKS) выполняет ряд проверок перед началом обновления. Эти проверки гарантируют, что кластер находится в работоспособном состоянии и может успешно обновиться.

Критические изменения API: определяет, существуют ли устаревшие API, которые могут повлиять на рабочие нагрузки.
Версия обновления Kubernetes: Убедитесь, что целевая версия действительна (например, переходы не превышают три минорные версии, нет понижения и обеспечивается совместимость с управляющей плоскостью).
Неправильная проверка конфигурации PDB: проверяет наличие неправильно настроенных бюджетов нарушения под (PDB), таких как maxUnavailable = 0 который не позволяет нарушать узлы.
Квота: Подтверждает наличие достаточной квоты для увеличения количества узлов, необходимых во время процесса обновления.
Подсеть: проверяет, есть ли достаточно доступных IP-адресов для обновления или если необходимы корректировки размера подсети.
Сертификаты/Служебные учётные записи: обнаруживает просроченные сертификаты или служебные учётные записи, что может повлиять на процесс обновления.

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

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

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