Ответ
В 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-оверлеи для автоматического деплоя в нужное окружение.