如何在Kubernetes中将容器推广至其他命名空间（DTAP环境）？

Got it, let's walk through how to smoothly roll out your containers across the dev→test→acc→prod pipeline—here are practical, team-friendly approaches that fit your workflow:

1. Use Kustomize (Native Kubernetes Tool, Lightweight & Efficient) #

Kustomize comes built into kubectl, so it's perfect for managing environment-specific differences without duplicating configs. Here's how to set it up:

• Step 1: Create a base config directory
  First, make a base folder for your core, environment-agnostic configs (like Deployment and Service definitions):

  # base/deployment.yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: my-app
  spec:
    replicas: 2
    selector:
      matchLabels:
        app: my-app
    template:
      metadata:
        labels:
          app: my-app
      spec:
        containers:
        - name: my-app-container
          image: my-app:placeholder-tag # We'll override this per environment
          ports:
          - containerPort: 8080
  

• Step 2: Create overlays for each environment
  Make overlays/dev, overlays/test, overlays/acc, and overlays/prod directories. Each gets a kustomization.yaml that defines namespace-specific tweaks:

  # overlays/dev/kustomization.yaml
  apiVersion: kustomize.config.k8s.io/v1beta1
  kind: Kustomization
  namespace: dev
  bases:
  - ../../base
  images:
  - name: my-app
    newTag: dev-1.0.0 # Unique tag for dev environment
  patches:
  - patch: |-
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: my-app
      spec:
        replicas: 1 # Fewer replicas for dev to save resources
  

  For test/acc/prod, adjust the namespace, newTag, and any other environment-specific settings (like replicas, resource limits, or ConfigMap references).
• Step 3: Roll out sequentially
  Start with dev:

  kubectl apply -k overlays/dev
  

  Once dev is validated, push to test:

  kubectl apply -k overlays/test
  

  Repeat for acc and prod once each environment passes testing:

  kubectl apply -k overlays/acc
  kubectl apply -k overlays/prod
  

2. GitOps Automation with Argo CD (Great for CI/CD Workflows) #

If your team uses GitOps, Argo CD makes it easy to track config changes and control promotions with manual approvals:

• Step 1: Host all environment configs in Git
  Store your Kustomize overlays or raw YAMLs in a Git repo, organized by environment (e.g., envs/dev, envs/test).
• Step 2: Set up Argo CD Applications
  Create an Argo CD Application for each namespace:
  • Dev: Set to auto-sync so changes to the dev config in Git deploy automatically.
  • Test/Acc/Prod: Set to manual sync—this means you have to approve the deployment before it rolls out, preventing accidental pushes to production.
• Step 3: Promote through the pipeline
  1. After dev testing passes, copy the validated config (like the image tag) from dev's Git directory to test's.
  2. Head to Argo CD, find the test application, and trigger a sync.
  3. Repeat the process for acc and prod, only moving forward once each environment's tests (including external partner integrations in acc) pass.
     This approach keeps all configs version-controlled and audit-ready.

3. Manual Promotion (For Small Teams or One-Off Deployments) #

If you don't want to use tools right now, you can manually migrate configs with kubectl:

• Step 1: Export the dev Deployment config
  (Note: --export is deprecated in newer Kubernetes versions, so use this grep trick to strip auto-generated fields):

  kubectl get deployment my-app -n dev -o yaml | grep -v '^\s*creationTimestamp:\|^\s*resourceVersion:\|^\s*uid:' > my-app-dev.yaml
  

• Step 2: Tweak for the target environment
  Edit my-app-dev.yaml to update:
  • metadata.namespace to test (or acc/prod later)
  • Image tag to a test-specific version (e.g., test-1.0.0)
  • Any other environment-specific settings (replicas, secrets, etc.)
• Step 3: Deploy to the target namespace

  kubectl apply -f my-app-dev.yaml -n test
  

  Repeat this edit-deploy cycle for acc and prod.

Key Best Practices to Follow #

• Use unique image tags: Avoid latest—use tags tied to commit hashes or release versions (e.g., dev-a1b2c3) so you always know exactly what's running in each environment.
• Isolate environment resources: Keep ConfigMaps, Secrets, and other sensitive data separate per namespace—never share prod secrets with dev/test.
• Validate at every stage: Especially for the acc environment, make sure to run full integration tests with your external partners before promoting to prod.

内容的提问来源于stack exchange，提问作者fandijunior