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

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

  • Статья

Примечание.

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

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

В этой статье раскрываются следующие темы:

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

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

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

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

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

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

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

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

Примечание.

Если обеспечение высокого уровня доступности для приложения является главным приоритетом, рекомендуется оставить немного более высокий буфер для минимального числа модулей pod для вашей HPA для учета времени масштабирования.

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

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

Предупреждение

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

Примечание.

VPA работает на основе исторических данных. Мы рекомендуем ждать не менее 24 часов после развертывания VPA, прежде чем применять любые изменения, чтобы предоставить ему время для сбора данных рекомендаций.

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

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

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

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

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

Избыточная подготовка

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

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

1-buffer/1+traffic

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

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

Эффективный метод перепроверки включает использование модулей pod приостановки. Приостановка модулей pod — это низкоприоритетные развертывания, которые можно легко заменить высокоприоритетными развертываниями. Вы создаете низкоприоритетные модули 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 поставляет улучшения производительности в еженедельных выпусках образов. Последние образы управляющей программы кэшируются на последнем образе VHD, что обеспечивает более низкие преимущества задержки для подготовки узлов и начальной загрузки. Отстать от обновлений может негативно повлиять на производительность, поэтому важно избежать больших пробелов между версиями.

Azure Linux

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

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

Ubuntu 2204

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

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

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

Общие рекомендации:

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

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

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

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

Создание операций

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

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

Сервер API Kubernetes

Операции LIST и WATCH

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

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

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

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

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

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

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

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

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

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

Настраиваемый ресурс Ключевые функции
PriorityLevelConfigurations • Определите различные уровни приоритета для запросов API.
• Задает уникальное имя и назначает целочисленное значение, представляющее уровень приоритета. Более высокие уровни приоритета имеют более низкие целые значения, указывающие, что они более важны.
• Может использовать несколько для классификации запросов на разные уровни приоритета на основе их важности.
• Позволяет указать, должны ли запросы на определенном уровне приоритета быть подвержены ограничениям скорости.
FlowSchemas • Определите способ маршрутизации запросов API на разные уровни приоритета на основе атрибутов запроса.
• Укажите правила, соответствующие запросам на основе таких критериев, как группы API, версии и ресурсы.
• Если запрос соответствует заданному правилу, запрос направляется на уровень приоритета, указанный в связанном параметре PriorityLevelConfiguration.
• Можно использовать для задания порядка оценки, если несколько FlowSchemas соответствуют запросу, чтобы обеспечить приоритет определенных правил.

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

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

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

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

Операции CREATE и UPDATE

Операция CREATE создает новые ресурсы в кластере Kubernetes, такие как pod, службы, развертывания, конфигурации и секреты. Во время операции 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" и т. д. в AKS.

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

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

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

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

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

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

Тип диска ОС Ключевые функции Рекомендуемые варианты использования
Временные диски ОС • Быстрое повторное создание и время загрузки.
• Низкая задержка чтения и записи на диске ОС узлов агента AKS.
• Высокая производительность и доступность.		 • Требования к корпоративным рабочим нагрузкам, таким как SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite и т. д.
• Рабочие нагрузки без отслеживания состояния, требующие высокой доступности и низкой задержки.
Диски ОС SSD уровня "Премиум" • Согласованная производительность и низкая задержка.
• Высокий уровень доступности.		 • Требования к корпоративным рабочим нагрузкам, таким как SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite и т. д.
• Интенсивные корпоративные рабочие нагрузки ввода-вывода (ввода-вывода).
Диски ОС SSD уровня "Стандартный" • Согласованная производительность.
• Повышение доступности и задержки по сравнению с дисками HDD уровня "Стандартный".		 • Веб-серверы.
• Низкое количество операций ввода-вывода в секунду (IOPS) серверов приложений.
• Легко используемые корпоративные приложения.
• Рабочие нагрузки разработки и тестирования.
Диски HDD категории "Стандартный" • Низкая стоимость.
• Вариативность в производительности и задержке.		 • Хранилище резервных копий.
• Массовое хранилище с редким доступом.

Операции ввода-вывода в секунду и пропускная способность

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

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

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

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

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

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

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

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