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

Kubernetes — это ведущий движок с открытым исходным кодом, который управляет контейнерными приложениями .

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

Что такое набор демонов Kubernetes?

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

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

Наборы демонов — неотъемлемая часть кластера Kubernetes, позволяющая администраторам легко настраивать службы (модули) на всех узлах или их подмножестве.

Варианты использования DaemonSet

Наборы демонов могут повысить производительность кластера Kubernetes, распределяя задачи обслуживания и службы поддержки посредством развертывания модулей на всех узлах. Они хорошо подходят для долговременных служб, таких как мониторинг или сбор журналов. Ниже приведены некоторые примеры использования DaemonSets:

• Чтобы запустить демон для хранения кластера на каждом узле, например, glusterd и ceph.
• Чтобы запустить демон для сбора журналов на каждом узле, например Fluentd и logstash.
• Для запуска демона для мониторинга узлов на каждой заметке, например Prometheus Node Exporter, collectd или агент Datadog.

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

Планирование модулей DaemonSet

По умолчанию узел, на котором работает модуль, определяется планировщиком Kubernetes. Однако модули DaemonSet создаются и планируются контроллером DaemonSet. Использование контроллера DaemonSet может привести к непоследовательному поведению пода и проблемам с вытеснением приоритета пода.

Чтобы смягчить эти проблемы, Kubernetes (ScheduleDaemonSetPods) позволяет пользователям планировать DaemonSets с помощью планировщика по умолчанию вместо контроллера DaemonSet. Это делается путем добавления термина NodeAffinity в модули DaemonSet вместо термина .spec.nodeName. Затем планировщик по умолчанию используется для привязки модуля к целевому хосту.

Ниже приведен пример конфигурации NodeAffinity:

апиВерсия : v1
вид : метаданные 
модуля : 
имя : nginx 
spec : 
affinity : 
nodeAffinity : 
requiredDuringSchedulingIgnoredDuringExecution : 
nodeSelectorTerms : -matchExpressions : # Имя ключа -key : оператор типа             диска
 : In # Значения 
значений : -ssd


 


контейнеры : - имя : nginx

изображение : nginx
imagePullPolicy : IfNotPresent

Выше мы настроили NodeAffinity так, чтобы модуль создавался только на узле с меткой «disktype=ssd».

Кроме того, модули DaemonSet соответствуют ограничениям и допускам в Kubernetes. Допуск node.kubernetes.io/unschedulable:NoSchedule автоматически добавляется в модули DaemonSet. (Для получения дополнительной информации о taints и допусках обратитесь к официальной документации Kubernetes .)

Как создать DaemonSet

Как и любой другой компонент в Kubernetes, наборы демонов настраиваются с помощью файла YAML. Давайте посмотрим на структуру файла DaemonSet.

apiVersion : приложения / v1
вид : 
метаданные DaemonSet : 
имя : test - daemonset
 пространство имен : test - daemonset - namespace Метки : 
app - type : test - app - type 

спецификация : шаблон : 
метаданные : 
метки : 
имя : test - daemonset - container

селектор : 
matchLabels : 
имя : test - daemonset - container

Как вы можете заметить в приведенной выше структуре, apiVersion , kind и метаданные являются обязательными полями в каждом манифесте Kubernetes. Специфические поля DaemonSet находятся в разделе спецификаций — оба эти поля являются обязательными.

• шаблон. Это определение модуля для модуля, который необходимо развернуть на всех узлах. Шаблон pod в DaemonSet должен иметь параметр RestartPolicy, установленный на «Всегда», и по умолчанию он будет принимать значение «Всегда», если вы не указали RestartPolicy.
• селектор. Селектор для модулей, управляемых DaemonSet. Это значение должно быть меткой, указанной в шаблоне модуля. (В приведенном выше примере мы использовали имя: test-daemonset-container в качестве селектора.) Это значение является фиксированным и не может быть изменено после первоначального создания DaemonSet. Изменение этого значения приведет к тому, что модули, созданные с помощью этого DaemonSet, будут потеряны. Kubernetes предлагает два способа сопоставления matchLabels и matchExpressions для создания сложных селекторов.

Другие необязательные поля

• template.spec.nodeSelector — можно использовать для указания подмножества узлов, которые создадут под, соответствующий указанному селектору.
• template.spec.affinity — это поле можно настроить для установки сходства, при котором модуль будет запускаться только на узлах, соответствующих настроенному сходству.

Создание набора демонов

Теперь приступим к созданию примера DaemonSet. Здесь мы будем использовать образ «fluent-elasticsearch», который будет работать на каждом узле в кластере Kubernetes. Затем каждый модуль будет собирать журналы и отправлять данные в ElasticSearch.

daemonset-example.yaml

apiVersion : приложения / v1
kind : 
метаданные DaemonSet : 
name : fluentd- elasticsearch - test namespace
 : default # Name Space 
labels : 
k8s - app : fluentd - logging   
spec : 
selector : # Selector 
matchLabels :  
name : fluentd- elasticsearch - test - deamonset template
 : # Метаданные 
шаблона пода : 
labels : 
name : fluentd - asticsearch - test - deamonset  
spec : 
tolerations : #Tolerations - key : node - role . кубернет . ио / мастер 

эффект : NoSchedule 
containers : # Container Details — name : fluentd — elasticsearch  

изображение : набережная . io / fluentd_elasticsearch / fluentd : v2 . 5.2 
ресурсы : 
лимиты : 
память : 200Ми 
запросы : 
ЦП : 100М 
память : 
200Ми VolumeMounts : - имя : varlog   

mountPath : /var / имя журнала
 : varlibdockercontainers 
путь монтирования : /var/ lib / docker / Containers 
readOnly : true 
TerminationGracePeriodSeconds : 30 
томов : - имя : varlog  

hostPath : 
путь : /var / имя журнала
 : varlibdockercontainers 
hostPath : 
путь : /var/ lib / docker / Containers

Во-первых, давайте создадим DaemonSet с помощью команды kubectl create и получим информацию о DaemonSet и pod следующим образом:

kubectl create -f daemonset - example . батат

kubectl получить daemonset

kubectl get pod - широкий

Как видно из приведенного выше вывода, наш DaemonSet успешно развернут.

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

Обновление наборов демонов

Когда дело доходит до обновления наборов DaemonSet, если метка узла изменена, DaemonSet автоматически добавит новые модули к совпадающим узлам, удаляя модули с несовпадающих узлов. Мы можем использовать команду «kubectl apply» для обновления DaemonSet, как показано ниже.

Есть две стратегии, которым можно следовать при обновлении наборов демонов:

• Стратегия по умолчанию в Kubernetes, она удаляет старые модули DaemonSet и автоматически создает новые модули при обновлении шаблона DaemonSet.
• При использовании этого параметра новые модули DaemonSet создаются только после того, как пользователь вручную удалит старые модули DaemonSet.

Эти стратегии можно настроить с помощью параметра spec.updateStrategy.type.

Удаление наборов демонов

Удаление DaemonSet — простая задача. Для этого просто запустите команду удаления kubectl с DaemonSet. Это удалит DaemonSet со всеми базовыми модулями, которые он создал.

Мы можем использовать флаг cascade=false в команде удаления kubectl, чтобы удалить только DaemonSet без удаления модулей.

Взаимодействие с модулями, созданными DaemonSet

Существует несколько способов связи с модулями, созданными DaemonSets. Вот некоторые доступные варианты:

• Толкать. Таким образом, модули могут быть настроены для отправки информации в другие службы (служба мониторинга, база данных статистики). Однако они не получают никаких данных.
• NodeIP и известный порт. Поды доступны через IP-адреса узлов, использующие hostPort. Затем пользователи могут использовать известные порты и IP-адрес узла для связи с модулями.
• DNS. В этом методе пользователи могут настроить безголовую службу с тем же селектором pod для обнаружения DaemonSet с использованием ресурса конечных точек.
• Обслуживание. Чтобы выбрать случайный узел в DaemonSet, который мы можем использовать для создания службы с тем же селектором модуля.

Сводка DaemonSet

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