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

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

В этой статье приведены основные понятия:

• Компоненты инфраструктуры Kubernetes:

  • уровень управления
  • узлы
  • пулы узлов

• Ресурсы рабочей нагрузки:

  • модули pod
  • deployments
  • наборы

• Группировать ресурсы с помощью пространств имен.

Что такое Kubernetes?

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

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

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

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

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

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

• Уровень управления: предоставляют основные службы Kubernetes и управляют рабочими нагрузками приложения.
• Узлы: непосредственно выполняют рабочие нагрузки приложения.

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

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

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

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

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

И хотя вам не нужно настраивать компоненты (например, высокодоступное хранилище etcd) для этого настраиваемого уровня управления, доступ к уровню управления напрямую невозможен. Уровень управления Kubernetes и обновления узла управляются с помощью Azure CLI или портала Azure. Для устранения возникших неполадок вы можете изучить журналы главного уровня управления с помощью журналов Azure Monitor.

Чтобы настроить уровень управления или получить к нему прямой доступ, разверните самоуправляемый кластер Kubernetes с помощью Cluster API Provider Azure.

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

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

Узлы и пулы узлов

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

Компонент	Description
kubelet	Агент Kubernetes обрабатывает запросы оркестрации, поступающие от уровня управления, и распределяет работу по выполнению назначенных контейнеров.
kube-proxy	Обрабатывает виртуальные сети на каждом узле. Этот прокси-сервер перенаправляет сетевой трафик и управляет IP-адресами для служб и модулей pod.
container runtime	Позволяет контейнерным приложениям запускать и взаимодействовать с дополнительными ресурсами, такими как виртуальная сеть или хранилище. Кластеры AKS с использованием Kubernetes версии 1.19+ для пулов узлов Linux используют containerd в качестве среды выполнения контейнеров. Начиная с Kubernetes версии 1.20 для пулов узлов Windows, containerd можно использовать в предварительной версии для среды выполнения контейнера, но средой выполнения контейнера по умолчанию по-прежнему является Docker. Кластеры AKS, использующие предыдущие версии Kubernetes для пулов узлов, используют Docker в качестве среды выполнения контейнера.

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

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

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

Если требуется расширенная конфигурация и контроль над средой выполнения контейнера Kubernetes и операционной системой, можно развернуть самостоятельно управляемый кластер с помощью Cluster API Provider Azure.

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

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

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

kubectl describe node [NODE_NAME]

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

Примечание.

Использование надстроек AKS, таких как Container Insights (OMS), приводит к использованию дополнительных ресурсов узла.

Резервируются два типа ресурсов:

ЦП

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

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

Память

Объем памяти, используемый AKS, включает сумму двух значений.

Важно!

Предварительная версия AKS 1.29 в январе 2024 года и включает некоторые изменения в резервирования памяти. Эти изменения подробно описаны в следующем разделе.

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 Управляющая программа устанавливается на всех узлах агента Kubernetes для управления созданием и завершением контейнера. По умолчанию в AKS kubelet управляющая программа имеет правило вытеснения памяти.доступно<750Mi , гарантируя, что узел всегда должен иметь по крайней мере 750Mi распределить все время. Если значение памяти на узле оказывается ниже указанного порогового, kubelet активируется для завершения одного из запущенных модулей и освобождения памяти на хост-компьютере.

2. Регрессивная частота резервирования памяти для управляющей программы kubelet (kube-reserved).

   • 25 % от первого 4 ГБ памяти
   • 20% от следующей 4 ГБ памяти (до 8 ГБ)
   • 10% от следующей 8 ГБ памяти (до 16 ГБ)
   • 6% от следующей 112 ГБ памяти (до 128 ГБ)
   • 2 % любой памяти выше 128 ГБ

Примечание.

AKS резервирует дополнительные 2 ГБ для системного процесса на узлах Windows, которые не входят в вычисленный объем памяти.

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

• Обеспечьте работоспособность узлов агентов, включая некоторые системные модули размещения, критически важные для работоспособности кластера.
• Чтобы узел сообщал меньше распределимой памяти и ЦП, чем сообщал, если он не был частью кластера 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.

Пулы узлов

Примечание.

Пул узлов Linux Azure теперь общедоступен (общедоступная версия). Дополнительные сведения о преимуществах и действиях по развертыванию см. в статье "Общие сведения о узле контейнеров Linux Azure для AKS".

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

Примечание.

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

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

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

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

В кластере 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

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

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

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

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

Группа ресурсов узла по умолчанию назначается имя, например MC_myResourceGroup_myAKSCluster_eastus. Во время создания кластера также можно указать имя, назначенное группе ресурсов узла. При удалении кластера AKS поставщик ресурсов AKS автоматически удаляет группу ресурсов узла.

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

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

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

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

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

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

Предупреждение

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

Объекты pod

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

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

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

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

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

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

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

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

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

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

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

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

В следующем примере создается базовое развертывание веб-сервера NGINX. Для этого развертывания настроено создание 3 (трех) реплик и открытый порт 80 для контейнера. Также определены требуемые и максимальные объемы ресурсов ЦП и памяти.

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	Указывает имя развертывания. Этот файл будет запускать образ nginx из Docker Hub.
.spec.replicas	Указывает количество создаваемых модулей pod. Этот файл создаст три повторяющихся модуля 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 поддерживает состояние приложений за пределами отдельного жизненного цикла pod.
• Наборы DaemonSet, которые обеспечивают запуск экземпляров на каждом узле с самых ранних этапов начальной загрузки Kubernetes.

Наборы StatefulSet

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

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

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

Включенные в StatefulSet реплики назначаются и выполняются в любом доступном узле кластера AKS. Чтобы убедиться, что на узле выполняется по крайней мере один модуль, вместо него следует использовать DaemonSet.

Наборы DaemonSet

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

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

DaemonSet, как и StatefulSet, включается в определение YAML с помощью kind: DaemonSet.

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

Примечание.

Если используется надстройка Virtual Nodes, DaemonSets не будет создавать модули pod на виртуальном узле.

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

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

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

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

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

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

Из этой статьи вы узнали об основных компонентах Kubernetes и о том, как они применяются к кластерах AKS. Дополнительные сведения о ключевых понятиях Kubernetes и AKS приведены в следующих статьях:

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