Дублирующиеся метрики с несколькими экземплярами метрик состояния куба

Question

Проблема :

Повторяющиеся данные при запросе от Прометея для метрик из kube-state-metrics .

Пример запроса и результат с 3 экземпляры метрики состояния куба работает:

Запрос:

kube_pod_container_resource_requests_cpu_cores{namespace="ns-dummy"}

Метрика

kube_pod_container_resource_requests_cpu_cores{container="appname",endpoint="http",instance="172.232.35.142:8080",job="kube-state-metrics",namespace="ns-dummy",node="ip-172-232-34-25.ec2.internal",pod="app1-appname-6bd9d8d978-gfk7f",service="prom-kube-state-metrics"}
1
kube_pod_container_resource_requests_cpu_cores{container="appname",endpoint="http",instance="172.232.35.142:8080",job="kube-state-metrics",namespace="ns-dummy",node="ip-172-232-35-22.ec2.internal",pod="app2-appname-ccbdfc7c8-g9x6s",service="prom-kube-state-metrics"}
1
kube_pod_container_resource_requests_cpu_cores{container="appname",endpoint="http",instance="172.232.35.17:8080",job="kube-state-metrics",namespace="ns-dummy",node="ip-172-232-34-25.ec2.internal",pod="app1-appname-6bd9d8d978-gfk7f",service="prom-kube-state-metrics"}
1
kube_pod_container_resource_requests_cpu_cores{container="appname",endpoint="http",instance="172.232.35.17:8080",job="kube-state-metrics",namespace="ns-dummy",node="ip-172-232-35-22.ec2.internal",pod="app2-appname-ccbdfc7c8-g9x6s",service="prom-kube-state-metrics"}
1
kube_pod_container_resource_requests_cpu_cores{container="appname",endpoint="http",instance="172.232.37.171:8080",job="kube-state-metrics",namespace="ns-dummy",node="ip-172-232-34-25.ec2.internal",pod="app1-appname-6bd9d8d978-gfk7f",service="prom-kube-state-metrics"}
1
kube_pod_container_resource_requests_cpu_cores{container="appname",endpoint="http",instance="172.232.37.171:8080",job="kube-state-metrics",namespace="ns-dummy",node="ip-172-232-35-22.ec2.internal",pod="app2-appname-ccbdfc7c8-g9x6s",service="prom-kube-state-metrics"}

Наблюдение :

Каждый показатель c возрастает Nx, когда N модулей работают для kube-state-metrics . Если запущен один модуль, мы получим правильную информацию.

Возможные решения :

1. Уменьшите до одного экземпляра показателей состояния куба. (Снижение доступности является проблемой)
2. Включить шардинг. (Решает проблему дублирования, все еще менее доступно)

Согласно документам , для горизонтального масштабирования мы должны передавать аргументы шардинга модулям.

Осколки ноль индексируется. Таким образом, мы должны передать индекс и общее количество шардов для каждого модуля.

Мы используем Диаграмма Хелма , и она развернута как развертывание.

Вопросы :

1. Как мы можем передать различные аргументы различным модулям в этом сценарии, если это возможно?
2. Должны ли мы волноваться о доступности показателей состояния куба с учетом самовосстановления природы рабочих нагрузок k8s?
3. Когда мы должны масштабировать его на несколько экземпляров и как?

Answer 1

Вы можете использовать «самовосстанавливающееся» развертывание только с одной репликой kube-state-metric, если контейнер не работает, развертывание запустит новый контейнер. Поскольку kube-state-metri c не ориентирован на здоровье отдельных компонентов kubernetes . Это повлияет на вас только в том случае, если ваш кластер слишком велик и будет производить много изменений объектов в секунду.

Он ориентирован не на здоровье отдельных компонентов Kubernetes, а скорее на здоровье различных объектов. внутри, такие как развертывания, узлы и модули.

Для небольших кластеров нет проблем с использованием этого способа, но вам действительно нужна платформа мониторинга высокой доступности, я рекомендую вам взглянуть на эти две статьи : создание хорошо спроектированного и высокодоступного стека мониторинга для мониторинга kubernetes и kubernetes