Мониторинг Kubernetes в Zabbix

В этой публикации я продолжу рассказывать про систему мониторинга Zabbix. Только на этот раз я покажу, как выполняется мониторинг Kubernetes в Zabbix. Это типовой вариант мониторинга на основе шаблона, который идет “Из коробки”. На странице документации Zabbix есть описание этого шаблона.

Основная суть работы этого шаблона заключается в том, что он создает определенное количество объектов в кластере Kubernetes (поды, сервисы и т.д.), которые будут непосредственно отдавать данные при запросе данных сервером Zabbix.

Описание демонстрационной среды

Ниже я приведу схему моего доменстрационного кластера Kubernetes.

В кластере настроен один сервер управления и две ноды для рабочей нагрузки.

IP-адреса узлов и их описание приведены в таблице ниже.

Узел КластераIP-адресОписание
master0110.10.10.59Узел управления
worker0110.10.10.58Узел рабочей нагрузки
worker0210.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.0
roman@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.yaml

3. Далее я создам отдельное пространство имен в Kubernetes. Именно в этом пространстве имен и будет развернут Zabbix:

kubectl create namespace monitoring

4. Запустим развертывание диаграммы Helm для Zabbix в пространстве имен monitoring:

helm install zabbix zabbix-chart-6.0/zabbix-helm-chrt --dependency-update -f $HOME/zabbix_values.yaml -n monitoring

5. Проверим состояние развертывания. Убедимся, что все поды развернулись и запустились успешно:

kubectl get pods -n monitoring
roman@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 monitoring
roman@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 && echo
roman@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: 10 комментариев

  1. Делаю все по инструкции получаю: 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

    В чем может быть проблема?

    1. Добрый день! Если честно, то сложно что-то предположить. У меня только один раз были проблемы с запуском, но только потому, что на самой ноде k8s был установлен агент Zabbix. И он конфликтовал с агентом на подах. После удаления агента Zabbix с ноды проблем с мониторингом не было.

      1. Вот у меня похожая проблема – 4 ноды с установленными агентами. И когда ставлю – то какой-то конфликт.

        1. Если у вас уже на узлах установлен Zabbix агент, то DeamonSet из Helm чарта не сможет запустить своего агента. Есть такой момент.

          1. А случайно не сможете подсказать, как обойти не удаляя агента, установленного на нодах?

          2. А в агенте у вас сильно много кастомизаций? Лично в моем случае я понял, что проще удалить агента, настроит мониторинг, а потом заново переподключить узлы с шаблоном “Linux by Zabbix agent”. Так я мониторю и хосты и окружение Kubernetes кластера.

          3. А там суть в том, что оно в разные заббиксы пойдет. Но в принципе нашел решение. На тех агентах, которые на хостах стоят поменял порт.

          4. Кстати да, вполне хорошее решение. Думаю тем, кто еще будет читать эту статью это решение будет к месту.

  2. Во время мониторинга моего кластера kubernetes я получил два action с проблемой “Kubernetes API: Kubernetes client certificate expires in 7 days”
    “Remote commands are not enabled” и “Script does not have permission to be executed on the host.”
    Как я могу узнать, какая команда и скрипт завершились ошибкой?
    Спасибо

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *