Часто задаваемые вопросы об AKS

AKS предоставляет гарантии соглашения об уровне обслуживания (SLA) в ценовой категории "Стандартный" с функцией Uptime SLA.

Поддержка платформы — это сокращенный план поддержки для неподдерживаемых кластеров версии n-3. Поддержка платформы включает только поддержку инфраструктуры Azure.

Дополнительные сведения см. в политике поддержки платформы.

Да, AKS инициирует автоматическое обновление неподдерживаемых кластеров. Если кластер в версии n-3 (где n является последней поддерживаемой младшей версией AKS, которая общедоступна) опустится до n-4, AKS автоматически обновляет кластер до n-2, чтобы соответствовать политике поддержки AKS.

Дополнительные сведения см. в статье "Поддерживаемые версии Kubernetes", "Запланированные периоды обслуживания" и "Автоматическое обновление".

Узлы агентов AKS тарифицируются как стандартные виртуальные машины Azure (VM). Если вы приобрели Azure резервирования для размера виртуальной машины, используемой в AKS, эти скидки применяются автоматически.

Да, AKS поддерживает контейнеры Windows Server. Дополнительную информацию см. в разделе Windows Server на AKS: Вопросы и ответы.

AKS поддерживает четыре основных операционных системы Linux, включая Ubuntu Linux, Azure Linux, Azure Linux OS Guard и Flatcar Container Linux для AKS. При указании --os-type Linux при создании пула узлов или кластера, операционная система по умолчанию используется Ubuntu Linux.

При использовании --os-sku Ubuntu по умолчанию используется Ubuntu 22.04 в AKS в версиях Kubernetes 1.25-1.34. AKS по умолчанию использует Ubuntu 24.04 в Kubernetes версии 1.35+. При использовании --os-sku AzureLinux AKS по умолчанию используется Azure Linux 3.0, начиная с Kubernetes версии 1.32+. В некоторых сценариях, таких как пулы узлов с поддержкой FIPS, версия ОС по умолчанию может отличаться. См. образы ноды для получения дополнительной информации.

Нет. Перемещение кластера AKS между клиентами в настоящее время не поддерживается.

Нет. Перемещение кластера AKS между подписками в настоящее время не поддерживается.

Нет. Перенос кластера AKS в другую виртуальную сеть в настоящее время не поддерживается.

Нет. Перемещение или переименование кластера AKS и связанных с ним ресурсов не поддерживается.

Нет. После удаления кластера невозможно восстановить его. При удалении кластера группа ресурсов узла и все его ресурсы также удаляются.

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

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

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

Нет. Операции масштабирования с использованием API масштабируемых наборов виртуальных машин не поддерживаются. API AKS можно использовать (az aks scale).

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

Нет. Такая конфигурация не поддерживается. Вместо этого следует остановить работу кластера.

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

Для обеспечения такой архитектуры каждое развертывание AKS охватывает две группы ресурсов.

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

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

Чтобы указать собственное имя группы ресурсов, установите aks-preview Azure CLI версию расширения 0.3.2 или более поздней версии. При создании кластера AKS с помощью az aks create команды используйте --node-resource-group параметр и укажите имя группы ресурсов. Если вы используете шаблон Azure Resource Manager для развертывания кластера AKS, можно определить имя группы ресурсов с помощью свойства nodeResourceGroup.

• Поставщик ресурсов Azure автоматически создает вторичную группу ресурсов.
• Можно указать имя настраиваемой группы ресурсов только при создании кластера.

При работе с группой ресурсов узла не следует:

• Указать существующую группу ресурсов узла.
• Укажите другую подписку для группы ресурсов узла.
• Измените имя группы ресурсов узла после создания кластера.
• выбрать имена управляемых ресурсов в группе ресурсов узла;
• Модификация или удаление тегов, созданных Azure для управляемых ресурсов в группе ресурсов узла.

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

Созданные Azure теги создаются для соответствующих служб Azure, и их всегда следует разрешать. Для AKS существуют aks-managed и k8s-azure теги. Изменение любых тегов, созданных Azure, на ресурсах в группе ресурсов для узла в кластере AKS — это неподдерживаемое действие, которое нарушает цель уровня обслуживания (SLO).

AKS использует Helm для доставки компонентов в кластер. Вы можете безопасно игнорировать релизы Helm с префиксом aks-managed. Ожидается, что в этих релизах Helm будут безопасно и постепенно увеличиваться версии.

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

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

Да, кластер AKS можно развернуть в одном или нескольких зонах доступности в регионах, поддерживающих их.

Да, вы можете использовать различные размеры виртуальных машин в кластере AKS, создав несколько пулов узлов.

AKS не задает ограничение размера образа контейнера. Но чем больше изображение, тем выше спрос на память. Больший размер может превышать ограничения ресурсов или общую доступную память рабочих узлов. По умолчанию для размера виртуальной машины Standard_DS2_v2 для кластера AKS выделяется 7 ГиБ памяти.

Если образ контейнера слишком велик, например, в диапазоне терабайтов (ТБ), kubelet может не суметь загрузить его из реестра контейнеров на узел из-за нехватки места на диске.

Для узлов Windows Server клиентский компонент Центра обновления Windows не выполняется автоматически и не применяет последние обновления. Необходимо выполнить обновление кластера и пулов узлов Windows Server в кластере AKS. Следуйте регулярному расписанию на основе цикла выпуска клиентский компонент Центра обновления Windows и собственного процесса проверки. Этот процесс обновления создает узлы, которые выполняют последнюю версию образа и исправления Windows Server, а затем удаляют старые узлы. Дополнительные сведения об обновлении пула узлов в AKS см. в этой статье.

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

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Да, существует два варианта ограничения доступа к серверу API:

• Используйте авторизованные диапазоны IP-адресов сервера API , если вы хотите сохранить общедоступную конечную точку для сервера API, но ограничить доступ к набору доверенных диапазонов IP-адресов.
• Используйте частный кластер , если вы хотите ограничить доступ сервера API только из виртуальной сети.

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

• Вручную через портал Azure или Azure CLI.
• Обновив кластер AKS. Кластер автоматически обновляет узлы кордона и очистки . Затем он вводит в сеть новый узел с последним образом Ubuntu и новой версией патча или малой версией Kubernetes. Дополнительные сведения см. в статье Обновление кластера службы Azure Kubernetes (AKS).
• С помощью обновления образа узла.

Майкрософт предоставляет рекомендации по другим действиям, которые можно предпринять для защиты рабочих нагрузок через службы, такие как Microsoft Defender для контейнеров. Сведения об угрозе безопасности, связанной с AKS и Kubernetes, см. в статье «Новая крупномасштабная кампания, нацеленная на Kubeflow» (8 июня 2021 г.).

Нет. Все данные хранятся в регионе кластера.

Традиционно, если pod выполняется как непривилегированный пользователь (что и должно быть), в параметрах fsGroup внутри контекста безопасности pod необходимо указать, чтобы том был доступен для чтения и записи этим pod. Дополнительные сведения об этом требовании см. в разделе "Настройка контекста безопасности" для модуля pod или контейнера.

Побочный эффект настройки fsGroup заключается в том, что при каждом монтировании тома Kubernetes должен рекурсивно применять команды chown() и chmod() к каждому файлу и каталогу внутри тома (с несколькими исключениями). Этот сценарий происходит даже в том случае, если групповое владение томом уже соответствует запрошенному fsGroup параметру. Эта конфигурация может быть дорогой для больших томов с большим количеством небольших файлов, что может привести к тому, что запуск pod займет много времени. Этот сценарий был известной проблемой до версии 1.20. Обходной путь — запустить pod от имени root:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Проблема устранена с помощью Kubernetes версии 1.20. Дополнительные сведения см. в статье Kubernetes 1.20: гранулярный контроль изменений разрешений томов.

AKS использует безопасный тоннель связи, чтобы обеспечить коммуникацию между api-server и отдельными узлами kubelets, даже находящимися в разных виртуальных сетях. Туннель защищен с помощью взаимного шифрования TLS (Безопасности транспортного уровня). Текущий основной туннель, который использует AKS , — Konnectivity, ранее известный как apiserver-network-proxy. Убедитесь, что все правила сети соответствуют Azure обязательным сетевым правилам и полным доменным именам (FQDNs).

Да, можно добавить аннотацию kubernetes.azure.com/set-kube-service-host-fqdn в поды, чтобы установить переменную KUBERNETES_SERVICE_HOST на доменное имя сервера API вместо IP-адреса службы в кластере. Это изменение полезно в случаях, когда исходящий трафик кластера выполняется через брандмауэр уровня 7. Примером является использование Брандмауэр Azure с правилами приложения.

AKS не применяет группы безопасности сети (NSG) к своей подсети и не изменяет группы безопасности сети, связанные с этой подсетью. AKS изменяет только параметры NSG сетевого интерфейса. Если вы используете сетевой интерфейс контейнера (CNI), необходимо также убедиться, что правила безопасности в группах безопасности сети (NSG) разрешают трафик между диапазонами маршрутизации без классного междоменного маршрута (CIDR) узлов и pod. Если вы используете kubenet, необходимо также убедиться, что правила безопасности в группах безопасности разрешают трафик между узлом и подом CIDR. Дополнительные сведения см. в разделе Группы безопасности сети.

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

Нет. AKS — это управляемая служба. Манипуляция с ресурсами инфраструктуры как услуги (IaaS) не поддерживается. Чтобы установить пользовательские компоненты, используйте интерфейсы API и механизмы Kubernetes. Например, используйте daemonSets для установки всех необходимых компонентов.

AKS поддерживает следующие контроллеры допуска:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

В настоящее время изменить список контроллеров допуска в AKS невозможно.

Да, вы можете использовать веб-перехватчики контроллера допуска в AKS. Рекомендуется исключить внутренние пространства имен AKS, помеченные control-plane меткой. Например:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS ограничивает исходящий трафик сервера API, чтобы вебхуки приёмного контроллера были доступны изнутри кластера.

Чтобы защитить стабильность системы и запретить пользовательским контроллерам допуска влиять на внутренние службы в kube-system пространстве имен, AKS имеет средство принудительного применения, которое автоматически исключает kube-system и внутренние пространства имен AKS. Эта служба гарантирует, что пользовательские контроллеры допуска не влияют на сервисы, которые работают в kube-system.

Если у вас есть критический сценарий для развертывания чего-либо на kube-system (не рекомендуется) для поддержки настроенного веб-перехватчика допуска, можно добавить следующую метку или аннотацию, чтобы контролер допуска пропускал его:

• Метка: "admissions.enforcer/disabled": "true"
• Аннотация: "admissions.enforcer/disabled": true

поставщик Azure Key Vault для драйвера CSI хранилища секретов обеспечивает встроенную интеграцию Azure Key Vault с AKS.

Теперь узлы, включенные с помощью федеральных стандартов обработки информации (FIPS), поддерживаются в пулах узлов на основе Linux. Дополнительные сведения см. в статье Добавление пула узлов с поддержкой FIPS.

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

Расширение AKS Linux — это расширение виртуальной машины Azure, которое устанавливает и настраивает средства мониторинга на рабочих узлах Kubernetes. Расширение устанавливается на всех новых и существующих узлах Linux. Он настраивает следующие средства мониторинга:

• node_exporter: собирает данные телеметрии оборудования из виртуальной машины и делает их доступными с помощью конечной точки метрик. Затем средство мониторинга, например Prometheus, может отказаться от этих метрик.
• Детектор проблем с узлами: стремится сделать различные проблемы узлов видимыми для вышестоящих слоев в стеке управления кластерами. Это системный модуль, который выполняется на каждом узле, обнаруживает проблемы с узлами и сообщает их серверу API кластера с помощью Events и NodeConditions.
• ig: является платформой с открытым исходным кодом eBPF для отладки и наблюдения за системами Linux и Kubernetes. Он предоставляет набор средств (или гаджетов), которые собирают соответствующие сведения, которые пользователи могут использовать для выявления причин проблем с производительностью, сбоев или других аномалий. В частности, независимость от Kubernetes позволяет пользователям использовать его также для отладки проблем уровня управления.

Эти инструменты помогают обеспечить мониторинг в отношении многих проблем, связанных с работоспособностью узлов, таких как:

• Проблемы с управляющей программой инфраструктуры: Служба NTP не работает
• Проблемы с оборудованием: Неисправный процессор, память или диск
• Проблемы с ядром: Взаимоблокировка ядра, поврежденная файловая система
• Проблемы со средой выполнения контейнера: Неотвечающий демон среды выполнения

Для расширения не требуется дополнительный исходящий доступ к url-адресам, IP-адресам или портам за пределами задокументированных требований исходящего трафика AKS. Для этого не требуются специальные разрешения, предоставленные в Azure. Он использует kubeconfig для подключения к серверу API и отправки собранных данных мониторинга.

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

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

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

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

Чаще всего эта ошибка возникает, если у вас есть одна или несколько групп безопасности сети, которые по-прежнему связаны с кластером. Удалите их и повторите попытку удалить кластер.

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

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

Начиная с 17 марта 2027 г. Azure Kubernetes Service (AKS) больше не поддерживает или предоставляет обновления для системы безопасности Ubuntu 20.04. Все существующие образы узлов будут удалены, и вы не сможете масштабировать пулы узлов под управлением Ubuntu 20.04. Выполните миграцию в поддерживаемую версию Ubuntu, обновив пулы узлов до Kubernetes версии 1.35+. Дополнительные сведения об этом прекращении поддержки см. в теме GitHub и в анонсе прекращения поддержки в Azure Updates. Чтобы оставаться в курсе обновлений и объявлений, следите за заметками о релизах AKS.

Начиная с 1 марта 2026 г. Azure Kubernetes Service (AKS) больше не поддерживает пулы узлов Windows Server 2019. Пулы узлов под управлением Kubernetes версии 1.33+ не могут использовать Windows Server 2019. Начиная с 1 апреля 2027 года, AKS удалит все существующие образы узлов для Windows Server 2019, что приведет к сбоям при выполнении операций масштабирования. Дополнительные сведения об этом прекращении поддержки см. в теме GitHub и в анонсе прекращения поддержки в Azure Updates. Чтобы оставаться в курсе обновлений и объявлений, следите за заметками о релизах AKS. Начиная с 15 марта 2027 г. Azure Kubernetes Service (AKS) больше не поддерживает пулы узлов Windows Server 2022. Пулы узлов под управлением Kubernetes версии 1.36+ не могут использовать Windows Server 2022. Начиная с 1 апреля 2028 г. AKS удаляет все существующие образы узлов для Windows Server 2022, что означает, что операции масштабирования завершаются сбоем. Дополнительные сведения об этом прекращении поддержки см. в теме GitHub и в анонсе прекращения поддержки в Azure Updates. Чтобы оставаться в курсе обновлений и объявлений, следите за заметками о релизах AKS.