Контейнеры в Kubernetes: образы, использование частных реестров (Private Registry)

Частные реестры могут требовать ключи для чтения образов с них. Учетные данные могут быть предоставлены несколькими способами:

Использование Google Container Registry
- Один на каждый кластер
- автоматически настраивается в Google Compute Engine или Google Kubernetes Engine
- все модули (pods) могут читать частный реестр проекта
Использование Amazon Elastic Container Registry (ECR)
- использовать роли и политики IAM для контроля доступа к репозиториям ECR
- автоматически обновляет учетные данные ECR
Использование Oracle Cloud Infrastructure Registry (OCIR)
- использовать роли и политики IAM для контроля доступа к репозиториям OCIR
Использование реестра Azure Container (ACR)
Использование реестра IBM Cloud Container
Настройка узлов для аутентификации в частном реестре
- все модули (pods) могут читать любые настроенные частные реестры
- требует настройки узла администратором кластера
Предварительно загруженные образы
- все модули могут использовать любые образы, кэшированные на узле
- требует настройки root-доступа ко всем узлам
Указание ImagePullSecrets на Pod
- только модули, которые предоставляют собственные ключи, могут получить доступ к частному реестру

Каждый вариант более подробно описан ниже.

Использование Google Container Registry

Kubernetes имеет встроенную поддержку реестра контейнеров Google (Google Container Registry) (GCR) при работе в Google Compute Engine (GCE). Если вы работаете в кластере в GCE или в Google Kubernetes Engine, просто используйте полное имя образа (например, gcr.io/my_project/image:tag).

Все модули (pods) в кластере будут иметь доступ на чтение образов в этом реестре.

Kubelet аутентифицируется в GCR, используя учетную запись Google service account. У учетной записи службы в инстансе будет https://www.googleapis.com/auth/devstorage.read_only, поэтому он может извлекать данные из GCR проекта, но не загружать их в реестр.

Использование Amazon Elastic Container Registry

Kubernetes имеет встроенную поддержку Amazon Elastic Container Registry, когда узлами являются экземпляры AWS EC2.

Просто используйте полное имя образа (например, ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag) в определении Pod.

Все пользователи кластера, которые могут создавать модули (pods), смогут запускать модули (pods), которые используют любые образы в реестре ECR.

kubelet будет извлекать и периодически обновлять учетные данные ECR. Для этого необходимы следующие разрешения:

ecr:GetAuthorizationToken
ecr:BatchCheckLayerAvailability
ecr:GetDownloadUrlForLayer
ecr:GetRepositoryPolicy
ecr:DescribeRepositories
ecr:ListImages
ecr:BatchGetImage

Требования:

Вы должны использовать версию kubelet v1.2.0 или новее. (например, запустите /usr/bin/kubelet --version=true).

Если ваши узлы находятся в регионе A, а ваш реестр находится в другом регионе B, вам нужна версия v1.3.0 или новее.

ECR должен быть предложен в вашем регионе

Поиск проблемы:

Проверьте все требования выше.

Получите учетные данные $REGION (например, us-west-2) на своей рабочей станции. SSH в хост и запустить Docker вручную с этими данными. Это работает?

Убедитесь, что kubelet работает с --cloud-provider=aws.

Проверьте логи kubelet (например, journalctl -u kubelet) на наличие строк лога, таких как:
plugins.go:56] Registering credential provider: aws-ecr-key
provider.go:91] Refreshing cache for provider: *aws_credentials.ecrProvider

Использование Azure Container Registry (ACR)

При использовании Azure Container Registry вы можете проходить аутентификацию, используя пользователя-администратора или участника службы. В любом случае аутентификация выполняется через стандартную аутентификацию Docker. Эти инструкции предполагают использование инструмента командной строки azure-cli.

Сначала вам нужно создать реестр и сгенерировать учетные данные, полную документацию по этому вопросу можно найти в документации по реестру контейнера Azure.

Создав реестр контейнеров, вы будете использовать для входа следующие учетные данные:

DOCKER_USER: участник службы или имя администратора
DOCKER_PASSWORD: пароль участника службы или пароль администратора
DOCKER_REGISTRY_SERVER: ${имя-реестра}.azurecr.io
DOCKER_EMAIL: ${некоторый адрес электронной почты}

Заполнив эти переменные, вы можете сконфигурировать секрет Kubernetes и использовать его для развертывания Pod.

Использование IBM Cloud Container Registry

IBM Cloud Container Registry предоставляет многопользовательский реестр частных образов, который вы можете использовать для безопасного хранения и обмена вашими образами Docker. По умолчанию образы в вашем личном реестре сканируются встроенным консультантом по уязвимостям для выявления проблем безопасности и потенциальных уязвимостей. Пользователи вашей учетной записи IBM Cloud могут получить доступ к вашим образам или вы можете создать токен для предоставления доступа к пространствам имен реестра.

Чтобы установить подключаемый модуль CLI IBM Cloud Container Registry и создать пространство имен для ваших образов, смотрите раздел Начало работы с IBM Cloud Container Registry.

Вы можете использовать IBM Cloud Container Registry для развертывания контейнеров из общедоступных образов IBM Cloud и ваших личных образов в пространство имен default (по умолчанию) вашего кластера IBM Cloud Kubernetes Service. Чтобы развернуть контейнер в других пространствах имен или использовать образ из другого региона реестра IBM Cloud Container или учетной записи IBM Cloud, создайте Kubernetes imagePullSecret.

Настройка узлов для аутентификации в частном реестре

Примечание. Если вы используете Google Kubernetes Engine, на каждом узле уже будет файл .dockercfg с учетными данными для реестра контейнеров Google. Вы не можете использовать этот подход.

Примечание. Если вы работаете в AWS EC2 и используете реестр контейнеров EC2 (ECR), kubelet на каждом узле будет управлять и обновлять учетные данные для входа в ECR. Вы не можете использовать этот подход.

Примечание. Этот подход подходит, если вы можете контролировать конфигурацию узла. Он не будет надежно работать на GCE и любом другом облачном провайдере, который выполняет автоматическую замену узлов.

Примечание. На данный момент Kubernetes поддерживает только раздел auths и HttpHeaders в конфигурации docker. Это означает, что учетные данные помощников (credHelpers или credsStore) не поддерживаются.

Docker хранит ключи для частных реестров в файле $HOME/.dockercfg или $HOME/.docker/config.json. Если вы поместите тот же файл в список путей поиска ниже, kubelet использует его в качестве поставщика учетных данных при извлечении образов.

{--root-dir:-/var/lib/kubelet}/config.json
{cwd of kubelet}/config.json
${HOME}/.docker/config.json
/.docker/config.json
{--root-dir:-/var/lib/kubelet}/.dockercfg
{cwd of kubelet}/.dockercfg
${HOME}/.dockercfg
/.dockercfg

Примечание. Возможно, вам придется явно указать HOME=/root в файле среды для kubelet.

Вот рекомендуемые шаги по настройке ваших узлов для использования частного реестра. В этом примере запустите их на своем настольном компьютере/ноутбуке:

1. Запустите docker login [server] для каждого набора учетных данных, которые вы хотите использовать. Это обновляет $HOME/.docker/config.json.

2. Просмотрите файл $HOME/.docker/config.json в редакторе, чтобы убедиться, что он содержит только те учетные данные, которые вы хотите использовать.

3. Получите список ваших узлов, например:

если вам нужны имена: nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')

если вы хотите получить IP-адреса: nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')

4. Скопируйте ваш локальный .docker/config.json в один из приведенных выше списков путей поиска.

например: for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done

5. Проверьте это, создав пакет, который использует частный образ, например:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: private-image-test-1
spec:
  containers:
    - name: uses-private-image
      image: $PRIVATE_IMAGE_NAME
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]
EOF

pod/private-image-test-1 created

Если все работает, то после выполнения команды:

kubectl logs private-image-test-1

через несколько секунд вы должны увидеть:

SUCCESS

Если это не удалось, то после выполнения команды:

kubectl describe pods/private-image-test-1 | grep "Failed"

вы увидите

  Fri, 26 Jun 2015 15:36:13 -0700    Fri, 26 Jun 2015 15:39:13 -0700    19    {kubelet node-i2hq}    spec.containers{uses-private-image}    failed        Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found

Вы должны убедиться, что все узлы в кластере имеют одинаковый .docker/config.json. В противном случае модули (pods) будут работать на некоторых узлах и не будут работать на других. Например, если вы используете автоматическое масштабирование узла, то каждый шаблон экземпляра должен включать файл .docker/config.json или монтировать диск, на котором он находится.

Все модули (pods) будут иметь доступ для чтения к Образам в любом частном реестре, как только частные ключи реестра будут добавлены в .docker/config.json.

Предварительно извлеченные образы

По умолчанию kubelet будет пытаться извлечь каждый образ из указанного реестра. Однако, если для свойства imagePullPolicy контейнера установлено значение IfNotPresent или Never, используется локальный образ (предпочтительно или исключительно, соответственно).

Если вы хотите использовать предварительно извлеченные образы в качестве замены проверки подлинности реестра, необходимо убедиться, что все узлы в кластере имеют одинаковые предварительно извлеченные образы.

Этот подход может быть использован для увеличения скорости предварительной загрузки определенных образов или в качестве альтернативы аутентификации в частном реестре.

Все модули (pods) будут иметь доступ для чтения к любым предварительно извлеченным образам.

Указание ImagePullSecrets на Pod'е

Примечание. Этот подход в настоящее время является рекомендуемым подходом для Google Kubernetes Engine, GCE и любых облачных провайдеров, в которых создание узлов автоматизировано. Kubernetes поддерживает указание ключей реестра на модуле (pod).

Создание секрета с помощью Docker Config

Запустите следующую команду, подставив соответствующие значения в верхнем регистре:

kubectl create secret docker-registry  --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

Если у вас уже есть файл учетных данных Docker, то вместо использования вышеуказанной команды вы можете импортировать файл учетных данных в качестве секрета Kubernetes. Создание секрета на основе существующих учетных данных Docker объясняет, как его настроить. Это особенно полезно, если вы используете несколько частных реестров контейнеров, так как kubectl create secret docker-registry создает Secret, который будет работать только с одним частным реестром.

Примечание. Модули (pods) могут ссылаться только на секреты извлечения образов в своем собственном пространстве имен, поэтому этот процесс необходимо выполнять один раз для каждого пространства имен.

Ссылка на imagePullSecrets на Pod'е

Теперь вы можете создавать модули, которые ссылаются на этот секрет, добавив раздел imagePullSecrets в определение модуля (pod).

cat <<EOF > pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: myregistrykey
EOF

cat <<EOF >> ./kustomization.yaml
resources:
- pod.yaml
EOF

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

Однако установка этого поля может быть автоматизирована путем установки imagePullSecrets в ресурсе serviceAccount.

Вы можете использовать это вместе с .docker/config.json для каждого узла. Полномочия будут объединены. Этот подход будет работать на Google Kubernetes Engine.

Случаи применения

Существует ряд решений для настройки частных реестров. Вот несколько распространенных вариантов использования и предлагаемых решений.

1. Кластер работает только с непатентованными (например, с открытым исходным кодом) образами. Не нужно скрывать образы.

Используйте общедоступные образы с Docker Hub.

Конфигурация не требуется.
В GCE/Google Kubernetes Engine локальное зеркало автоматически используется для повышения скорости и доступности.

2. Кластер запускает некоторые проприетарные образы, которые должны быть скрыты за пределами компании, но видимы для всех пользователей кластера.

Используйте размещенный частный реестр Docker.

Он может быть размещен на Docker Hub или в другом месте.
Вручную настройте .docker/config.json на каждом узле, как описано выше.

Или запустите внутренний закрытый реестр за фаерволом с открытым доступом для чтения.

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

Или, когда вы используете GCE/Google Kubernetes Engine, используйте Google Container Registry.

Это будет работать лучше с автоматическим масштабированием кластера, чем ручная конфигурация узла.

Или в кластере, где изменение конфигурации узла неудобно, используйте imagePullSecrets.

3. Кластер с проприетарными образами, некоторые из которых требуют более строгого контроля доступа.

Убедитесь, что контроллер доступа AlwaysPullImages активен. В противном случае все модули (pods) могут иметь доступ ко всем образам.

Переместите конфиденциальные данные в “Secret” ресурс, а не упаковывайте его в образ.

4. Многопользовательский кластер, где каждому арендатору необходим собственный частный реестр.

Убедитесь, что контроллер доступа AlwaysPullImages активен. В противном случае все модули (pods) всех арендаторов могут иметь доступ ко всем образам.

Запустите частный реестр с необходимой авторизацией.

Создайте учетные данные реестра для каждого арендатора, поместите их в secret и заполните secret для каждого пространства имен арендатора.

Арендатор добавляет этот secret к imagePullSecrets каждого пространства имен.

Если вам нужен доступ к нескольким реестрам, вы можете создать один секрет для каждого реестра. Kubelet объединит любые imagePullSecrets в один виртуальный .docker/config.json

Поиск по этому блогу

Kubernetes блог