Общий кластер Kubernetes

Общий кластер Kubernetes

Мы планируем нашу новую инфраструктуру кластера Kubernetes, и у меня есть несколько вопросов. В настоящее время у нас есть один большой кластер, в котором работают среды (dev, staging, prod) и несколько команд. В начале это был просто "POC", демо, но, ребята, вы знаете: ничто не длится дольше временных решений. В этой настройке у нас есть некоторые общие проблемы, и в нашей целевой архитектуре мы планируем исправить некоторые из этих тем.

Надеюсь, что некоторые из вас смогут поделиться знаниями/опытом.

Прежде всего: один кластер на приложение — это не решение. Приложения действительно маленькие, и у каждой команды около 3-5 приложений, и им нужно около 6-20 ГБ оперативной памяти на все узлы в каждой среде. Поэтому один кластер — это не совсем вариант.

Мы планируем один кластер на среду: dev, staging (qa), prod и, возможно, для операций — демонстрационный кластер. Все автоматизировано и будет автоматизировано и IaC с terraform + ansible (kubespray). Каждая область действия команды/приложения получит единое пространство имен — конечно же.

Наши вопросы/проблемы:

Мониторинг Обычно мы используем Prometheus и Grafana для мониторинга использования ресурсов pod/кластера. New также должен содержать центральное ведение журнала (сейчас мы пробуем решения). Это нормально для команды infra, но infra не хочет осуществлять мониторинг на уровне приложения.

Есть ли рабочий способ предоставить командам приложений мониторинг? Например: вы (команда приложений) можете настроить оповещения по журналам, процессору, использованию оперативной памяти, что вам нужно. «Вам просто нужно развернуть эту диаграмму Helm». В прекрасном мире я бы предоставил каждой команде (то есть каждому пространству имен) свой собственный стек мониторинга, чтобы мы также могли ограничивать использование хранилища и оперативной памяти + процессора, и каждая команда могла бы использовать «упорядоченные» ресурсы (то есть, если у команды много журналов / потребностей в мониторинге, ей нужно «упорядочить» больше ресурсов»). Также на основе этого подхода они могут выбрать программное обеспечение, которое подходит лучше всего.

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

Это может быть вариантом, что команда infra устанавливает этот стек - но все, что я видел, это: когда я устанавливаю стек мониторинга в определенном пространстве имен, стеку нужен административный доступ к кластеру. Это нехорошо, по моему мнению.

Я ошибаюсь?

Хранилище У нас есть хранилище gluster, и мы хотим его сохранить. Если команде нужен диск, мы добавляем "glusterfs persistent volume" с определенным размером и storageClassName, например "team1-disk5". На основе этого команда может создать PVC и использовать хранилище. Раньше работало нормально.

Это хорошее решение? Есть еще идеи?

Думаю, на этом все на данный момент. Только эти два вопроса. Есть идеи, как направить меня в правильном направлении?

Спасибо!

Связанный контент