Кластер GKE не может извлечь (ErrImagePull) из реестра GCR в том же проекте (интеграция GitLab Kubernetes): почему? - PullRequest
0 голосов
/ 04 января 2019

Так что после небольшого поиска в Google (который загрязняется людьми, имеющими проблемы с секретами извлечения), я публикую это здесь - и в службу поддержки GCP (обновлю, как я слышу).

Я создал кластер из интеграции GitLab Kubernetes (документы: https://about.gitlab.com/solutions/kubernetes) в том же проекте, что и мой реестр / изображения GCR.

Когда я добавляю новую службу / развертывание в этот Кластер с помощью Kubectl (который в этом проекте использует частный образ в реестре GCR), модули в созданном GitLab кластере не могут извлечь из GCR с помощью: ErrImagePull.

Для ясности: я НЕ извлекаю данные из частного реестра GitLab, я пытаюсь извлечь данные из реестра GCR в рамках того же проекта, что и кластер GKE, созданный из GitLab (для которого не требуется секрет извлечения).

Другие кластеры (созданные из консоли GCP) в рамках этого проекта могут правильно обращаться к одному и тому же образу, поэтому я считаю, что есть некоторая разница между кластерами, созданными с помощью API (в данном случае из GitLab), и кластерами, созданными из консоли GCP.

Я надеюсь, что кто-то сталкивался с этим в прошлом - или может объяснить различия в учетных записях служб и т. Д., Которые могут быть причиной проблемы.

Я попытаюсь создать учетную запись службы и вручную предоставить ей роль Project Viewer, чтобы посмотреть, решит ли это проблему.

Обновление: настроенная вручную учетная запись службы не решила проблему.

Примечание. Я пытаюсь вставить изображение в кластер, а не в GitLab Runner, который работает на кластере. То есть. Я хочу, чтобы отдельная служба / развертывание работали параллельно с моей инфраструктурой GitLab.

Ответы [ 2 ]

0 голосов
/ 05 января 2019

TL; DR - Кластеры, созданные GitLab-Ci Kubernetes Integration, не смогут получить изображение из реестра GCR в том же проекте, что и изображения контейнера, - без изменения разрешений узла (-ов). (прицелы).

В то время как вы МОЖЕТЕ вручную изменить разрешения на отдельных машинах узла для предоставления учетных данных по умолчанию для приложения (см .: 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
  2. 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

Для меня я сделал gke-default (так же, как мой другой кластер) и sql-admin. Причиной этого является то, что мне нужно иметь доступ к базе данных SQL в Cloud SQL во время части моей сборки, и я не хочу подключаться к общедоступному IP-адресу для этого.

gke-default Scopes (для справки)

  1. https://www.googleapis.com/auth/devstorage.read_only (позволяет тянуть)
  2. https://www.googleapis.com/auth/logging.write
  3. https://www.googleapis.com/auth/monitoring
  4. https://www.googleapis.com/auth/service.management.readonly
  5. https://www.googleapis.com/auth/servicecontrol
  6. https://www.googleapis.com/auth/trace.append

Сравните вышеупомянутое с более заблокированными разрешениями от созданного GitLab-Ci кластера (ТОЛЬКО эти два: https://www.googleapis.com/auth/logging.write, https://www.googleapis.com/auth/monitoring):

Obviosuly настройка вашего кластера ТОЛЬКО с минимальными необходимыми разрешениями, безусловно, путь сюда. Как только вы поймете, что это такое, и создадите новый пул узлов в правильной области действия ...

Перечислите ваши узлы с помощью:

kubectl get nodes

Тот, который вы только что создали (самый последний), имеет новые настройки, в то время как более старая опция - это кластер gitlab по умолчанию, который можно извлечь из GCR.

Тогда:

kubectl cordon [your-node-name-here]

После этого вы хотите слить:

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

Я столкнулся с проблемами, когда тот факт, что у меня установлен GitLab Runner, означал, что я не мог нормально дренировать модули из-за локального набора данных / демона, который использовался для его управления.

По этой причине, как только я оцепил свой Узел, я просто удалил узел из Kubectl (не уверен, что это вызовет проблемы - но это было хорошо для меня). После удаления вашего узла вам нужно удалить пул узлов «default-pool», созданный 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>

В моем личном случае я все еще пытаюсь выяснить, как разрешить доступ к частной сети (т. Е. Получить доступ к облачному SQL через частный IP-адрес), но теперь я могу вытащить свои изображения, чтобы оказаться на полпути.

Думаю, все, надеюсь, это сэкономило вам несколько минут!

0 голосов
/ 05 января 2019

TL; DR - Кластеры, созданные GitLab-Ci Kubernetes Integration, не смогут извлекать изображение из реестра GCR в том же проекте, что и изображения контейнеров, - без изменения разрешений узлов (областей).

По умолчанию узлы кластера, созданные кластером, который сам был создан интеграцией Kubernetes GitLab-Ci, создаются с минимальными разрешениями (областями) для облачных сервисов Google.

Это можно увидеть визуально на панели мониторинга консоли GCP для вашего кластера, прокрутите вниз до раздела разрешений и найдите «Хранилище»:

enter image description here

По сути, это означает, что узлы, работающие в вашем кластере интеграции GitLab-Ci Kubernetes, НЕ будут иметь разрешений по умолчанию для реестра GCR (только для чтения), необходимых для извлечения изображения из реестра GCR.

Это также означает (насколько я могу судить), что даже если вы предоставите служебной учетной записи надлежащий доступ к реестру GCR, она все равно не будет работать - не совсем уверен, что я правильно настроил свою служебную учетную запись, но я верю, что сделал.

Отлично.

Как исправить разрешения

Обычно у вас есть два варианта. Первый - создать кластер (т. Е. Вне GitLab Kubernetes Integration), а затем повторно подключить ваш проект GitLab к кластеру THAT, следуя инструкциям «подключиться к существующему кластеру», которые можно найти здесь: https://gitlab.com/help/user/project/clusters/index#adding-an-existing-kubernetes-cluster

Второй вариант - изменить ваши разрешения, но это более сложно.

...