如何用kubectl命令临时切换Ingress映射服务（替代edit）

Great question! You're absolutely correct that Kubernetes doesn't offer a dedicated kubectl set-style command for directly tweaking Ingress resources (unlike Deployments or Services, which have built-in set subcommands for common changes). But there are several automation-friendly workarounds that let you temporarily switch backend services and roll back easily—perfect for your blue-green deployment scenario.

1. Use kubectl patch for targeted changes #

This is the closest equivalent to a set command for Ingress. kubectl patch lets you modify specific fields in your Ingress resource without editing the entire YAML, making it ideal for scripts and automation.

Example: Switch backend service from blue to green #

JSON Patch (precise field targeting)

If you know the exact path to the backend service name in your Ingress spec, use a JSON patch to replace it:

kubectl patch ingress your-ingress-name --type json -p '[{"op": "replace", "path": "/spec/rules/0/http/paths/0/backend/service/name", "value": "green-service"}]'

• Adjust the path value to match your Ingress structure (e.g., if you have multiple rules or paths, change the index numbers like 0 to the correct position).
• To roll back, just run the same command with "value": "blue-service".

Merge Patch (simpler YAML syntax)

For a more readable approach, use a merge patch with YAML formatting:

kubectl patch ingress your-ingress-name --type merge -p '{"spec":{"rules":[{"http":{"paths":[{"backend":{"service":{"name":"green-service"}}}]}}]}'

This works well if your Ingress has a single rule/path; adjust the nested structure if you have multiple routes.

2. Predefine blue/green Ingress YAMLs and use kubectl apply #

For blue-green deployments, this is often the most straightforward method. Create two separate YAML files for your blue and green environments:

• blue-ingress.yaml: Points to your blue backend service
• green-ingress.yaml: Points to your green backend service

Switch to green: #

kubectl apply -f green-ingress.yaml

Roll back to blue: #

kubectl apply -f blue-ingress.yaml

You can even wrap this in a script with environment variables to make switching dynamic (e.g., kubectl apply -f ${DEPLOYMENT_TARGET}-ingress.yaml).

3. Use Kustomize for managed configuration overlays #

If you want to avoid duplicating YAML code, Kustomize lets you define a base Ingress configuration and create overlays for blue and green deployments that only modify the backend service.

1. Create a base directory with your core Ingress YAML (base/ingress.yaml)
2. Create overlays/blue and overlays/green directories, each with a kustomization.yaml that patches the backend service name:
   • overlays/blue/kustomization.yaml:

     bases:
     - ../../base
     patches:
     - patch: |-
         - op: replace
           path: /spec/rules/0/http/paths/0/backend/service/name
           value: blue-service
     

   • overlays/green/kustomization.yaml:

     bases:
     - ../../base
     patches:
     - patch: |-
         - op: replace
           path: /spec/rules/0/http/paths/0/backend/service/name
           value: green-service
     

Switch to green: #

kubectl apply -k ./overlays/green

Roll back to blue: #

kubectl apply -k ./overlays/blue

Why no kubectl set for Ingress? #

Kubernetes' kubectl set commands are designed for common, repetitive changes to resources like Deployments (e.g., updating container images) or Services (e.g., changing ports). Ingress configurations are highly variable (different rules, paths, TLS settings, etc.), so there's no single "common change" that justifies a dedicated set subcommand. The above methods are the official, supported ways to modify Ingresses in automation.

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