GKE - ErrImagePull извлекает данные из реестра контейнеров Google

Question

У меня есть кластер Google Kubernetes Engine, который до недавнего времени успешно извлекал изображения частных контейнеров из корзины реестра контейнеров Google.Я ничего не изменил, но теперь, когда я обновляю свои Развертывания Kubernetes, он не может запускать новые модули, и я получаю следующие события:

Normal   Pulling  14s                kubelet, <node-id>  pulling image "gcr.io/cloudsql-docker/gce-proxy:latest"
Normal   Pulling  14s                kubelet, <node-id>  pulling image "gcr.io/<project-id>/backend:62d634e"
Warning  Failed   14s                kubelet, <node-id>  Failed to pull image "gcr.io/<project-id>/backend:62d634e": rpc error: code = Unknown desc = unauthorized: authentication required
Warning  Failed   14s                kubelet, <node-id>  Error: ErrImagePull
Normal   Pulled   13s                kubelet, <node-id>  Successfully pulled image "gcr.io/cloudsql-docker/gce-proxy:latest"
Normal   Created  13s                kubelet, <node-id>  Created container
Normal   Started  13s                kubelet, <node-id>  Started container
Normal   BackOff  11s (x2 over 12s)  kubelet, <node-id>  Back-off pulling image "gcr.io/<project-id>/backend:62d634e"
Warning  Failed   11s (x2 over 12s)  kubelet, <node-id>  Error: ImagePullBackOff

Я проверил следующие вещи, которые кажутся всечтобы быть такими, какими они должны быть:

• Контейнеры и их теги действительно существуют и являются правильными.
• Пул узлов / экземпляры виртуальных машин для кластера GKE имеют разрешение storage-ro
• Ведро реестра контейнеров Google и кластер GKE находятся в одном проекте

Я также попытался отключить и снова включить службы container.googleapis.com и containerregistry.googleapis.com., но это не помогает.

Документация Google по реестру контейнеров гласит:

Кластеры Kubernetes Engine автоматически настраиваются с доступом для извлечения частных изображений из реестра контейнеров втот же проект.Вам не нужно выполнять дополнительные шаги для настройки аутентификации, если реестр и кластер находятся в одном облачном проекте.

Но, похоже, это не так.

Может кто-нибудь пролить дополнительный свет на то, что может происходить?Или дополнительные шаги, чтобы попробовать?

Answer 1

В моем случае проблема заключалась в том, что в пулах узлов, генерируемых минимальным спецификационным файлом, отсутствуют области oauth2, которые предоставляют доступ к реестру.Добавление

nodePools:
  config:
    oauthScopes:
    - https://www.googleapis.com/auth/devstorage.read_only
    - https://www.googleapis.com/auth/servicecontrol
    - https://www.googleapis.com/auth/service.management.readonly
    - https://www.googleapis.com/auth/trace.append

в мои спецификации исправлены вещи.Я думаю, это важная область действия devstorage, но я не уверен, так как я просто скопировал весь список областей из спецификации, которую генерирует веб-консоль.

Answer 2

У меня возникла такая же проблема, когда я создал кластер с terraform.Во-первых, я указал только service_account в node_config, поэтому пул узлов создавался со слишком малыми областями OAuth.Явно пишите service_account и oauth_scope, как показано ниже, узлы могут извлекать изображения из частных репозиториев GCR.

resource "google_container_node_pool" "primary_preemptible_nodes" {
  node_config {
    service_account = "${google_service_account.gke_nodes.email}"

    oauth_scopes = [
      "storage-ro",
      "logging-write",
      "monitoring"
    ]
  }
}

Answer 3

Хорошо, это оказалось сложно, но причина была в следующем:

Я использовал Terraform, чтобы установить учетную запись службы для узлов в кластере GKE, но вместо использования вывода emailресурс google_service_account для указания учетной записи службы, вместо этого я использовал вывод unique_id.Terraform и Google Cloud API прекрасно с этим согласились.

Когда Kubernetes (и другие вещи) пытался получить доступ к внутреннему API метаданных на каждом узле, чтобы получить токен, который он мог использовать, он получал ответService account is invalid/disabled и статус 403.

Повторное создание пула узлов с правильно указанной учетной записью службы устранило проблему.