GKE 集群无法从同一项目（GitLab Kubernetes 集成）中的 GCR 注册表中提取 (ErrImagePull)：为什么？

因此，在谷歌搜索了一下之后（被那些在 Pull Secrets 方面遇到麻烦的人污染了），我将其发布在这里 - 以及 GCP 支持（据我所知将更新）。

我通过 GitLab Kubernetes 集成创建了一个集群（文档：https://about.gitlab.com/solutions/kubernetes https://about.gitlab.com/solutions/kubernetes）与我的 GCR 注册表/图像位于同一项目中。

当我使用 Kubectl（依赖于本项目中 GCR 注册表中的私有映像）向该集群添加新服务/部署时，GitLab 创建的集群中的 Pod 无法从 GCR 中拉取，并显示：ErrImagePull。

需要明确的是，我不是从 GitLab 私有注册表中提取数据，而是尝试从与从 GitLab 创建的 GKE 集群同一项目内的 GCR 注册表中提取数据（不需要 Pull Secret）。

该项目中的其他集群（从 GCP 控制台创建）可以正确访问相同的映像，因此我的想法是，通过 API（在本例中来自 GitLab）创建的集群与从 GCP 控制台创建的集群之间存在一些差异。

我希望有人过去遇到过这个问题，或者可以解释可能导致问题的服务帐户等方面的差异。

我将尝试创建一个服务帐户并手动授予其项目查看者角色，看看是否可以解决问题。

更新：手动配置服务帐户没有解决问题。

注意：我正在尝试将映像拉入集群，而不是拉入集群上运行的 GitLab Runner。 IE。我希望有一个单独的服务/部署与我的 GitLab 基础设施一起运行。

TL;DR— 如果不修改节点权限（范围），GitLab-Ci Kubernetes Integration 创建的集群将无法从与容器镜像相同的项目中的 GCR 注册表中提取镜像。

虽然您可以手动修改单个节点计算机上的权限以授予应用程序默认凭据（请参阅：https://developers.google.com/identity/protocols/application-default-credentials https://developers.google.com/identity/protocols/application-default-credentials）实时正确的范围 - 这样做意味着如果您的节点在将来的某个时候重新创建，它不会有您修改的范围，并且事情会中断。

您无需手动修改权限，而是创建一个具有适当范围的新节点池来访问所需的 GCP 服务。

以下是我使用的一些资源供参考：

1. https://medium.com/google-cloud/updating-google-container-engine-vm-scopes-with-zero-downtime-50bff87e5f80 https://medium.com/google-cloud/updating-google-container-engine-vm-scopes-with-zero-downtime-50bff87e5f80
2. https://adilsoncarvalho.com/changing-a-running-kubernetes-cluster-permissions-a-k-a-scopes-3e90a3b95636 https://adilsoncarvalho.com/changing-a-running-kubernetes-cluster-permissions-a-k-a-scopes-3e90a3b95636

创建一个适当范围的节点池通常看起来像这样

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 https://cloud.google.com/sdk/gcloud/reference/container/node-pools/create

对我来说，我使用了 gke-default （与我的其他集群相同）和 sql-admin。原因是我需要能够在构建过程中访问 Cloud SQL 中的 SQL 数据库，并且我不想连接到公共 IP 才能执行此操作。

gke-default 范围（仅供参考）

1. https://www.googleapis.com/auth/devstorage.read_only https://www.googleapis.com/auth/devstorage.read_only（允许你拉）
2. https://www.googleapis.com/auth/logging.write https://www.googleapis.com/auth/logging.write
3. https://www.googleapis.com/auth/monitoring https://www.googleapis.com/auth/monitoring
4. https://www.googleapis.com/auth/service.management.readonly https://www.googleapis.com/auth/service.management.readonly
5. https://www.googleapis.com/auth/servicecontrol https://www.googleapis.com/auth/servicecontrol
6. https://www.googleapis.com/auth/trace.append https://www.googleapis.com/auth/trace.append

将上述内容与 GitLab-Ci 创建的集群中更多锁定的权限进行对比（仅这两个：https://www.googleapis.com/auth/logging.write https://www.googleapis.com/auth/logging.write, https://www.googleapis.com/auth/monitoring https://www.googleapis.com/auth/monitoring):

显然，将集群配置为仅需要所需的最低权限肯定是这里的方法。一旦你弄清楚那是什么并创建新的适当范围的节点池......

列出您的节点：

kubectl get nodes

您刚刚创建的（最新的）具有新设置，而旧选项是可以从 GCR 拉取的默认 gitlab 集群。

Then:

kubectl cordon [your-node-name-here]

之后你想要排水：

kubectl drain [your-node-name-here] --force

我遇到了一些问题，因为我安装了 GitLab Runner，这意味着由于用于控制它的本地数据/守护进程集，我无法正常耗尽 Pod。

因此，一旦我封锁了我的节点，我就从 Kubectl 中删除了该节点（不确定这是否会导致问题 - 但这对我来说很好）。删除节点后，您需要删除 GitLab 创建的“default-pool”节点池。

列出您的节点池：

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>

就我个人而言，我仍在尝试弄清楚如何允许访问专用网络（即通过专用 IP 访问 Cloud SQL），但我现在可以提取图像，所以我已经成功了一半。

我想就是这样了——希望它能为您节省几分钟的时间！