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

Сводка

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

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

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

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

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

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

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

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

• Чтобы спланировать виртуальную сеть и подсети для размещения количества узлов и подов, которые вы развертываете, см. подробнее о планировании 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

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

• Виртуальные машины семейства SKU серии B не поддерживаются AKS в системном узле и могут испытывать низкую производительность во время и после обновлений.
• Проверьте параметры ресурсов PDB развертывания, чтобы убедиться, что они точны для успешного обновления. Для получения дополнительной информации см. рекомендации по рабочей нагрузке AKS.

Мое обновление достигает предела квоты (5,000 кластеров)

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

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

Обновления пула сервера Standard Load Balancer (SLB) являются известной проблемой производительности. Мы работаем над новой возможностью, которая позволит ускорить создание служб и Server Load Balancer (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. Корпорация Microsoft не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.