Введение
Кластер Kubernetes можно представить как большой многоквартирный дом.
Если бы все жили в вестибюле, начался бы хаос. Было бы непонятно, кому какая мебель принадлежит, а один шумный сосед мог бы мешать всем остальным.
Пространства имён (Namespaces) логически разделяют кластер, чтобы разные команды, среды или приложения могли организовывать ресурсы независимо друг от друга.
ResourceQuota ограничивает объём определённых ресурсов, который может потребить пространство имён. Это помогает не допустить, чтобы одна команда или рабочая нагрузка исчерпала общую ёмкость кластера.
В этой лабораторной работе вы:
- Создадите новую «квартиру» (Namespace) с именем
dev. - Установите для этой «квартиры» строгий «лимит электричества» (ResourceQuota).
- Попробуете занести в неё мебель (Pod) и проверите, помещается ли она.
Создание пространства имён
На этом шаге вы создадите новое пространство имён, чтобы изолировать ресурсы команды разработки.
Пространство имён — это логическая граница внутри одного кластера, а не отдельный кластер. Команды по-прежнему используют одну и ту же плоскость управления и базовые узлы, но имена, политики и многие представления ресурсов можно разделить, чтобы упорядочить работу.
По умолчанию всё размещается в пространстве имён default — нашем вестибюле. Посмотрите, какие пространства имён уже существуют:
kubectl get namespaces
В списке должны быть default, kube-system (там работают администраторы здания) и ещё несколько пространств имён.
Теперь создайте «квартиру» dev:
kubectl create namespace dev
Проверьте, что она создана:
kubectl get namespaces
В списке появится dev. Пока это пустая «квартира» без стен и ограничений — в неё можно поместить любые ресурсы.
Применение ограничений ресурсов
Теперь нужно установить правила. Мы не хотим, чтобы команда dev использовала весь CPU и всю память кластера.
Мы создадим объект ResourceQuota. Он задаёт правило: «В пространстве имён dev можно использовать не более 2 CPU и 2Gi памяти».
Квоты особенно важны в общих кластерах, поскольку CPU и память — ограниченные ресурсы. Без квот одна ресурсоёмкая рабочая нагрузка может потребить больше своей справедливой доли и сделать кластер ненадёжным для всех остальных. Поэтому квоты нужны не только для учёта ресурсов. Они также помогают поддерживать стабильность.
Создайте файл quota.yaml:
nano quota.yaml
Вставьте в него следующую конфигурацию:
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-quota
namespace: dev
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
Сохраните файл и выйдите из редактора (Ctrl+X, Y, Enter).
Примените это правило к кластеру:
kubectl apply -f quota.yaml
Теперь можно посмотреть подробности правила. В выводе отображаются лимит «Hard» (заданное вами значение) и использованный объём «Used» (сейчас он равен 0).
kubectl describe resourcequota dev-quota --namespace=dev
Развёртывание Pod
Теперь, когда правила установлены, попробуем заселиться.
Критически важное правило: если для «квартиры» установлен лимит, для каждого предмета мебели, который вы в неё заносите, необходимо указать его размер. В терминах Kubernetes это означает: если для пространства имён настроена квота, каждый Pod должен явно задавать resources — requests и limits. Если этого не сделать, управляющий зданием (Kubernetes) остановит вас у входа.
Здесь встречаются два связанных понятия. Request сообщает планировщику, какой объём ресурса должен быть гарантирован Pod при его размещении. Limit — это максимальный объём, который контейнер может использовать. Квоты суммируют requests и limits всех ресурсов в пространстве имён, чтобы общий объём оставался в пределах политики.
Создайте файл pod.yaml:
nano pod.yaml
Вставьте следующую конфигурацию. Обратите внимание: размер этого Pod указан явно:
apiVersion: v1
kind: Pod
metadata:
name: dev-pod
namespace: dev ## <-- Putting it in the 'dev' apartment
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "256Mi"
cpu: "500m"
Сохраните файл и выйдите из редактора (Ctrl+X, Y, Enter).
Разверните Pod:
kubectl apply -f pod.yaml
Проверьте, запущен ли он в пространстве имён dev:
kubectl get pods --namespace=dev
Подождите, пока в столбце состояния не появится Running.
Теперь снова проверьте использование квоты. Вы увидите, что значение в столбце «Used» увеличилось:
kubectl describe resourcequota dev-quota --namespace=dev
Теперь вы успешно отслеживаете использование ресурсов относительно выделенного бюджета.
Проверка изоляции
В заключение проверим, действительно ли «стены» нашей «квартиры» работают.
Изоляция пространства имён в основном относится к именам, политикам и области действия операций. По умолчанию это не означает, что рабочие нагрузки запускаются на физически отдельных узлах. Это различие пригодится позже, когда вы будете изучать выбор узлов и более строгие механизмы изоляции.
Мы разместили dev-pod в пространстве имён dev. Он не должен быть виден из вестибюля (default).
Выведите список Pod в пространстве имён default:
kubectl get pods
Вы должны увидеть сообщение No resources found in default namespace или, по крайней мере, не увидеть dev-pod.
Теперь проверьте наличие квоты в пространстве имён default:
kubectl get resourcequota
Вы не должны увидеть никаких ресурсов. Установленный нами лимит электричества действует только для «квартиры» dev, а не для всего здания.
Это подтверждает, что пространства имён обеспечивают изоляцию команд.
Итоги
В этой лабораторной работе вы выступили в роли управляющего здания для своего кластера Kubernetes.
Вы успешно:
- Создали отдельное пространство имён (
dev) для команды. - Установили строгую ResourceQuota (лимит электричества), чтобы предотвратить чрезмерное потребление ресурсов.
- Развернули приложение, соблюдающее эти ограничения.
- Проверили, что стены между пространствами имён обеспечивают изоляцию ресурсов.
Так крупные организации используют один кластер Kubernetes совместно сотнями команд, не позволяя им мешать работе друг друга.
