Nutanix Karbon – Failed to pull image. Service Unavailable при обращении к приватному реестру

На днях посчастливилось протестировать Nutanix Karbon, который позволяет без каких-либо трудозатрат развернуть на площадке Nutanix готовый к использованию кластер Kubernetes.

Процесс развертывания крайне прост и через ~20-30 минут в моем распоряжении был готовый к использованию кластер.

Естественно, в первую очередь захотелось развернуть простейший «Hello World» из местного реестра на базе Harbor, и проверить работоспособность, но первый деплой был, как говорится, комом.

Стоит начать, пожалуй, с основного – что такое Nutanix Karbon и что он делает? Karbon разворачивает кластер Kubernetes (или несколько) на площадке виртуализации Nutanix с заранее заданными параметрами (сети, характеристики и количество master/etcd/worker нод) из заранее подготовленных образов. Его легко расширять, добавлять новые ноды, выполнять процесс обновления и т.п.

IP адресацией в кластере Karbon управляет сам, главное выделить ему сеть, со включенной функцией IPAM и выделенным внутри этой сети пулом адресов.  

Вот так, за пару нажатий кнопкой мыши, можно получить работающий кластер k8s, доступ к которому будет как с помощью kubectl, так и, при необходимости, по ssh.

В моей инсталляции используется Karbon самой последней доступной версии, с образом ntnx-0.7.

Подключившись к недавно созданному кластеру, я решил развернуть образ из своего тестового реестра. Создал namespace, secret, запустил ранее заготовленный deployment и сразу же я сразу же столкнулся с ошибкой ImagePullBackOff, что обычно говорит о том, что по какой-то причине загрузить указанный образ не удалось.

Смотрю более подробно:

# kubectl describe pods myweb-deployment-56cc984bf9-g2nl9 --namespace=kube-test
Error: ImagePullBackOff
Pulling image "kube-registry.cdn /kube-test/myweb:1.0"
Failed to pull image "kube-registry.cdn /kube-test/myweb:1.0": rpc error: code = Unknown desc = Error response from daemon: Get https://kube-registry.cdn /v2/: Service Unavailable
Error: ErrImagePull

Уже что-то. Проверяю с тестовой машины с установленным docker, которая находится в той же сети, где и кластер k8s, push и pull данного образа проходят без проблем.

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

Подключившись к ноде по ssh, пробую выполнить docker login до своего реестра. Неудачно:

$ sudo docker login kube-registry.cdn
Error response from daemon: Get https://kube-registry.cdn/v2/: Service Unavailable

Пинг присутствует, dns имя определяется корректно. Проверяю через curl:

$ curl -k https://kube-registry.cdn/v2/
{"errors":[{"code":"UNAUTHORIZED","message":"unauthorized: unauthorized"}]}

Реестр отвечает, что я не авторизован, а значит доступен.

Короткий гугл по ошибке «Docker Service Unavailable» выводит на похожее описание проблемы у людей, которые используют прокси. Это крайне интересно, учитывая, что никакие параметры прокси не указываются при создании кластера Kubernets в Karbon.

Достаточно часто, настройки прокси для Docker выполняются в описание конфигурационного файла для systemd. Проверяю:

$ cat /etc/systemd/system/docker.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://192.168.100.25:3128"
Environment="HTTPS_PROXY=http://192.168.100.25:3128"
Environment="NO_PROXY=http://127.0.0.1,localhost"

Вот и оно. Docker запущен с использованием прокси. Данные адреса мне не говорят ни о чем. Связываюсь с администратором кластера Nutanix, поскольку не имею к нему прямого доступа, уточняю. Все сходится, данный прокси прописан на уровне Prism Element и автоматически применяется к образам, которые развертывает Karbon.

Что странно, в документации к Karbon данный момент не описан, но подозреваю, что при использовании списков адресов, для которых нет необходимости использовать прокси в Prism Element, они автоматически попадут в переменную NO_PROXY кластеров Karbon. Update: исключения прокси из Prism Element и Prism Central не применяются.

Я не планирую использовать прокси, поэтому удаляю данный конфигурационный файл на всех Worker нодах, и перезагружаю их:

$ sudo rm /etc/systemd/system/docker.service.d/http-proxy.conf
$ sudo reboot

Проверяем:

$ sudo docker login kube-registry.cdn
Error response from daemon: Get https://kube-registry.cdn/v2/: x509: certificate signed by unknown authority

Docker’у не понравился мой самоподписанный сертификат, который установлен в Harhor.

Создаем директорию по имени hostname нашего реестра и копируем в нее crt файл:

$ sudo mkdir -p /etc/docker/certs.d/kube-registry.cdn/
$ sudo scp kube-registry.cdn:/etc/docker/certs.d/kube-registry.cdn/ca.crt /etc/docker/certs.d/kube-registry.cdn/

Перезапускаем Docker:

$ systemctl restart docker.service

Пробуем операцию Login:

$ sudo docker login kube-registry.cdn
Login Succeeded

Провожу данную операцию на всех Worker нодах и вновь запускаю Deployment в Kubernetes. Результат не заставил себя ждать:

kubectl get pods -n kube-test
NAME                                READY   STATUS    RESTARTS   AGE
myweb-deployment-56cc984bf9-c6bsm   1/1     Running   0          6m
myweb-deployment-56cc984bf9-tfnq7   1/1     Running   0          6m
myweb-deployment-56cc984bf9-v7rtf   1/1     Running   0          6m

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

В качестве заключения:

Несмотря на то, что развертывание кластера Kubernetes с помощью Karbon крайне простое занятие, есть важные моменты, на которые все же стоит обратить внимание:

  1. В выбранной для k8s сети IPAM должны быть прописаны корректные DNS сервера;
  2. Время между Prism Central и Prism Element должно быть синхронизировано. Будущие ноды возьмут настройки NTP также, как и настройки прокси с кластера;
  3. При создании Storage Class потребуется логин и пароль для доступа к Prism Element, и, если в дальнейшем данный пароль будет изменен, инфраструктура k8s об этом не узнает, будет необходимо менять секреты вручную, поэтому стоит заранее выделить техническую учетную запись, только для нужд Karbon.

Leave a Reply

Your email address will not be published. Required fields are marked *