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

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

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

Рекомендации на уровне развертывания

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

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

Руководство по лучшим практикам

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

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

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

В следующем примере файла определения pod раздел resources задает ограничения ЦП и памяти для pod:

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

kubectl describe node <node-name>

# Example output
Capacity:
 cpu:                8
 ephemeral-storage:  129886128Ki
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             32863116Ki
 pods:               110
Allocatable:
 cpu:                7820m
 ephemeral-storage:  119703055367
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             28362636Ki
 pods:               110

Дополнительные сведения см. в статьях "Назначение ресурсов ЦП контейнерам и подам" и "Назначение ресурсов памяти контейнерам и подам".

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

Руководство по лучшим практикам

Используйте вертикальный автомасштабировщик подов (VPA), чтобы автоматически настраивать запросы ЦП и памяти для ваших подов на основе их фактического использования.

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

VPA работает в трех режимах:

• Выкл. Предоставляет рекомендации только без применения изменений.
• Авто: автоматически обновляет запросы ресурсов pod во время перезапуска pod.
• Начальное. Задает запросы ресурсов только во время создания pod.

В следующем примере показано, как настроить ресурс VPA в Kubernetes:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-deployment
  updatePolicy:
    updateMode: "Auto" # Options: Off, Auto, Initial

Дополнительные сведения см. в документации по вертикальному автоматическому масштабированию Pod.

Бюджеты нарушений Pod (PDB)

Руководство по лучшим практикам

Используйте бюджеты прерываний контейнеров (PDB), чтобы обеспечить доступность минимального количества контейнеров во время добровольных прерываний, таких как операции обновления или случайное удаление контейнеров.

Бюджеты прерываний Pod (PDBs) позволяют определить, как развертывания или наборы реплик реагируют при добровольных прерываниях, таких как операции обновления или случайное удаление Pod. С помощью PDB можно определить минимальное или максимальное количество недоступных ресурсов. ППР влияют только на API выселения при добровольных перерывах.

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

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

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
   name: mypdb
spec:
   minAvailable: 3 # Minimum number of pods that must remain available during voluntary disruptions
   selector:
    matchLabels:
      app: myapp

Для получения дополнительной информации см. Планирование доступности с помощью PDB и Определение бюджета на нарушение для вашего приложения.

Корректное завершение для модулей pod

Руководство по лучшим практикам

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

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

Использование PreStop хуков

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

В следующем примере определения "pod" показано, как использовать перехватчик PreStop для обеспечения корректного завершения контейнера:

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "nginx -s quit; while killall -0 nginx; do sleep 1; done"]

Настройка terminationGracePeriodSeconds

Поле terminationGracePeriodSeconds указывает время ожидания Kubernetes перед принудительной завершением модуля pod. Этот период включает время, необходимое для выполнения PreStop процедуры. Если PreStop hook не завершается в течение льготного периода, pod принудительно завершается.

Например, следующее определение pod задает льготный период завершения 30 секунд:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  terminationGracePeriodSeconds: 30
  containers:
  - name: example-container
    image: nginx

Дополнительные сведения см. в разделе "Хуки жизненного цикла контейнеров" и "Завершение капсул".

Высокий уровень доступности во время обновлений

Использование maxSurge для более быстрых обновлений

Руководство по лучшим практикам

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

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

В следующем примере манифеста развертывания показано, как настроить maxSurge:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 33% # Maximum number of additional pods created during the update

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

Использование maxUnavailable для управляемых обновлений

Руководство по лучшим практикам

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

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

Можно задать maxUnavailable как абсолютное число (например, 1) или процент требуемого количества модулей pod (например, 25%). Например, если у вашего приложения есть четыре реплики и задано значение maxUnavailable1, Kubernetes гарантирует, что в процессе обновления по крайней мере три модуля pod остаются доступными.

В следующем примере манифеста развертывания показано, как настроить maxUnavailable:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1 # Maximum number of pods that can be unavailable during the update

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

Для получения дополнительной информации, см. поэтапные обновления в Kubernetes.

Ограничения распространения топологии Pod

Руководство по лучшим практикам

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

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

В следующем примере файла определения pod показано, как использовать topologySpreadConstraints поле для распределения pod по разным узлам.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # Configure a topology spread constraint
  topologySpreadConstraints:
    - maxSkew: <integer>
      minDomains: <integer> # optional
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>
      matchLabelKeys: <list> # optional
      nodeAffinityPolicy: [Honor|Ignore] # optional
      nodeTaintsPolicy: [Honor|Ignore] # optional

Дополнительные сведения см. в разделе "Ограничения распространения топологии pod".

Готовность, активность и начальные проверки

Руководство по лучшим практикам

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

Пробы готовности

В Kubernetes kubelet использует пробы готовности, чтобы узнать, когда контейнер готов к принятию трафика. Модуль pod считается готовым , когда все его контейнеры готовы. Если модуль pod не готов, его удаляют из балансировщиков нагрузки. Дополнительные сведения см. в разделе "Пробы готовности" в Kubernetes.

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

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

Дополнительные сведения см. в разделе "Настройка проб готовности".

Пробы жизнеспособности

В Kubernetes kubelet использует пробы активности, чтобы узнать, когда перезапустить контейнер. Если контейнер не проходит проверку живучести, он перезапускается. Дополнительные сведения см. в статье Проверки готовности в Kubernetes.

В следующем примере файла определения pod показана конфигурация пробы активности:

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy

Другой вид проверки активности использует HTTP-запрос GET. В следующем примере файла определения pod показана конфигурация проверки живучести с использованием HTTP-запроса GET.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

Для получения дополнительной информации см. Настройка проверок готовности и Определение запроса HTTP для проверки готовности.

Тесты запуска

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

В следующем примере файла определения pod показана конфигурация пробы запуска:

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Приложения с несколькими репликами

Руководство по лучшим практикам

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

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

В следующем примере файла определения pod показано, как использовать replicas поле для указания количества модулей pod, которые требуется запустить:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Дополнительные сведения см. в разделе "Рекомендуемое решение высокой готовности active-active для AKS" и "Реплики в Спецификациях Развертывания".

Рекомендации по лучшим практикам на уровне кластеров и пулов узлов

Следующие рекомендации по уровню кластера и пула узлов помогают обеспечить высокий уровень доступности и надежности кластеров AKS. Эти рекомендации можно реализовать при создании или обновлении кластеров AKS.

Зоны доступности

Руководство по лучшим практикам

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

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

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

Руководство по лучшим практикам

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

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

Параметр можно использовать --enable-cluster-autoscaler при создании кластера AKS для включения автомасштабирования кластера, как показано в следующем примере:

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --enable-cluster-autoscaler  \
    --min-count 1 \
    --max-count 3 \
    --generate-ssh-keys

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

Дополнительные сведения см. в статье Об использовании автомасштабирования кластера в AKS.

Стандартный балансировщик нагрузки

Руководство по лучшим практикам

Используйте Стандартный балансировщик нагрузки для обеспечения большей надежности и ресурсов, поддержки нескольких зон доступности, проб HTTP и функциональности в нескольких центрах обработки данных.

В Azure SKU Standard Load Balancer предназначена для балансировки трафика сетевого уровня, когда требуется высокая производительность и низкие задержки. Стандартный балансировщик нагрузки маршрутизирует трафик как в пределах, так и между регионами, а также в зоны доступности для обеспечения высокой устойчивости. SKU «Стандартный» рекомендуется и используется по умолчанию при создании кластера AKS.

В следующем примере показан LoadBalancer манифест службы, использующий Standard Load Balancer.

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-ipv4 # Service annotation for an IPv4 address
  name: azure-load-balancer
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-load-balancer

Дополнительные сведения см. в статье "Использование стандартной подсистемы балансировки нагрузки" в AKS.

Пулы системных узлов

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

Руководство по лучшим практикам

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

Используйте пулы выделенных системных узлов, чтобы гарантировать отсутствие других пользовательских приложений на одних узлах, что может привести к нехватке ресурсов и потенциальных сбоев кластера из-за условий гонки. Чтобы использовать выделенный пул системных узлов, можно использовать CriticalAddonsOnly фрагмент в пуле системных узлов. Дополнительные сведения см. в разделе "Использование пулов системных узлов" в AKS.

Автомасштабирование для пулов системных узлов

Руководство по лучшим практикам

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

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

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

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

Руководство по лучшим практикам

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

Пулы системных узлов используются для запуска системных подов, таких как kube-proxy, coredns и подключаемый модуль Azure CNI. Рекомендуется убедиться, что пулы системных узлов имеют по крайней мере два узла , чтобы обеспечить устойчивость к сценариям замораживания и обновления, что может привести к перезапуску или закрытию узлов. Дополнительные сведения см. в разделе "Управление пулами системных узлов" в AKS.

Обновление конфигураций для пулов узлов

Использование maxSurge для обновления пула узлов

Руководство по лучшим практикам

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

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

Например, следующая команда Azure CLI задает maxSurge значение 1 для пула узлов:

az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name myNodePool \
  --max-surge 1

Настроив настройку maxSurge, вы можете обеспечить более быстрое выполнение обновлений при сохранении доступности приложений.

Дополнительные сведения см. в разделе "Обновление пулов узлов" в AKS.

Использование maxUnavailable для обновления пула узлов

Руководство по лучшим практикам

maxUnavailable Настройте параметр обновления пула узлов, чтобы обеспечить доступность приложения во время операций обновления.

Параметр maxUnavailable задает максимальное количество узлов, которые могут быть недоступны во время обновления. Это гарантирует, что часть пула узлов остается операционной во время обновления узлов.

Например, следующая команда Azure CLI задает maxUnavailable значение 1 для пула узлов:

az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name myNodePool \
  --max-unavailable 1

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

Дополнительные сведения см. в разделе "Обновление пулов узлов" в AKS.

Руководство по лучшим практикам

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

Ускорение сети обеспечивает виртуализацию одно корневых операций ввода-вывода (SR-IOV) в поддерживаемых типах виртуальных машин, что значительно повышает производительность сети.

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

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

Версии изображений

Руководство по лучшим практикам

Изображения не должны использовать latest тег.

Теги образа контейнера

latest Использование тега latest для контейнерных образов может привести к непредсказуемому поведению и затрудняет отслеживание версии образа, который выполняется в вашем кластере. Эти риски можно свести к минимуму, интегрируя и выполняя средства сканирования и исправления в контейнерах во время сборки и выполнения. Дополнительные сведения см. в рекомендациях по управлению образами контейнеров в AKS.

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

AKS предоставляет несколько каналов автоматического обновления для обновлений образа ОС узла. Эти каналы можно использовать для управления временем обновления. Мы рекомендуем присоединиться к этим каналам автоматического обновления, чтобы убедиться, что узлы работают с последними исправлениями безопасности и обновлениями. Дополнительные сведения см. в разделе "Образы ОС узла автоматического обновления" в AKS.

стандартный уровень для производственных нагрузок

Руководство по лучшим практикам

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

Уровень "Стандартный" для Службы Azure Kubernetes (AKS) предоставляет финансово гарантирующее 99,9 % соглашение об уровне обслуживания (SLA) для ваших рабочих нагрузок в продуктивной среде. Уровень "Стандартный" также обеспечивает более высокую надежность кластера и ресурсы, поддержку до 5000 узлов в кластере и соглашение об уровне обслуживания, включенное по умолчанию. Дополнительные сведения см. в разделе "Ценовые категории" для управления кластерами AKS.

Azure CNI для динамического выделения IP-адресов

Руководство по лучшим практикам

Настройте Azure CNI для динамического выделения IP-адресов для улучшения использования IP-адресов и предотвращения исчерпания IP-адресов для кластеров AKS.

Возможность динамического выделения IP-адресов в Azure CNI выделяет IP-адреса pod из подсети, отдельной от подсети, в котором размещен кластер AKS, и предлагает следующие преимущества:

• Улучшенное использование IP-адресов: IP-адреса динамически распределяются между Pod кластера из подсети Pod. Это обеспечивает более эффективное использование IP-адресов в кластере по сравнению с традиционным решением CNI, которое выполняет статическое выделение IP-адресов для каждого узла.
• Масштабируемость и гибкость. Подсети узлов и модулей pod можно масштабировать независимо друг от друга. Одну и ту же подсеть pod можно совместно использовать в нескольких пулах узлов кластера или в нескольких кластерах AKS, развернутых в одной виртуальной сети. Можно также настроить отдельную подсеть pod для пула узлов.
• Высокая производительность: Поскольку подам назначаются IP-адреса виртуальной сети, они имеют прямое подключение к другим подам кластера и ресурсам в виртуальной сети. Такое решение обеспечивает поддержку очень больших кластеров без снижения производительности.
• Отдельные политики виртуальной сети для модулей pod. Так как модули pod размещаются в отдельной подсети, для них можно настроить отдельные политики виртуальной сети, отличные от политик узлов. Это позволяет использовать множество полезных сценариев, таких как разрешение подключения к Интернету только для модулей pod, а не для узлов, исправление исходного IP-адреса для pod в пуле узлов с помощью шлюза NAT Azure и использование групп безопасности сети для фильтрации трафика между пулами узлов.
• Сетевые политики Kubernetes: Сетевые политики Azure и Calico работают с этим решением.

Дополнительные сведения см. в статье "Настройка сети Azure CNI" для динамического распределения IP-адресов и расширенной поддержки подсети.

Виртуальные машины SKU v5

Руководство по лучшим практикам

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

Для пулов узлов в AKS используйте виртуальные машины серии SKU v5 с эфемерными дисками ОС, чтобы обеспечить достаточные вычислительные мощности для pod-ов kube-system. Дополнительные сведения см. в рекомендациях по повышению производительности и масштабированию больших рабочих нагрузок в AKS.

Не используйте виртуальные машины серии B

Руководство по лучшим практикам

Не используйте виртуальные машины серии B для кластеров AKS, так как они не работают хорошо с AKS.

Виртуальные машины серии B являются низкой производительностью и не работают хорошо с AKS. Вместо этого мы рекомендуем использовать виртуальные машины SKU V5.

Диски класса Premium

Руководство по лучшим практикам

Используйте диски уровня "Премиум" для обеспечения доступности на 99,9 % на одной виртуальной машине (ВМ).

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

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

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: premium2-disk-sc
parameters:
   cachingMode: None
   skuName: PremiumV2_LRS
   DiskIOPSReadWrite: "4000"
   DiskMBpsReadWrite: "1000"
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

Дополнительные сведения см. в статье Об использовании дисков SSD уровня "Премиум" azure версии 2 в AKS.

Аналитика контейнеров

Руководство по лучшим практикам

Включите Аналитику контейнеров для мониторинга и диагностики производительности контейнерных приложений.

Container Insights — это функция Azure Monitor, которая собирает и анализирует журналы контейнеров из AKS. Собранные данные можно анализировать с помощью коллекции представлений и готовых рабочих книг.

Вы можете включить мониторинг Container Insights в кластере AKS с помощью различных методов. В следующем примере показано, как включить мониторинг Container Insights в существующем кластере с помощью Azure CLI:

az aks enable-addons -a monitoring --name myAKSCluster --resource-group myResourceGroup

Дополнительные сведения см. в разделе "Включение мониторинга для кластеров Kubernetes".

Политика Azure

Руководство по лучшим практикам

Применяйте и обеспечивайте выполнение требований к безопасности и соответствию для кластеров AKS с помощью Azure Policy.

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

Дополнительные сведения см. в статье "Защита кластеров AKS с помощью Политика Azure".

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

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

• Общие сведения о высокой доступности и аварийном восстановлении для AKS
• Запуск кластеров AKS в большом масштабе
• Базовая архитектура кластера AKS