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

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

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

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

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

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

Да, AKS поддерживает контейнеры Windows Server. Дополнительные сведения см. в разделе "Часто задаваемые вопросы о Windows Server в AKS".

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

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

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

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

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

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

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

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

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

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

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

Нет, операции масштабирования с помощью API масштабируемого набора виртуальных машин не поддерживаются. Api AKS (az aks scale) можно использовать. AKS основывается на многих ресурсах инфраструктуры Azure, включая Масштабируемые наборы виртуальных машин, виртуальные сети и управляемые диски. Эти интеграции позволяют применять многие основные возможности платформы Azure в управляемой среде Kubernetes, предоставляемой AKS. Например, большинство типов виртуальных машин Azure можно использовать с AKS напрямую, а резервирования Azure можно использовать для автоматического получения скидок на эти ресурсы.

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

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

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

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

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

При работе с группой ресурсов для узлов учитывайте, что нельзя:

• указать существующую группу ресурсов для узлов;
• поместить узлы в группу ресурсов в другой подписке;
• изменить имя группы ресурсов узла после создания кластера;
• выбрать имена управляемых ресурсов в группе ресурсов узла;
• изменять или удалять созданные Azure теги управляемых ресурсов в группе ресурсов для узлов.

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

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

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

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

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

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

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

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

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

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

• 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. Кластер автоматически обновляет узлы cordon и drain, после чего включает узлы с помощью последнего образа Ubuntu и новой версии исправлений или дополнительной версии Kubernetes. Дополнительные сведения см. в статье Обновление кластера службы Azure Kubernetes (AKS).
• Посредством обновления образа узла.

Корпорация Майкрософт предлагает рекомендации по иным мерам, которые помогут защитить рабочие нагрузки с помощью таких служб, как Microsoft Defender для контейнеров. Следующая угроза безопасности связана с AKS и Kubernetes, о которых следует знать:

• Новая масштабная кампания нацелена на Kubeflow (8 июня 2021 г.).

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

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

Побочный эффект настройки fsGroup заключается в том, что каждый раз при установке тома Kubernetes должен рекурсивно chmod() chown() и все файлы и каталоги внутри тома (с несколькими исключениями, указанными ниже). Этот сценарий происходит, даже если право владения группой тома уже соответствует запрошенному 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-серверы и отдельные kubelets узлов могли обмениваться данными даже в разных виртуальных сетях. Туннель защищен с помощью шифрования mTLS. Текущий основной туннель, используемый AKS — Konnectivity, ранее известный как apiserver-network-proxy. Убедитесь, что все сетевые правила удовлетворяют обязательным правилам сети Azure и полным доменным именам.

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

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

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

Нет, AKS является управляемой службой, и управление ресурсами IaaS не поддерживается. Чтобы установить пользовательские компоненты, используйте интерфейсы API и механизмы Kubernetes. Например, вы можете использовать для установки необходимых компонентов контроллеры DaemonSet.

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.

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

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

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

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

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

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

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

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

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

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

Убедитесь, что срок действия субъекта-службы не истек. См. сведения о субъекте-службе AKS и учетных данных обновления AKS.

Убедитесь, что срок действия субъекта-службы не истек. См. сведения о субъекте-службе AKS и учетных данных обновления AKS.