Ответ
Namespace (пространство имён) в Kubernetes — это виртуальный кластер внутри физического кластера. Это механизм для изоляции групп ресурсов (подов, сервисов, ConfigMaps, Secrets) в рамках одного кластера.
Основные цели использования:
- Логическое разделение: Изоляция окружений (dev, staging, prod), команд или проектов.
- Управление доступом: Привязка политик RBAC (Role-Based Access Control) к конкретному пространству имён.
- Квотирование ресурсов: Ограничение потребления CPU, памяти и количества объектов через
ResourceQuota. - Изоляция сети: Применение
NetworkPolicyдля управления сетевым трафиком между подами в разных неймспейсах.
Пример манифеста для создания Namespace:
apiVersion: v1
kind: Namespace
metadata:
name: productionВажные особенности:
- Системные неймспейсы, такие как
kube-system,kube-public,kube-node-lease, создаются и управляются самим Kubernetes. - Ресурсы уровня кластера (Nodes, PersistentVolumes, ClusterRoles) не принадлежат ни одному неймспейсу и являются глобальными.
- Имена ресурсов (например, Pod или Service) должны быть уникальны только в пределах одного неймспейса.
Работа с неймспейсами через kubectl:
# Создать неймспейс
kubectl create namespace dev
# Показать все ресурсы в конкретном неймспейсе
kubectl get all -n dev
# Установить неймспейс по умолчанию для текущего контекста
kubectl config set-context --current --namespace=devОтвет 18+ 🔞
А, неймспейсы в кубере! Ну это ж, ёпта, как квартиры в общаге — все в одном здании, но у каждого своя комнатушка, и чтоб сосед к тебе в тапки не срал. Логика простая, как три копейки.
Namespace (пространство имён) — это, грубо говоря, виртуальный закуток внутри одного большого кластера. Туда ты можешь запихнуть свои поды, сервисы, конфиги и прочую хуету, чтобы она не мешалась с ресурсами других ребят. Представь, что у тебя один сервер, но на нём и продакшн, и тестовый стенд, и ещё какая-нибудь левая фигня от стажёра. Без неймспейсов это был бы пиздец и бардак, все бы лезли друг другу в конфиги, как мартышлюшки.
Зачем это вообще нужно, спросишь?
- Чтобы не запутаться, как свинья в апельсинах. Отделяешь, например,
devотprod. Вdevможно хуярить что угодно, а вprod— только проверенное, иначе будет вам хиросима и нагасаки. - Чтобы ограничить доступ. Через RBAC можно дать одной команде права только в их неймспейс, а не на весь кластер, чтобы они там чего лишнего не натворили. Доверия ебать ноль, знаешь ли.
- Чтобы жадные не сожрали все ресурсы. Через
ResourceQuotaможно сказать: "ребята из отдела маркетинга, вам вот столько CPU и памяти, и ни гигабайтом больше". Иначе они развернут своё говно, которое будет жрать ресурсов овердохуища. - Чтобы сеть изолировать. Через
NetworkPolicyможно запретить подам из неймспейсаmonitoringлезть вproductionбез спросу. Безопасность, мать её.
Вот тебе пример, как эту штуку создать:
apiVersion: v1
kind: Namespace
metadata:
name: productionСоздал — и вот тебе чистая песочница под названием production.
А теперь важные нюансы, чтоб не обосраться:
- Системные неймспейсы типа
kube-system— это святое. Там живёт мозг кластера. Туда лучше не лезть со своими кривыми руками, если не хочешь, чтобы всё накрылось медным тазом. - Некоторые штуки — глобальные. Ноды, PersistentVolumes, ClusterRoles — они как общий туалет на этаже, не привязаны ни к одной "квартире"-неймспейсу.
- Имена ресурсов должны быть уникальными только внутри своего неймспейса. То есть в
devи вprodможет быть по сервису с именемfrontend. А вот если в одном неймспейсе попробуешь создать два одинаковых — получишь по шапке.
Поработать с этим через kubectl — проще пареной репы:
# Создаём неймспейс 'dev', где будет твориться непотребство
kubectl create namespace dev
# Посмотреть, что там понавтыкали в этом неймспейсе
kubectl get all -n dev
# Сделать неймспейс 'dev' рабочим по умолчанию, чтобы не писать '-n dev' каждый раз
kubectl config set-context --current --namespace=devВот и вся магия. Разделяй, изолируй, контролируй — и будет тебе счастье, а не каша в одной большой куче.