代码之家 › 专栏 › 技术社区 › Necevil

GKE集群不能从同一个项目(Gitlab-Kubernetes集成)中的GCR注册表中提取(errImagePull):为什么?

gke gitlab google-cloud-platform kubernetes

1

Necevil · 技术社区 · 7 年前

所以,在谷歌搜索了一点(这是被有拉秘密问题的人污染的)之后,我将在这里发布这个消息,并发送给GCP支持(我听到后会更新)。

我从Gitlab Kubernetes集成创建了一个集群(文档: https://about.gitlab.com/solutions/kubernetes )在与我的GCR注册表/图像相同的项目中。

当我使用kubectl(依赖于此项目中gcr注册表中的私有映像)向该集群添加新的服务/部署时,gitlab创建的集群中的pods无法使用:errImagePull从gcr中提取。

明确地说,“我不是从Gitlab私人注册处提取,我正试图从与Gitlab创建的GKE集群相同项目内的GCR注册处提取(不需要提取机密)。

这个项目中的其他集群(从GCP控制台创建)可以正确访问相同的映像,所以我的想法是,通过API创建的集群(在本例中是从Gitlab创建的)与从GCP控制台创建的集群之间存在一些差异。

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

我将尝试创建一个服务帐户,并手动授予IT项目查看器角色,以查看这是否解决了问题。

更新:手动配置的服务帐户未解决问题。

注意:我试图将一个映像拉入集群,而不是拉入运行在集群上的Gitlab运行程序。也就是说,我希望在我的Gitlab基础设施旁边运行一个单独的服务/部署。

2 回复 | 直到 7 年前

1

3

Necevil 7 年前

DR gitlab ci kubernetes integration创建的集群在不修改节点权限(作用域)的情况下,将无法从与容器映像相同的项目中的GCR注册表中提取映像。

同时,您可以手动修改单个节点计算机上的权限以授予应用程序默认凭据(请参见: https://developers.google.com/identity/protocols/application-default-credentials )以这种方式实时执行适当的作用域将意味着,如果您的节点在将来某个时间点被重新创建,它将不会有您修改的作用域,并且事情将会中断。

不要手动修改权限,而是创建一个新的节点池,该池具有访问所需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。原因是我需要在构建的过程中能够访问云SQL中的SQL数据库,我不想连接到公共IP来实现这一点。

GKE默认范围(供参考)

与上面相比,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运行程序,这意味着由于用于控制它的本地数据/守护进程集,我无法正常地排出pods。

因为这个原因,一旦我记录了我的节点,我就从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>

在我个人的情况下,我仍在努力找出如何允许访问私有网络(即通过私有IP访问云SQL),但我现在可以拉我的图像,所以我已经走到一半了。

我想就是这样,希望它能帮你节省几分钟!

2

1

Necevil 7 年前

由Gitlab-Ci-Kubernetes集成创建的“Dr_”集群在不修改节点权限(作用域)的情况下,将无法从与容器映像_相同项目中的GCR注册表中提取映像。

默认情况下,由Gitlab CI的Kubernetes集成创建的集群创建的集群节点是以对Google云服务的最小权限(作用域)创建的。

您可以在集群的GCP控制台仪表板上看到这一点,向下滚动到“权限”部分并查找“存储”:

这本质上意味着在Gitlab CI Kubernetes集成集群中运行的节点将没有从GCR注册表中提取图像所需的默认GCR注册表(只读)权限。

这也意味着(据我所知),即使您授予服务帐户访问GCR注册表的适当权限,它仍然不起作用,不完全确定我是否正确设置了服务帐户,但我相信我做到了。

伟大的。

如何修复权限

基本上你有两个选择。第一种方法是创建一个集群(即Gitlab-Kubernetes集成之外),然后按照手册中的“连接到现有集群”说明将Gitlab项目重新连接到该集群,如下所示: https://gitlab.com/help/user/project/clusters/index#adding-an-existing-kubernetes-cluster

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