因此，在谷歌上搜索了一下(被 Pull Secrets 有问题的人污染了)后，我将其发布在这里 - 并发布到 GCP 支持(我会在听到时更新)。
我在与我的 GCR 注册表/图像相同的项目中从 GitLab Kubernetes 集成(文档:https://about.gitlab.com/solutions/kubernetes)创建了一个集群。
当我使用 Kubectl(它依赖于该项目中 GCR 注册表中的私有(private)镜像)向该集群添加新服务/部署时，GitLab 创建的集群中的 pod 无法从 GCR 拉取:ErrImagePull。
需要明确的是——我不是从 GitLab 私有(private)注册表中提取，而是尝试从与从 GitLab 创建的 GKE 集群相同的项目中的 GCR 注册表中提取(这不应该需要 Pull Secret)。
此项目中的其他集群(从 GCP 控制台创建)可以正确访问相同的图像，所以我的想法是通过 API 创建的集群(在本例中来自 GitLab)与从 GCP 控制台创建的集群之间存在一些差异。
我希望过去有人遇到过这种情况——或者可以解释可能导致问题的服务帐户等方面的差异。
I am going to attempt to create a service account and manually grant it Project Viewer role to see if that solves the problem.
更新:手动配置的服务帐户没有解决问题。
注意:我正在尝试将图像拉入集群而不是拉入集群上运行的 GitLab Runner。 IE。我想要一个单独的服务/部署与我的 GitLab 基础设施一起运行。
最佳答案
TL;DR — 由 GitLab-Ci Kubernetes 集成创建的集群将无法从与容器图像相同的项目中的 GCR 注册表中提取图像 — 无需修改节点权限(范围)。
While you CAN manually modify the permissions on an Individual Node machine(s) to grant the Application Default Credentials (see: https://developers.google.com/identity/protocols/application-default-credentials) the proper scopes in real time — doing it this way would mean that if your node is re-created at some point in the future it WOULD NOT have your modified scopes and things would break.
与其手动修改权限，不如创建一个具有适当范围的新节点池来访问您所需的 GCP 服务。
以下是我用来引用的一些资源:
创建适当范围的节点池通常如下所示
gcloud container node-pools create [new pool name] \
--cluster [cluster name] \
--machine-type [your desired machine type] \
--num-nodes [same-number-nodes] \
--scopes [your new set of scopes]
如果您不确定所需范围的名称是什么 — 您可以在此处查看范围和范围别名的完整列表:https://cloud.google.com/sdk/gcloud/reference/container/node-pools/create
对我来说，我做了 gke-default(与我的其他集群相同)和 sql-admin。这样做的原因是我需要能够在部分构建期间访问 Cloud SQL 中的 SQL 数据库，并且我不想连接到公共(public) IP 来执行此操作。
gke-default 范围(供引用)
将上述内容与来自 GitLab-Ci 创建的集群的更多锁定权限进行对比(只有这两个:https://www.googleapis.com/auth/logging.write，https://www.googleapis.com/auth/monitoring):
Obviosuly 将您的集群配置为仅所需的最低权限是肯定的方法。一旦你弄清楚那是什么并创建新的适当范围的节点池......
列出您的节点:
kubectl get nodes
您刚刚创建的(最近的)具有新设置，而较旧的选项是可以从 GCR 中提取的默认 gitlab 集群。
然后:
kubectl cordon [your-node-name-here]
之后你想排干:
kubectl drain [your-node-name-here] --force
我遇到了一些问题，即我安装了 GitLab Runner 意味着由于用于控制它的本地数据/守护程序集，我无法正常排空 pod。
出于这个原因，一旦我封锁了我的节点，我就从 Kubectl 中删除了该节点(不确定这是否会导致问题——但这对我来说很好)。删除节点后，您需要删除 GitLab 创建的“默认池”节点池。
列出您的节点池:
gcloud container node-pools list --cluster [CLUSTER_NAME]
查看 gitlab 创建的旧范围:
gcloud container node-pools describe default-pool \
--cluster [CLUSTER_NAME]
检查您是否有正确的新范围(您刚刚添加):
gcloud container node-pools describe [NEW_POOL_NAME] \
--cluster [CLUSTER_NAME]
如果您的新节点池具有正确的范围，您的部署现在可以删除默认池:
gcloud container node-pools delete default-pool \
--cluster <YOUR_CLUSTER_NAME> --zone <YOUR_ZONE>
就我个人而言，我仍在试图弄清楚如何允许访问私有(private)网络(即通过私有(private) IP 访问 Cloud SQL)，但我现在可以提取图像，所以我已经完成了一半。
我想就是这样 - 希望它为您节省了几分钟!
关于kubernetes - GKE 集群无法从同一项目中的 GCR 注册表中提取 (ErrImagePull) (GitLab Kubernetes 集成) : Why?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54043495/