делают же docker-in-docker, ну вот. можно так. Кривовато, но не сильно

Типа в докеровском поде запускать nvidia-docker?

Есть свои веселые моменты

Типа в докеровском поде запускать nvidia-docker?

тип под запускает docker run внутри, да

фронт (control-plane небулы) - это обычное приложение, так что опять же в кубе его деплоить удобнее

да вы, ребят, извращенцы)

докер в докере

фронт (control-plane небулы) - это обычное приложение, так что опять же в кубе его деплоить удобнее

мне нравится в таком кейсе, что это мгновенно раскаывается 😁

тип под запускает docker run внутри, да

Звучит как костылина, конечно) Для лабы мб ок, попробую.

так а что это дает?

Я же уже расписал подробно: декларативность и легко управлять

Звучит как костылина, конечно) Для лабы мб ок, попробую.

может даже так... наверное docker run -v /var/run/docker.sock:/run/docker.sock -v $(which docker):/bin/docker anyimage docker run ... 😆

докер в докере

Причем тут докер в докере? OpenNebula - это kvm вообще

может даже так... наверное docker run -v /var/run/docker.sock:/run/docker.sock -v $(which docker):/bin/docker anyimage docker run ... 😆

Ебануться 😂

ой сорри, это не мне

Да)

может даже так... наверное docker run -v /var/run/docker.sock:/run/docker.sock -v $(which docker):/bin/docker anyimage docker run ... 😆

ну лучше разрабов попросить запускаться несколькими процессами в одном контейнере

С каждым днём всё больше и больше удивляюсь докеру и кубернетесу

докер в докере

до появления всяких тулов для rootless сборки image это был единственный вариант запускать pipeline сборки image в docker, поэтому норм. привет drone.io

Зачем его в Докере запускать?

Вопрос по мониторингу есть: поставил графан и прометеусов себе, вижу что алерты можно слать и через Алерт менеджер и через саму Графану. Как правильнее?

Вопрос по мониторингу есть: поставил графан и прометеусов себе, вижу что алерты можно слать и через Алерт менеджер и через саму Графану. Как правильнее?

kube-prometheus ставит HA alertmanager, лучше использовать, что дают

И графана не вывозит много алертов

kube-prometheus ставит HA alertmanager, лучше использовать, что дают

Я все через helm ставлю, боже храни helm

Разобрался с волюмами в кубере

Теперь забудь это всё и учи CSI

Теперь забудь это всё и учи CSI

Буду учить то что нужно на работе)

Я все через helm ставлю, боже храни helm

- тут-тук - кто там? - Error: UPGRADE FAILED: "foo" has no deployed releases

- тут-тук - кто там? - Error: UPGRADE FAILED: "foo" has no deployed releases

Это да, с адекватным дебагом там жопа

пойду майку с надписью GOD SAVE HELM сделаю, а то без него и правда половина клиентов бы к нам не пришли

пойду майку с надписью GOD SAVE HELM сделаю, а то без него и правда половина клиентов бы к нам не пришли

есть байки? в чем там проблема? с деплоем своих приложений он нам очень ускоряет дело и помогает все структурировать

ну лучше разрабов попросить запускаться несколькими процессами в одном контейнере

нужно будет тащить визора за процессами в контейнер, эт похуже dind

Иногда я даже не жалею что стал девопсом

Всего лишь всегда?

- тут-тук - кто там? - Error: UPGRADE FAILED: "foo" has no deployed releases

Хочу футболку с этой надписью

есть байки? в чем там проблема? с деплоем своих приложений он нам очень ускоряет дело и помогает все структурировать

там всё хорошо, не слушай никого, но на всякий случай лучше учить Lua

там всё хорошо, не слушай никого, но на всякий случай лучше учить Lua

Шутки про Half-Life и helm были уже?

- тут-тук - кто там? - Error: UPGRADE FAILED: "foo" has no deployed releases

--atomic --cleanup-on-fail

Шутки про Half-Life и helm были уже?

это скорее будет второе пришествие, с такими же последствиями

--atomic --cleanup-on-fail

Я там ответ ещё жду 😅

в копилку хейтерам helm: эпичный, кмк, баг https://github.com/helm/helm/issues/1979 с явной неадекватностью девелоперов, которые в соседнем продукте сами на него напоролись, но нет, мы не будем это говно чинить, потому что у нас спек такой

причём ничего им не помешало принять фикс в ветку с helm 3, который появится когда уже всеперейдут на что-нибудь более приемлемое

Ну я так и не смог найти адекватный вариант чтобы запустить на одной ноде на gpu парралельно несколько контейнеров. Из готовых решений есть только какой-то модицифированный китайский nvidia plugin device, к которому нужно ещё левый шедулер модифицированный ставить - мне это не очень нравится.

А вообще каким макаром происходит распределение ресурсов GPU? Я просто в доке не могу найти инфы по шарингу ресурсов. GPU в итоге становятся "кластерными", или нет?

А вообще каким макаром происходит распределение ресурсов GPU? Я просто в доке не могу найти инфы по шарингу ресурсов. GPU в итоге становятся "кластерными", или нет?

Девайс плагин берет физ. gpu и отдает его первому же поду, который его запросит, и все, шарить и делить на части как CPU - нельзя https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/

Тогда ваще неясно в чем профит, если nvidia-docker большую гибкость дает

Тогда ваще неясно в чем профит, если nvidia-docker большую гибкость дает

Ну если у тебя все в Кубе, хотелось бы и всякую нвидиа херню тоже в Кубе видеть

https://github.com/kubernetes/kubernetes/issues/52757

Да, там как раз в конце ссылки на китайские вундервафли

Ну если у тебя все в Кубе, хотелось бы и всякую нвидиа херню тоже в Кубе видеть

А ты эти плагины не накатывал в итоге?

А ты эти плагины не накатывал в итоге?

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

На днях попробую

это скорее будет второе пришествие, с такими же последствиями

всем утра)

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

Гайс, а как в можно выполнить несколько шагов с вызовом эндпоинта аймаджа? Например, мне нужно запускать миграции при деплое, миграции я реализовал как подпрограмму своего основного приложения. В итоге мне нужно вызывать что-то вроде myapp migration init myapp migration up --dir [path/to/migration/dir] myapp run --main --logic --with --some --flags, при этом вместо myapp в моем случае эндпоинт докера Это можно в одном контейнере в кубере прописать? Пробовал просто в args через точку с запятой прописать, не работает

tini, supervisor

initContainer

В него миграцию, в основной уже апп

В него миграцию, в основной уже апп

И все окружение заново прописывать?

initContainer

ну зачем так 😢

Самое просто решение - запускать миграции в CI/CD пайплайне перед kubectl apply/helm upgrade

Ребят обьясните почему не могу смаунтить путь /usr/share/elasticsearch/data

?

Самое просто решение - запускать миграции в CI/CD пайплайне перед kubectl apply/helm upgrade

Дай человеку набить шишек

Ребят обьясните почему не могу смаунтить путь /usr/share/elasticsearch/data

можешь

можешь

Когда создаю Стейтфул сет то он ругается на этот путь

А если нет CI/CD пайплайна - написать. Лучшее из решений.

Привет, мне нужно порты некоторых сервисов выкидывать наружу(не http/s) и разрешать к ним подключаться только с определенных IP. Как это обычно делают в Кубе?

например network policy ingress/egress

на неймспейсе

Caused by: java.nio.file.AccessDeniedException: /usr/share/elasticsearch/data/nodes

Что я делаю не так?

Самое просто решение - запускать миграции в CI/CD пайплайне перед kubectl apply/helm upgrade

Проблема в том, что у меня приложение использует клауд прокси для постгреса в кубере, соответственно чтобы выполнить миграцию мне нужно будет либо поднимать параллельно эту прокси (а проще всего это сделать опять же в кубере, ну либо в докер-композе, чего я не хочу), либо переделывать то, как приложение общается с бд, а этого я тоже делать не хочу, потому что на локальной машине запускаю с локальной бд, а разница всего лишь в конфиге

например network policy ingress/egress

А сам порт в интернет как выкинуть, через что?

nodeport\hostport

Проблема в том, что у меня приложение использует клауд прокси для постгреса в кубере, соответственно чтобы выполнить миграцию мне нужно будет либо поднимать параллельно эту прокси (а проще всего это сделать опять же в кубере, ну либо в докер-композе, чего я не хочу), либо переделывать то, как приложение общается с бд, а этого я тоже делать не хочу, потому что на локальной машине запускаю с локальной бд, а разница всего лишь в конфиге

воркер ci/cd в кубе оставить

nodeport\hostport

Просто сервис то может переехать на другую ноду, например потому что нода упала. В идеале какой-то типа ингресс

Просто сервис то может переехать на другую ноду, например потому что нода упала. В идеале какой-то типа ингресс

nodeport доступен со всех нод

https://kubernetes.io/docs/concepts/services-networking/service/#nodeport

воркер ci/cd в кубе оставить

Вот ведь У меня CD нет, руками скрипт на локальной машине запускается Получается что для такой простой задачи, как запуск дополнительной команды в том же аймадже в том же окружении докера мне нужно будет реализовывать весь CD, копировать туда все секреты, настройки проектов GCP, и там запускать миграции отдельным деплоем?

Вот ведь У меня CD нет, руками скрипт на локальной машине запускается Получается что для такой простой задачи, как запуск дополнительной команды в том же аймадже в том же окружении докера мне нужно будет реализовывать весь CD, копировать туда все секреты, настройки проектов GCP, и там запускать миграции отдельным деплоем?

реализовать ci/cd это хорошая мысть и перестать страдать фигней без ci/cd.

каждая нода на которой есть кубпрокси (по дефолту это все воркеры) сможет принимать конекшены на этот порт и уже форвардить внутрь контейнера на ноде или коммутировать на ноду с контейнером

реализовать ci/cd это хорошая мысть и перестать страдать фигней без ci/cd.

CI у меня и так есть