Мониторинг использования ресурсов модуля на узлах Kubernetes

Question

Вариант использования / Проблема

Я отвечаю за поддержку кластера kubernetes с 40 узлами (разделенными на 2 зоны).У нас есть около 100 микросервисов и платформ, таких как брокеры Kafka, работающие в этом кластере.Все микросервисы определили запрос ресурсов и лимиты.Большинство из них, однако, являются пакетными и не имеют гарантированной оперативной памяти.Разработчики, которые развертывают свои сервисы в нашем кластере, определили пределы, намного превышающие запрос (см. Пример ниже), что в конечном итоге привело к большому количеству выселенных модулей на различных узлах.Мы по-прежнему хотим использовать в наших сервисах пакетные ресурсы, так как мы можем сэкономить деньги, используя ресурсные ресурсы.Поэтому мне нужна лучшая возможность мониторинга всех модулей, работающих на каждом узле, которые содержат следующую информацию:

• Имя узла и емкость ЦП / ОЗУ
• Все имена модулей плюс
  • запросы и ресурсы ресурса pod
  • текущее использование процессора и оперативной памяти pod

Таким образом, я мог бы легко определить два проблемных вида услуг:

Случай A: Микросервис, который просто устанавливает огромные ограничения ресурсов, потому что разработчик просто тестировал материал или слишком ленив, чтобы тестировать / отслеживать свой сервис

resources:
  requests:
    cpu: 100m
    ram: 500Mi
  limits:
    cpu: 6
    ram: 20Gi

Случай B: Слишком много служб на одном узле, которые установили неточные ограничения ресурсов (например, 500Mi, но служба постоянно использует 1,5 ГБ ОЗУ).Этот случай произошел с нами, потому что разработчики Java не заметили, что сборщик мусора Java начнет очищаться только при использовании 75% доступной оперативной памяти.

Мой вопрос:

Как я мог правильно контролировать это и, следовательно, выявлять неправильно настроенные микросервисы, чтобы предотвратить такие проблемы с выселением?В меньшем масштабе я мог бы просто запустить kubectl describe nodes и kubectl top pods, чтобы выяснить это вручную, но в этом масштабе это больше не работает.

Примечание: Я не могнайти любое существующее решение этой проблемы (в том числе доски Prometheus + Grafana с использованием Kube метрик и аналогичных).Я думал, что это возможно, но визуализировать это в Grafana действительно сложно.

Answer 1

Это известная проблема, поскольку все еще существует открытая проблема github , и сообщество просит разработчиков создать новую команду, которая отображала бы общее использование ЦП и контейнера для модуля и контейнера.Пожалуйста, проверьте эту ссылку, так как есть некоторые идеи и обходные пути, предоставленные сообществом, которые выглядят как полезные для вашего случая.

Вы использовали правильные метрики и не смогли увидеть необходимую информацию? Здесь - это список метрик, и я думаю, что некоторые из них будут полезны для вашего случая использования.

Несмотря на то, что не существует полностью функционального решения этой проблемы благодаря сообществу и некоторым другим ресурсам, есть несколько способов достижения вашей цели: Как указано в этой статье :

kubectl get nodes --no-headers | awk '{print $1}' | xargs -I {} sh -c 'echo {}; kubectl describe node {} | grep Allocated -A 5 | grep -ve Event -ve Allocated -ve percent -ve -- ; echo'

Также автор этой статьи рекомендует CoScale Я не использовал его, но, похоже, стоит попробовать, если другие решения не сработают.

Я думаю, что другой момент заключается в том, что вы никогда не сможете контролировать ситуацию, если ваши разработчики будут выделять гораздо больше ресурсов, чем это необходимо.Решение, рекомендованное Никола Беном , поможет вам решить подобные проблемы.

Answer 2

В итоге я написал собственный экспортер прометея для этой цели.Хотя экспортер узлов предоставляет статистику использования, а метрики состояния куба - метрики об объектах ресурсов kubernetes, нелегко объединить и объединить эти метрики, чтобы они предоставили ценную информацию для решения описанного варианта использования.

С Kube Eagle (https://github.com/google-cloud-tools/kube-eagle/) Вы можете легко создать такую ​​панель инструментов (https://grafana.com/dashboards/9871):

Я также написал небольшую статью о том, как это помогло мне сохранитьмного аппаратных ресурсов: https://medium.com/@martin.schneppenheim/utilizing-and-monitoring-kubernetes-cluster-resources-more-effectively-using-this-tool-df4c68ec2053

Answer 3

Если вы можете, я предлагаю вам использовать ресурсы LimitRange и ResourceQuota , например:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: happy-developer-quota
spec:
  hard:
    requests.cpu: 400m
    requests.memory: 200Mi
    limits.cpu: 600m
    limits.memory: 500Mi

Для LimitRange:

 apiVersion: v1
 kind: LimitRange
 metadata:
   name: happy-developer-limit
 spec:
   limits:
   - default:
       cpu: 600m
       memory: 100Mib
     defaultRequest
       cpu: 100m
       memory: 200Mib
     max:
       cpu: 1000m
       memory: 500Mib
     type: Container

Это не позволяет людям создавать супер миниатюрные или супер большие контейнеры в пространстве имен по умолчанию.