Question

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

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

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

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

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

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

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

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

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

Answer 1

TL; 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。这样做的原因是，在构建的一部分过程中，我需要能够访问Cloud SQL中的SQL数据库，并且我不想连接到公共IP即可。

gke-default范围（供参考）

将以上内容与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 <YOUR_CLUSTER_NAME> --zone <YOUR_ZONE>

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

我想就是这样-希望它为您节省了几分钟！

Answer 2

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

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

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

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

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

太好了。

如何修复权限

基本上，您有两个选择。第一个是创建一个集群（即在GitLab Kubernetes集成之外），然后按照手册“连接到现有集群”的说明进行操作，将您的GitLab项目重新连接到THAT集群：{{3} }

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

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

2 个答案:

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

gke-default范围（供参考）

如何修复权限