Создание секрета docker-registry и проверка статуса пода

Создание секрета docker-registry

Чтобы создать секрет типа docker-registry с учётными данными для доступа к Docker Registry, выполните команду (в терминале, где у вас настроен доступ к кластеру):

kubectl create secret docker-registry <имя секрета> \
  --docker-server=<URL репозитория> \
  --docker-username=<логин> \
  --docker-password=<пароль или токен> \
  --docker-email=<email>

где:

<имя секрета> — имя создаваемого секрета;
<URL репозитория> — URL, который вы указали в поле URL при настройке приватного репозитория;
<логин> — логин для доступа к репозиторию;
<пароль или токен> — пароль или токен доступа (например, Personal Access Token из GitLab/GitHub);
<email> — электронная почта, привязанная к учётной записи на хостинге репозиториев.

Подробнее см. в официальной документации Kubernetes.

Добавление секрета в манифесты подов

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

Добавьте блок imagePullSecrets в манифест вашего пода.

Пример манифеста deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-private-app
spec:
  template:
    spec:
      containers:
      - name: app-container
        image: <URL репозитория>
      imagePullSecrets: # Секция для указания секретов
      - name: <имя секрета>

где:

<URL репозитория> — URL, который вы указали в поле URL при настройке приватного репозитория;
<имя секрета> — имя созданного секрета.

Подробнее о imagePullSecrets см. в официальной документации Kubernetes.

Это глобальный подход. Если вы добавите секрет в сервисный аккаунт (ServiceAccount), который используют ваши поды, то они смогут использовать этот секрет для доступа к приватным репозиториям. Это избавляет от необходимости прописывать imagePullSecrets в каждом манифесте.

Отредактируйте ServiceAccount, добавив в него ссылку на секрет:

kubectl patch serviceaccount <имя сервисного аккаунта> -p '{"imagePullSecrets": [{"name": "<имя секрета>"}]}' -n <namespace>

где:

<имя сервисного аккаунта> — имя сервисного аккаунта (ServiceAccount);
<имя секрета> — имя секрета типа docker-registry, который вы создали ранее;
<namespace> — имя пространства имён, в котором запускается под.

В результате новые поды, созданные в этом пространстве имён с указанным сервисным аккаунтом, будут автоматически использовать указанный секрет для загрузки образов.

Проверка статуса пода

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

Проверьте статус пода, выполнив команду:
```
kubectl get pods -n <namespace>
```
- STATUS = Running — под запущен и работает;
- STATUS = ContainerCreating — под создаётся. На этом этапе Kubernetes загружает образы контейнеров и настраивает их. Если под остаётся в этом состоянии более 5 минут, возможно, возникли проблемы с загрузкой образа или нехваткой ресурсов на узле (например, недостаточно места на диске). В таком случае рекомендуется провести диагностику;
- STATUS = ErrImagePull — Kubernetes не смог загрузить образ контейнера, проведите диагностику;
  неверное имя образа или тег;
  проблемы с доступом к приватному репозиторию (сетевые настройки, firewall);
  неправильные учётные данные для приватного репозитория;
  отсутствует образ в указанном репозитории;
  превышен лимит загрузок.
- STATUS = ImagePullBackOff — Kubernetes не смог загрузить образ и перешёл в режим паузы перед повторной попыткой (backoff), проведите диагностику.
  все причины, характерные для ErrImagePull;
  недостаточно прав у сервисного аккаунта;
  недостаточно места на диске;
  блокировка в репозитории IP-адреса узла, с которого отправляется запрос на загрузку образа;
  повреждение локального кеша образов на узле.
Проведите диагностику. Если под завис в статусе ContainerCreating или статус пода ErrImagePull или ImagePullBackOff, изучите описание пода. Чтобы получить описание пода, выполните команду:
```
kubectl describe pod <имя пода> -n <namespace>
```
Обратите внимание на секцию Events — Kubernetes хронологически выводит всё, что происходило с подом. Ищите сообщения с типом Warning.
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 47s default-scheduler Successfully assigned default/my-app-pod to node-1 Normal BackOff 20s (x2 over 46s) kubelet Back-off pulling image "privateregistry.com/my-image:latest" Warning Failed 20s (x2 over 46s) kubelet Error: ImagePullBackOff Normal Pulling 5s (x3 over 47s) kubelet Pulling image "privateregistry.com/my-image:latest" Warning Failed 5s (x3 over 47s) kubelet Failed to pull image "privateregistry.com/my-image:latest": rpc error: code = Unknown desc = failed to pull and unpack image "privateregistry.com/my-image:latest": failed to resolve reference "privateregistry.com/my-image:latest": failed to authorize: failed to fetch anonymous token: unexpected status: 401 Unauthorized
В этом примере видно, что проблема в доступе к репозиторию — 401 Unauthorized.
Частые ошибки в секции Events:
- 404 Not Found — образ не найден по указанному URL. Проверьте путь к образу, тег и имя образа;
- x509: certificate signed by unknown authority — Kubernetes не может проверить SSL-сертификат при подключении к приватному репозиторию. Возможно, сертификат самоподписанный или корневой сертификат не доверен. Установите корневой доверенный сертификат или настройте Kubernetes на игнорирование проверки сертификатов (что небезопасно);
- no basic auth credentials — не предоставлены учётные данные для доступа к образу в приватном репозитории. Убедитесь, что:
  - секрет добавлен в манифесты подов и связан с соответствующим пространством имен (namespace);
    # Получить список всех секретов в указанном пространстве имен kubectl get secrets -n <namespace> # Посмотреть детали секрета kubectl describe secret <имя секрета> -n <namespace>
    где:
    <namespace> — имя пространства имён, в котором запускается под;
    <имя секрета> — имя секрета типа docker-registry, который вы создали ранее.
    NAME TYPE DATA AGE my-registry-secret kubernetes.io/dockerconfigjson 1 5d2h default-token-abcde kubernetes.io/service-account-token 3 30d another-secret Opaque 2 7d
    где:
    NAME — имя секрета. Найдите секрет, который создали для приватного репозитория;
    TYPE — тип секрета. Для учётных данных приватного репозитория должен быть тип kubernetes.io/dockerconfigjson. Если есть тип Opaque, значит, секрет создан неправильно;
    DATA — количество ключей/записей внутри секрета. Для секрета типа kubernetes.io/dockerconfigjson всегда будет 1 (один ключ с именем .dockerconfigjson);
    AGE — как давно был создан секрет.
    Name: <имя секрета> Namespace: <namespace> Labels: <none> Annotations: <none> Type: kubernetes.io/dockerconfigjson Data ==== .dockerconfigjson: 150 bytes
    где:
    <имя секрета> — имя секрета. Проверьте, что это секрет, который вы создали ранее;
    <namespace> — имя пространства имён. Проверьте, что под запускается в соответствующем пространстве имён;
    Type — проверьте, что тип секрета kubernetes.io/dockerconfigjson;
    Data — ключ с именем .dockerconfigjson (стандартное имя для учётных данных) и размер его значения в байтах. Размер 0 указывает на ошибку создания — секрет пуст.
    Примечание
    Команда describe secret не показывает сами учётные данные (логин, пароль, URL репозитория). Они хранятся в закодированном формате base64 внутри секрета.
    Для просмотра учётных данных используйте команду get secret.
  - учётные данные в секрете верные, непросроченные и имеют права на скачивание образа;
    # Декодировать данные секрета (.dockerconfigjson) kubectl get secret <имя секрета> -n <namespace> -o jsonpath='{.data.\.dockerconfigjson}' | base64 --decode
    где:
    <имя секрета> — имя секрета типа docker-registry, который вы создали ранее;
    <namespace> — имя пространства имён, в котором запускается под.
    В результате будет выведен JSON, где вы можете проверить правильность логина, пароля и URL репозитория.
  - секрет корректно добавлен в сервисный аккаунт (ServiceAccount), если используется метод привязки секрета к ServiceAccount;
    kubectl describe serviceaccount default -n <namespace>
    где:
    <namespace> — имя пространства имён, в котором запускается под.
    В результате секрет будет указан в разделе imagePullSecrets.
    Name: <имя сервисного аккаунта> Namespace: <namespace> Labels: <none> Annotations: <none> Image pull secrets: <имя секрета> Mountable secrets: <имя монтируемого секрета> Tokens: <имя токена> Events: <none>
    где:
    <имя сервисного аккаунта> — имя сервисного аккаунта (ServiceAccount);
    <namespace> — имя пространства имён, в котором запускается под;
    <имя секрета> — имя секрета типа docker-registry, который вы создали ранее;
    <имя монтируемого секрета> — имя секрета, который можно смонтировать (подключить как файл) в поды, использующие этот сервисный аккаунт;
    <имя токена> — имя JWT -токена. Создаётся автоматически и используется для доступа к Kubernetes API.
  - брандмауэр, группа безопасности и DNS не блокируют доступ узла к приватному репозиторию;
  - указанный образ имеется в приватном репозитории, и у него верный тег.
Если под перешёл в статус Running, но вы хотите увидеть логи работы приложения внутри контейнера, используйте команду:
```
kubectl logs <имя пода> -n <namespace>
```
Команда покажет логи приложения (например, логи Nginx или вашего кода), но не покажет логи процесса загрузки образа. Для диагностики проблем с загрузкой образа используйте команду kubectl describe pod.

В этой статье

Мы ответили на ваш вопрос?