GKE 自动部署具有不同映像的多个部署/服务

Posted 2023-02-16

【中文标题】GKE 自动部署具有不同映像的多个部署/服务

【英文标题】：GKE automating deploy of multiple deployments/services with different images

【发布时间】：2021-06-07 19:03:12

【问题描述】：

我目前正在查看 GKE 和谷歌云上的一些教程。我在这里关注这个https://cloud.google.com/solutions/integrating-microservices-with-pubsub#building_images_for_the_app（源代码https://github.com/GoogleCloudPlatform/gke-photoalbum-example）

这个例子有 3 个部署和一个服务。示例教程让您通过命令行部署所有内容，这很好并且一切正常。然后我开始研究如何通过云构建实现部署自动化，并发现了这一点：

https://cloud.google.com/build/docs/deploying-builds/deploy-gke#automating_deployments

这些文档说您可以为触发器创建构建配置（例如推送到特定的存储库），它将触发构建。他们为此展示的示例 yaml 如下：

# deploy container image to GKE
- name: "gcr.io/cloud-builders/gke-deploy"
  args:
  - run
  - --filename=kubernetes-resource-file
  - --image=gcr.io/project-id/image:tag
  - --location=$_CLOUDSDK_COMPUTE_ZONE
  - --cluster=$_CLOUDSDK_CONTAINER_CLUSTER

我了解如何传入位置和集群参数，这些文档还对资源文件（文件名参数）和图像参数进行了以下说明：

kubernetes-resource-file 是您的 Kubernetes 配置文件的文件路径或包含您的 Kubernetes 资源文件的目录路径。

image 是容器映像的所需名称，通常是应用程序名称。

将此与所有服务都在一个存储库中的演示应用程序存储库相关联，我相信我可以为文件名参数提供文件夹路径，例如来自存储库https://github.com/GoogleCloudPlatform/gke-photoalbum-example/tree/master/config的配置文件夹

但这里的问题是这些资源文件本身具有图像属性，所以我不知道这与云构建触发器 yaml 的 image 属性有何关系。我也不知道如何在触发器 yaml 中拥有多个“图像”属性，其中每个部署都有自己的容器图像。

我是 GKE 和 Kubernetes 的新手，所以我想知道在这种情况下我是否误解了 kubernetes-resource-file 应该是什么。

但是，当多个部署/服务都捆绑到一个存储库中时，是否可以以这种方式自动部署多个部署/服务？还是让 Google 为本教程过度简化了一些事情 - 事实上大多数服务都在自己的存储库中，以便单独构建/测试/部署？

无论哪种方式，image 属性与部署 yaml 中已定义 图像 的事实有何关联？例如：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    name: photoalbum-app
  name: photoalbum-app
spec:
  replicas: 3
  selector:
    matchLabels:
      name: photoalbum-app
  template:
    metadata:
      labels:
        name: photoalbum-app
    spec:
      containers:
      - name: photoalbum-app
        image: gcr.io/[PROJECT_ID]/photoalbum-app@[DIGEST]
        tty: true
        ports:
        - containerPort: 8080
        env:
        - name: PROJECT_ID
          value: "[PROJECT_ID]"

 

【参考方案1】：

您使用的命令非常适合测试一个映像的部署。但是，当您使用 Kubernetes (K8S) 和托管版本的 GCP (GKE) 时，您通常不会这样做。

您使用 YAML 文件来描述您的部署、服务和所有其他您想要的 K8S 对象。部署时，您可以执行类似的操作

kubectl apply -f <file.yaml>

如果你有多个文件，你可以根据需要使用通配符

kubectl apply -f config/*.yaml

如果你喜欢只使用一个文件，你可以用---分隔对象

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
  labels:
    app: nginx
spec:...
...

【讨论】：

抱歉，我有点困惑这将如何与云构建的持续部署一起工作？云构建部署 yaml 是否只省略 image 参数，依赖 config 文件夹？

不，您需要更新 YAML 文件然后应用它们。或者重建它们。

对不起，我仍然不确定我是否关注。我想在提交到 repo 时触发云构建，并按照教程中的方式构建所有 3 个部署和服务。您是说这不是要走的路，还是专门针对提交的云构建不可能？我注意到 gke-deploy 页面上的以下评论“gke-deploy 只能在您的构建配置文件中引用一个图像。如果您的 Kubernetes 资源文件包含多个图像引用，则只有以 gcr/project-id/image 开头的图像将被更新以引用指定的标签。”我会只使用内联构建脚本吗？

我相信我已经找到了这个 repo github.com/GoogleCloudPlatform/software-delivery-workshop/blob/… 与这个 codelab codelabs.developers.google.com/codelabs/… 相关，我相信这是我需要调查的内容

同意，github repo的第65行告诉您如何替换yaml文件中的最新图像名称。以下行应用了更改。