LINUX.ORG.RU
ФорумAdmin

k8s offline registry

 , , ,


2

3

Приветствую.

Стала перед мной такая задача:

Есть изолированная сеть, доступа к интернету нет, совсем.
На хосты в сети ансиблом разворачивается кластер k8s из локального rpm репо.
Не понятно как быть с докер образами, пока что использую docker save/load, а хочется все устанавливать из локального docker registry.

Сразу оговорюсь что опыт работы с кубером поверхностный.

Вопросы:

  • Можно ли как-то запушить все нужные образы в registry с исходными именами и тегами, а не docker push localhost.localdomain:5000/alpine? К примеру может быть что-то наподобии tar xf docker-image.tar -C /var/lib/registry
  • Как избавится от возможных проблем с деплоем подов? Допустим мне дали compose.yml, я его конвертирую при помощи kompose и отдаю kubectl apply. Как k8s поймет, что когда публичный registry недоступен ему следует взять образ из приватного registry (он подключен)?
  • Возможно ли выполнить инициализацию кластера из приватного registry, не пойму как это объяснить kubectl

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

Все эти проблемы умеет решать podman, но скорее всего у тебя на нем не получится k8s завести пока

alpha ★★★★★ ()

Можно ли как-то запушить все нужные образы в registry с исходными именами и тегами

А как ты себе это представляешь? Ведь имя registry — это часть имени образа.

Если только выключать HTTPS и перехватывать все запросы к :5000 прокси-сервером. но вообще я хз.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

У меня registry и так через docker-distribution запущен, и nginx-ом проксируется, к такому исходу готовился сразу.

Неужели нет готового решения для переезда в офлайн по аналогии с yum repo, выкачал нужные пакеты, проиндексил базу, опубликовал и радуешься.

WoozyMasta ()
Ответ на: комментарий от WoozyMasta

Докер намеренно недопускает управления репозиториями, завязывая все процессы на докерхаб.

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

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

alpha ★★★★★ ()
Ответ на: комментарий от alpha

Что значит «завязывая все процессы на докерхаб»? У нас в арче вроде всё хорошо с докером, по крайней мере с registry.gitlab.com (и с stratofortress.nexus.i.intelfx.name, то бишь сервера в соседней комнате ;)) всё тянется.

Если ТС говорит, что у него действительно настроено какое-то прозрачное проксирование на свой сервер — то что мешает просто натравить dockerd и kubelet на каждой ноде на этот же прокси-сервер?

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

что мешает просто натравить dockerd и kubelet на каждой ноде на этот же прокси-сервер?

то что в докере нет такой опции

docker pull image:tag всегда тянет образы с докерхаба

ты можешь тянуть образы с других registry но только через полное имя с указанием хоста:

docker pull stratofortress.nexus.i.intelfx.name/image:tag

И это плохо, потому что адреса нужных registry оказываются захардкоженными в самых странных местах - в конфигах деплоя, в настройках тестов, в локальных конфигах у разработчиков и т.п.

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

Аналогично тому как например пользователю совершенно по барабану какие зеркала рпм-реп настроены в системе, локальные, глобальные, кеширующие прокси или что ещё, он просто ставит yum install <имя>. Так же должно было быть и с докером.

alpha ★★★★★ ()
Последнее исправление: alpha (всего исправлений: 1)

при деплое (ci,helm,etc) можно использовать подобную схему ${REGISTRY}/${IMAGE}:${TAG}
нужные притащить с докерхаба, либо самому из докерфайлов собрать и положить в локальный регистри
переменные задавать соответсно джобе

Suicide_inc ★★ ()
Ответ на: комментарий от alpha

Мы говорим слегка о разных вещах.

Кмк говорить «докер [завязывает] все процессы на докерхаб» некорректно, потому что у тебя никто не забирает возможность тянуть образы из других репозиториев, когда они там лежат штатным образом. При этом адрес докерхаба подставляется только в том случае, когда в имени образа registry вообще не указан — это, конечно, слегка свинство, но лишь слегка. Т. е. докер действительно завязывает какие-то процессы на докерхаб, но далеко не все.

А то, что хочет ТС (как я понял) — это перенаправлять все обращения ко всем registry на свой приватный сервер. Это как если бы я хотел заставить git при запросе вида git clone github.com/foo/bar обращаться не к github.com, а к mycompany.tld.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

А то, что хочет ТС (как я понял) — это перенаправлять все обращения ко всем registry на свой приватный сервер.

Не обязательно перенаправить, скорее услышать видение других людей и прийти к общему знаменателю. Ибо данная тема после пары дней поисков в интернете не была раскрыта.

В любом случае, вы мне уже помогли, сегодня буду пробовать различные варианты. О успехах отпишусь.

WoozyMasta ()
Ответ на: комментарий от intelfx

ТС хочет свой default registry.

По сути это просто самый естественный путь организации инфры: разделение самого артефакта от пути по которому этот артефакт доставляется. Что ставить - это дело приложения/деплоя, откуда ставить - дело инфры.

По аналогии со всеми другими репами, maven, rpm, deb, pypy и т.п., где этот подход всегда работал из коробки, ты точно так же идешь первым делом в мануал/гугл искать простой параметр. И не находишь.

И тогда начинается поиск альтернативных костылей. (Описанная тобой подмена DNS - это очень плохой вариант костыля, если что)

Да, можно делать костыли на уровне деплой-скриптов, ansible, helm, ci, можно на уровне сети. Они даже будут работать, но костылями от этого быть не перестанут.

При этом адрес докерхаба подставляется только в том случае, когда в имени образа registry вообще не указан — это, конечно, слегка свинство, но лишь слегка.

Это не слегка.

Это например проблема когда у тебя инфраструктура по нескольким ДЦ раскатывается и в каждом ДЦ есть свой кеширующий registry. Внезапно каждый скрипт дергающий docker вдруг начинает оперировать информацией о своем географическом положении. И при добавлении новой локации все CI/helm/и прочие конфиги вдруг оказывается требуют правок, о которых никто даже и не помнит. И вместо того чтобы выкатывать универсальный абстрактный облачный конфиг, разработчики работают с хардкодом кластерных нод чуть не поименно.

alpha ★★★★★ ()

Там выше уже присоветовали Nexus - он умеет как самостоятельные репы, так и проксировать репы (конечно с кешированием!) с докерхаба и вообще откуда угодно.

А для полного счастья надо править докерный daemon.json на всех (!) хостах на предмет registry-mirrors. Скорее всего, в отсутствие SSL с настоящими сертификатами, понадобится ещё insecure-registries.

Чё делать с другими рантаймами не знаю, юзаем докер.

MumiyTroll ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.