Основные понятия Kubernetes для Служба Azure Kubernetes (AKS)

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

Что такое Kubernetes?

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

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

Kubernetes как открытая платформа позволяет создавать приложения на любом языке программирования, для любой операционной системы, с применением любых библиотек и служб сообщений. С Kubernetes можно интегрировать любые средства непрерывной интеграции и непрерывной поставки (CI/CD) для планирования и развертывания выпусков.

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

Архитектура кластера Kubernetes

Кластер Kubernetes разделяется на два компонента:

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

Уровень управления

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

В уровень управления входят следующие основные компоненты Kubernetes:

Компонент	Description
kube-apiserver	Сервер API предоставляет базовые API Kubernetes и обеспечивает взаимодействие с средствами управления, такими как kubectl панель мониторинга Kubernetes.
etcd	etcd — это хранилище с высоким уровнем доступности key-value в Kubernetes, которое помогает поддерживать состояние кластера Kubernetes и конфигурации.
kube-scheduler	При создании или масштабировании приложений планировщик определяет, какие узлы могут запускать рабочую нагрузку и запускать определенные узлы.
kube-controller-manager	Диспетчер контроллеров контролирует ряд небольших контроллеров, выполняющих такие действия, как реплика управление модулями pod и обработка операций узлов.

Помните, что вы не можете напрямую получить доступ к плоскости управления. Уровень управления Kubernetes и обновления узла управляются с помощью Azure CLI или портала Azure. Чтобы устранить возможные проблемы, можно просмотреть журналы плоскости управления с помощью Azure Monitor.

Узлы

Чтобы запускать приложения и вспомогательные службы, вам нужен узел Kubernetes. Каждый кластер AKS имеет по крайней мере один узел, виртуальную машину Azure, которая выполняет компоненты узлов Kubernetes и среду выполнения контейнера.

Узлы включают следующие основные компоненты Kubernetes:

Компонент	Description
kubelet	Агент Kubernetes обрабатывает запросы оркестрации, поступающие от уровня управления, и распределяет работу по выполнению назначенных контейнеров.
kube-proxy	Прокси-сервер обрабатывает виртуальные сети на каждом узле, маршрутизацию сетевого трафика и управление IP-адресами для служб и модулей pod.
container runtime	Среда выполнения контейнера позволяет контейнерным приложениям запускать и взаимодействовать с другими ресурсами, такими как виртуальная сеть или хранилище. Дополнительные сведения см. в разделе "Конфигурация среды выполнения контейнера".

Размер виртуальной машины Azure для узлов определяет ЦП, память, размер и доступный тип хранилища, например ssd с высокой производительностью или обычный HDD. Спланируйте размер узла вокруг того, могут ли приложения требовать большого объема ЦП и памяти или высокопроизводительного хранилища. Вы также можете масштабировать количество узлов в кластере AKS в соответствии с текущими потребностями. Дополнительные сведения о масштабировании см. в разделе "Параметры масштабирования" для приложений в AKS.

В AKS образ виртуальной машины для узлов кластера основан на Ubuntu Linux, Azure Linux или Windows Server 2022. Когда вы создаете кластер AKS или масштабируете количество узлов, платформа Azure создает и настраивает необходимое количество виртуальных машин. Узлы агента выставляются как стандартные виртуальные машины, поэтому все скидки на размер виртуальной машины, включая резервирование Azure, автоматически применяются.

Для управляемых дисков размер диска и производительность по умолчанию назначаются в соответствии с выбранным номером SKU виртуальной машины и числом виртуальных ЦП. Дополнительные сведения см. в разделе Определение размера диска ОС по умолчанию.

Конфигурация ОС

AKS поддерживает Ubuntu 22.04 и Azure Linux 2.0 в качестве операционной системы узла для кластеров с Kubernetes 1.25 и выше. Ubuntu 18.04 также можно указать при создании пула узлов для Kubernetes версии 1.24 и ниже.

AKS поддерживает Windows Server 2022 в качестве ОС по умолчанию для пулов узлов Windows в кластерах с Kubernetes 1.25 и выше. Windows Server 2019 также можно указать при создании пула узлов для Kubernetes версии 1.32 и ниже. Windows Server 2019 отменяется после окончания срока действия Kubernetes версии 1.32 и не поддерживается в будущих выпусках. Дополнительные сведения об этом выходе из эксплуатации см. в заметках о выпуске AKS.

Конфигурация среды выполнения контейнеров

Среда выполнения контейнеров — это программное обеспечение, выполняющее контейнеры и управляющее их образами на узле. Среда выполнения помогает абстрагировать функции системных вызовов или определенных ОС для запуска контейнеров в Linux или Windows. Для пулов containerd узлов Linux используется в Kubernetes версии 1.19 и выше. Для пулов containerd узлов Windows Server 2019 и 2022 общедоступен и является единственным вариантом среды выполнения в Kubernetes версии 1.23 и выше. По состоянию на май 2023 года Docker отставлен и больше не поддерживается. Дополнительные сведения об этом выходе из эксплуатации см. в заметках о выпуске AKS.

Containerd — это основная среда выполнения контейнера, соответствующая (открытой инициативе контейнеров) OCI, которая предоставляет минимальный набор необходимых функций, чтобы выполнять контейнеры и управлять образами на узле. Сcontainerd помощью узлов и пулов узлов kubelet напрямую взаимодействует с containerd подключаемым модулем CRI (интерфейсом среды выполнения контейнера), удаляя дополнительные прыжки в потоке данных при сравнении с реализацией Docker CRI. Таким образом, вы видите лучшую задержку запуска pod и меньше ресурсов (ЦП и памяти).

Containerd работает над каждой общедоступной версией Kubernetes в AKS, в каждой версии Kubernetes, начиная с версии 1.19, и поддерживает все функции Kubernetes и AKS.

Ограничения и различия для containerd

• Для containerdэтого рекомендуется использовать crictl в качестве замены интерфейса командной строки Docker для устранения неполадок модулей pod, контейнеров и образов контейнеров на узлах Kubernetes. Дополнительные сведения см. в crictlобщих параметрах использования и конфигурации клиента.

  • Containerd не предоставляет полную функциональность Интерфейса командной строки Docker. Он доступен только для устранения неполадок.
  • crictl предлагает более понятное представление контейнеров Kubernetes, с такими понятиями, как pod и т. д., которые присутствуют.

• Containerd настраивает ведение журнала с помощью стандартного cri формата ведения журнала. Решение для ведения журнала должно поддерживать cri формат ведения журнала, например Azure Monitor для контейнеров.

• Вы больше не можете получить доступ к подсистеме /var/run/docker.sockDocker или использовать Docker-in-Docker (DinD).

  • Если вы извлекаете журналы приложений или отслеживаете данные из подсистемы Docker, используйте вместо этого контейнер Аналитика. AKS не поддерживает выполнение каких-либо команд из группы на узлах агента, которые могут вызвать нестабильность.
  • Мы не рекомендуем создавать образы или напрямую использовать подсистему Docker. Kubernetes не полностью знает об этих потребляемых ресурсах, и эти методы представляют многочисленные проблемы, как описано здесь и здесь.

• При создании образов можно продолжать использовать текущий рабочий процесс сборки Docker как обычный, если только вы не создаете образы в кластере AKS. В этом случае рекомендуется переключиться на рекомендуемый подход к созданию образов с помощью задач ACR или более безопасный вариант в кластере, например Docker Buildx.

Резервирование ресурсов

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

Чтобы найти ресурс узла, доступный для выделения, можно использовать kubectl describe node команду:

kubectl describe node [NODE_NAME]

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

ЦП

Зарезервированный ЦП зависит от типа узла и конфигурации кластера, что может привести к снижению доступности ЦП из-за выполнения дополнительных функций. В следующей таблице показано резервирование ЦП в милликорах:

Ядра ЦП на узле	1	2	4	8	16	32	64
Зарезервированные Kube (миллиядра)	60	100	140	180	260	420	740

Память

Зарезервированная память в AKS включает сумму двух значений:

AKS 1.29 и более поздних версий

1. kubelet Управляющая программа имеет правило вытеснения memory.available<100Mi по умолчанию. Это правило гарантирует, что узел имеет по крайней мере 100Mi распределить все время. Если узел находится ниже порогового значения доступной памяти, kubelet активирует завершение одного из запущенных модулей pod и освобождает память на хост-компьютере.

2. Частота резервирований памяти, установленных в соответствии с меньшим значением: 20 МБ * Max Pod, поддерживаемых на узле + 50 МБ или 25% общих ресурсов памяти системы.

   Примеры:

   • Если виртуальная машина предоставляет 8 ГБ памяти и узел поддерживает до 30 модулей pod, AKS резервирует 20 МБ * 30 Max Pods + 50 МБ = 650 МБ для зарезервированных kube. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
   • Если виртуальная машина предоставляет 4 ГБ памяти, а узел поддерживает до 70 модулей pod, AKS резервирует 25 % * 4 ГБ = 1000 МБ для kube-зарезервированных модулей, так как это менее 20 МБ * 70 Max Pods + 50 МБ = 1450 МБ.

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

Версии AKS до версии 1.29

1. kubelet Управляющая программа имеет правило вытеснения memory.available<750Mi по умолчанию. Это правило гарантирует, что узел имеет по крайней мере 750Mi распределить все время. Если узел находится ниже порогового значения доступной памяти, kubelet активирует завершение одного из запущенных модулей pod и освобождает память на хост-компьютере.
2. Регрессивная частота резервирования памяти для управляющей программы kubelet (kube-reserved).
   • 25 % от первого 4 ГБ памяти
   • 20% от следующей 4 ГБ памяти (до 8 ГБ)
   • 10% от следующей 8 ГБ памяти (до 16 ГБ)
   • 6% от следующей 112 ГБ памяти (до 128 ГБ)
   • 2 % любой памяти больше 128 ГБ

Правила выделения памяти и ЦП предназначены для следующих способов:

• Обеспечьте работоспособность узлов агентов, включая некоторые системные модули размещения, критически важные для работоспособности кластера.
• Чтобы узел сообщал меньше распределимой памяти и ЦП, чем сообщал, если он не был частью кластера Kubernetes.

Например, если узел предлагает 7 ГБ, он сообщит, что 34 % памяти не доступно для распределения, включая пороговое значение 750Mi жесткого вытеснения.

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

Помимо резервирования для Kubernetes, базовая ОС узла также резервирует ресурсы ЦП и памяти для поддержания функций ОС.

Соответствующие рекомендации см. в разделе Рекомендации по функциям базового расписания в AKS.

Пулы узлов

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

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

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

Определение размера диска ОС по умолчанию

При создании кластера или добавлении нового пула узлов в существующий кластер число виртуальных ЦП по умолчанию определяет размер диска ОС. Количество виртуальных ЦП основано на номере SKU виртуальной машины. В следующей таблице перечислены размеры дисков ОС по умолчанию для каждого номера SKU виртуальной машины:

Ядра SKU виртуальной машины (виртуальные ЦП)	Размера диска ОС по умолчанию	Подготовлено операций ввода-вывода в секунду	Подготовленная пропускная способность (Мбит/с)
1–7	P10/128G	500	100
8–15	P15/256G	1 100	125
16–63	P20/512G	2300	150
64+	P30/1024G	5000	200

Селекторы узлов

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

В следующем примере экземпляр NGINX планируется на узле Linux с помощью средства выбора узла "kubernetes.io/os": linux:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

Дополнительные сведения см. в рекомендациях по расширенным функциям планировщика в AKS.

Группа ресурсов узла

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

• Масштабируемые наборы виртуальных машин и виртуальные машины для каждого узла в пулах узлов
• Виртуальная сеть для кластера
• Хранилище для кластера

Группа ресурсов узла по умолчанию назначается имя со следующим форматом: MC_resourceGroupName_clusterName_location. Во время создания кластера можно указать имя, назначенное группе ресурсов узла. При использовании шаблона Azure Resource Manager можно определить имя с помощью nodeResourceGroup свойства. При использовании Azure CLI используется параметр с командой --node-resource-groupaz aks create , как показано в следующем примере:

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

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

Группа ресурсов узла имеет следующие ограничения:

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

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

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

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

Объекты pod

Kubernetes использует модули pod для запуска экземпляров приложения. Один модуль pod представляет один экземпляр приложения.

Для pod обычно действует сопоставление 1:1 с контейнером. В расширенных сценариях модуль pod может содержать несколько контейнеров. Модули pod с несколькими контейнерами планируются вместе на одном узле и позволяют контейнерам совместно использовать связанные ресурсы.

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

Дополнительные сведения см. в обзоре модулей pod Kubernetes и документации по жизненному циклу pod Kubernetes.

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

Развертывания и манифесты YAML

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

Контроллер развертывания управляет жизненным циклом развертывания и выполняет следующие действия.

• Убирает и прерывает заданное количество реплик.
• Создает реплики из нового определения развертывания.
• Продолжает процесс, пока не будут обновлены все реплики в развертывании.

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

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

Развертывания обычно создаются и управляются с помощью kubectl create или kubectl apply. Развертывание можно создать, определив файл манифеста в формате YAML. В следующем примере показан базовый файл манифеста развертывания для веб-сервера NGINX:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

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

Спецификация	Description
.apiVersion	Указывает группу API и ресурс API, которые необходимо использовать при создании ресурса.
.kind	Указывает тип ресурса, который требуется создать.
.metadata.name	Указывает имя развертывания. В этом примере файл YAML запускает образ nginx из Docker Hub.
.spec.replicas	Указывает количество создаваемых модулей pod. В этом примере YAML-файл создает три повторяющихся модуля pod.
.spec.selector	Указывает, какие модули pod будут затронуты этим развертыванием.
.spec.selector.matchLabels	Содержит карту пар {key, value} , которые позволяют развертыванию находить созданные модули pod и управлять ими.
.spec.selector.matchLabels.app	Должен соответствовать .spec.template.metadata.labels.
.spec.template.labels	Указывает пары {key, value} , присоединенные к объекту.
.spec.template.app	Должен соответствовать .spec.selector.matchLabels.
.spec.spec.containers	Указывает список контейнеров, принадлежащих pod.
.spec.spec.containers.name	Указывает имя контейнера, указанного в качестве метки DNS.
.spec.spec.containers.image	Указывает имя образа контейнера.
.spec.spec.containers.ports	Указывает список портов для предоставления из контейнера.
.spec.spec.containers.ports.containerPort	Указывает количество портов, предоставляемых в IP-адресе pod.
.spec.spec.resources	Указывает вычислительные ресурсы, необходимые контейнеру.
.spec.spec.resources.requests	Указывает минимальный объем необходимых вычислительных ресурсов.
.spec.spec.resources.requests.cpu	Указывает минимальный объем необходимого ЦП.
.spec.spec.resources.requests.memory	Указывает минимальный объем памяти, необходимый.
.spec.spec.resources.limits	Указывает максимальный объем разрешенных вычислительных ресурсов. Kubelet применяет это ограничение.
.spec.spec.resources.limits.cpu	Указывает максимально допустимое количество ЦП. Kubelet применяет это ограничение.
.spec.spec.resources.limits.memory	Указывает максимальный объем памяти, разрешенный. Kubelet применяет это ограничение.

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

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

Управление пакетами с помощью Helm

Helm обычно используется для управления приложениями в Kubernetes. Вы можете создавать новые или использовать существующие общедоступные диаграммы Helm, которые содержат упакованную версию кода приложения и YAML-манифесты Kubernetes для развертывания ресурсов. Эти диаграммы Helm можно хранить локально или в удаленном репозитории, например в репозитории диаграмм Helm в Реестре контейнеров Azure.

Чтобы использовать Helm, установите клиент Helm на компьютер или используйте клиент Helm в Azure Cloud Shell. С помощью клиента вы можете находить или создавать диаграммы Helm, а затем устанавливать их в кластере Kubernetes. Дополнительные сведения см. в статье Установка существующих приложений с помощью Helm в AKS.

StatefulSet и DaemonSet

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

• Постоянное соглашение об именовании или хранилище.
• Реплика, которая будет существовать на каждом узле "select" в кластере.

Однако два ресурса Kubernetes позволяют управлять этими типами приложений: StatefulSets и DaemonSets.

StatefulSets поддерживает состояние приложений за пределами отдельного жизненного цикла pod. DaemonSets гарантирует выполнение экземпляра на каждом узле в начале процесса начальной загрузки Kubernetes.

Наборы StatefulSet

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

Вы можете определить приложение в формате YAML с помощью kind: StatefulSet. После этого контроллер StatefulSet обрабатывает развертывание и управление необходимыми репликами. Данные записываются в постоянное хранилище, предоставляемое Azure Управляемые диски или Файлы Azure. При использовании StatefulSet базовое постоянное хранилище сохраняется даже после удаления StatefulSet.

Дополнительные сведения см. в документации по StatefulSet в Kubernetes.

Наборы DaemonSet

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

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

Как и StatefulSets, можно определить daemonSet в рамках определения YAML с помощью kind: DaemonSet.

Дополнительные сведения см. в документации по DaemonSet в Kubernetes.

Пространства имен

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

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

Пространство имен	Description
default	Здесь по умолчанию создаются модули pod и развертывания, для которых не указано пространство имен. В небольших средах вполне допустимо развертывать все приложения в пространстве имен по умолчанию, не создавая дополнительные логические разделы. Если при любом взаимодействии с API Kubernetes, например через kubectl get pods, не указано конкретное пространство имен, всегда используется пространство имен по умолчанию.
kube-system	Здесь содержатся основные ресурсы, такие как DNS, прокси-сервер и другие сетевые компоненты, а также панели мониторинга Kubernetes. Обычно вам не нужно развертывать приложения в этом пространстве имен.
kube-public	Как правило, он не используется для отображения ресурсов во всем кластере и может просматриваться любым пользователем.

Дополнительные сведения см. в документации по пространствам имен в Kubernetes.

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

Дополнительные сведения о ключевых понятиях Kubernetes и AKS приведены в следующих статьях:

• Доступ и удостоверение AKS
• Безопасность AKS
• Виртуальные сети AKS
• Хранилище AKS
• Масштабирование AKS