Что такое Namespace в Kubernetes и для чего он используется?

Question

Что такое Namespace в Kubernetes и для чего он используется?

Тип вопроса: Kubernetes Вероятность: 24% Категория: Devops Инженер

Ответ

Namespace (пространство имен) в Kubernetes — это механизм виртуальной изоляции и организации ресурсов (Pods, Services, Deployments и т.д.) внутри одного физического кластера. Это не изоляция на уровне безопасности (как в виртуальных машинах), а логическое разделение для управления доступом, квотами и сетевым взаимодействием.

Основные практические применения:

Разделение по окружениям: dev, staging, prod. Позволяет запускать разные версии одного приложения бок о бок.
Разделение по командам или проектам: team-frontend, team-backend, project-alpha. Каждая команда работает в своем пространстве.
Управление ресурсами через ResourceQuotas: Ограничение суммарного потребления CPU, памяти и количества объектов для всего namespace.
Контроль доступа через RBAC: Роли (Roles) и привязки ролей (RoleBindings) привязаны к namespace, ограничивая права пользователей или сервисных аккаунтов.
Изоляция сетевого трафика: NetworkPolicies можно применять для контроля трафика между Pods в разных namespace.

Пример создания namespace и deployment в нем:

# 1. Создаем namespace
apiVersion: v1
kind: Namespace
metadata:
  name: production
---
# 2. Создаем deployment в namespace production
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: production # Ключевой параметр
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

Важные нюансы:

Служебные namespace: kube-system, kube-public, default. Не удаляйте их.
Глобальные ресурсы: Некоторые ресурсы кластера (Nodes, PersistentVolumes, ClusterRoles) находятся вне namespace.
Сетевое взаимодействие: Сервисы внутри namespace доступны по короткому имени (service-name). Для доступа к сервису из другого namespace используйте FQDN: service-name.namespace-name.svc.cluster.local.

Работа с namespace через kubectl:

# Просмотр всех namespace
kubectl get namespaces

# Выполнение команды в конкретном namespace
kubectl get pods -n production

# Установка namespace по умолчанию для текущего контекста
kubectl config set-context --current --namespace=production

Ответ 18+ 🔞

Э, слушай сюда, друг. Ты когда-нибудь пытался в одной комнате и спать, и готовить, и детей воспитывать? Получается пиздец, правда? Так вот, Namespace в Kubernetes — это как раз способ навести в этом бардаке хоть какой-то порядок. Это не железобетонная стена, а типа перегородки из гипсокартона в одной большой квартире-кластере. Все живут в одном доме, но у каждой команды — своя комнатушка.

Зачем это, блядь, нужно на практике:

Чтобы не устроить пожар. Отдельно dev (где всё постоянно падает), staging (где всё вроде работает, но мы не уверены) и prod (где все бздят чихнуть, чтобы ничего не сломалось). Это чтобы твой кривой код из dev не впиздюрил продакшену.
Чтобы команды не подрались. team-frontend сидит в своём углу и рисует кнопочки, а team-backend в своём — вздрачивает микросервисы. И они друг другу по головам не ездят.
Чтобы один жадный проект не сожрал все ресурсы. Есть такая штука — ResourceQuotas. Можно сказать: «Вот тебе, project-alpha, 10 ядер и 40 гигов памяти, и ни байта больше, пидарас шерстяной». И он не сможет обожрать всех.
Чтобы доступ раздать правильно. Через RBAC можно дать права: например, девопсу в production — только смотреть логи, а в dev — пусть хоть всё удаляет, да похуй.
Чтобы трафик зря не болтался. NetworkPolicies — это как правила: «Подам из frontend могут стучаться к подам в backend, а к базе данных — ни-ни, хуй с горы».

Вот как это выглядит в деле, смотри:

# 1. Отгораживаем себе комнатушку под названием 'production'
apiVersion: v1
kind: Namespace
metadata:
  name: production
---
# 2. Разворачиваем в этой комнате наш деплоймент
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: production # Вот эта строчка — ключевая! Говорит, куда ставить.
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

А теперь, чувак, важные подводные камни, о которых все забывают:

Есть служебные комнаты: kube-system (там мозги кластера), kube-public, default. Их не трогай, а то будет вам хиросима. Это как не лезть в электрощиток.
Некоторые вещи общие на весь дом: Ноды, постоянные тома (PersistentVolumes), роли кластера (ClusterRoles). Они вне namespace, они как лифт или мусоропровод.
Как общаться между комнатами: Внутри своего namespace можешь звать сервис просто по имени (mysql). Хочешь позвать сервис из соседней комнаты (staging) — придётся выкрикивать его полный адрес: mysql.staging.svc.cluster.local. Ёпта, но так уж устроено.

Поработаем с этим через консоль:

# Посмотреть, какие комнаты вообще есть
kubectl get namespaces

# Заглянуть в конкретную комнату (например, production) и посмотреть, кто там живет (поды)
kubectl get pods -n production

# Сделать так, чтобы все твои команды по умолчанию выполнялись в комнате 'production'.
# Иначе каждый раз придётся писать -n, а это, бля, надоедает.
kubectl config set-context --current --namespace=production

Короче, namespace — это манда с ушами, без которой в большом проекте быстро наступит пиздец. Не пренебрегай, организуй свой бардак.