Мы планируем нашу новую кластерную инфраструктуру Kubernetes, и у меня есть несколько вопросов.
В настоящее время у нас есть один большой кластер, над которым работают среды (dev, staging, prod) и несколько команд. Вначале это была просто «POC», демо-но, ребята, вы знаете: ничто не длится дольше, чем временные решения.
В этой настройке у нас есть некоторые общие проблемы, и в нашей целевой архитектуре мы планируем исправить некоторые из этих проблем.
Я надеюсь, что некоторые из вас могут поделиться знаниями/опытом.
Прежде всего: один кластер на приложение — это не решение. Приложения очень маленькие, и каждая команда имеет около 3-5 приложений и требует около 6-20 ГБ оперативной памяти на всех узлах в каждой среде. Таким образом, один кластер на самом деле не вариант.
Мы планируем по одному кластеру на каждую среду: dev, staging (qa), prod и, возможно, для работы демонстрационный кластер.
Все есть и будет автоматизировано и IaC с terraform + ansible (kubespray).
Каждая область действия команды/приложения получит единое пространство имен.
Наши вопросы/проблемы:
Мониторинг
Обычно мы используем Prometheus и Grafana для мониторинга использования ресурсов пода/кластера.Новое также должно содержать централизованное ведение журнала (мы сейчас тестируем решения).
Это нормально для внутренней команды, но она не хочет отслеживать на уровне приложений.
Есть ли какой-нибудь рабочий способ предоставить командам приложений мониторинг? Например: вы (команда приложения) можете настроить оповещения о журналах, использовании процессора, оперативной памяти, что вам нужно. «Вам просто нужно развернуть эту диаграмму руля».
В прекрасном мире я бы предоставил каждой команде (т. е. каждому пространству имен) свой собственный стек мониторинга, чтобы мы также могли ограничивать использование хранилища и оперативной памяти + процессора, и каждая команда могла бы использовать «упорядоченные» ресурсы (поэтому, если команда требует много логов/мониторинга, ему нужно "заказывать" больше ресурсов).
Кроме того, на основе этого подхода они могут выбрать наиболее подходящее программное обеспечение.
Другое решение может заключаться в том, что команда инфраструктуры настраивает централизованное решение для мониторинга/журнала и ограничивает доступ. Команда приложения A не должна иметь доступа к журналам/использованию процессора/использованию оперативной памяти/использованию диска из команды приложения B. Но я не вижу никакого способа сделать это действительно хорошо.
Это может быть вариант, когда команда Infra устанавливает этот стек, но все, что я видел, таково: когда я устанавливаю стек мониторинга в определенном пространстве имен, стеку требуется доступ администратора к кластеру. Это не красиво на мой взгляд.
Я ошибся?
Место хранения
У нас есть хранилище gluster, и мы хотим его сохранить. Если команде нужен диск, мы добавляем «постоянный том glusterfs» с определенным размером и именем класса хранилища, например «team1-disk5».
Исходя из этого, команда может создать PVC и использовать хранилище. Раньше работал нормально.
Это хорошее решение? Любые другие идеи?
Я думаю, что это все на данный момент. Только эти два вопроса. Любая идея переместить меня в правильном направлении?
Спасибо!
