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

Мақала
10/31/2024

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

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

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

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

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

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

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

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

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

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

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

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

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

Разделы справки задать новое поведение Cordon?

Используйте предварительную версию cli и установите aks-preview расширение 9.0.0b3 или более поздней версии.

Для обновления или установки aks-preview расширения можно использовать следующие команды:

az extension update --name aks-preview

az extension add --name aks-preview

Обновите поведение неуправляемого узла пула узлов следующим образом Cordon:

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 nodes --show-labels=true

Заблокированные узлы незапланированы для модулей pod и помечены меткой "kubernetes.azure.com/upgrade-status: Quarantined". Максимальное количество узлов, которые можно оставить заблокированными, не может превышать Max-Surge значение.

Разделы справки удалить заблокированные узлы?

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

kubectl delete pdb nginx-pdb
poddisruptionbudget.policy "nginx-pdb" deleted.

Затем удалите заблокированный узел с помощью az aks nodepool delete-machines команды. Эта команда полезна, если вы планируете сократить объем ресурсов пула узлов, удалив узлы, оставленные в более ранних версиях.

az aks nodepool delete-machines --cluster-name MyCluster --machine-names aks-nodepool1-test123-vmss000000 --name nodepool1 --resource-group TestRG

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

Пример команды:

az aks update --resource-group TestRG --name MyCluster

Кроме того, можно масштабировать пул узлов до того же количества узлов, что и количество обновленных узлов. Это действие гарантирует, что пул узлов получает свой исходный размер. AKS определяет удаление заблокированных узлов. Эта команда также восстанавливает состояние Succeededподготовки кластера в . В приведенном 2 примере — общее количество обновленных узлов.

az aks nodepool scale --resource-group TestRG --cluster-name MyCluster --name nodepool1 --node-count 2

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

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

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

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

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

Бөлісу құралы: