Ответ
Да, это стандартная практика для изоляции команд и проектов в общем кластере. Я использую ResourceQuotas и LimitRanges для предотвращения "войн за ресурсы" и обеспечения стабильности кластера.
1. ResourceQuotas для ограничения ресурсов на namespace: Создаю квоту при инициализации namespace для каждой команды или среды (dev/staging).
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-alpha-quota
namespace: team-alpha-dev
spec:
hard:
# Вычислительные ресурсы
requests.cpu: "8" # Не более 8 ядер в сумме по всем request'ам
requests.memory: 16Gi # Не более 16 GiB памяти в request'ах
limits.cpu: "16" # Не более 16 ядер в сумме по всем limit'ам
limits.memory: 32Gi # Не более 32 GiB памяти в limit'ах
# Количество объектов
pods: "30" # Не более 30 подов
services: "10" # Не более 10 сервисов
persistentvolumeclaims: "5" # Не более 5 PVC
secrets: "20" # Не более 20 секретов
2. LimitRanges для установки дефолтных лимитов и валидации: Чтобы разработчики не забывали указывать requests/limits, настраиваю LimitRange, который применяет значения по умолчанию.
apiVersion: v1
kind: LimitRange
metadata:
name: mem-cpu-limit-range
namespace: team-alpha-dev
spec:
limits:
- default: # Лимиты, применяемые если не указаны в Pod spec
memory: 512Mi
cpu: 500m
defaultRequest: # Requests, применяемые если не указаны в Pod spec
memory: 256Mi
cpu: 100m
max: # Максимально допустимые значения
memory: 2Gi
cpu: "2"
min: # Минимально допустимые значения
memory: 64Mi
cpu: 50m
type: Container
Практическое применение:
- При попытке создать под, превышающий квоту, Kubernetes отклонит его с понятной ошибкой.
- Регулярно проверяю использование через
kubectl describe quota -n <namespace>и адаптирую лимиты под реальные потребности. - Для более сложных сценариев (например, квоты на GPU) использовал механизм Extended Resources.