Как использовать наборы демонов 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, так и контейнеров

Перейти к верхней панели