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

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

В этой статье рассматривается запуск кластеров и рабочих нагрузок с точки зрения разработчика приложений. Рекомендации для администраторов см. в этой статье.

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

Определение запросов и ограничений ресурсов pod

Рекомендации по рекомендациям

Настройте запросы и ограничения для всех контейнеров pod в манифестах YAML. Если использовать квоты ресурсов в кластере AKS и не задать эти значения, развертывание может быть отклонено.

Используйте запросы и ограничения pod для управления вычислительными ресурсами в кластере AKS. Запросы и ограничения pod сообщают планировщику Kubernetes вычислительных ресурсов, назначаемых модулем pod.

Запросы ЦП и памяти pod

Запросы pod определяют набор ресурсов ЦП и памяти, необходимых pod регулярно.

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

Отслеживайте производительность приложения для настройки запросов pod. Если количество запросов pod занижено, производительность приложения может снизиться из-за чрезмерного планирования задач на узле. Если запросы переоценены, возможно, у приложения возникли трудности с планированием.

Ограничения ЦП и памяти pod

Ограничения pod задают максимальный объем ЦП и памяти, которую может использовать модуль pod. Ограничения памяти определяют, какие модули pod следует удалять при нестабильном состоянии узлов из-за нехватки ресурсов. Без надлежащего набора ограничений модули pod удаляются до тех пор, пока не будет отменено давление ресурсов. Хотя модуль pod может периодически превышать ограничение ЦП, модуль pod не удаляется для превышения предела ЦП.

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

Не настраивайте ограничения pod на больший объем ресурсов ЦП и памяти, чем могут обеспечить узлы. Каждый узел AKS резервирует определенный объем ресурсов ЦП и памяти для основных компонентов Kubernetes. Использование слишком большого количества ресурсов на узле будет мешать успешному выполнению других контейнеров pod.

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

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

Когда вы определяете запрос или ограничение по ресурсам ЦП, значение измеряется в единицах ЦП.

• 1.0 ЦП соответствует одному базовому виртуальному ядру ЦП на узле.
  • Для графических процессоров используется та же единица измерения.
• Можно определить фрагменты, измеряемые в миллиядрах. Например, 100 м — 0,1 ядра базового виртуального ЦП.

В следующем базовом примере для одного модуля POD NGINX модуль pod запрашивает 100 м времени ЦП и 128Mi памяти. Ограничения ресурсов для модуля pod устанавливаются на 250 м ЦП и 256Mi памяти.

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 250m
        memory: 256Mi

Дополнительную информацию об измерениях и назначениях ресурсов см. в разделе Управление вычислительными ресурсами для контейнеров.

Разработка и отладка приложений в кластере AKS

Рекомендации по рекомендациям

Команды разработчиков должны развертывать и отлаживать приложения в кластере AKS, используя Bridge to Kubernetes.

Bridge to Kubernetes позволяет разрабатывать, отлаживать и тестировать приложения непосредственно в кластере AKS. Разработчики в команде вместе работают над созданием и тестированием на протяжении всего жизненного цикла приложения. Вы можете использовать расширение Bridge to Kubernetes в существующих инструментах, например Visual Studio или Visual Studio Code.

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

Использование расширения Visual Studio Code (VS Code) для Kubernetes

Рекомендации по рекомендациям

Установите и используйте расширение VS Code для Kubernetes при написании манифестов YAML. Вы также можете использовать расширение для интегрированного решения по развертыванию, которое поможет владельцам приложений, которые редко взаимодействуют с кластером AKS.

Расширение Visual Studio Code для Kubernetes помогает разрабатывать и развертывать приложения в AKS. Расширение предоставляет указанные ниже возможности.

• IntelliSense для ресурсов Kubernetes, диаграмм Helm и шаблонов.

• Возможность просматривать, развертывать и изменять возможности для ресурсов Kubernetes из VS Code.

• Intellisense проверяет наличие запросов ресурсов или ограничений, заданных в спецификациях pod:

  

Следующие шаги

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

Чтобы реализовать некоторые из этих рекомендаций, см. статью "Разработка с помощью Моста к Kubernetes".