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

все контейнеры стартуют одновременно. Синкай их различными хаками, через пошаренный emptyDir, например

Мы же не про инит говорим, йа? Т.е. именно равноценные контейнеры

не, один контейнер висит и динамически перерендеривает файлики

тогда другой вопрос

можно ли как-то инициализировать смерть второго контейнера?

не, один контейнер висит и динамически перерендеривает файлики

Он может HUP (или любой другой 'сигнал )слать в сокет, который в вольюме

Чтобы ребутать процесс с пид=1 в соседнем контейнере

а где можно на пример посмотреть?

а где можно на пример посмотреть?

https://github.com/openshift/release/blob/master/ci-operator/templates/openshift/installer/cluster-launch-installer-e2e.yaml#L115 https://github.com/openshift/release/blob/master/ci-operator/templates/openshift/installer/cluster-launch-installer-e2e.yaml#L828-L833

крутой хак

спасибо большое

Фолкс, а какой сейчас модный ультраудобный дашборд для к8с? K9s видел, сток не возбуждает, опеншифт ненадо предлагать))

Фолкс, а какой сейчас модный ультраудобный дашборд для к8с? K9s видел, сток не возбуждает, опеншифт ненадо предлагать))

https://github.com/weaveworks/scope

https://github.com/weaveworks/scope

Пробовал. Сгорел с возможности провалиться в шел ноды(!!!) под рутом

Не знаю это мои кривые руки или багофича, но ставил по доке 😅

подразумевает ли понятие кластер собой, что ноды внутри него физически расположены рядом?

подразумевает ли понятие кластер собой, что ноды внутри него физически расположены рядом?

Необязательно

Главное что они соединяются одной сетью

https://github.com/weaveworks/scope

Ох, а ещё?

Ох, а ещё?

https://github.com/openshift/console

Главное что они соединяются одной сетью

тоесть нода в Питере и нода в Москве не могут находиться в рамках одного кластера?

тоесть нода в Питере и нода в Москве не могут находиться в рамках одного кластера?

Почему нет?

Я наверное немного неправильно выразился

)

могут, но с большой вероятностью кластер недолго проживет

тоесть нода в Питере и нода в Москве не могут находиться в рамках одного кластера?

Но это будет ооооооочень медленно

И ноды часто будут NotReady

Но это будет ооооооочень медленно

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

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

Если собираете кластер желательно чтобы машины были рядом и в диапазоне 10.0.0/24 или /29

Если это бар метал конечно

Если это бар метал конечно

именно нет, ноды могут быть расположены за 1000км друг от друга

именно нет, ноды могут быть расположены за 1000км друг от друга

Тогда ничего хорошего из этого не выйдет

Проще делать мастер-воркер и где-то хранилище данных

Если этого не избежать

Но на проде такая вещь долго не проживает

тоесть если сервера расположенны территориально далеко и их много, лучше собирать один кластер, в котором внутри много нод или собирать много кластеров, в котором две ноды (мастер и воркер)?

тоесть если сервера расположенны территориально далеко и их много, лучше собирать один кластер, в котором внутри много нод или собирать много кластеров, в котором две ноды (мастер и воркер)?

Второй вариант

Но 1 мастер и 1 нода = плохая отказоустойчивость

лучше вообще не k8s использовать в таком случае, потому что кучу вещей из k8s нельзя будет использовать всё равно при такой физической конфигурации

нужно просто через ci/cd обновлять поды(микросервисное приложение) на большом количестве серверов и получать мониторинг

не веб приложение же?

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

а что в качестве бэкенда?

гошечка

я про данные. Как они у вас распределяются? У каждого свой кусок?

поды в разных регионах независимо живут, или общаются как-то?

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

поды в разных регионах независимо живут, или общаются как-то?

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

а локально из функциональности k8s что нужно? pod scaling, ingress?

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

тогда их наверное не стоит объединять в кластер

а локально из функциональности k8s что нужно? pod scaling, ingress?

скейлинг врятли, ну только 1-2 реплики если создать - рестарт если под упал - открыть доступ к фронту в рамках локальной сети - получить сигнал от GitLab runnera, что нужно обновляться

рассказал бы детальнее, просто не знаю что можно говорить, что нельзя)

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

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

проще сделать больше мелких кластеров и объединить в kubefed. Тогда gitlab runner и остальное можно привязать к одному серверу, а потом изменения расползутся по остальным кластерам

Ну при перечисленных условиях проще пускать докер контейнеры через ci/cd

проще сделать больше мелких кластеров и объединить в kubefed. Тогда gitlab runner и остальное можно привязать к одному серверу, а потом изменения расползутся по остальным кластерам

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

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

условный 1c у него там с локальными пользователями и локальной базой, надо централизованно обновления накатывать в кучу регионов

условный 1c у него там с локальными пользователями и локальной базой, надо централизованно обновления накатывать в кучу регионов

Вопрос в том, зачем там кубер. В принципе и ansible будет достаточно

чтоб поды переподнимать

Вопрос в том, зачем там кубер. В принципе и ansible будет достаточно

управление, мониторинг

чтоб поды переподнимать

Докер с --restart=always тогда )

Докер с --restart=always тогда )

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

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

Скрипт на 50 строк и ci/cd для описанной задачи норм хватить должно, на самом деле

это немного не то. k8s в рамках даже одного сервера гораздо удобнее чем голый докер

Ну и мониторить всегда можно тем же прометеем с графаной

это немного не то. k8s в рамках даже одного сервера гораздо удобнее чем голый докер

Согласен, конечно, но в данном кейсе звучит как небольшой оверинжиниринг

очень много интересной информации для размышлений предоставили, крайне признателен за мысли и время:), попробую все варианты. ласт вопрос, по сути не особой роли играет с помощью чего создавать кластер?, тоесть можно с помощью ansible создать плейбук, который идет на сервер, устанавливает там kubectl, kubeadm, соединяет ноды

Кстати, тут может k3s зайти, наверное

это немного не то. k8s в рамках даже одного сервера гораздо удобнее чем голый докер

😮

Согласен, конечно, но в данном кейсе звучит как небольшой оверинжиниринг

как раз наоборот, kubeadm init и вперёд. Большинство веще типа того же прома и графаны ставятся через kubectl apply или helm без головной боли

😮

Ну вариантов немного, по использовании докера. Либо сворм, либо скрипты, либо что-нибудь маргинальное )

> 1 хост > сворм Вы серьёзно?

как раз наоборот, kubeadm init и вперёд. Большинство веще типа того же прома и графаны ставятся через kubectl apply или helm без головной боли

Ну я скорее о том, что добавляется ещё один слой абстракции (на самом деле больше), который может где-то сломаться

> 1 хост > сворм Вы серьёзно?

Как-то пробовал - мне понравилось )

Согласен, конечно, но в данном кейсе звучит как небольшой оверинжиниринг

хорошо что клепать свою оркестрацию однонодовой системы с мониторингом и апишкой точно не оверинжиниринг :)

кругомнаркоманыжпг

хорошо что клепать свою оркестрацию однонодовой системы с мониторингом и апишкой точно не оверинжиниринг :)

Ага, оркестрации 2-х контейнеров )

Ага, оркестрации 2-х контейнеров )

а сделайте нам PoC, обсудим что проще?

Ну я скорее о том, что добавляется ещё один слой абстракции (на самом деле больше), который может где-то сломаться

тут соглашусь, но если правильно подходить к вопросу, то все ваши бэкапы в локальных томах и манифесты в гите, если что-то ломается - быстро переставляем ОС, и kubectl apply