Helm - активно развивающаяся утилита в состоянии постоянного совершенствования. Кто-то предпочитает свой велосипед "более надёжный". Кто-то активно контрибьютит в Helm, чтобы обеспечить свои хотелки. У каждого свой выбор. Для гарантии релизов нужно побольше делать вклад в развитие helm.InstallWait (--wait option)

Deis пользуется helm :)

> Helm - активно развивающаяся утилита в состоянии постоянного совершенствования. ну кто же спорит, молодцы парни... я ведь не говорю что это какашка :) тем более сам пользуюсь за отсутствием альтернатив но вот пример: я изменил конфиг (лимит ресурсов), сделал "helm update" и ожидал что под перезапустится с измененным лимитом... этого не произошло, понятно что сам дурак но я щас про ожидания от утилиты и фактическое ее действие к'мон, если отбросить некоторые юзкейсы вещи то в целом какая разница где конфиги епошить: в формате для kubectl или в формате для helm, причем в нем еще многословнее с helm безусловно удобнее распространять решения возможно, я скажу непопулярную вещь: но мне жутко не нравится писать простыни конфигов и поддерживать их :) я говорю не про развитие концепции текущей, а про желание видеть альтернативы

helm чо попало мне кажется. вот он пакет типа поставить захотел. пофейлился. вот в манифесте все что он там дедал до этого никуда не откатывается.

нельзя было сделать как в apt?

> но вот пример: я изменил конфиг (лимит ресурсов), сделал "helm update" и ожидал что под перезапустится с измененным лимитом... этого не произошло Если в качестве аргумента у helm upgrade был chart reference(напрмер 'stable/mariadb'), то ничего и не должно меняться без дополнительного аргумента --set или --values

bebebe Не, в один ряд мы их не ставим. Это уже ваши додумки. На данный момент у нас автоматический деплой это просто вызов helm upgrade из Jenkins, а нам этого недостаточно, поэтому и смотрим на spinnaker, чтобы иметь более умные стратегии развёртывания обновлений.

@takama 1) deis авторы хелма, вот и пользуются. 2) microsoft купила deis, так что больше такой конторы нет. (https://blogs.microsoft.com/blog/2017/04/10/microsoft-acquire-deis-help-companies-innovate-containers/ https://deis.com/blog/2017/deis-to-join-microsoft/ )

@vkfont Посмотри на опцию —recreate-pods при обновлении

@uthark Авторы хелма - Microsoft :)

bebebe Не, в один ряд мы их не ставим. Это уже ваши додумки. На данный момент у нас автоматический деплой это просто вызов helm upgrade из Jenkins, а нам этого недостаточно, поэтому и смотрим на spinnaker, чтобы иметь более умные стратегии развёртывания обновлений.

ок понял вас, тогда вам возможно будет интересная следующая инфа делал R&D по спиннакеру в декабре (сейчас уже у них первый релиз, в этом месяце помойму) вкратце: 9 контейнеров, которые нужно между с собой законнектить, что это означает, что сервисам нужно прописать нужные endpoint'ы, т.к. каждому рассказать где сидит сосединй сервис kubernetes-plugin для деплоя он вроде как умеет, но на декабрь месяц в нем не было нужной гибкости, может допилили api хорош, но несколько удручал, был не допилен, приходилось некоторые вещи делать коряво в итоге у меня было демо, которое показвыает как деплоится кубернетес и на него ставится openstack, показывалось все в рамках flow самого spinnaker'a который под копотом дергал дженкинс

@takama это утверждение стало правдой только после того, как МС их купил.

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

типа ui который красиво продается

@uthark Оно с 2016 года правда, политику делают основные контрибьюторы, достаточно посмотреть первых трёх https://github.com/kubernetes/helm/graphs/contributors

bebebe Кубернетес мы ставим собственным тулом, так что для нас это вообще не вопрос. Про спиннакер — мы тоже на него уже посмотрели, меня лично смущает общая недопиленность, хотя если они официально объявили 1.0, то, может, и поменялось что.

да, у меня было схожее ощущение, что недопиленность

их релиз я не смотрел

@takama Очевидно же, что если МС купила Deis, то у основных контрибьюторов будет указано место работы MC. :)

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

а для внутренних целей - ну хз если честно

если только опять же такие R&D задача есть

Конкретно helm не устраивает тем, что это слишком простой тул для развёртывания, иной раз ломается при обновлении и сидишь руками разгребаешь. Понятно, что спиннакер тоже не панацея, но с ним можно хотя бы делать полноценный gradual rollout.

оффтоп: а есть какая-нибудь утилитка которая опросит мой кластер и покажет все ресурсы (request/limits), да так красиво что я бы понял какого хрена у меня новый сервис не влезает и кого можно ужать :)

Конкретно helm не устраивает тем, что это слишком простой тул для развёртывания, иной раз ломается при обновлении и сидишь руками разгребаешь. Понятно, что спиннакер тоже не панацея, но с ним можно хотя бы делать полноценный gradual rollout.

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

@vkfont Посмотри на опцию —recreate-pods при обновлении

Спасибо. Правильно ли я понимаю что helm не сможет корректно обновить стейтсфулсеты?

@vkfont Вроде в master уже починили. https://github.com/kubernetes/helm/issues/1971

@vkfont + https://github.com/kubernetes/helm/issues/2149

спасибо

оффтоп: а есть какая-нибудь утилитка которая опросит мой кластер и покажет все ресурсы (request/limits), да так красиво что я бы понял какого хрена у меня новый сервис не влезает и кого можно ужать :)

мы такой функционал на prometheus + grafana построили. Есть дашборды по capacity каждого кластера, дашборды с подами, которые потребляют ресурсов больше/меньше заявленного, алерты на cpu.limits

Вот тоже наверно буду

мы такой функционал на prometheus + grafana построили. Есть дашборды по capacity каждого кластера, дашборды с подами, которые потребляют ресурсов больше/меньше заявленного, алерты на cpu.limits

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

поды просто таблицами сделаны топ N https://www.evernote.com/shard/s123/sh/b354979a-6127-43f8-81b6-70d90d376d3e/683bb55e3e06c810

дашборд по утилизации кластера суммарно сделан, без подов https://www.evernote.com/shard/s123/sh/4f7525d3-1a02-4f92-875a-39103e6221a6/000baea99b86101c https://www.evernote.com/shard/s123/sh/40bdd96c-a291-4f16-9149-df1cb650ac2c/0e83f6d9eaf67b83

дашборды повседневно не используются. Приходят алерты по container_cpu_cfs_throttled_periods_total и oom killer :)

Prometheus сами конфигурировали или через Operatorи ?

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

оператор во первых страшно, во вторых недостаточно гибко (но это не точно:))

Согласен мне показалось это тема еще сырая

Я на helm тоже остановился

но не уверен какой стораж использовать

Gluster или просто HostPath

я почти уверен что гластер загнётся. У нас hostPath на ssd и fsync выключен. Prometheus пишет по 100мб/с

ок спасибо. То есть если упадет то вторая реплика имеет полную копию я думаю..

это на 20к точек в секунду примерно

а Graphanu другим helm ?

или у вас уже стояла где нибудь grafana

да, графана другим чартом. Кто-то в одном делает. Но у нас графана одна, а прометэусов несколько.

ясно. А федерацию не делаете между Prometheusami ?

не думаю что в helmе чарте есть такие опции

не делали, т.к. вроде незачем

у нас все чарты самописные:)

ну как я понял у Вас prometheus ранится на каждом clustere

ага

а можно было бы один центральный еще сделать

на всякий случай :)

можно, да. Но мы за данные в прометэусах вообще не паримся, даже не бэкапим их))

ок. A alertmanager тоже настроен на каждом кластере?

да. Конфиги и алерты везде одинаковые, только prometheus.yml шаблонизируем

Спасибо очень интересно я на стадии планирования, поэтому очень интересно как люди пользуются

можно, да. Но мы за данные в прометэусах вообще не паримся, даже не бэкапим их))

А long-term метрики как-то отдельно хранятся?

По прометеусу тема интересная, сам щас метрики запускаю. Удивлен что Денис ещё канал не создал )

это на 20к точек в секунду примерно

любопытно, как часто с экспортеров собираете инфу? и какое число экспортеров?

ERROR: S client not available

По прометеусу тема интересная, сам щас метрики запускаю. Удивлен что Денис ещё канал не создал )

вроде тут где-то проскакивал канал metrics где как раз обсуждают это

У меня есть replicaset. Там я могу указывать, сколько подов запускать. И в процессе жизнедеятельности я буду наращивать количество нод. Мне нужно на каждой ноде запускать только один под из этого rs. Например: есть ноды nginx1 и nginx2. 1. Как настроить, чтобы у меня на каждой ноде запускался только один под? 2. Как указать в rs, чтобы деплой nginx разворачивался только на нодах nginxN? Я так понимаю, мне надо роли и метки почитать? Или как-то по другому делают?

во, тоже по теме спрошу :) подскажите плиз где я накосячил? apiVersion: v1 kind: Service metadata: labels: app: neo4j name: neo4j spec: ports: - port: 7474 selector: app: neo4j --- apiVersion: apps/v1beta1 kind: StatefulSet metadata: name: neo4j spec: serviceName: neo4j replicas: 3 template: spec: ... neo4j-0 под есть, neo4j сервис есть, а хост neo4j-0.neo4j.default.svc.cluster.local не пингуется

У меня есть replicaset. Там я могу указывать, сколько подов запускать. И в процессе жизнедеятельности я буду наращивать количество нод. Мне нужно на каждой ноде запускать только один под из этого rs. Например: есть ноды nginx1 и nginx2. 1. Как настроить, чтобы у меня на каждой ноде запускался только один под? 2. Как указать в rs, чтобы деплой nginx разворачивался только на нодах nginxN? Я так понимаю, мне надо роли и метки почитать? Или как-то по другому делают?

подаффинити

подаффинити

Спасибо.

во, тоже по теме спрошу :) подскажите плиз где я накосячил? apiVersion: v1 kind: Service metadata: labels: app: neo4j name: neo4j spec: ports: - port: 7474 selector: app: neo4j --- apiVersion: apps/v1beta1 kind: StatefulSet metadata: name: neo4j spec: serviceName: neo4j replicas: 3 template: spec: ... neo4j-0 под есть, neo4j сервис есть, а хост neo4j-0.neo4j.default.svc.cluster.local не пингуется

по-моему у тебя лишний сегмент в адресе

Не, это с стейтфулами норм, походу днс глючит

/var/lib/neo4j # nslookup neo4j.default.svc.cluster.local Name: neo4j.default.svc.cluster.local Address 1: 10.51.242.56 neo4j.default.svc.cluster.local /var/lib/neo4j # nslookup neo4j-1.neo4j.default.svc.cluster.local nslookup: can't resolve 'neo4j-1.neo4j.default.svc.cluster.local': Name does not resolve кто знает как править? %)

cat /etc/resolv.conf

+ смотри что с kube-dns творится, у тебя явно dns фигово раотает

с dns все норм (GKE), нашел в чем трабла: https://github.com/kubernetes/kubernetes/issues/30076

если вкратце то в сервисе надо было выставить clusterIP: None, не знал

А long-term метрики как-то отдельно хранятся?

Мы не придумали, как старые метрики могут пригодиться. В prometheus хранятся 45 дней.

Мы не придумали, как старые метрики могут пригодиться. В prometheus хранятся 45 дней.

тренды? я думаю когда-то натравить на них ML команду

любопытно, как часто с экспортеров собираете инфу? и какое число экспортеров?

несколько сотен таргетов у prometheus с наших приложений раз в 15 секунд. со всего остального, включая node_exporter и kubelet раз в минуту

вроде тут где-то проскакивал канал metrics где как раз обсуждают это

https://t.me/metrics_ru

есть набор стейтфулсетов которые по рафту выбирают мастера, при этом у мастера открывается порт а у слейвов закрывается сервис кубернетеса ведь не умеет пускать на открытый порт? то есть если под лабел попадают 10 подов а порт открыт у 3-го то запрос всегда на 3-й пойдет

есть набор стейтфулсетов которые по рафту выбирают мастера, при этом у мастера открывается порт а у слейвов закрывается сервис кубернетеса ведь не умеет пускать на открытый порт? то есть если под лабел попадают 10 подов а порт открыт у 3-го то запрос всегда на 3-й пойдет

Readiness probe можно на порт натравить

ммм, ну да это должно сработать, спасибо

а не, не сработает... он же вешается на pod: если сервис A должен смотреть на все 10 подов а сервис B только на те что с открытыми портами то когда сработает readiness оба сервиса на 3 будут смотреть

каким-нибудь нжинксом с апрстримами это не решается?

как вариант... или ingress :)

У меня есть replicaset. Там я могу указывать, сколько подов запускать. И в процессе жизнедеятельности я буду наращивать количество нод. Мне нужно на каждой ноде запускать только один под из этого rs. Например: есть ноды nginx1 и nginx2. 1. Как настроить, чтобы у меня на каждой ноде запускался только один под? 2. Как указать в rs, чтобы деплой nginx разворачивался только на нодах nginxN? Я так понимаю, мне надо роли и метки почитать? Или как-то по другому делают?

вам нужен daemonset

вам нужен daemonset

Спасибо. А в чём важные отличия в моём случае?

rs ведь просто следит за запуском определённого количества реплик?

ну вам нужно по поду на каждой ноде, это daemonset

ноды добавляются - поды добавляются

replicset просто следить за кол-во подов, но ему пофиг где и как они запущены

О. Вот оно как. Спасибо. Завтра буду изучать.

daemonset следит что бы на каждой node был экзепляр пода

replicset просто следить за кол-во подов, но ему пофиг где и как они запущены

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