如何在不重置服务配置的情况下搭配使用Cloud Deploy与Cloud Run

你的问题根源在于Google Cloud Deploy默认会用新配置全量覆盖原有Cloud Run服务的配置，如果发布时提供的配置（比如仅通过--images指定镜像）不包含之前的密钥、Cloud SQL连接等设置，这些配置就会被清除。以下是具体解决方法：

1. 确保部署配置包含所有需要保留的设置 #

把密钥、Cloud SQL连接等所有必要配置都写入Knative Service的YAML文件，每次发布时使用这个完整的配置文件，而非仅指定镜像。

比如在你的现有配置基础上，补充Cloud SQL连接的配置：

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: backend
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/startup-cpu-boost: 'true'
        # 新增Cloud SQL实例连接注解
        run.googleapis.com/cloudsql-instances: "{projectName}:us-east1:{sqlInstanceName}"
    spec:
      containers:
      - image: backend
        # 挂载Cloud SQL代理socket目录
        volumeMounts:
        - name: cloudsql
          mountPath: /cloudsql
      env:
      - name: DB_USER
        value: postgres
      - name: ApiKey
        valueFrom:
          secretKeyRef:
            name: test-key
            key: '1'
      - name: DB_PASS
        valueFrom:
          secretKeyRef:
            name: postgres-pass
            key: '1'
      # 新增Cloud SQL凭证卷
      volumes:
      - name: cloudsql
        secret:
          secretName: cloudsql-instance-credentials

发布时改用指定完整配置文件的命令，替换原来的--images参数：

gcloud deploy releases create rel-b256 --project {projectName} --region us-east1 --delivery-pipeline backend-pipeline --config=service.yaml

2. 使用Kustomize实现增量更新 #

如果不想每次修改YAML里的镜像地址，可以用Kustomize管理配置，只更新镜像tag，保留其他所有配置：

1. 创建kustomization.yaml文件：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- service.yaml
images:
- name: backend
  newName: {backendPath}

2. 发布时指定Kustomize配置目录：

gcloud deploy releases create rel-b256 --project {projectName} --region us-east1 --delivery-pipeline backend-pipeline --config=./kustomize

这样每次发布只会更新镜像，原有环境变量、Cloud SQL连接等配置都会保留。

3. 利用服务绑定解耦配置与镜像部署 #

对于敏感密钥、Cloud SQL这类服务连接，可以使用Cloud Run的服务绑定功能，将配置与服务本身关联，而非写入Knative Service的spec中：

• 密钥可以绑定Secret Manager中的密钥，Cloud SQL可以通过服务绑定直接关联实例
• 这种方式下，即使更新镜像，绑定的配置不会被清除，因为配置独立于镜像部署存在

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