Когда ты разворачиваешь стандартный кластер кубера, что делает твой namespace?

Роль Namespace при развёртывании стандартного кластера Kubernetes

Когда я разворачиваю стандартный кластер Kubernetes, namespace выполняет критически важную функцию виртуализации кластера — он создаёт изолированные логические среды внутри одного физического кластера для организации, разделения и управления ресурсами.

Функциональное назначение namespace

Namespace в Kubernetes — это не просто папка, а полноценный механизм изоляции, который решает несколько ключевых задач:

1. Логическое разделение:

    *   Позволяет разбить кластер на отдельные "виртуальные кластеры" для разных команд, проектов, стадий разработки (dev/stage/prod) или приложений
    *   Пример: один кластер может содержать `namespace` для фронтенда, бэкенда, мониторинга и CI/CD

1. Изоляция ресурсов:

    *   Ресурсы (Pods, Services, ConfigMaps, Secrets) существуют внутри конкретного namespace
    *   Ресурсы с одинаковыми именами могут существовать в разных namespace без конфликтов
    *   Большинство запросов API по умолчанию ограничены текущим namespace

1. Управление доступом и квотами:

    *   **RBAC (Role-Based Access Control)** привязывается к namespace, позволяя давать командам доступ только к своим пространствам
    *   **ResourceQuotas** ограничивают потребление CPU, RAM, количество Pods и других ресурсов на уровне namespace
    *   **LimitRanges** устанавливают стандартные лимиты для контейнеров внутри namespace

Стандартные namespace в свежем кластере

При развёртывании кластера создаются несколько системных namespace:

# Проверяем стандартные namespace в новом кластере
kubectl get namespaces

# Пример вывода:
NAME              STATUS   AGE
default           Active   1m   # Пространство по умолчанию для пользовательских ресурсов
kube-system       Active   1m   # Системные компоненты (kube-proxy, DNS, сетевые плагины)
kube-public       Active   1m   # Публичные ресурсы, доступные всем пользователям
kube-node-lease   Active   1m   # Механизм аренды нод для отслеживания их доступности

Практическое применение в развёртывании

При развёртывании кластера я обычно создаю дополнительные namespace для структурирования:

# Создание namespace для продакшн-окружения
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    environment: prod
    tier: production

# Создание namespace через CLI
kubectl create namespace staging
kubectl label namespace staging environment=staging

# Настройка квот для namespace
kubectl apply -f - <<EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: production
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "50"
EOF

Ключевые особенности работы с namespace

• Сетевые политики могут ограничивать трафик между namespace
• Service Discovery работает внутри namespace: service-name разрешается автоматически
• Для доступа к сервису из другого namespace используется FQDN: service-name.namespace-name.svc.cluster.local
• Некоторые ресурсы являются кластерными и не принадлежат namespace (Nodes, PersistentVolumes, ClusterRoles)

Best Practices при работе с namespace

1. Не используйте default для продакшн-нагрузок — это антипаттерн
2. Изолируйте окружения через разные namespace для dev/stage/prod
3. Применяйте ResourceQuotas на всех несистемных namespace
4. Используйте префиксы или суффиксы в именах для clarity: team-backend-prod, monitoring-global
5. Настройте RBAC до начала использования namespace

В моей практике, namespace — это фундаментальный примитив Kubernetes, который превращает кластер из единой монолитной системы в управляемый многопользовательский и многопроектный инструмент. Правильное проектирование namespace-структуры на этапе развёртывания кластера предотвращает множество проблем с безопасностью, управлением ресурсами и взаимодействием команд в будущем.