В этой публикации я продолжу рассказывать про систему мониторинга Zabbix. Только на этот раз я покажу, как выполняется мониторинг Kubernetes в Zabbix. Это типовой вариант мониторинга на основе шаблона, который идет “Из коробки”. На странице документации Zabbix есть описание этого шаблона.
Основная суть работы этого шаблона заключается в том, что он создает определенное количество объектов в кластере Kubernetes (поды, сервисы и т.д.), которые будут непосредственно отдавать данные при запросе данных сервером Zabbix.
Описание демонстрационной среды
Ниже я приведу схему моего доменстрационного кластера Kubernetes.
В кластере настроен один сервер управления и две ноды для рабочей нагрузки.
IP-адреса узлов и их описание приведены в таблице ниже.
| Узел Кластера | IP-адрес | Описание |
| master01 | 10.10.10.59 | Узел управления |
| worker01 | 10.10.10.58 | Узел рабочей нагрузки |
| worker02 | 10.10.1057 | Узел рабочей нагрузки |
Также в демонстрационной среде установлен Zabbix Server 6.2.
Как я уже говорил ранее, для настройки мониторинга Kubernetes я буду использовать стандартный шаблон для Zabbix сервера.
Предварительные требования
Перед началом настройки мониторинга необходимо установить Helm на тот узел кластера или рабочую станцию, с которого(ой) будет осуществляться управление кластером Kubernetes.
Я установлю Helm на узел master01 кластера Kubernetes.
Мониторинг Kubernetes – настройка
Приступим к настройке мониторинга. Тем более, что каких-то особых сложностей настройка мониторинга Kubernetes в Zabbix не должна составлять.
Подготовка
Самый первый подготовительный шаг – это развертывание Zabbix в Kubernetes через Helm Chart.
Нужно выполнить следующее:
1. Добавить Helm репозиторий:
helm repo add zabbix-chart-6.0 https://cdn.zabbix.com/zabbix/integrations/kubernetes-helm/6.0roman@master01:~$ helm repo add zabbix-chart-6.0 https://cdn.zabbix.com/zabbix/integrations/kubernetes-helm/6.0
"zabbix-chart-6.0" has been added to your repositories
roman@master01:~$
2. Экспортировать в файл содержимое диаграммы helm-zabbix:
helm show values zabbix-chart-6.0/zabbix-helm-chrt > $HOME/zabbix_values.yaml3. Далее я создам отдельное пространство имен в Kubernetes. Именно в этом пространстве имен и будет развернут Zabbix:
kubectl create namespace monitoring4. Запустим развертывание диаграммы Helm для Zabbix в пространстве имен monitoring:
helm install zabbix zabbix-chart-6.0/zabbix-helm-chrt --dependency-update -f $HOME/zabbix_values.yaml -n monitoring5. Проверим состояние развертывания. Убедимся, что все поды развернулись и запустились успешно:
kubectl get pods -n monitoringroman@master01:~$ kubectl get pods -n monitoring
NAME READY STATUS RESTARTS AGE
zabbix-agent-jwv4q 0/1 Running 0 10s
zabbix-agent-v2gwg 0/1 Running 0 10s
zabbix-kube-state-metrics-56b6f796bc-hpzx5 0/1 Running 0 10s
zabbix-proxy-656f885bdb-cmjh7 0/1 Running 0 10s
roman@master01:~$ 
6. Также проверим все ли создались сервисы – их должно быть три штуки:
kubectl get svc -n monitoringroman@master01:~$ kubectl get svc -n monitoring
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
zabbix-kube-state-metrics ClusterIP 10.101.135.231 <none> 8080/TCP 116s
zabbix-zabbix-helm-chrt-agent ClusterIP 10.98.46.173 <none> 10050/TCP 116s
zabbix-zabbix-helm-chrt-proxy ClusterIP 10.100.68.71 <none> 10051/TCP 116s
roman@master01:~$
7. Последним шагом необходимо сгенерировать токен доступа для сервисной учетной записи. Этот токен мы будем использовать в шаблонах мониторинга.
kubectl get secret zabbix-service-account -n monitoring -o jsonpath={.data.token} | base64 -d && echoroman@master01:~$ kubectl get secret zabbix-service-account -n monitoring -o jsonpath={.data.token} | base64 -d && echo
eyJhbGciOiJSUzI1NiIsImtpZCI6IkxVVHpfdjJKcHB1WUtIZk9NQ09rSk92RkFIZERhdm5iRl9scGpTb3VGNjgifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtb25pdG9yaW5nIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InphYmJpeC1zZXJ2aWNlLWFjY291bnQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiemFiYml4LXNlcnZpY2UtYWNjb3VudCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjcyNzE0MGRkLTRlOTAtNGYyNy04YzdiLWMyNzRiYjZiNDU2MyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptb25pdG9yaW5nOnphYmJpeC1zZXJ2aWNlLWFjY291bnQifQ.bFo6b8vzYEtpMKt69EPhx0GN80yXajsFAVzKiiy9zpOdDvq7eWq3V_E75H_m1PgB7kxHxQ3Q-ztuRKsfG094PygqR5_za-Uoijj_hYWN1TZCI--kwQORvAUaiz1Q7sSjUs0M7337VNvcOgg7w6w2ZWDl0ofGRlt0y9G5ZyAMQamZHx7E13kFNeFQNZr8-Z5GSaAxSPto0-tXazNs434orWDR5_IFfuzSA4AN3MCFwBgj8GpsTSZfdFfqjy3kz1F1ot8kWl_2ZjV_CoFtzAvjxcILvuJR8Q30DZu89msmQhLMYQiVxHjf8gQUY6gX-K7xm4rx3y3d2yburTvZHDEJeA
roman@master01:~$ 
Сохраните этот токен доступа – он нам еще понадобится.
Предварительная подготовка кластера Kubernetes в виде развертывания диаграммы Helm и генерации токена доступа завершена.
Настройка мониторинга узлов кластера Kubernetes
Мы с вами завершили предварительную подготовку на стороне кластера Kubernetes. Теперь переходим к Zabbix. Сначала создадим в настройках Zabbix фиктивный узел, который будет использоваться для мониторинга узлов рабочей нагрузки.
Какие шаги необходимо выполнить:
1. Перейти в веб панель администрирования сервера Zabbix.
2. Перейти в раздел “Configurations – Hosts“.
3. Нажать кнопку “Create Host“.
На вкладке “Host” вы можете указать произвольное имя (которое позволит понять зачем нужен этот фиктивный узел) и группу хоста. Обратите внимание на пустую секцию с указанием интерфейсов – так и должно быть. Это фиктивный хост. Всю необходимую информацию об актуальных узлах кластера мы получим от API Kubernetes. Важный момент – это выбор шаблона. Шаблон необходимо выбрать “Kubernetes nodes by HTTP“. Именно этот шаблон позволяет собирать данные с узлов кластера Kubernetes.
4. Переходим на вкладке “Macros“. Здесь нужно переопределить два макроса – {$KUBE.API.ENDPOINT.URL} и {$KUBE.API.TOKEN}. Значение для этих макросов я приведу в таблице ниже.
| Макрос | Значение | Описание |
| {$KUBE.API.ENDPOINT.URL} | https://10.10.10.59:6443/api | Ссылка на API сервер ноды управления |
| {$KUBE.API.TOKEN} | <токен_доступа> | Токен доступа системной учетной записи |
Укажите соответствующие значения, как показано на рисунке выше и сохраните внесенные изменения.
В случае успешного обнаружения узлов рабочей нагрузки они отобразятся в списке всех хостов с пометкой “Cluster node discovery”, как показано на скриншоте ниже.
Настройка мониторинга состояния кластера Kubernetes
Теперь настроим мониторинг за компонентами управления кластера Kubernetes: сервером API, планировщиком и т.д.
Какие шаги необходимо выполнить:
1. Перейти в веб панель администрирования сервера Zabbix.
2. Перейти в раздел “Configurations – Hosts“.
3. Нажать кнопку “Create Host“.
На вкладке “Host” также укажем имя для фиктивного хоста. Группу хоста можете выбрать любую на ваше усмотрение. Важный момент – выбор шаблона. Нужен именно шаблон “Kubernetes cluster state by HTTP“.
4. Теперь зайдем на вкладку “Macros“. Аналогично предыдущему фиктивному хосту, тут нужно переопределить два макроса – {$KUBE.API.URL} и {$KUBE.API.TOKEN}. Значение для этих макросов я приведу в таблице ниже.
| акрос | Значение | Описание |
| {$KUBE.API.URL} | https://10.10.10.59:6443 | Ссылка на сервер управления |
| {$KUBE.API.TOKEN} | <токен_доступа> | Токен доступа системной учетной записи |
Укажите соответствующие значения, как показано на рисунке выше и сохраните внесенные изменения.
В случае успешного обнаружения вы должны увидеть еще ряд дополнительных компонентов нашего кластера Kubernetes.
Проверка работы мониторинга
Частично проверку успешного мониторинга за кластером Kubernetes мы выполнили еще при настройке соответствующих шаблонов и фиктивных хостов.
Дополнительно убедиться в том, что мониторинг Kubernetes работает вы можете убедиться либо в представлении “Latest Data” с фильтрацией по соответствующим компонентам.
Либо непосредственно убедившись в том, что данные мониторинга собираются и, например, отображаются на графиках и диаграммах.
Вместо заключения
Если на вашем кластере Kubernetes запущено очень много подов и в целом он очень высоко нагружен, то вы можете выполнять фильтрацию по меткам для нод, узлов или по аннотации. Это нужно для того, чтобы включить в мониторинг не все, скажем, 1000 подом, а только критичные.
О том как выполнить фильтрацию при настройке шаблона для узлов Kubernetes указано вот в этой странице документации.
О том как выполнить фильтрацию при настройке шаблона для наблюдения за состоянием кластера Kubernetes указано вот на этой страницы документации.
Мониторинг Kubernetes в Zabbix: 8 комментариев
Делаю все по инструкции получаю: zabbix_agent2 [1213658]: ERROR: cannot start server listener: cannot parse the “Server” parameter: address “0.0.0.0/0” specified more than once │
│ Stream closed EOF for monitoring/zabbix-agent-g6xf6 (zabbix-agent)
monitoring zabbix-agent-g6xf6 ● 0/1 7 CrashLoopBackOff 1*.*.* node1 13m │
│ monitoring zabbix-agent-j7znx ● 0/1 7 CrashLoopBackOff 2*.*.* master 13m │
│ monitoring zabbix-agent-l9jwv
В чем может быть проблема?
Добрый день! Если честно, то сложно что-то предположить. У меня только один раз были проблемы с запуском, но только потому, что на самой ноде k8s был установлен агент Zabbix. И он конфликтовал с агентом на подах. После удаления агента Zabbix с ноды проблем с мониторингом не было.
Вот у меня похожая проблема – 4 ноды с установленными агентами. И когда ставлю – то какой-то конфликт.
Если у вас уже на узлах установлен Zabbix агент, то DeamonSet из Helm чарта не сможет запустить своего агента. Есть такой момент.
А случайно не сможете подсказать, как обойти не удаляя агента, установленного на нодах?
А в агенте у вас сильно много кастомизаций? Лично в моем случае я понял, что проще удалить агента, настроит мониторинг, а потом заново переподключить узлы с шаблоном “Linux by Zabbix agent”. Так я мониторю и хосты и окружение Kubernetes кластера.
А там суть в том, что оно в разные заббиксы пойдет. Но в принципе нашел решение. На тех агентах, которые на хостах стоят поменял порт.
Кстати да, вполне хорошее решение. Думаю тем, кто еще будет читать эту статью это решение будет к месту.