коллеги, а может мне кто-то внятно объяснить, для чего нужен helm?

коллеги, а может мне кто-то внятно объяснить, для чего нужен helm?

можешь считать пакетным менеджером его + немного сахара

не очень понимаю, что имеется ввиду под пакетным менеджером. Образы то я все равно из registry беру

а конфигурации к образам и настройки ?

внутри yml файлов?

ага

просто я не очень понимаю, зачем тут helm. Один раз этот yaml написал - постоянно используешь. Что дает helm?

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

просто я не очень понимаю, зачем тут helm. Один раз этот yaml написал - постоянно используешь. Что дает helm?

мм а ты про который yaml ?

ну вот у меня есть yml, который описывает все, что мне необходимо для развертывания - тома, сервисы, ingress-ы. Это, грубо говоря, один файл. Я пытаюсь понять, зачем нужен helm, а то я пока как-то не въезжаю

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

https://github.com/kubernetes/helm/pull/965/files

видимо

просто я правда не понимаю, что именно он делает. Все же в yml описано. Но при этом все пользуются и хвалят. Вот я и думаю - может я не догоняю чего?

https://deis.com/blog/2015/why-kubernetes-needs-helm/

вот еще

но я пока не в теме просто прохожий

Для разворачивания сервисов в среде Kubernetes нужен инструмент, который должен делать следующие задачи: 1. Деплоить в кластер подготовленные манифесты 2. Отслеживать результат деплоймента и сообщать о неудачах 3. Откатывать релизы 4. Желательно иметь возможность создавать шаблоны манифестов, чтобы уменьшить влияние чел. фактора и копипасты 5. Желательно умение и знания про типы деплоймента (blue/green, rolling, canary) 6. История релизов Всё это или часть можно организовать разными способами: 1. Kubectl + свой велосипед 2. Helm 3. Terraform 4. Что-то еще Свой велосипед конечно "лучше всего", но он как каша/суп из топора. Простота этого подхода лишь обманчива. Вместе с ростом потребностей и кол-ва сервисов в кластере будут расти требования к релиз-менеджеру. И в случае велосипеда в итоге будет реализован аналогичный Helm'у инструмент. Возможно он будет лучше (свой же велосипед всегда лучше). Но на него будет потрачен серьёзный ресурс. Каша не становится бесплатной, даже если она из топора.

Может кому полезно будет.

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

справедливости ради, circuit breaker и кудрявый лоадбалансинг nginx не умеет

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

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

справедливости ради, circuit breaker и кудрявый лоадбалансинг nginx не умеет

это умеет openresty например

это умеет openresty например

для http может что-то и созрело, в stream модуле (голый TCP) там вечные косяки были еще год назад

для http может что-то и созрело, в stream модуле (голый TCP) там вечные косяки были еще год назад

например?

сегфолтилось, не помню что делали :(

привет. а кто-нибудь подскажет, как в helm правильно работать с секретами? Например, чарт состоит из двух частей - сервиса и базы. При установке надо сгенерить пароль к базе. Но при обновлении пароль не надо менять. Вроде бы, можно объявить шаблон секрета как pre-install hook и в значение положить что-то типа {{ .Values.scopeMysqlPassword | default (randAlphaNum 16) | b64enc }} Но как быть, если надо секрет создать при обновлении чарта?

а никак. херачить job с bash script внутри

ох ё, я этого и боялся :)

Костылизация наше все :)

helm же всегда дергает kubectl apply и никогда kubectl patch ?

helm же всегда дергает kubectl apply и никогда kubectl patch ?

если бы, оно никогда не дергает kubectl appl

при этом kubectl patch которые оно генерирует - кривые. в итоге у вас в кластере может быть не то, что в релизе :)

хм... это интересно. а карта граблей где-то есть?

в смысле - к чему готовиться?

базовые вещи поломаны: релиз может "усыновить" ресурсы которые уже были, в итоге сам релиз фэйлится и пользователь скажем решает его удалить. оно удаляет и то, что реально не было установлено :) или скажем оно забывает про любые ресурсы, в которых явно прописан namespace. ну или самый ад: upgrade after failure, оно делает совсем не то, что кажется - там внутри идет генерация патча на каждый апгрейд, при этом база для патча - последний релиз, неважно зафэйлин он был или нет. в итоге скажем в релизе изменили A, B при этом B сломало релиз, пользователь делает B' и ожидает получить в кубе и A и B', а получает только B' :)

^^

ага, спасибо

а ну еще вещи, которые вроде и не баги, но "ну как так-то??" очень даже. например dependencies не то, чем кажутся. все ямлы из всего дерева зависимостей просто рендерятся в огромный список и сортируются: сначала идут все configmaps, затем все secrets и т.д. потом оно все пачкой загужается в куб, дальше уж как карта ляжет. подтянули redis по зависиомостям и в обновлении хотите включить какую-то фишку, которое обновленное приложение использует и без нее жить не может7 готовьтся к краш рестартам ваших подов, т.к. и redis и выше приложение будут обновляться одновременно

короче их надпись крупными буквами "package manager for kubernetes" самый большой и наглый п%здеж

альтернатив же пока не видно?

найдете - скажите

темплейтить ямлы и затем kubectl apply, оно хотя бы работает. единственная проблема - надо удалять то руками, что было переименовано/убрано .

по поводу обновлений - елси бы в helm'е была втроенная переменная .Resources для доступа к текущему состоянию ресурсов, то мою бы задачу это решило. какой-нибудь стандартный контейнер с хелпером add_if_not_exists тоже решил бы. не попадались никакие наработки на эту тему?

ресурсы в tiller не отслеживаются, там все на уровне текста ямла

Есть под с пхп и, когда он первый раз стартует, выполняется прогрев кэша. Занимает сей процесс около 40 секунд и в этот момент пользователь видит 504 при заходе на сайт. Даже, если у меня несколько реплик пхп, всё равно часть пользователей получит 504. Речь идёт о моменте, когда я деплою новую версию приложения в кластер. Как-нибудь можно настроить, чтобы запросы шли на старые поды определённое время, и только потом начинали идти на новые (а старые удалялись)?

proxy_next_upstream в nginx не подойдёт?

proxy_next_upstream в nginx не подойдёт?

Upstream один. А уже на уровне dns round-robin идёт выбор места назначения.

Судя по документации, должно быть насколько апстримов прописано в конфиге nginx?

readiness probe должны помочь

readiness probe должны помочь

Да. Вроде оно. Спасибо.

Есть под с пхп и, когда он первый раз стартует, выполняется прогрев кэша. Занимает сей процесс около 40 секунд и в этот момент пользователь видит 504 при заходе на сайт. Даже, если у меня несколько реплик пхп, всё равно часть пользователей получит 504. Речь идёт о моменте, когда я деплою новую версию приложения в кластер. Как-нибудь можно настроить, чтобы запросы шли на старые поды определённое время, и только потом начинали идти на новые (а старые удалялись)?

а как прогреваете? я вот этот fcgi client использую для прогрева https://github.com/adoy/PHP-FastCGI-Client собираюсь его же для проверки состояния использовать. в общем у меня достаточно будет проверить состояние для прогрева (opcache)

Есть под с пхп и, когда он первый раз стартует, выполняется прогрев кэша. Занимает сей процесс около 40 секунд и в этот момент пользователь видит 504 при заходе на сайт. Даже, если у меня несколько реплик пхп, всё равно часть пользователей получит 504. Речь идёт о моменте, когда я деплою новую версию приложения в кластер. Как-нибудь можно настроить, чтобы запросы шли на старые поды определённое время, и только потом начинали идти на новые (а старые удалялись)?

надо фейлить readiness probe, пока кеши не прогреются

просто я правда не понимаю, что именно он делает. Все же в yml описано. Но при этом все пользуются и хвалят. Вот я и думаю - может я не догоняю чего?

Это как rpm по сравнению с tar.gz. есть всякие хитрости, зависимости, post-install скрипты и т.п.

ну вот у меня есть yml, который описывает все, что мне необходимо для развертывания - тома, сервисы, ingress-ы. Это, грубо говоря, один файл. Я пытаюсь понять, зачем нужен helm, а то я пока как-то не въезжаю

если вам хватает kubectl apply нет смысла бежать к helm, только головную боль зарботаете

попробуйте задеплоить таким макаром spinnaker

у меня такой вопрос. Есть 2 кластера, 1 "продовый", второй пока стоит пустой. Находятся в разных ДЦ. Как лучше сделать (и можно ли вообще) резервирование, чтобы в случае падения (читай, пропал сетевой доступ) к первому, второй кластер поднял все поды, чтобы на первом? По идее, этот вопрос должен решаться федерализацией? Но как я понял из доки, при федерализации идет синхронизация и все поды\сервисы запускаются одновременно на двух кластерах, только как тогда продумать маршрутизацию, я что-то не осилил :( Может кто занимался этим вопросом, подскажет как "правильнее" продумать схему?)

Если датацентры недалеко то там есть такая штука (https://kubernetes.io/docs/admin/multiple-zones/)

надо фейлить readiness probe, пока кеши не прогреются

А как настроить удаление старых подов только тогда, когда новые ответят, что живы и работают?

deployment + maxSurge / maxUnavailable?

Всем привет. А на своих железных серверах поднимать k8s лучше на какой ОС ? Может CoreOS ? или без разницы ?

Всем привет. А на своих железных серверах поднимать k8s лучше на какой ОС ? Может CoreOS ? или без разницы ?

Гугли по докеру. где докеру лучше живётся то и запускаем

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

deployment + maxSurge / maxUnavailable?

Я придерживаюсь политики, что можно создать один лишний под и максимально недоступно - ноль. А тут получается, что новый под в состоянии running, но ещё не отвечает, так как прогревается кэш, readinessProbe решит проблему round-robin: на эти новые поды не будет отправляться трафик, но от удаления старых, когда новые ещё не работают, он не спасёт.

Я придерживаюсь политики, что можно создать один лишний под и максимально недоступно - ноль. А тут получается, что новый под в состоянии running, но ещё не отвечает, так как прогревается кэш, readinessProbe решит проблему round-robin: на эти новые поды не будет отправляться трафик, но от удаления старых, когда новые ещё не работают, он не спасёт.

maxUnavailable считается по количеству ready

ERROR: S client not available

maxUnavailable считается по количеству ready

То есть, если readinessProbe успешно, то только тогда произойдёт удаление?

должно быть так

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

configmap volume

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

Если датацентры недалеко то там есть такая штука (https://kubernetes.io/docs/admin/multiple-zones/)

а недалеко это сколько? )

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

ага. бегло посмотрел.

тоест ьфактически контейнер сам отвечает за создания своего конфига ?

кто за что отвечает , это не технический вопрос, а огранизационный :)

я просто сейчас сравниваю с номадом

там есть template

он берет шаблон и отрендерви кладет в нужное место

а в кубере ?

а недалеко это сколько? )

Чисто дедуктивно. В доке приводится в пример Amazon AZ в одном регионе. Погуглил среднее время пинга между AZ. медиана = 2ms, 90p = 30 ms, 99 = 47ms

вот настолько далеко :)

я просто сейчас сравниваю с номадом

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

штук вроде динамической подгрузки и обновления из vault/consul нет вообще

Чисто дедуктивно. В доке приводится в пример Amazon AZ в одном регионе. Погуглил среднее время пинга между AZ. медиана = 2ms, 90p = 30 ms, 99 = 47ms

?

ага. а как тогда решается вопрос изменился ключ в etcd HUP ни сервис ?

ага. а как тогда решается вопрос изменился ключ в etcd HUP ни сервис ?

это боль.

самое близкое - научить сервис делать релоад по запросу на какой-нибудь админский порт. тогда можно рядом крутить sidecar container, который смотрит за etcd и делает curl на 127.0.0.1

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

нее. процессы уже декомпозированы

всегда можно добавить еще

если само приложение не умеет следить за etcd, всегда кто-то должен делать это за него

ну врятли можно научить nginx следить за etcd

можно, но не нужно

ну врятли можно научить nginx следить за etcd

крутите confd рядом с nginx

а прикручивание чего то типа confd ?

ага