Рекомендации по повышению производительности и масштабированию для небольших и средних рабочих нагрузок в службе Azure Kubernetes (AKS)

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

В этой статье вы узнаете:

Автомасштабирование приложений и автомасштабирование инфраструктуры

Автомасштабирование приложений

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

Например, если существующий узел имеет место, но недостаточно IP-адресов в подсети, он может пропустить создание нового узла и сразу же начать запуск приложения в новом модуле pod.

Горизонтальное автомасштабирование podов

Реализация горизонтального автомасштабирования pod полезна для приложений с устойчивым и предсказуемым спросом на ресурсы. Горизонтальное автомасштабирование pod (HPA) динамически масштабирует количество реплик pod, которые эффективно распределяют нагрузку между несколькими модулями pod и узлами. Этот механизм масштабирования обычно наиболее выгоден для приложений, которые могут быть разложены на небольшие независимые компоненты, способные работать параллельно.

HPA предоставляет метрики использования ресурсов по умолчанию. Вы также можете интегрировать пользовательские метрики или использовать такие инструменты, как Kubernetes Event-Driven Autoscaler (KEDA) (предварительная версия). Эти расширения позволяют HPA принимать решения по масштабированию на основе нескольких перспектив и критериев, обеспечивая более целостное представление о производительности приложения. Это особенно полезно для приложений с различными сложными требованиями к масштабированию.

Автомасштабирование вертикального модуля Pod

Реализация автоматического масштабирования по вертикали pod полезна для приложений с изменяющимися и непредсказуемыми требованиями к ресурсам. Вертикальный автоскейлер подов (VPA) позволяет точно настраивать запросы ресурсов, включая CPU и память для отдельных подов, что обеспечивает точный контроль за распределением ресурсов. Эта степень детализации сводит к минимуму затраты ресурсов и повышает общую эффективность использования кластера. VPA также упрощает управление приложениями, автоматив выделение ресурсов, освобождая ресурсы для критически важных задач.

Автомасштабирование инфраструктуры

Автоматическое масштабирование кластера

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

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

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

Overprovisioning

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

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

1-buffer/1+traffic

Например, предположим, что вы хотите избежать достижения 100% использования процессора в вашем кластере. Вы можете выбрать 30% буфера для поддержания поля безопасности. Если вы ожидаете средний темп роста трафика в 40%, вы можете рассмотреть возможность перепланирования на 50%, как вычисленной по формуле:

1-30%/1+40%=50%

Эффективный метод оверпровижининга включает использование модулей приостановки. Модели паузы — это низкоприоритетные развёртывания, которые можно легко заменить высокоприоритетными развёртываниями. Вы создаете низкоприоритетные pod, которые служат единственной цели — резервированию буферного пространства. Если для высокоприоритетного модуля pod требуется пространство, приостанавливаемые модули pod удаляются и перепланируются на другом узле или новом узле для размещения модуля pod с высоким приоритетом.

В следующем YAML показан пример манифеста приостановки pod:

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi 

Масштабирование узлов и эффективность

Рекомендации по использованию:

Тщательно отслеживайте использование ресурсов и политики планирования, чтобы обеспечить эффективное использование узлов.

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

Изображения узлов

Рекомендации по использованию:

Используйте последнюю версию образа узла, чтобы обеспечить наличие последних исправлений безопасности и исправлений ошибок.

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

Azure Linux

Azure Linux Container Host в AKS использует собственный образ AKS и предоставляет единое место для разработки на Linux. Каждый пакет создается из источника и проверяется, обеспечивая выполнение служб на проверенных компонентах.

Azure Linux является упрощенным, включая только необходимый набор пакетов для запуска рабочих нагрузок контейнеров. Она обеспечивает снижение уровня атак и устраняет исправление и обслуживание ненужных пакетов. На базовом уровне он имеет ядро, защищенное корпорацией Майкрософт, настроенное для Azure. Этот образ идеально подходит для рабочих нагрузок, чувствительных к производительности, и инженеров платформ и операторов, которые управляют флотами кластеров AKS.

Ubuntu 2204

Образ Ubuntu 2204 — это образ узла по умолчанию для AKS. Это упрощенная и эффективная операционная система, оптимизированная для выполнения контейнерных рабочих нагрузок. Это означает, что это может помочь сократить использование ресурсов и повысить общую производительность. Образ включает последние исправления и обновления системы безопасности, которые помогают обеспечить защиту рабочих нагрузок от уязвимостей.

Образ Ubuntu 2204 полностью поддерживается корпорацией Майкрософт, компанией Canonical и сообществом Ubuntu и может помочь вам достичь лучшей производительности и безопасности для ваших контейнеризированных рабочих нагрузок.

Виртуальные машины (ВМ)

Рекомендации по использованию:

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

Производительность приложения тесно связана с номерами SKU виртуальных машин, используемыми в рабочих нагрузках. Более крупные и более мощные виртуальные машины, как правило, обеспечивают более высокую производительность. Для критически важных рабочих нагрузок или рабочих нагрузок продуктов рекомендуется использовать виртуальные машины по крайней мере с 8-ядром ЦП. Виртуальные машины с более новыми поколениями оборудования, такими как версия 4 и v5, также могут помочь повысить производительность. Помните, что задержка создания и масштабирования может отличаться в зависимости от используемых номеров SKU виртуальных машин.

Использование пулов выделенных системных узлов

Для масштабирования производительности и надежности рекомендуется использовать выделенный пул системных узлов. В этой конфигурации выделенный системный пул узлов резервирует место для критически важных системных ресурсов, таких как демоны ОС. Затем рабочая нагрузка приложения может выполняться в пуле узлов пользователя, чтобы повысить доступность ресурсов, доступных для вашего приложения. Эта конфигурация также помогает снизить риск конкуренции ресурсов между системой и приложением.

Создать операции

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

Вы также можете использовать зоны доступности, чтобы обеспечить более высокий уровень доступности для защиты от потенциальных сбоев оборудования или запланированных событий обслуживания. Кластеры AKS распределяют ресурсы по логическим разделам базовой инфраструктуры Azure. Зоны доступности физически отделяют узлы от других узлов, чтобы гарантировать, что один сбой не влияет на доступность приложения. Зоны доступности доступны только в определенных регионах. Дополнительные сведения см. в разделе "Зоны доступности" в Azure.

Сервер API Kubernetes

Операции LIST и WATCH

Kubernetes использует операции LIST и WATCH для взаимодействия с сервером API Kubernetes и мониторингом сведений о ресурсах кластера. Эти операции являются фундаментальными для того, как Kubernetes выполняет управление ресурсами.

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

Операция LIST может извлекать большие объемы данных, особенно в больших кластерах с несколькими ресурсами. Имейте в виду, что выполнение неограниченных или частых вызовов LIST создает значительную нагрузку на сервер API и может увеличить время отклика.

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

Учитывайте тот факт, что просмотр слишком большого количества изменяемых ресурсов или слишком большое количество одновременных запросов WATCH может перегрузить сервер API и вызвать чрезмерное потребление ресурсов.

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

Квоты ресурсов

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

Приоритет и справедливость API

Kubernetes представила концепцию приоритета и справедливости API (APF) для определения приоритета запросов API и управления ими. Вы можете использовать APF в Kubernetes для защиты сервера API кластера и уменьшения HTTP 429 Too Many Requests количества ответов, видимых клиентскими приложениями.

Настройка API с помощью PriorityLevelConfigurations и FlowSchemas обеспечивает приоритет критически важных запросов API через менее важные запросы. Это гарантирует, что основные операции не испытывают недостатка в ресурсах или задержек из-за запросов с более низким приоритетом.

Оптимизация меток и селекторов

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

Операции CREATE и UPDATE в Kubernetes относятся к действиям, которые управляют и изменяют ресурсы кластера.

Операции CREATE и UPDATE

Операция CREATE создает новые ресурсы в кластере Kubernetes, такие как поды, службы, развертывания, configmaps и секреты. Во время операции CREATE клиент, например kubectl или контроллер, отправляет запрос серверу API Kubernetes для создания нового ресурса. Сервер API проверяет запрос, гарантирует соответствие любым политикам контроллера допуска, а затем создает ресурс в требуемом состоянии кластера.

Операция UPDATE изменяет существующие ресурсы в кластере Kubernetes, включая изменения спецификаций ресурсов, таких как количество реплик, образов контейнеров, переменных среды или меток. Во время операции UPDATE клиент отправляет запрос серверу API для обновления существующего ресурса. Сервер API проверяет запрос, применяет изменения к определению ресурса и обновляет ресурс кластера.

Операции CREATE и UPDATE могут повлиять на производительность сервера API Kubernetes в следующих условиях:

• Высокая параллелизм: если несколько пользователей или приложений выполняют одновременные запросы CREATE или UPDATE, это может привести к всплеску запросов API, поступающих на сервер одновременно. Это может нагрузить вычислительную мощность сервера API и вызвать проблемы с производительностью.
• Сложные определения ресурсов: определения ресурсов, которые слишком сложны или связаны с несколькими вложенными объектами, могут увеличить время, необходимое для сервера API для проверки и обработки запросов CREATE и UPDATE, что может привести к снижению производительности.
• Проверка ресурсов и контроль допуска: Kubernetes применяет различные политики контроля допуска и проверки на входящие запросы CREATE и UPDATE. Для больших определений ресурсов, таких как с обширными заметками или конфигурациями, может потребоваться больше времени обработки.
• Пользовательские контроллеры: пользовательские контроллеры, которые отслеживают изменения в ресурсах, таких как развертывания или контроллеры StatefulSet, могут создавать значительное количество обновлений при масштабировании или развертывании изменений. Эти обновления могут напрягать ресурсы сервера API.

Дополнительные сведения см. в разделе "Устранение неполадок сервера API и etcd в AKS".

Производительность плоскости данных

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

Типы хранилища

AKS рекомендует и по умолчанию использовать временные диски ОС. Временные диски ОС создаются в локальном хранилище виртуальных машин и не сохраняются в удаленном хранилище Azure, например на управляемых дисках ОС. Они имеют более быстрое повторное создание и время загрузки, что обеспечивает более быстрые операции кластера, а также обеспечивает более низкую задержку чтения и записи на диске ОПЕРАЦИОННОй системы узлов агента AKS. Временные диски ОС хорошо работают для бесстатусных рабочих нагрузок, где приложения терпимы к отдельным сбоям виртуальных машин, но нетерпимы ко времени развертывания ВМ или отдельным случаям повторного создания образа ВМ. Только некоторые типы SKU виртуальных машин поддерживают временные диски ОС, поэтому необходимо убедиться, что выбранное поколение SKU и размер совместимы. Дополнительные сведения см. в разделе "Временные диски ОС" в службе Azure Kubernetes (AKS).

Если рабочая нагрузка не может использовать временные диски ОС, AKS по умолчанию использует диски ОС SSD уровня "Премиум". Если диски SSD уровня "Премиум" несовместимы с рабочей нагрузкой, AKS по умолчанию использует диски SSD уровня "Стандартный". В настоящее время единственным доступным типом диска ОС является стандартный HDD. Дополнительные сведения см. в разделе "Параметры хранилища" в службе Azure Kubernetes (AKS).

В следующей таблице представлена разбивка предлагаемых вариантов использования дисков ОС, поддерживаемых в AKS:

IOPS и пропускная способность

Операции ввода-вывода в секунду (IOPS) относятся к числу операций чтения и записи, которые диск может выполнять в секунду. Пропускная способность относится к объему данных, которые можно передать в течение заданного периода времени.

Диски ОС отвечают за хранение операционной системы и связанных с ним файлов, а виртуальные машины отвечают за запуск приложений. При выборе виртуальной машины убедитесь, что размер и производительность диска ОС и номера SKU виртуальной машины не имеют большого несоответствия. Несоответствие размера или различие производительности может вызвать проблемы с производительностью и конкуренцию за ресурсы. Например, если диск ОС значительно меньше, чем виртуальные машины, он может ограничить объем свободного места, доступного для данных приложения, и привести к тому, что система не будет свободного места на диске. Если диск ОС имеет более низкую производительность, чем виртуальные машины, он может стать узким местом и ограничить общую производительность системы. Убедитесь, что размер и производительность сбалансированы, чтобы обеспечить оптимальную производительность в Kubernetes.

Для мониторинга счетчиков операций ввода-вывода в секунду и пропускной способности на дисках ОС на портале Azure можно выполнить следующие действия.

1. Перейдите на портал Azure.
2. Найдите масштабируемый набор виртуальных машин и выберите свой масштабируемый набор виртуальных машин.
3. В разделе "Мониторинг" выберите "Метрики".

Эфемерные диски ОС могут обеспечивать динамические показатели IOPS и пропускной способности для вашего приложения, в то время как управляемые диски имеют ограниченные показатели IOPS и пропускной способности. Дополнительные сведения см. в разделе " Временные диски ОС" для виртуальных машин Azure.

Azure Premium SSD v2 предназначен для интенсивных по вводу-выводу нагрузок предприятия, требующих задержки диска менее миллисекунды и высокой IOPS и пропускной способности при низкой стоимости. Он подходит для широкого спектра рабочих нагрузок, таких как SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, большие данные и аналитика, игры и многое другое. Этот тип диска является самым высокопроизводительным вариантом, доступным в настоящее время для постоянных томов.

Планирование pod

Выделенные виртуальной машине ресурсы памяти и процессора напрямую влияют на производительность подов, работающих на ней. При создании pod ему назначается определенный объем памяти и процессорных ресурсов, которые используются для работы приложения. Если у виртуальной машины недостаточно доступной памяти или ресурсов ЦП, это может привести к замедлению или даже сбою подов. Если у виртуальной машины слишком много памяти или ресурсов ЦП, это может привести к неэффективной работе pod, излишнему расходу ресурсов и увеличению затрат. Мы рекомендуем отслеживать общий объем запросов Pod в ваших рабочих нагрузках в сравнении с общим объемом ресурсов, доступных для распределения, для предсказуемого и эффективного планирования и производительности. Вы также можете задать максимальное количество подов на узел в зависимости от планирования емкости с помощью --max-pods.