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

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

  • Статья

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

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

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

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

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

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

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

Решение

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

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

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

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

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

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

У меня возникают спорадические сбои исходящего подключения из-за нехватки портов SNAT

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

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

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

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

  1. Create минимальное количество пулов узлов в кластере (так как максимальное число узлов пула узлов составляет 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

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

Чтобы устранить эту проблему, см. статью Увеличение региональных квот виртуальных ЦП.

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

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

Решение

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

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

Чтобы создать внутреннюю подсистему балансировки нагрузки, создайте манифест службы с именем 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-адресов.

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

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

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

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