типа такой https://habr.com/post/258443/

сложная часть - это сеть, по крайней мере для меня

Эх, пропадет же человек...

чот короче подумал я подумал и не понял почему я сразу не на ksonnet сделал

а на голом jsonnet

народ, кто пробовал перенаправлять все запросы к api через nginx, как это сделано у kubespray, но не только с worker'ов, но и с master нод (kube-controller, kube-scheduler). В теории должно работать, может есть подводные камни?

народ, кто пробовал перенаправлять все запросы к api через nginx, как это сделано у kubespray, но не только с worker'ов, но и с master нод (kube-controller, kube-scheduler). В теории должно работать, может есть подводные камни?

а зачем?

на мастере будут тоже размещаться поды, думал сделать так же только kubelet, kube-proxy, а потом подумал, чего мелочиться

зачем на мастере размещать поды?

на мастере будут тоже размещаться поды, думал сделать так же только kubelet, kube-proxy, а потом подумал, чего мелочиться

поды на мастере из-за экономии средств?

да, т.к. сервера будут железные

народ, кто пробовал перенаправлять все запросы к api через nginx, как это сделано у kubespray, но не только с worker'ов, но и с master нод (kube-controller, kube-scheduler). В теории должно работать, может есть подводные камни?

А в чем проблема? В kubeadm-config любой же адрес указать можно, хоть localhost

А в чем проблема? В kubeadm-config любой же адрес указать можно, хоть localhost

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

@kvaps а ты в каждом app.yaml все кластера вписываешь?

или можно упростить как-то

@kvaps а ты в каждом app.yaml все кластера вписываешь?

В каждом, где оно должно работать, упростить можно через CLI: ks env add --namespace ... по дефолту добавится сервер из текущего контекста

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

а ксоннет только генерил для указанных контекстов ямл-файлы

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

А зачем тогда Ksonnet?)

мне не сложно даже их применять через kubectl apply -f и хранить в моём гите

чтобы генерить

у меня между кластерами конфиги разные например

ks apply <env> и никакой контекст переключать не надо перед этим, он сам задеплоит в нужный кластер

а откуда он возьмёт в какой мастер мне деплоить надо, а в какой - не надо?

вот я щас оператора запустил только в одном кластере

Ну ты же указываешь server url в app.yaml, он посмотрит на него, затем найдет в твоём кубе-конфиге подходящий костер и задеплоит в него

ks apply <env> и никакой контекст переключать не надо перед этим, он сам задеплоит в нужный кластер

костёр :)

Ну ты же указываешь server url в app.yaml, он посмотрит на него, затем найдет в твоём кубе-конфиге подходящий костер и задеплоит в него

подходящий костер. Прям вот в точку!

ну у меня прост кластера запущены копсом и это я менять точно не буду

он может вписать контексты в конфиг куба

дублировать это в app.yaml как-то тупо :|

Ну если хочешь самостоятельно применять, то можно просто: ks show <env> | kubectl apply -f - Ну а так Ksonnet - это deployment-manager же тоже, он даже какое-то состояние в аннотациях хранит

и ещё я не понял как мне заимпортить ксоннетом либу

могу это сделать через jb конечно

Ну если хочешь самостоятельно применять, то можно просто: ks show <env> | kubectl apply -f - Ну а так Ksonnet - это deployment-manager же тоже, он даже какое-то состояние в аннотациях хранит

ну вот <env> это же только для одного кластера, получается?

и ещё я не понял как мне заимпортить ксоннетом либу

Сгенери что-нить из прототипа, там были примеры

то есть нельзя сказать, что prod это вот эти вот три кластера указанные в трёх контекстах в ~/.kube/config

Ты ведь ksonnet-lib хочешь?

нет

я хочу kube-prometheus

ну вот <env> это же только для одного кластера, получается?

Ну у меня так: Если приложение одно на кластер, то указывается имя кластера: prod devel stage Если инстансов несколько на кластер, то указываю через /: prod/app1 prod/app2 prod/app3 Это удобно потому что для каждого приложения можно инклюдить общие параметры из prod

ну блин у меня prod - не имя кластер

прод у меня в двух кластерах

в разных

они запущены копсом

они запущены копсом

не используй kops :-)

не используй kops :-)

зашибись совет что ж тогда мне использовать предлагаешь?

зашибись совет что ж тогда мне использовать предлагаешь?

расскажи, что за задачи

а то я тебе ща опеншит начну продавать

или rke

нет смысла, я через неделю увольняюсь

ааа

копс на что-то левое менять я не собираюсь

тогда желаю успехов )

копс меня сейчас устраивает

Ну разделяй их через / значит: prod/ru prod/us Здесь как твоя фантазия тебе подскажет

копс на что-то левое менять я не собираюсь

rke, по-твоему, левое? как и опеншифт?

rke, по-твоему, левое? как и опеншифт?

да

эх. жаль.

Ну разделяй их через / значит: prod/ru prod/us Здесь как твоя фантазия тебе подскажет

Смысл в том что бы не описывать одни и те же параметры дважды

Сгенери что-нить из прототипа, там были примеры

карочи надо чтобы был файлик registry.yaml в репозитории рядом с kube-prometheus https://github.com/ksonnet/parts/blob/master/incubator/registry.yaml

Смысл в том что бы не описывать одни и те же параметры дважды

вот поэтому я и не понимаю зачем мне их описывать дважды: один раз в ~/.kube/config и второй раз в app.yaml

а на голом jsonnet

Я наоборот с ksonnet на голый jsonnet уйти хочу :)

особенно учитывая что первый генерится

Я наоборот с ksonnet на голый jsonnet уйти хочу :)

я очень хочу импорт готового ямля, в голом жсоннет его нет

и вообще дофига чего нет

не используй kops :-)

тю а что с ним не так?

я очень хочу импорт готового ямля, в голом жсоннет его нет

Готовый ямл это однострочник на питоне из ямла в джсон

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

и заметную часть моих наколенных поделок можно дропнуть

Готовый ямл это однострочник на питоне из ямла в джсон

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

Коллеги, добрый день! Подскажите пожалуйста, кто какие инструменты деплоя в k8s использует у себя на CI\CD конвейере

helm ?

тю а что с ним не так?

Ну, я не спорю, что он лучше, чем kube-spray

и вообще дофига чего нет

Чего ещё нет? Хочу знать что меня ждет

Коллеги, добрый день! Подскажите пожалуйста, кто какие инструменты деплоя в k8s использует у себя на CI\CD конвейере

сейчас jsonnet + kubectl apply -f

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

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

А зачем тебе ямл? - применяй json

Чего ещё нет? Хочу знать что меня ждет

ну в самом жсоннет нет фичи +:: для элемента массива, но её так же нет и в ksonnet

helm ?

ksonnet/jsonnet , ещё kaptain достойный