英文:

Where to host docker images for several environments

问题 {#heading}

1. 如果要让GKE部署能够拉取镜像，需要将哪个服务账号添加到注册表？
2. 这是否是推荐的方法？感觉有点奇怪，还需要一个专用项目。是否有类似"全局"仓库的东西？

英文:

I have several Google cloud projects with dedicated environments for prod, stag, dev, etc. All the Docker image are platform agnostic and completely controlled by environment variables. They should be used from all environments. What I have found is to create a project, deploy the docker images in the repository and then allow read access by using a
registry reader to the consuming service accounts.

1. What service account has to be added to the registry if GKE deployments should be able to pull the image?
2. Is this the recommended approach? I feels a little bit strange that also a dedicated project is needed. Is there something like a "global" repository?

答案1 {#1}

得分: 1

使用工作负载身份 和GKE ： https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity

您可以在IAM 中创建一个新的服务帐号 ，并为其分配必要的角色/权限。

这个GCP服务帐号 将使用K8s服务帐号 ，GKE的工作负载将能够从Docker注册表中拉取镜像。

所以在这种情况下，您不需要管理ImagePull secret，也不需要定期刷新它，您可以通过GCP服务帐号来管理认证。

更新：

是的，您可以专门为Docker注册表运行项目，这更多取决于您的需求。

只是提醒一下，如果您指的是GCR ，请确保随着时间的推移它将会被弃用 ，所以请查看Artifact注册表。

在特定于Docker注册表的单个项目中保留的利弊：

• 优点：简化管理和访问控制
• 缺点：更难以在项目之间隔离工件。

如果所有工件都存储在一个项目中，并且所有其他项目都从那里拉取。

如果您有一些敏感的工件不希望所有项目都能访问，您将需要为这些工件创建单独的存储库。 英文:

> What service account has to be added to the registry if GKE
> deployments should be able to pull the image?

Use the workload identity with GKE : https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity

You can create a new service account in IAM and assign it necessary role/permission to it.

That GCP serviceaccount will used the of K8s service account and GKE workloads will be able to pull the images from the Docker registry.

So in this case you don't need to manage the ImagePull secret, refresh it from time to time and you can manage Auth by GCP service account.

Update :

Yes you can run the project for Docker Registry specifically, it's more depends on your need.

Just to mentioned if by Registry you mean GCR make sure it will get deprecated with time so check out the Artifact registry.

There is pros & cons Keeping single Project specific to Docker registry

• Pros : Simplify management & access control
• Con : More difficult to isolate the Artifacts between projects.

If all artifacts are stored in one project and all others pulling from there.

If you have sensitive artifacts that you don't want to be accessible to all projects, you will need to create separate repositories for those artifacts.