Ответ
Для этого используется контроллер DaemonSet. Его основная задача — поддерживать запущенную копию pod на всех (или выбранных) узлах кластера. Я применяю DaemonSet для системных сервисов.
Базовый пример DaemonSet для агента мониторинга:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: node-exporter
namespace: monitoring
spec:
selector:
matchLabels:
app: node-exporter
template:
metadata:
labels:
app: node-exporter
spec:
# Селектор узлов: запускать только на worker-нодах
nodeSelector:
node-role.kubernetes.io/worker: ""
# Толерантности: разрешить запуск на нодах с taint
tolerations:
- key: "node-role.kubernetes.io/master"
operator: "Exists"
effect: "NoSchedule"
containers:
- name: node-exporter
image: prom/node-exporter:latest
ports:
- containerPort: 9100
hostPort: 9100 # Проброс порта на хост
securityContext:
privileged: true # Для доступа к системным метрикам
Ключевые аспекты и примеры использования:
- Системный мониторинг: Node Exporter, Datadog agent, Fluentd для сбора логов.
- Сетевые плагины: Calico, Cilium (их компоненты часто работают как DaemonSet).
- Хранилище: GlusterFS, Ceph (демоны для управления хранилищем на каждой ноде).
Управление размещением:
nodeSelector: Запуск только на нодах с определенными лейблами.tolerations: Позволяет pod быть запланированным на ноды с taint (например, на master-ноды).affinity/anti-affinity: Более сложные правила размещения относительно других pod.
Отличие от Deployment: Deployment управляет количеством pod-реплик, которые могут быть размещены на любых нодах. DaemonSet же гарантирует ровно один pod на ноду (соответствующую селекторам). При добавлении новой ноды в кластер DaemonSet автоматически создаст на ней pod.