Распространенные проблемы при запуске или масштабировании больших кластеров AKS: вопросы и ответы
В этой статье приведены ответы на часто задаваемые вопросы о распространенных проблемах, которые могут возникнуть при запуске или масштабировании больших кластеров в Microsoft Служба Azure Kubernetes (AKS). Большой кластер — это любой кластер, работающий в масштабе более 500 узлов.
При создании, масштабировании или обновлении появляется ошибка "Превышена квота"
Чтобы устранить эту проблему, создайте запрос на поддержку в подписке, в которой вы пытаетесь создать, масштабировать или обновить, и запросить квоту для соответствующего типа ресурса. Дополнительные сведения см. в разделе Квоты на региональные вычисления.
При развертывании кластера AKS, использующего расширенную сеть, возникает ошибка "insufficientSubnetSize"
Эта ошибка указывает, что подсеть, используемая для кластера, больше не имеет доступных IP-адресов в своем CIDR для успешного назначения ресурсов. Эта проблема может возникать во время обновления, масштабирования или создания пула узлов. Эта проблема возникает из-за того, что число бесплатных IP-адресов в подсети меньше, чем результат следующей формулы:
количество запрошенных узлов * значение пула
--max-pod
узлов
Предварительные условия
Чтобы масштабировать более 400 узлов, необходимо использовать подключаемый модуль сети Azure CNI.
Сведения о планировании виртуальной сети и подсетей с учетом количества развертываемых узлов и модулей pod см. в статье Планирование IP-адресов для кластера. Сведения о том, как сократить затраты на планирование подсети или повторное создание кластера из-за нехватки IP-адресов, см. в статье Динамическое выделение IP-адресов.
Решение
Так как вы не можете обновить диапазон CIDR существующей подсети, для решения этой проблемы необходимо иметь разрешение на создание новой подсети. Выполните следующие действия:
Перестройте новую подсеть с большим диапазоном CIDR, которого достаточно для операционных целей.
Create новую подсеть, которая имеет новый неперекрывающийся диапазон.
Create новый пул узлов в новой подсети.
Очистка модулей pod из старого пула узлов, который находится в старой подсети, которая будет заменена.
Удалите старую подсеть и старый пул узлов.
У меня возникают спорадические сбои исходящего подключения из-за нехватки портов SNAT
Для кластеров, работающих в относительно большом масштабе (более 500 узлов), рекомендуется использовать шлюз преобразования управляемых сетевых адресов AKS (NAT) для повышения масштабируемости. Шлюз Azure NAT обеспечивает до 64 512 исходящих потоков трафика UDP и TCP на КАЖДЫЙ IP-адрес и не более 16 IP-адресов.
Если вы не используете управляемый NAT, ознакомьтесь с разделом Устранение неполадок с нехваткой исходного сетевого адреса (SNAT) и истечением времени ожидания подключения , чтобы понять и устранить проблемы с нехваткой портов SNAT.
Не удается масштабировать до 5000 узлов с помощью портал Azure
Используйте Azure CLI для масштабирования до 5000 узлов, выполнив следующие действия.
Create минимальное количество пулов узлов в кластере (так как максимальное число узлов пула узлов составляет 1000), выполнив следующую команду:
az aks nodepool add --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster
Масштабируйте пулы узлов по одному. В идеале можно задать пять минут времени ожидания между последовательными увеличениями масштаба 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.
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по