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

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

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

当我使用Kubectl（依赖于该项目中GCR注册表中的私有映像）向该集群添加新服务/部署时，GitLab创建的集群中的Pod无法通过以下方式从GCR中提取：ErrImagePull。

需要明确的是，我不是从GitLab私有注册表中拉出，而是在与从GitLab创建的GKE集群（不需要拉出秘密）相同的项目中，从GCR注册表中拉出。

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

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

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

更新：手动配置的服务帐户无法解决问题。

注意：我试图将映像拉入群集，而不是拉入在群集上运行的GitLab Runner中。就是 我希望在我的GitLab基础架构旁边运行单独的服务/部署。

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

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

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

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

https://medium.com/google-cloud/updating-google-container-engine-vm-scopes-with-zero-downtime-50bff87e5f80

https://adilsoncarvalho.com/changing-a-running-kubernetes-cluster-permissions-aka-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 /创建

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

gke-default范围（供参考）

https://www.googleapis.com/auth/devstorage.read_only（允许您拉出）

https://www.googleapis.com/auth/logging.write

https://www.googleapis.com/auth/monitoring

https://www.googleapis.com/auth/service.management.readonly

https://www.googleapis.com/auth/servicecontrol

https://www.googleapis.com/auth/trace.append

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

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

列出您的节点：

kubectl get nodes

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

然后：

kubectl cordon [your-node-name-here]

之后，您需要消耗：

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

我遇到的一个问题是，我安装了GitLab Runner，这意味着由于用于控制它的本地数据/守护程序集，我无法正常排干豆荚。

出于这个原因，一旦我封入节点，我就从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  --zone 

就我个人而言，我仍在尝试找出如何允许访问私有网络（即，通过私有IP到达Cloud SQL），但是我现在可以提取我的映像了，所以我已经完成了一半。

我想就是这样-希望它可以节省您几分钟的时间！

TL; DR-由GitLab-Ci Kubernetes Integration创建的群集无法在与容器映像相同的项目中从GCR注册表中提取映像，而无需修改节点权限（范围）。

默认情况下，由GitLab-Ci的Kubernetes集成创建的群集创建的群集节点的创建对Google Cloud服务具有最小的权限（范围）。

您可以从GCP控制台仪表板的群集中直观地看到此内容，向下滚动到“权限”部分，然后查找“存储”：

这实际上意味着在您的GitLab-Ci Kubernetes集成集群中运行的节点将不具有从GCR注册表中提取映像所需的默认GCR注册表（只读）权限。

这也意味着（据我所知），即使您授予了服务帐户对GCR注册表的适当访问权限，也仍然无法使用-不能完全确定我正确设置了服务帐户，但我相信我做到了。

大。

如何修复权限

基本上，您有两个选择。第一个是创建一个集群（即在GitLab Kubernetes集成之外），然后按照手册“连接到现有集群”中的说明进行操作，将您的GitLab项目重新连接到THAT集群：https：// gitlab.com/help/user/project/clusters/index#adding-an-existing-kubernetes-cluster

第二个选项是修改您的权限，但这更复杂。