如何避免GKE创建带cloud-console管理标签选择器的Pod？

以下是几个替代手动删除重建的实用方案：

方案1：统一CD流程与GKE的选择器标签 #

直接修改Cloud Build流程中使用的Deployment配置，添加GKE自动生成的app.kubernetes.io/managed-by: cloud-console标签，让CD工具的选择器和现有资源保持一致：

# 修改后的Deployment模板示例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: healthcheck-deployment
spec:
  selector:
    matchLabels:
      app: healthcheck
      environment: development
      app.kubernetes.io/managed-by: cloud-console  # 新增GKE自动添加的标签
  template:
    metadata:
      labels:
        app: healthcheck
        environment: development
        app.kubernetes.io/managed-by: cloud-console  # Pod标签同步添加
    spec:
      containers:
      - name: healthcheck
        image: gcr.io/your-project/healthcheck:latest

修改后重新触发CD流程，选择器匹配就不会再报错。优点是改动小，不影响现有部署流程；缺点是如果GKE后续新增其他自动标签，可能需要再次调整配置。

方案2：用kubectl apply --force自动处理冲突 #

把Cloud Build中原来的gke-deploy步骤替换为kubectl apply --force，这个参数会自动删除旧的Deployment并重建新的，绕过选择器不可变的限制：

# cloudbuild.yaml中替换后的步骤
steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['apply', '-f', 'path/to/your/deployment.yaml', '--force']
  env:
  - 'CLOUDSDK_COMPUTE_ZONE=your-cluster-zone'
  - 'CLOUDSDK_CONTAINER_CLUSTER=your-cluster-name'

注意：--force会导致服务短暂中断，生产环境建议配合滚动更新策略使用，或者在低峰期执行。优点是无需修改YAML配置，快速解决问题；缺点是存在短暂服务不可用的风险。

方案3：标准化部署流程，放弃手动控制台部署 #

从根源解决冲突：停止在GKE控制台手动部署资源，完全通过Cloud Build的CI/CD流程管理所有Deployment。这样GKE不会自动添加app.kubernetes.io/managed-by: cloud-console标签（CD工具部署的资源会带有对应工具的managed-by标签），选择器始终保持一致。

具体操作：将现有手动部署的Deployment导出为YAML，添加到代码仓库，后续所有更新都通过CD流程触发。优点是彻底避免手动与自动化流程的冲突，部署流程更规范；缺点是需要一次性迁移现有手动部署的资源，初期有一定工作量。

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