Kubernetes блог
Контроллеры в Kubernetes: DaemonSet
DaemonSet гарантирует, что все (или некоторые) узлы запускают копию Pod. Когда узлы добавляются в кластер, к ним добавляются Pod’ы. Когда узлы удаляются из кластера, эти Pod’ы удаляются. Удаление DaemonSet приведет к очистке созданных им Pod’ов.
Некоторые типичные применения DaemonSet:
В простом случае один DaemonSet, охватывающий все узлы, будет использоваться для каждого типа демона. Более сложная установка может использовать несколько DaemonSets для одного типа демона, но с разными флагами и/или разными запросами памяти и процессора для разных типов оборудования.
Написание спецификации DaemonSet
Создание DaemonSet
Вы можете описать DaemonSet в файле YAML. Например, файл daemonset.yaml ниже описывает DaemonSet, который запускает образ Docker fluentd-elasticsearch:
Создайте DaemonSet на основе файла YAML:
Обязательные поля
Как и во всех других конфигурациях Kubernetes, для DaemonSet нужны поля apiVersion, kind и metadata.
Pod шаблон
.spec.template является шаблоном pod. Он имеет ту же схему, что и Pod, за исключением того, что он вложенный и не имеет apiVersion или kind.
В дополнение к обязательным полям для Pod, шаблон Pod в DaemonSet должен указывать соответствующие метки.
Шаблон Pod в DaemonSet должен иметь RestartPolicy, равный Always, или быть неопределенным, что по умолчанию означает Always.
Pod селектор
Когда они оба указаны, результатом будет их совместная работа (применение их обоих как связанных логическим И).
Запуск Pod’ов только на некоторых узлах
Как планируются Pod’ы демонов
Запланировано контроллером DaemonSet (по умолчанию отключено с 1.12)
Обычно машина, на которой работает Pod, выбирается планировщиком Kubernetes. Однако для Pod’ов, созданных контроллером DaemonSet, машина уже выбрана (.spec.nodeName указывается при создании Pod’а, поэтому он игнорируется планировщиком). Следовательно:
Запланировано планировщиком по умолчанию (включен по умолчанию с 1.12)
DaemonSet гарантирует, что все подходящие узлы запускают копию Pod. Обычно узел, на котором работает Pod, выбирается планировщиком Kubernetes. Однако Pod’ы DaemonSet создаются и планируются контроллером DaemonSet. Это создает следующие проблемы:
Кроме того, допуск node.kubernetes.io/unschedulable:NoSchedule автоматически добавляется в Pod’ы DaemonSet. Планировщик по умолчанию игнорирует не подлежащие планированию узлы при планировании Pod’ов DaemonSet.
Пороки и допуски (Taints и Tolerations)
Несмотря на то, что Daemon Pods учитывают пороки и допуски, следующие допуски добавляются в DaemonSet Pods автоматически в соответствии со связанными функциями.
Общение с Daemon Pod’ами
Вот некоторые возможные шаблоны для взаимодействия с Pod’ами в DaemonSet:
Обновление DaemonSet
Если метки узлов изменены, DaemonSet быстро добавит Pod’ы к новым соответствующим узлам и удалит Pod’ы из новых не соответствующих узлов.
Вы можете изменить Pod, который создает DaemonSet. Однако Pod’ы не позволяют обновлять все поля. Кроме того, контроллер DaemonSet будет использовать оригинальный шаблон при следующем создании узла (даже с тем же именем).
Вы можете выполнить раскатываемое обновление (rolling update) DaemonSet.
Альтернативы DaemonSet
Init скрипты
Безусловно, можно запускать процессы демона, непосредственно запуская их на узле (например, используя init, upstartd или systemd). Это прекрасно. Тем не менее, есть несколько преимуществ для запуска таких процессов через DaemonSet:
Голые Pod’ы
Можно создавать Pod’ы напрямую, которые указывают конкретный узел для запуска. Однако DaemonSet заменяет Pod’ы, которые были удалены или прекращены по любой причине, например, в случае сбоя узла или прерывистого обслуживания узла, например, при обновлении ядра. По этой причине вы должны использовать DaemonSet, а не создавать отдельные Pod’ы.
Статичные Pod’ы
Pod’ы можно создать, записав файл в определенный каталог, который просматривает Kubelet. Это так называемые статичные Pod’ы. В отличие от DaemonSet, статичными Pod’ами нельзя управлять с помощью kubectl или других клиентов API Kubernetes. Статичные Pod’ы не зависят от apiserver, что делает их полезными в случаях начальной загрузки кластера. Однако, в будущем статичные Pod’ы могут быть устаревшими.
Deployment
DaemonSet похожи на Deployment в том, что они оба создают Pod, и у этих Pod есть процессы, которые не должны завершаться (например, веб-серверы, серверы хранения).
Используйте Deployment для сервисов без сохранения состояния, таких как внешние интерфейсы (frontends), где увеличение и уменьшение количества реплик и развертывание обновлений важнее, чем точный контроль того, на каком хосте работает Pod. Используйте DaemonSet, когда важно, чтобы копия Pod’а всегда выполнялась на всех или определенных хостах, а также когда он должен запускаться раньше других Pod’ов.
K8S для начинающих. Первая часть
Предисловие
Что такое Kubernetes?
Kubernetes делает следующее:
Управляет и запускает контейнеры
Балансирует сетевой трафик между узлами кластера Kubernetes и количеством реплик контейнеров
Осуществляет контроль состояния, автоматические развертывания и откаты реплик контейнеров внутри узлов кластера Kubernetes
Осуществляет распределение нагрузки между узлами кластера Kubernetes
Предоставляет автоматическое монтирование систем хранения для контейнеров
Предоставляет декларативный API и CLI для управления
И еще множество полезных, и не очень, модулей и сервисов, которые можно развернуть для управления автоматизацией, инфраструктурой и контейнерами
Kubernetes не делает следующее:
Не собирает контейнеры с исходным кодом вашего приложения или сервиса
Не предоставляет процессы и решения непрерывной интеграции (CI)
Не включает в себя решения и системы сбора журналов и метрик
Не включает в себя решения и системы хранения данных
Не включает в себя решения и системы хранения контейнеров (registry)
Не включает в себя решения и системы от всех бед и болячек инфраструктуры
Kubernetes или K8S — это не просто система оркестрации. Техническое определение оркестрации — это выполнение определенного рабочего процесса: сначала сделай A, затем B, затем C. Напротив, Kubernetes содержит набор независимых, компонуемых процессов управления, которые непрерывно переводят текущее состояние к предполагаемому состоянию. Неважно, как добраться от А до С. Не требуется также и централизованный контроль. Это делает систему более простой в использовании, более мощной, надежной, устойчивой и расширяемой.
Но что если у нас таких сервисов тысячи, каждый за что-то отвечает и работает сам по себе? А если еще развернуты несколько реплик для отказоустойчивости? Как управлять всем и уделить внимание каждому из них? Как понять, что сервис правильно работает и взаимодействует с другими? Для этого есть специальные системы, оркестраторы в своем роде, такие как HashiCorp Nomad, Docker Swarm и Kubernetes. Последний используется активнее всего, так как предоставляет более гибкий функционал в контексте управления всей конструкцией приложения.
На самом деле бизнесу нужен не Kubernetes, а система, которая позволит более быстрее подходить к изменению рынка и подстраиваться под его запросы предоставления набора новых услуг или вывода старых. В НАТ.Тех мы давно используем этот инструмент и чувствуем большую разницу, как для нас, так и для наших клиентов. Исходя из нашего опыта, бизнес чаще всего ценит такие возможности К8S как собирать и тестировать только часть приложения, с которой мы работаем, что в разы уменьшает объем необходимых ресурсов; добавлять и убирать сервисы «на лету», тестировать новый функционал в разных регионах и смотреть, как он себя показывает.
Именно для этого нам и нужен Kubernetes, который дает унификацию и гибкость в способе обслуживания и содержания сервисов приложения. Kubernetes предоставляет:
Быструю и автоматическую масштабируемость. При росте нагрузки можно быстро добавить необходимые узлы приложения, а также быстро их вывести, чтобы не тратить драгоценные ресурсы
Гибкий подход в управлении. Kubernetes не потребует перестройки инфраструктуры и прочего, если вы захотели провести тестирование, внедрить новый сервис или сделать деплой по методологии blue-green
Универсальность. С помощью манифестов легко переехать, если вы захотели поменять провайдера или переезжали в свой собственный кластер
Низкий порог вхождения в использование. Kubernetes довольно легок в освоении манифестов, потому что большую часть работы он делает за вас
Если вы задумываетесь о преимуществах, описанных выше, и можете точно сказать, что вам нужна гибкость в разработке и быстрое внедрение сервисов, адаптируемый подход и универсальность в управлении большим количеством сервисов и их реплик, то думаю, что пора попробовать Kubernetes и у себя.
Однако, если ваш проект имеет постоянную нагрузку и не требует высокой степени гибкости и быстрого масштабирования, новый функционал появляется редко и у вас есть команда, уверенно работающая с существующим окружением, то на данный момент возможности K8S для бизнеса избыточны, но «посмотреть» на технологию в фоновом режиме все же стоит, так как те или иные условия могут и поменяться.
Внедрение Kubernetes
Kubernetes, так как он был реализован как облачное решение, предпочтительнее разворачивать именно в облаке.
Если вы решились ставить Kubernetes внутри, на своих собственных ресурсах, то вам придется позаботиться о развёртывании и обслуживании такой инфраструктуры вокруг кластера как: репозиторий для контейнеров, внешние или внутренние балансировщики, сетевые хранилища, хранилище секретов, решения для сбора логов и метрик. Также важна и внутренняя инфраструктура “кубера”: CertManager, Ingress, Istio и другие.
При этом существует много компаний, которые предоставляют Kubernetes как IaaS-решение, где не требуется поднимать и обслуживать окружение для кластера и процессов, которые будут на нем. Или, например, в NUT.Tech, где я сейчас работаю, разрабатываются решения “под ключ” индивидуально под запрос заказчика.
Компоненты и архитектура
Давайте поверхностно коснемся архитектуры самого K8S и его важных компонентов.
Сам кластер K8S состоит из, барабанная дробь, рабочих узлов. В узлах или нодах (Nodes, Worker nodes), помимо контейнеров компонентов самого кластера, размещаются контейнеры наших проектов и сервисов.
Worker nodes состоит из компонентов:
Плоскость управления (Master nodes) управляет рабочими узлами и подами в кластере. Там располагаются компоненты, которые управляют узлами кластера и предоставляют доступ к API.
Control plane состоит из компонентов:
Виды контроллеров
Тестовые кластеры, где потренироваться
Kubectl: как пользоваться, основные команды
При работе с кластером нам потребуется инструмент командной строки kubectl. https://Kubernetes.io/ru/docs/tasks/tools/install-kubectl/
Его можно установить на локальную машину и управлять несколькими кластерами с одной точки.
Основные команды, которые мы часто будем использовать:
Тестовый кластер
Давайте развернем свой k8s кластер на примере kind https://kind.sigs.k8s.io/
После выполнения команды посмотрим и убедимся, что все хорошо и наш кластер появился в списке.
Убедимся, что в kubectl добавился context нашего кластера
Что такое Pods
Pods или поды — это абстрактный объект в кластере K8S, который состоит из одного или нескольких контейнеров с общим хранилищем и сетевыми ресурсами, а также спецификации для запуска контейнеров.
Это главный объект в кластере, в нем прописаны, какие контейнеры должны быть запущены, количество экземпляров или реплик, политика перезапуска, лимиты, подключаемые ресурсы, узел кластера для размещения.
kube-scheduler планирует размещение пода на узлах кластера
kubelet на рабочем узле кластера запускает под
Любители забегать вперед и просто углубиться в тему могут почитать прекрасную статью на github.
Что такое Namespace
Namespace или пространство имен — это абстрактный объект, который логически разграничивает и изолирует ресурсы между подами. Вы можете рассматривать пространство имен как внутренний виртуальный кластер, который поможет вам изолировать проекты или пользователей между собой, применить разные политики квот на свои проекты или выдать права доступа только на определенную область.
default — пространство имён по умолчанию для объектов без какого-либо другого пространства имён
kube-system — пространство имён для объектов, созданных Kubernetes. Там размещаются системные поды кластера
kube-public — создаваемое автоматически пространство имён, которое доступно для чтения всем пользователям (включая также неаутентифицированных пользователей)
Размещение объектов
Давайте разместим свой первый объект в нашем тестовом кластере, для этого создадим свой namespace и положим туда простенький pod с nginx.
Чтобы создать свой namespace, нам нужно передать его спецификацию или манифест в формате yaml.
apiVersion — используемая для создания объекта версия API Kubernetes. Стоит отметить, что из версии к версии версии api могут меняться
kind — тип создаваемого объекта
metadata — данные, позволяющие идентифицировать объект (name, UID и необязательное поле namespace)
spec — требуемое состояние объекта
Давайте создадим test-namespace.yaml со следующим содержанием:
И применим его с помощью команды:
Посмотрим на результат:
Как видим, наш namespace успешно создался. Приступим к созданию своего первого пода (pod). Давайте положим контейнер с NGINX в наш namespace.
Как и с namespace, опишем его. Создадим hello.yaml
Если манифест применился то увидим:
Узнаем развернулся ли наш контейнер
Зайдем через наш браузер на http://localhost:30080/
Если вы видите в браузере:
То контейнер работает, неожиданно. 🙂
Ключевые концепции Kubernetes для службы Azure Kubernetes (AKS)
Разработка приложений продолжает двигаться в сторону подхода на основе контейнеров, что повышает потребность в организации и управлении ресурсами. Как ведущая платформа, Kubernetes обеспечивает надежное планирование рабочих нагрузок отказоустойчивых приложений. Служба Azure Kubernetes (AKS) — это управляемая среда Kubernetes, упрощающая развертывание приложений на основе контейнеров и управление ими.
В этой статье описаны:
Что такое Kubernetes?
Платформа Kubernetes, которая сейчас очень быстро развивается, предназначена для управления контейнерными приложениями и связанными с ними компонентами сети и хранилища. Основное внимание в Kubernetes уделяется рабочим нагрузкам приложений, а не базовым компонентам инфраструктуры. В Kubernetes реализуется декларативный подход к развертываниям, подкрепленный продуманным набором API-интерфейсов для операций управления.
Вы можете создавать и запускать переносимые версии современных приложений на базе микрослужб, использующие возможности Kubernetes по оркестрации и управлению доступностью для поддерживаемых компонентов приложения. Kubernetes поддерживает приложения без отслеживания состояния и с отслеживанием состояния, что очень удобно при адаптации приложений на базе микрослужб.
Kubernetes как открытая платформа позволяет создавать приложения на любом языке программирования, для любой операционной системы, с применением любых библиотек и служб сообщений. С Kubernetes можно интегрировать любые средства непрерывной интеграции и непрерывной поставки (CI/CD) для планирования и развертывания выпусков.
AKS предоставляет управляемую среду Kubernetes, которая сокращает сложность задач по развертыванию и базовому управлению, например координацию обновления. Главным уровнем управления AKS управляет платформа Azure, а вы оплачиваете работу только тех узлов AKS, где фактически выполняется ваше приложение. Служба AKS основана на использовании обработчика Службы Azure Kubernetes с открытым кодом (aks-engine).
Архитектура кластера Kubernetes
Кластер Kubernetes разделяется на два компонента:
Уровень управления
При создании кластера AKS автоматически создается и настраивается уровень управления. Этот уровень управления предоставляется бесплатно в качестве управляемого ресурса Azure от пользователя. Вы платите только за узлы, подключенные к кластеру AKS. Плоскость управления и ее ресурсы находятся только в том регионе, в котором вы создали кластер.
В уровень управления входят следующие основные компоненты Kubernetes:
| Компонент | Описание: |
|---|---|
| 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 с помощью aks-engine.
Узлы и пулы узлов
Чтобы запускать приложения и вспомогательные службы, вам нужен узел Kubernetes. Кластер AKS содержит как минимум один узел, а именно виртуальную машину Azure, которая выполняет компоненты узла Kubernetes и среду выполнения контейнера.
| Компонент | Описание: |
|---|---|
| kubelet | Агент Kubernetes обрабатывает запросы оркестрации, поступающие от уровня управления, и распределяет работу по выполнению назначенных контейнеров. |
| kube-proxy | Обрабатывает виртуальные сети на каждом узле. Этот прокси-сервер перенаправляет сетевой трафик и управляет IP-адресами для служб и модулей pod. |
| container runtime | Поддерживает выполнение контейнерных приложений, а также их взаимодействие с дополнительными ресурсами, такими как виртуальная сеть и хранилище. Кластеры AKS с использованием Kubernetes версии 1.19+ для пулов узлов Linux используют containerd в качестве среды выполнения контейнеров. Начиная с Kubernetes версии 1.20 для пулов узлов Windows, containerd можно использовать в предварительной версии для среды выполнения контейнера, но средой выполнения контейнера по умолчанию по-прежнему является Docker. Кластеры AKS, использующие предыдущие версии Kubernetes для пулов узлов, используют Docker в качестве среды выполнения контейнера. |
Размер виртуальной Машины Azure для узлов определяет количество ядер ЦП, объем памяти, а также тип и размер хранилища (высокопроизводительные твердотельные накопители или обычные жесткие диски), которые будут доступны. Планируйте размер узла относительно того, могут ли приложения потребовать большого объема ресурсов ЦП и памяти или высокопроизводительного хранилища. Вы также можете масштабировать количество узлов в кластере AKS в соответствии с текущими потребностями.
В AKS образ виртуальной машины для узлов кластера основан на Ubuntu Linux или Windows Server 2019. Когда вы создаете кластер AKS или масштабируете количество узлов, платформа Azure создает и настраивает необходимое количество виртуальных машин. Узлы агентов тарифицируются как стандартные виртуальные машины, поэтому все скидки на размер виртуальной машины (включая резервирование Azure) применяются автоматически.
Резервирование ресурсов
AKS использует ресурсы узлов, чтобы обеспечить функцию узлов в составе кластера. Такое использование может привести к расхождению между общим ресурсом вашего узла и доступными для распределения ресурсами в AKS. Эти сведения следует запомнить при настройке запросов и ограничений для развернутых пользователем модулей Pod.
Чтобы найти доступные для распределения ресурсы узла, выполните команду:
Для поддержания производительности и функциональности узла AKS резервирует ресурсы на каждом узле. По мере роста ресурсов размера узла резервирование ресурсов также увеличивается из-за более высокой потребности в управлении развернутыми пользователями модулями.
Использование надстроек AKS, таких как Container Insights (OMS), приводит к использованию дополнительных ресурсов узла.
Резервируются два типа ресурсов:
ЦП
Зарезервированная мощность ЦП зависит от типа узла и конфигурации кластера, что может привести к уменьшению доступной для распределения мощности ЦП из-за выполнения дополнительных функций.
| Ядра ЦП на узле | 1 | 2 | 4 | 8 | 16 | 32 | 64 |
|---|---|---|---|---|---|---|---|
| Зарезервированные Kube (миллиядра) | 60 | 100 | 140 | 180 | 260 | 420 | 740 |
Память
Объем памяти, используемый AKS, включает сумму двух значений.
kubelet управляющая программа
kubelet Управляющая программа устанавливается на всех узлах агента Kubernetes для управления созданием и завершением контейнеров.
По умолчанию в AKS kubelet управляющей программе задано правило вытеснения 750Mi memory.available kubelet активируется для завершения одного из запущенных модулей и освобождения памяти на хост-компьютере.
Регрессивная частота резервирования памяти для управляющей программы kubelet (kube-reserved).
Правила распределения памяти и ЦП:
Вышеуказанное резервирование ресурсов нельзя изменить.
Например, если узел предлагает 7 ГБ, он сообщит, что 34 % памяти не доступно для распределения, включая пороговое значение 750Mi жесткого вытеснения.
0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved
Помимо резервирования для Kubernetes, базовая ОС узла также резервирует ресурсы ЦП и памяти для поддержания функций ОС.
Пулы узлов
Узлы с одинаковой конфигурацией группируются в пулы узлов. Кластер Kubernetes содержит хотя бы один пул узлов. При создании кластера AKS вы указываете начальное количество и размер узлов, которые составляют пул узлов по умолчанию. В пуле узлов по умолчанию в AKS содержатся базовые виртуальные машины, на которых выполняются узлы агентов.
Чтобы обеспечить надежную работу кластера, создайте не менее 2 (двух) узлов в пуле узлов по умолчанию.
Когда вы масштабируете или обновляете кластер AKS, выбранные действия применяются именно к пулу узлов по умолчанию. Можно выбрать масштабирование или обновление определенного пула узлов. При операциях обновления все запущенные контейнеры поочередно переносятся в другие узлы в том же пуле узлов, пока все узлы не будут успешно обновлены.
Дополнительные сведения об использовании нескольких пулов узлов в AKS см. в статье Создание пулов из нескольких узлов для кластера в AKS и управление ими.
Селекторы узлов
В кластере AKS с несколькими пулами узлов может потребоваться сообщить планировщику Kubernetes, какой пул узлов использовать для данного ресурса. Например, контроллеры входящих данных не должны выполняться на узлах Windows Server.
С помощью селекторов узлов можно определять различные параметры, например ОС узла, для управления тем, где следует планировать модуль pod.
В следующем примере экземпляр NGINX планируется на узле Linux с помощью средства выбора узла «kubernetes.io/os»: linux:
Дополнительные сведения о том, где составляется расписание модулей Pod, см. в разделе рекомендации по использованию расширенных функций планировщика в AKS.
Модули pod
Для запуска экземпляров приложения Kubernetes использует модули pod. Каждый pod соответствует одному экземпляру приложения.
Для модулей Pod обычно действует сопоставление 1:1 с контейнером. В продвинутых сценариях модули pod могут содержать несколько контейнеров. Такие модули pod с несколькими контейнерами планируются на одном узле и позволяют контейнерам совместно использовать связанные с ними ресурсы.
При создании pod вы можете определить запросы ресурсов, чтобы запрашивать определенный объем ресурсов ЦП или памяти. В этом случае планировщик Kubernetes будет пытаться распределить pod в узел, содержащий достаточное количество ресурсов. Вы также можете указать максимальное ограничение на используемые ресурсы, чтобы модуль pod не потреблял слишком много вычислительных ресурсов базового узла. Лучшей методикой считается включение ограничения ресурсов для всех pod, чтобы планировщик Kubernetes лучше понимал, какие ресурсы потребуются для работы и какие можно использовать.
Pod представляет собой логический ресурс, а фактические рабочие нагрузки выполняют контейнеры. Модули pod обычно являются временными, высвобождаемыми ресурсами. Запланированным по отдельности модулям pod не хватает некоторых функций Kubernetes высокого уровня доступности и избыточности. Лучше всего доверить развертывание pod и управление ими контроллерам Kubernetes, например контроллеру развертывания.
Развертывания и манифесты YAML
Развертывание обозначает идентичные модули pod под управлением контроллера развертывания Kubernetes. Развертывание определяет количество реплик модулей pod, которые будут созданы. Планировщик Kubernetes гарантирует, что в случае возникновения проблем в модулях или узлах в работоспособных узлах будут планироваться дополнительные модули.
Вы можете обновить развертывание, изменяя конфигурацию pod, используемого образа контейнера или хранилища данных. Контроллер развертывания:
Для большинства приложений без отслеживания состояний следует использовать именно такую модель развертывания в AKS, а не распределять отдельные модули pod. Kubernetes может отслеживать работоспособность и состояние развертывания, поддерживая выполнение в кластере необходимого количества реплик. Если вы распределяете отдельные модули pod, они не перезапускаются в случае возникновения проблем и не переносятся в работоспособные узлы в случае неполадок на работающих узлах.
Если приложению требуется минимальное количество доступных экземпляров, не следует нарушать решения по управлению с помощью процесса обновления. Бюджеты неработоспособности pod определяют, сколько реплик в развертывании допустимо одновременно отключать на период обновления или изменения узлов. Например, для развертывания с 5 (пятью) репликами вы можете указать минимальное ограничение в 4 (четыре) модуля pod, чтобы за один раз можно было удалять или переназначать только одну реплику. Как и с ограничениями ресурсов для pod, мы рекомендуем всегда указывать бюджет неработоспособности pod для приложений, для которых требуется постоянное присутствие минимального количества реплик.
В следующем примере создается базовое развертывание веб-сервера NGINX. Для этого развертывания настроено создание 3 (трех) реплик и открытый порт 80 для контейнера. Также определены требуемые и максимальные объемы ресурсов ЦП и памяти.
Чтобы создать более сложные приложения, можно включить в манифест в формате YAML дополнительные службы, например подсистемы балансировки нагрузки.
Управление пакетами с помощью Helm
Helm обычно используется для управления приложениями в Kubernetes. Вы можете создавать новые или использовать существующие общедоступные диаграммы Helm, которые содержат упакованную версию кода приложения и YAML-манифесты Kubernetes для развертывания ресурсов. Эти диаграммы Helm можно хранить локально или в удаленном репозитории, например в репозитории диаграмм Helm в Реестре контейнеров Azure.
Чтобы использовать Helm, установите клиент Helm на компьютер или используйте клиент Helm в Azure Cloud Shell. С помощью клиента вы можете находить или создавать диаграммы Helm, а затем устанавливать их в кластере Kubernetes. Дополнительные сведения см. в статье Установка существующих приложений с помощью Helm в AKS.
StatefulSet и DaemonSet
Контроллер развертывания использует планировщик Kubernetes для выполнения указанного количества реплик в любом доступном узле с достаточными ресурсами. Хотя этот подход может быть достаточным для приложений без отслеживания состояния, контроллер развертывания не является идеальным для приложений, которым требуется:
Управлять такими приложениями вам позволяют два ресурса Kubernetes:
Наборы StatefulSet
Разработка современных приложений часто нацелена на приложения без отслеживания состояния. Для приложений с отслеживанием состояния, например, которые включают компоненты базы данных, можно использовать наборы StatefulSets. Как и развертывания, набор StatefulSet создает и управляет как минимум одним идентичным модулем pod. Для реплик, включенных в набор StatefulSet, соблюдаются мягкие и последовательные процессы развертывания, масштабирования, обновления и прерывания. Если используется StatefulSet, то при перемещении реплик сохраняются соглашение об именовании, сетевые имена и состояния хранилищ.
Включенные в StatefulSet реплики назначаются и выполняются в любом доступном узле кластера AKS. Чтобы убедиться, что на узле выполняется по крайней мере один модуль, вместо него следует использовать DaemonSet.
Наборы DaemonSet
Для некоторых задач сбора журналов и (или) мониторинга, возможно, потребуется выполнять модуль pod во всех узлах или в определенном наборе узлов. Объект DaemonSet также можно использовать для развертывания одного или нескольких идентичных модулей pod, однако контроллер DaemonSet гарантирует выполнение экземпляра pod на каждом из указанных узлов.
Контроллер DaemonSet может распределять модули pod в узлы в самом начале процесса загрузки кластера, еще до запуска стандартного планировщика Kubernetes. Эта возможность гарантирует, что модули pod из набора DaemonSet будут запущены раньше, чем модули pod из основного развертывания или набора StatefulSet.
Если используется надстройка Virtual Nodes, DaemonSets не будет создавать модули pod на виртуальном узле.
Пространства имен
Kubernetes ресурсы, такие как модули pod и развертывания, логически группируются в пространство имен, чтобы разделить кластер AKS и ограничить создание, просмотр и управление доступом к ресурсам. Например, вы можете создать отдельные пространства имен для разных бизнес-подразделений. Пользователи смогут взаимодействовать только с ресурсами из назначенных им пространств имен.
Когда вы создаете кластер AKS, вам доступны следующие пространства имен:
Дальнейшие действия
Из этой статьи вы узнали об основных компонентах Kubernetes и о том, как они применяются к кластерах AKS. Дополнительные сведения о ключевых понятиях Kubernetes и AKS приведены в следующих статьях:
