ну вот все что нужно чтобы например поднять mongo это файл mongo-params.yml и команда 'helm upgrade super-mongo stable/mongodb —install -f mongo-params.yml —version 0.4.2`

mongo-params.yml с плоским списоком параметров конкретных для запуска данного mongo образа в этом случае заменяет deployment service и прочие манифесты

имхо kubectl сильно не хватает шаблонизатора

https://github.com/etki/kubely только я его никогда не напишу, походу

но можно оставить какой-нибудь фидбэк, и, может, я все-таки доберусь до этого дела

Ну вот helm же и предоставляет шаблонизатор, там как раз всякие условия и функции можно добавлять в свои шаблоны

если честно, я просто не добрался до него

https://github.com/kubernetes/helm/blob/master/docs/chart_template_guide/functions_and_pipelines.md

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

да я те самые три месяца немного другими вещами занимаюсь просто

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

но опять же имхо, потому что я не уверен в том что выше сказал и существуют юзкейсы о которых я не знаю: так что ковыряйте и рассказывайте best practices

Есть у workflow не позразумевает никаких ручных вмешательств измнения конфигураций в кластере, т.е. все делается автоматически через CI в зависимости от состояния кода конфигураций?

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

у меня за три дня съел почти 10 гигов озу

я лимиты настроил

я лимиты настроил

и когда он выходит за них кубер его перезапускает?

Нет, он не может выйти просто

ну он в них уперся?

короче смотрите: надо впихнуть слой кеша между юзерами и моим приложением щас так: [юзер]->[ингресс]->[сервис]->[приложение] ничего лучше не придумал чем: [юзер]->[ингресс]->[сервис кеша]->[нгинкс/варниш/whatever]->[сервис]->[приложение] выглядит конечно рукожопно... может у кого еще варианты получше есть?

теоретически можно сделать отдельный ингресс кеша. Или балансер - кеш - контейнер

я бы второй вариант сделал

это если кеш нужен общий, а не для каждого пода свой

балансер это внешний ресурс?

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

нет, почему внешний? это ингресс

он будет смотреть через порт контейнера (targetPort)

то есть service с с полем LoadBalancer?

не, я бы хотел чтобы трафик приходил на ингресс: там kube-lego поддерживает ssl

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

то есть то что я и описал

а кстати, ingress умеет слать не на сервис а сразу на поды? че-то я этот момент упустил

поидее везде в примерах я видел только serviceName как эндпоинт ингресса

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

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

насколько я помню - сервис нужен, но он именно как эндпоинт используется. То есть можно сделать сервис без ингресса, просто как селектор

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

headless service

кто как шаблонизирует манифесты кубернетеса? @etkee напомни плиз вроде ты кидал ссылку на свой проект? я вот думаю изобретать велосипед, или поисмотреть может до меня уже все изобрели :)

https://github.com/kubernetes/charts

ну да, тоже тема

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

Подскажите, что бы зафиксировать падение пода в prometheusAlerts нужно использовать что то вроде rate, irate? Пробовал чекать по времени последнего пинга, но если серви падает то получаю no data и сравнение вида rule < 1 не срабатывает

up

up

up == 0 не фиксирует убийство rc,deploy,service,pods их нужно поменить аннотацией, повесить на них экспортер, как это работает у вас?

У нас кластер в азуре, у каждого сервиса свой статический ip на внешнем азуровском балансере. Иногда хочется, чтобы сервисы друг к другу ходили напрямую (не через балансер). Подскажите, куда копать?

Overlay network

Обращаться к сервисам по внутреннему днс имени?

Ну я понимаю, что там виртуальная сеть и у контейнеров свои айпишки. Понятно, что нужен какой-то внутренний днс. А где его взять? Это какая-то приблуда, которую надо поднять или он уже есть где-то?

Ну я понимаю, что там виртуальная сеть и у контейнеров свои айпишки. Понятно, что нужен какой-то внутренний днс. А где его взять? Это какая-то приблуда, которую надо поднять или он уже есть где-то?

kubedns или dns-addon называется, установка описана почти в каждом мануале по к8с

ок, спасибо

ок, спасибо

https://github.com/kubernetes/kubernetes/tree/master/build/kube-dns вот он

А интересно можно сделать так: инстансы сервиса (поды) разбросаны по кластеру по одному на машину. Другие сервисы, при обращении к этому сервису ходят на тот инстанс, который на их машине бегает. Такое возможно?

куб не подразумевает варианта "один под на машину", хоть это и достижимо. без составления сервиса на каждую машину такое вряд ли взлетит.

А интересно можно сделать так: инстансы сервиса (поды) разбросаны по кластеру по одному на машину. Другие сервисы, при обращении к этому сервису ходят на тот инстанс, который на их машине бегает. Такое возможно?

сколько времени реально теряется если сходить на соседний хост?

вот только хотел написать

как правило, это время не значительно

один под на машину = Daemon Set. но в целях оптимизации его обычно не используют

кто-нибудь юзал https://github.com/wercker/cronetes?

MacBook-Pro-Andrey:sheduler drago$ kubectl get pods NAME READY STATUS RESTARTS AGE cronetes-226926354-zcj83 1/1 Running 0 4m nginx-1198612364-en04a 1/1 Running 0 17h nginx-1198612364-lxgep 1/1 Running 0 17h nginx-1198612364-wingz 1/1 Running 0 17h redis-redis-1314662045-3pruz 1/1 Running 0 17h info: 6 completed object(s) was(were) not shown in pods list. Pass —show-all to see all objects.

суть в том что он джобы запускает и компы потом остаются со статусом "completed"

это баг или фича?

по идее это фича

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

насколько понимаю, все будет храниться, пока gc limit не ударит

ERROR: S client not available

к контейнерам, правда, это может не относиться

у меня просто каждую минуту запускается джоб... как бы много их будет :)

n general, pods which are created do not disappear until someone destroys them. This might be a human or a ReplicationController, or another controller. The only exception to this rule is that pods with a PodPhase of Succeeded or Failed for more than some duration (determined by the master) will expire and be automatically reaped.

мастер это контроллер домена?

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

мастер-нода, насколько понимаю

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

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

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

речь идет о попытке вынести все шедулен таски во что-то что в кубернетесе называется "sheduledjobs"

или как там щас... названия постоянно меняют :)

так, не врубился, в 1.5.1 петсеты как-то по другому называются, или это баг GKE? $ kubectl apply -f statefulset.yaml error validating "statefulset.yaml": error validating data: couldn't find type: v1beta1.StatefulSet;

или в какой apiVersion они должны быть? если честно то я в них уже запутался

походу что-то пошло не так: $ kubectl version Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1", GitCommit:"82450d03cb057bab0950214ef122b67c83fb11df", GitTreeState:"clean", BuildDate:"2016-12-14T00:52:01Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} $ kubectl get statefulsets the server doesn't have a resource type "statefulsets"

так, не врубился, в 1.5.1 петсеты как-то по другому называются, или это баг GKE? $ kubectl apply -f statefulset.yaml error validating "statefulset.yaml": error validating data: couldn't find type: v1beta1.StatefulSet;

Должно быть StatefulSet

ну я не возражаю против твоего утверждения, даже был бы рад если б оно работало в гугле

ну или бы знал что у меня одного не работает а у кого-то работает... в связи с этим вопрос к @all - у кого в GKE 1.5.1 запущен и он StatefulSet уже запустил? все ок?

не в гке запустили тестово

ты пробовал? как кластер апгрейдил? (у меня в gui нет опции и я через gcloud обновлял, при этом 1.4.7 у них дефолтным стоит)

делал какие-то дополнительные действия над нодами? как statefulset запускал и проверял работоспособность?

ну или бы знал что у меня одного не работает а у кого-то работает... в связи с этим вопрос к @all - у кого в GKE 1.5.1 запущен и он StatefulSet уже запустил? все ок?

ты через https://cloud.google.com/container-engine/docs/clusters/upgrade#opt-in_early_master_upgrades делал?

Почитал, в целом "да", только там написано что master может только до default. А я явно задал 1.5.1 а щас default=1.4.7

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

То есть у тебя работает?

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

apps/vbeta1 есть?

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

Вжух! ? https://github.com/kelseyhightower/consul-on-kubernetes

apps/vbeta1 есть?

{ "kind": "StatefulSetList", "apiVersion": "apps/v1beta1", "metadata": { "selfLink": "/apis/apps/v1beta1/statefulsets/", "resourceVersion": "23051489" }, "items": null }

но через cli не ест

а через api если залить - то всё ок