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

Распространенные проблемы при запуске или масштабировании крупных кластеров AKS: вопросы и ответы

  • Статья

В этой статье приводятся ответы на часто задаваемые вопросы о распространенных проблемах, которые могут возникнуть при запуске или масштабировании крупных кластеров в Microsoft Служба Azure Kubernetes (AKS). Большой кластер — это любой кластер, работающий на более чем 500 узлах.

При создании, масштабировании или обновлении возникает ошибка "превышена квота"

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

При развертывании кластера AKSsize, использующего расширенную сеть, возникает ошибка "недостаточной сети"

Эта ошибка означает, что подсеть, используемая для кластера, больше не имеет доступных IP-адресов в ciDR для успешного назначения ресурсов. Эта проблема может возникать во время обновления, горизонтального масштабирования или создания пула узлов. Эта проблема возникает из-за того, что число свободных IP-адресов в подсети меньше результата следующей формулы:

количество запрошенных узлов * значение пула --max-pod узлов

Предварительные требования

  • Чтобы увеличить масштаб до 400 узлов, необходимо использовать подключаемый модуль сети Azure CNI.

  • Чтобы спланировать виртуальную сеть и подсети для размещения количества узлов и модулей pod, которые вы развертываете, см . сведения о планировании IP-адресов для кластера. Сведения о снижении затрат на планирование подсети или повторное создание кластера из-за нехватки IP-адресов см. в разделе Динамическое выделение IP-адресов.

Решение

Так как вы не можете обновить диапазон CIDR существующей подсети, необходимо иметь разрешение на создание новой подсети для устранения этой проблемы. Выполните следующие действия:

  1. Перестройте новую подсеть с большим диапазоном CIDR, достаточной для целей операций.

  2. Создайте новую подсеть с новым не перекрывающимся диапазоном.

  3. Создайте новый пул узлов в новой подсети.

  4. Очистка модулей pod из старого пула узлов, который находится в старой подсети, которая будет заменена.

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

Из-за нехватки портов SNAT у меня возникают проблемы с исходящим исходящим трафиком

Для кластеров, работающих в относительно большом масштабе (более 500 узлов), рекомендуется использовать шлюз преобразования управляемых сетевых адресов AKS (NAT) для повышения масштабируемости. Шлюз NAT Azure поддерживает до 64 512 исходящих потоков UDP и TCP-трафика на IP-адрес и не более 16 IP-адресов.

Если вы не используете управляемый NAT, см . статью "Устранение неполадок с исчерпанием исходного сетевого адреса (SNAT) и временем ожидания подключения, чтобы понять и устранить проблемы с исчерпанием портов SNAT.

Невозможно масштабировать до 5000 узлов с помощью портал Azure

Используйте Azure CLI для масштабирования до 5 000 узлов, выполнив следующие действия.

  1. Создайте минимальное количество пулов узлов в кластере (так как максимальный предел узла пула узлов составляет 1000), выполнив следующую команду:

    az aks nodepool add --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

  2. Масштабирование пулов узлов по одному за раз. В идеале установите пять минут времени сна между последовательными масштабированием 1000. Выполните следующую команду:

    az aks nodepool scale --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

Обновление выполняется, но это медленно

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

  • Создание одного нового узла.
  • Масштабирование пула узлов за пределами требуемого количества узлов по одному узлу.

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

При обновлении кластеров с большим количеством узлов может потребоваться несколько часов для обновления всего кластера, если используется значение max-surgeпо умолчанию. Вы можете настроить max-surge свойство для пула узлов, чтобы обеспечить компромисс между скоростью обновления и прерыванием обновления. Увеличив максимальное значение всплеска, можно быстрее завершить процесс обновления. Однако большое значение для максимального всплеска также может привести к сбоям во время процесса обновления.

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

az aks nodepool update --resource-group MyResourceGroup --name mynodepool --cluster-name MyManagedCluster --max-surge 5

Также важно учитывать, как параметры развертывания могут отложить завершение операции обновления или масштабирования:

Совет

Чтобы получить дополнительные сведения об этом поведении, вы можете просмотреть сведения об ошибке на странице журнала действий в портал Azure или просмотреть журналы ресурсов в кластере.

Мое обновление достигает квоты (5000 кластеров)

Сведения об устранении этой проблемы см. в разделе "Увеличение квот виртуальных ЦП регионов".

Создание внутренней службы на более чем 750 узлах замедляется или завершается сбоем из-за ошибки времени ожидания

обновления внутреннего пула Load Balancer (цен. категория (SLB) являются известным узким местом производительности. Мы работаем над новой возможностью, которая позволит ускорить создание служб и SLB в масштабе. Чтобы отправить нам отзыв об этой проблеме, ознакомьтесь с поддержкой Azure Kubernetes для подсистемы балансировки нагрузки с помощью внутреннего пула на основе IP-адресов.

Решение

Рекомендуется уменьшить масштаб кластера до менее 750 узлов, а затем создать внутреннюю подсистему балансировки нагрузки для кластера. Чтобы создать внутреннюю подсистему балансировки нагрузки, создайте LoadBalancer тип службы и azure-load-balancer-internal заметку для следующей процедуры.

Шаг 1. Создание внутренней подсистемы балансировки нагрузки

Чтобы создать внутреннюю подсистему балансировки нагрузки, создайте манифест службы с именем internal-lb.yaml и содержащий LoadBalancer тип службы и azure-load-balancer-internal заметку, как показано в следующем примере:

apiVersion: v1
kind: Service
metadata:
  name: internal-app
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: internal-app

Шаг 2. Развертывание внутренней подсистемы балансировки нагрузки

Разверните внутреннюю подсистему балансировки нагрузки с помощью kubectl apply команды и укажите имя манифеста YAML, как показано в следующем примере:

kubectl apply -f internal-lb.yaml

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

Создание службы SLB в масштабе занимает несколько часов.

Обновления внутреннего пула SLB являются известным узким местом производительности. Мы работаем над новой возможностью, которая позволит выполнять службы с балансировкой нагрузки в масштабе с значительно более высокой производительностью для создания, обновления и удаления операций. Чтобы отправить нам отзыв, ознакомьтесь с поддержкой Azure Kubernetes для подсистемы балансировки нагрузки с помощью внутреннего пула на основе IP-адресов.

Заявление об отказе от ответственности за сведения о продуктах сторонних производителей

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

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.