На днях посчастливилось протестировать 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 крайне простое занятие, есть важные моменты, на которые все же стоит обратить внимание:
- В выбранной для k8s сети IPAM должны быть прописаны корректные DNS сервера;
- Время между Prism Central и Prism Element должно быть синхронизировано. Будущие ноды возьмут настройки NTP также, как и настройки прокси с кластера;
- При создании Storage Class потребуется логин и пароль для доступа к Prism Element, и, если в дальнейшем данный пароль будет изменен, инфраструктура k8s об этом не узнает, будет необходимо менять секреты вручную, поэтому стоит заранее выделить техническую учетную запись, только для нужд Karbon.
