Вопросы и ответы о Службе Azure Kubernetes (AKS)

В этой статье представлены ответы на часто задаваемые вопросы о Службе Azure Kubernetes.

В каких регионах Azure в настоящее время предоставляется служба AKS?

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

Может ли кластер AKS охватывать несколько регионов?

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

Может ли кластер AKS охватывать несколько зон доступности?

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

Можно ли ограничить доступ пользователей к серверу API Kubernetes?

Да. Доступ к серверу API можно ограничить двумя способами.

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

Могут ли в одном кластере быть виртуальные машины разных размеров?

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

Применяются ли обновления для системы безопасности к узлам агентов AKS?

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

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

Какое ограничение размера для образа контейнера в AKS?

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

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

Узлы Windows Server

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

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

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

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

Как управляемый уровень управления взаимодействует с моими узлами?

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

Можно ли использовать полное доменное имя сервера API вместо IP-адреса кластера?

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

Почему с AKS создаются две группы ресурсов?

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

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

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

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

   Примечание.

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

Можно ли указать собственное имя для группы ресурсов узла AKS?

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

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

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

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

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

Можно ли изменять теги и другие свойства ресурсов AKS в группе ресурсов узла?

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

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

Примечание.

В прошлом имя тега "Владелец" было зарезервировано для AKS для управления общедоступным IP-адресом, назначенным на интерфейсном IP-адресе loadbalancer. Теперь службы следуют за aks-managed префиксом. Для устаревших ресурсов не используйте политики Azure для применения имени тега "Владелец". В противном случае все ресурсы в развертывании кластера AKS и операциях обновления будут нарушены. Это не относится к вновь созданным ресурсам.

Какие контроллеры допуска Kubernetes поддерживает AKS? Можно ли добавлять и удалять контроллеры допуска?

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

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

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

Можно ли использовать веб-перехватчики контроллеров допуска в AKS?

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

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

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

Могут ли веб-перехватчики контроллеров допуска влиять на kube-system и внутренние пространства имен AKS?

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

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

Метка "admissions.enforcer/disabled": "true" или заметка "admissions.enforcer/disabled": true

Интегрируется ли Azure Key Vault с AKS?

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

Можно ли запускать контейнеры Windows Server в AKS?

Да, контейнеры Windows Server доступны в AKS. Чтобы запустить контейнеры Windows Server в AKS, создайте пул узлов с Windows Server в качестве гостевой ОС. Контейнеры Windows Server могут использовать только Windows Server 2019. Чтобы приступить к работе, см. статью Создание кластера AKS с пулом узлов Windows Server.

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

AKS предлагает соглашение об уровне обслуживания?

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

У ценовой категории "Бесплатный" нет связанного соглашения об уровне обслуживания, но имеется цель уровня обслуживания 99,5%. При возникновении временных проблем с подключением возникают проблемы с обновлением, неработоспособными узлами подложки, обслуживанием платформы, приложением перегружен сервер API с запросами и т. д. Для критически важных рабочих нагрузок и рабочих нагрузок или если рабочая нагрузка не допускает перезапуска сервера API, рекомендуется использовать уровень "Стандартный", который включает соглашение об уровне обслуживания от времени простоя.

Можно ли применять скидки на резервирования Azure к узлам агента AKS?

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

Можно ли переносить кластер между клиентами Azure?

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

Можно ли переносить кластер между подписками?

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

Можно ли переместить кластеры AKS из текущей подписки Azure в другую?

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

Можно ли переносить кластер AKS или ресурсы инфраструктуры кластера в другие группы ресурсов или переименовывать их?

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

Почему удаление моего кластера занимает так много времени?

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

Почему создание или обновление кластера занимает столько времени?

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

Можно ли восстановить кластер после его удаления?

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

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

Что такое поддержка платформы и что такое поддержка платформы?

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

• Функции и компоненты Kubernetes
• Создание кластера или пула узлов
• Исправления
• Исправления ошибок
• Исправления системы безопасности
• Устаревшие компоненты

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

AKS использует выпуски и исправления из Kubernetes, который является проектом с открытым исходным кодом, который поддерживает только скользящее окно из трех дополнительных версий. AKS может гарантировать полную поддержку, пока эти версии обслуживаются вышестоящий. Так как никаких исправлений, создаваемых вышестоящий, AKS может либо оставить эти версии неотвеченными или вилками. Из-за этого ограничения поддержка платформы не поддерживает ничего от использования kubernetes вышестоящий.

Автоматически ли AKS обновляет неподдерживаемые кластеры?

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

Например, kubernetes версии 1.25 обновляется до версии 1.26 во время выпуска общедоступной версии 1.29. Чтобы свести к минимуму нарушения, настройте периоды обслуживания. Дополнительные сведения о каналах автоматического обновления см. в статье об автоматическом обновлении .

Можно ли обновить кластер, если имеются модули pod или развертывания в состоянии NodeLost или Unknown?

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

Можно ли выполнить обновление, если один или несколько узлов кластера находятся в неработоспособном состоянии или их работа завершена?

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

При запуске удаления кластера выводится сообщение об ошибке [Errno 11001] getaddrinfo failed

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

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

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

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

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

Можно ли масштабировать кластер AKS до нуля?

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

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

Можно ли использовать API масштабируемого набора виртуальных машин для масштабирования вручную?

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

Можно ли использовать Масштабируемые наборы виртуальных машин для ручного масштабирования до нуля узлов?

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

Можно ли остановить все виртуальные машины или отменить их выделение?

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

Можно ли использовать пользовательские расширения виртуальных машин?

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

Хранит ли AKS данные клиентов за пределами региона кластера?

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

Требуется ли запускать образы 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

Что такое прозрачный режим и режим моста в Azure CNI?

Начиная с версии 1.2.0 Azure CNI по умолчанию задает прозрачный режим для развертываний Linux CNI с одним клиентом. Прозрачный режим приходит на замену режиму моста. В следующих разделах "Режим моста" и "Прозрачный режим " мы обсудим больше о различиях между обоими режимами и преимуществами и ограничениями для прозрачного режима в Azure CNI.

Режим моста

Режим моста Azure CNI создает мост L2 с именем Azure0 в режиме "просто во времени". Все интерфейсы пар pod veth на стороне узла подключены к этому мосту. Обмен данными между виртуальными машинами Pod и оставшийся трафик проходят через этот мост. Мост — это виртуальное устройство уровня 2, которое самостоятельно не может получать или передавать что-либо, если вы не привязываете к нему один или несколько реальных устройств. По этой причине эта0 виртуальной машины Linux должна быть преобразована в подчиненный мост azure0, который создает сложную сетевую топологию на виртуальной машине Linux. В качестве симптома CNI пришлось обрабатывать другие сетевые функции, такие как обновления DNS-сервера.

В следующем примере показано, как выглядит настройка ip-маршрута в режиме моста. Независимо от того, сколько модулей pod имеет узел, существует только два маршрута. Первый маршрут говорит, что трафик (за исключением локального в Azure0) переходит к шлюзу подсети по умолчанию через интерфейс с ip-адресом src 10.240.0.4, который является основным IP-адресом узла. Второй — "10.20.x.x.x" — пространство pod для ядра для принятия решения.

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

Прозрачный режим

Прозрачный режим использует простой подход к настройке сети Linux. В этом режиме Azure CNI не изменяет свойства интерфейса eth0 на виртуальной машине Linux. Этот подход к изменению свойств сети Linux помогает сократить сложные проблемы, с которыми кластеры могут столкнуться с режимом моста. В прозрачном режиме Azure CNI создает и добавляет интерфейсы пар pod veth на стороне узла, которые добавляются в сеть узлов. Взаимодействие между виртуальными машинами pod и pod осуществляется через IP-маршруты, добавленные CNI. По сути, обмен данными pod-to-Pod превышает правила маршрутизации уровня 3 и L3, маршрутивный трафик pod.

В следующем примере показана настройка ip-маршрута прозрачного режима. Интерфейс каждого pod получает статический маршрут, подключенный таким образом, чтобы трафик с ip-адресом dest, так как pod отправляется непосредственно в интерфейс пары сторон veth pod.

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

Преимущества прозрачного режима

• Удается устранить последствия параллельного состояния гонки DNS conntrack и избежать проблем с 5-секундной задержкой DNS без необходимости настраивать локальную службу DNS узла (при этом локальную DNS-службу узла можно использовать для повышения производительности).
• Устраняется начальная задержка DNS в 5 секунд, которая сейчас существует в CNI из-за операций JIT в режиме моста.
• Одним из основных случаев в режиме моста является то, что Azure CNI не может обновлять настраиваемый DNS-сервер списков пользователей, добавляемых в виртуальную сеть или сетевой адаптер. Этот сценарий приводит к сбору CNI только первого экземпляра списка DNS-серверов. Эта проблема устранена в прозрачном режиме, так как CNI не изменяет свойства eth0. Дополнительные сведения см. здесь.
• Обеспечивает лучшую обработку трафика UDP и устранение рисков для шторма наводнений UDP при истечении времени ожидания ARP. В режиме моста, когда мост не знает MAC-адрес целевого модуля pod во взаимодействии внутри виртуальной машины pod-to-Pod-Pod с помощью конструктора, он приводит к шторму пакета ко всем портам. Эта проблема устранена в прозрачном режиме, так как на пути нет устройств L2. Дополнительные сведения см. здесь.
• Прозрачный режим лучше работает в режиме внутри виртуальной машины Pod-to-Pod с точки зрения пропускной способности и задержки при сравнении с режимом моста.

Как избежать медленных проблем, связанных с настройкой прав владения разрешениями при наличии многочисленных файлов тома?

Традиционно, если модуль 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: детализированный контроль за изменениями разрешений тома.

Можно ли использовать библиотеки шифрования FIPS с развертываниями в AKS?

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

Можно ли настроить группы безопасности сети с AKS?

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

Как работает синхронизация времени в AKS?

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

Как обновляются надстройки AKS?

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

Что такое расширение AKS Linux, установленное на экземплярах Масштабируемые наборы виртуальных машин Linux?

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

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

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

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

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