Как раз наоборот. Бережливое производство это отказаться от хелма и не плодить лишних сущностей. Качественный скачок возможен, когда инструменты подбираются в соответствии с потребностями, а не потому, что они популярны есть видимость, что все с популярными инструментами умеют обращаться. Переход от DevOps к SRE возможен, когда инженер думает о качестве, тестируемости и обслуживаемости кода, который он пишет, а не сидит и ввчитывается в кудри типа таких:
{{- if .Values.ingress.enabled -}}
{{- $fullName := include "tttt.fullname" . -}}
{{- $svcPort := .Values.service.port -}}
{{- if semverCompare ">=1.14-0" .Capabilities.KubeVersion.GitVersion -}}
apiVersion: networking.k8s.io/v1beta1
{{- else -}}
apiVersion: extensions/v1beta1
{{- end }}
Обе ваших статьи на 50% состоят из попыток доказать, что GitOps не работает потому, что helm. У нас гитопс прекрасно работает. десятки наших кластеров в разных окружениях и на разных площадках обслуживаются без проблем из единого репозитория.
Деплоимся несколько раз в день, все изменения происходят через гит с ревью коллег и через этапы тестирования. Это как раз исключает человеческую ошибку полностью. Коммит в 2 репы как раз защищает от просачивания непротестированного кода в кластера. Это все хорошо задокументировано в README и на вики. За вновь присоединившимися инженерами устанавливаются менторство и особый контроль.
Есть репозитории с аддонами. Если там лежит вендорский софт, поставляемый в виде хелм чарта (например istio или cilium), то в папочке положены манифесты, сделанные посредством `helm template`. Если манифесты самописные, то kustomize.
Есть стейт репа, в которой через kustomize собираются аддонны ссылками на конкретный тег в репы аддонов.
И есть плоская, отрендеренная стейт репа, в которую автоматически коммитится выхлоп `kustomize buld` стейт репозитория. На эту репу смотрит ArgoCD, опять же не на ветку, а на тег.
Соответственно процесс выкатки выглядит так: Инженер коммитит новую версию аддона, ставит тег, меняет тег в стейт репе, новый тег синкается в арго. Если надо откатить, тег в арго меняется на предыдущий.
Как, например, будет раскатываться релиз, если кто-то руками поменял configMap в приложении? Или релиз в состоянии Failed? Тут GitOps кончается и инженер идет в куб править руками
Для GitOps хорошо подходят "плоские" манифесты. В идеале готовые к применению в кластер. Хелм же делает свою магию в процессе применения. Есть темплейты и вельюсы. Проблемы с этим Вы хорошо описали в первой части статьи
Я просто оставлю это здесь
https://kind.sigs.k8s.io/
Вы законтрибьютили в апстрим или поддерживаете свой форк?
По RDP
Покупал тут https://aliexpress.ru/item/1005004421352451.html?sku_id=12000029832016175
Спасибо! Оказывается БП едет отдельной посылкой
Можете посмотреть полярность БП? Сегодня пришла посылка с такии, но забыли положить блок питания, а включить хочется.
Как раз наоборот. Бережливое производство это отказаться от хелма и не плодить лишних сущностей. Качественный скачок возможен, когда инструменты подбираются в соответствии с потребностями, а не потому, что они популярны есть видимость, что все с популярными инструментами умеют обращаться. Переход от DevOps к SRE возможен, когда инженер думает о качестве, тестируемости и обслуживаемости кода, который он пишет, а не сидит и ввчитывается в кудри типа таких:
Обе ваших статьи на 50% состоят из попыток доказать, что GitOps не работает потому, что helm.
У нас гитопс прекрасно работает. десятки наших кластеров в разных окружениях и на разных площадках обслуживаются без проблем из единого репозитория.
К сожалению, не понимаю.
Ребята переизобретают kustomize?
Деплоимся несколько раз в день, все изменения происходят через гит с ревью коллег и через этапы тестирования. Это как раз исключает человеческую ошибку полностью. Коммит в 2 репы как раз защищает от просачивания непротестированного кода в кластера. Это все хорошо задокументировано в README и на вики. За вновь присоединившимися инженерами устанавливаются менторство и особый контроль.
Почему кривовато? Какие Вы видите минусы?
Да, это коммит в репу. Во кусок kustomization:
Инженер сначала ставит тег v1.1.2 на репозитории Сертменеджера, потом коммитит в стейтрепу
Ладно, расскажу как у нас сделано
Есть репозитории с аддонами. Если там лежит вендорский софт, поставляемый в виде хелм чарта (например istio или cilium), то в папочке положены манифесты, сделанные посредством `helm template`. Если манифесты самописные, то kustomize.
Есть стейт репа, в которой через kustomize собираются аддонны ссылками на конкретный тег в репы аддонов.
И есть плоская, отрендеренная стейт репа, в которую автоматически коммитится выхлоп `kustomize buld` стейт репозитория. На эту репу смотрит ArgoCD, опять же не на ветку, а на тег.
Соответственно процесс выкатки выглядит так: Инженер коммитит новую версию аддона, ставит тег, меняет тег в стейт репе, новый тег синкается в арго. Если надо откатить, тег в арго меняется на предыдущий.
Бин, ftp. Давайте перестанем откапывать стюардессу
Как, например, будет раскатываться релиз, если кто-то руками поменял configMap в приложении?
Или релиз в состоянии Failed?
Тут GitOps кончается и инженер идет в куб править руками
Костыли и велосипеды
Для GitOps хорошо подходят "плоские" манифесты. В идеале готовые к применению в кластер. Хелм же делает свою магию в процессе применения. Есть темплейты и вельюсы. Проблемы с этим Вы хорошо описали в первой части статьи
Опять Вы путаете GitOps и Helm. Это никак не связанные вещи. Helm очень плохо подходит для GitOps.
Не забываем так же, что композ это всего лишь пачка питоновских скриптов вокруг докера, а докер - абстракция над containerd
Хелм это всего лишь sed на стероидах. Гиперусложнен и избыточен. Без него процессы поставки сильно упрощаются.