Как деплоить ресурсы в определенное пространство имен (namespace) в Kubernetes?

«Как деплоить ресурсы в определенное пространство имен (namespace) в Kubernetes?» — вопрос из категории Kubernetes, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

В Kubernetes все деплои выполняются в контексте namespace, который логически изолирует ресурсы (например, dev, staging, production). Я использую несколько подходов.

1. Указание namespace при вызове kubectl: Самый простой способ — флаг -n или --namespace.

# Деплой манифеста в namespace 'production'
kubectl apply -f deployment.yaml -n production

# Просмотр подов в конкретном namespace
kubectl get pods -n staging

2. Определение namespace непосредственно в YAML-манифесте: Поле metadata.namespace имеет высший приоритет.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-api
  namespace: production # Ресурс будет создан именно здесь
spec:
  replicas: 3
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
      - name: app
        image: myregistry/backend:v1.2.3

3. Установка контекста namespace по умолчанию для текущей сессии: Удобно для длительной работы с одной средой.

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

# Теперь все команды без флага -n будут выполняться в 'staging'
kubectl get pods

Основные типы ресурсов, которые я чаще всего деплою в namespaces:

  • Рабочие нагрузки: Deployment, StatefulSet, DaemonSet, Job, CronJob.
  • Сервисы и сетевое взаимодействие: Service, Ingress.
  • Конфигурация и секреты: ConfigMap, Secret.
  • Политики и RBAC: NetworkPolicy, Role, RoleBinding.

В нашем CI/CD пайплайне (например, GitLab CI) мы используем переменные окружения (K8S_NAMESPACE), которые подставляются в Helm-чарты или kustomize-оверлеи для автоматического деплоя в нужное окружение.