Ставить ли sonatype nexus внутрь кубера, или ну его нафиг?

Штатно он скачивается как nexus-linux-x86_64.tar.gz

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

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

helm чарты тут беру,там и nexus есть artifacthub.io

тоже учу kuber

у меня свои docker образы сам делал.

Ага и образы того nexus в nexus же и положить

Отдельная история потом будет – как натравить кубер на этот registry.

В каком смысле? image для pod’а берется оттуда, откуда ты сказал

Ставить ли sonatype nexus внутрь кубера, или ну его нафиг?

В проде на нормальном железе - не вижу особых проблем, если использовать внешнюю базу и внешнее хранилище блобов (например, postgres и s3). В песочнице - лучше поставь обычный https://hub.docker.com/_/registry (или если хочется какого-то enterprise-like решения - Harbor), жизнь будет приятнее. Нексус пусть и очень хорош и с киллерфичами под капотом, это все же джава-танк и ресурсы жрет как не в себя, и чаще всего для песочницы оверкилл.

Можно ли его натравить на собственный pod?

Кубер вообще никак не работает с registry, с ним работает твой CRI (crio, containerd, и так далее). Соответственно, чтобы они ходили в твой поднятый реджистри, тебе надо его как-то анонсировать за пределы кубера. Можно nodeport’ом, можно ingress’ом, можно ExternalIP (если cni поддерживает или стоит metalllb).

Типа, стандарт де факто

Есть ещё Harbor.

Отдельная история потом будет – как натравить кубер на этот registry. Тут пока даже не гуглил. Можно ли его натравить на собственный pod?

Не на собственный под, а на ингресс, который в него смотрит. Как и на любое приложение.

Лично я использую https://github.com/distribution/distribution мне нравится. В кластере запускать можно, проблем с этим нет.

С Nexus я не работал. Но вообще тут получается змея, кусающая себя за хвост. Так или иначе тебе нужен образ, который будет лежать где-то снаружи. Напиши Dockerfile, собери образ, залей его на docker hub, и деплой в таком виде.

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

Я бы советовал посмотреть на Harbor, если distribution не устраивает.

собери образ, залей его на docker hub,

Вот как раз этот вариант категорически исключён: нарушение NDA.

Helm charts по слухам какие-то энтузиасты пилят

И вы пилите. В процессе и k8s выучите.

Ну подними distribution registry, туда залей нексус и из него уже подними нексус, хе-хе.

Чисто теоретически я могу себе представить сценарий бутстрапа нексуса из самого себя. И даже обновляться оно будет, но только пока всё идёт по плану. Если что-то пошло не так, то всё начнёт ломаться. Оно даже падение ноды и миграцию на другую может не пережить. В общем я бы так делать не стал.

Оно даже падение ноды и миграцию на другую может не пережить.

С первого выборочного прочтения доков кубера я мало что запомнил, но у меня сложилось впечатление, что если pod содержит PVC, то он будет деплоиться на ноду, на которой есть соответствующий PV. Гора не ходит к Магомету. Так что никаких миграций на другую ноду быть не должно.

Неверно в случае сетевых файловых систем/блочных устройств. Куда надо, туда PV и подмонтируют.

Сенькс.

Ваше погружение в мир kubernetes только началось.

Пройдут месяцы и станет все понятно.

Как правило в большинстве кубернетес кластеров (ну которые я видел) - PV представляют из себя сетевые хранилища. Т.е. они подключаются к любой нужной ноде и переключаются при необходимости. Если используется локальный PV то - да, под будет прибит к ноде. Но вообще это не очень хорошо в общем случае, хотя и может быть полезно в специализированных.

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

Распишу в целом сценарий фейла. Предположим, что мы как-то родили работающий деплоймент с нексусом, у которого image ссылается сам на себя. Далее мы правим image, например хотим установить обновление. Что дальше происходит:

1. При настройках по умолчанию запускается второй pod, параллельно работающему. Из работающего стягивается образ. Когда второй pod начинает отвечать на health check-и, первый тушится. Это счастливый сценарий и тут всё даже работает.

2. Если мы используем PV, тут возникает вопрос с тем, получится ли запустить второй под вместе с первым. Если они будут запускаться на одной ноде - наверное получится, если это сетевое хранилище, то как правило оно монтируется только на одну ноду одновременно и на другой ноде под не запустится. Если оба пода запустятся и будут использовать общее хранилище - поладят ли они друг с другом, рассчитан ли нексус на такое использование? Не знаю.

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

Теоретически наверное можно как-то «прогреть» кеш нод, сначала запулить туда новый образ и потом перезапускать. Но это как-то максимально «опасно».

В общем не надо так делать, хотя сценарий забавный.

Не знаю, умеет ли Nexus хранить в S3

Я тут уже harbor читаю, как выше насоветовали.

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

Ну у меня ж тупо домашние игрища в виртуалке. Создал .vdi, примонтировал в /mnt/k8s-harbor-data. Идея ещё и s3 под кубером поднять – любопытная, по работе возможно придётся (и hive с metastore, и ещё кучу всякого говна, которое в разрабатываемой системе используется), но пока что не до него.

UPD: Сейчас всё дебажим на корпоративных стендах, полный стек не поднят ни у кого. Да и неполный тоже. Те ещё пляски – после каждой исправленной буквы всё проливать-проверять. Карикатура_про_пинающего_балду_cpp_кодера,_который_на_окрик_начальства_отвечает:_у_меня_компиляция!.jpeg.

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

Вроде бы один и тот же PV, в отличие от просто V, в два места сразу не примонтируешь? Прикидывать сценарии гонок мне ещё слишком рано, да и вообще скорее всего не придётся: сам себе деплоить всё буду сам, хелпер скриптов себе понарисую, отлажу, в них всё будет по порядку.

Вроде бы один и тот же PV, в отличие от просто V, в два места сразу не примонтируешь?

На одной ноде можно. Там есть нюансы с Mode но обычно - можно. Вот чтобы можно было один PV монтировать на несколько нод одновременно - тут уже нужна сетевая ФС вроде NFS, такое тоже можно, но обычно не нужно.

за что ты его так не любишь, что NFS советуешь? он, конечно, простой, но тормозной и без резервирования. тогда уж CEPH надо смотреть какой-нибудь, или DRBD. в любом случае, я бы не начинал с нексуса в кубе, да

Не знаю, умеет ли Nexus хранить в S3 и есть ли в вашей инфраструктуре S3 вообще

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

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

тогда уж CEPH надо смотреть какой-нибудь

CEPH — прекрасная штука и работает великолепно. Но в нём нужно разбираться, а он как бы не посложенее кубернетеса будет. Т.е. лёгким движением руки мы тут удвоили количество работы. Минимум.

Для экспериментов и игр с виртуалками это адово избыточно.

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

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

Это хорошая учебная задача. Согласен. А вот разбираться как такую хранилку с нуля построить — это уж явный перебор.

Мне кубер интересен как программисту: как своё барахлишко в него выливать. Хранилища – это уже чистый девопс. Щас погуглил что это за CEPH – любопытно, хвалебный отзыв запомню, но мимо.

Не советую, я наоборот пишу, что это обычно не нужно. С NFS у меня опыта нет, я просто знаю, что он такую опцию позволяет. Нужды делать PV расшаренный между разными нодами у меня пока не возникало, надеюсь, что и не возникнет.

...ну его нафиг?

На самом деле ты всё прекрасно знаешь. 😁