вообще он ревизию инкрементит (100, 101, 102 и тд), статус всегда DEPLOYED

надо образ чтобы поменялся

ну, тег ты имеешь ввиду?

образ то меняется конечно

поле image, как текст, изменения

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

хотел бы сказать хелм Г, но тут он не виноват.

поле image, как текст, изменения

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

Документацию ж не читаем

можете закостылить: делать Release.Version в annotation , и imagePullPolicy:always

Документацию ж не читаем

кто документацию читает )) кто работает

можете закостылить: делать Release.Version в annotation , и imagePullPolicy:always

Спасибо добрый человек, пойду пробовать ?

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

Они вроде уже выкатили. Но я хочу для себя изучить.

Preview можно делать https://aws.amazon.com/eks/

можно иметь отдельную коллекцию веток в репе, где чисто деплой ресурсы. там сделать common ветку, и для каждого окружения. мержить все изменения common в окружение при помощи CI как будто это релиз самого кода (что логично, ибо новые параметры деплоя могут сломать деплой точно так же как новый код)

звучит логично. т.е. common хранит общие конфиги а сами ветки dev/prod хранят только переменные? Как в таком случае секретами управлять?

звучит логично. т.е. common хранит общие конфиги а сами ветки dev/prod хранят только переменные? Как в таком случае секретами управлять?

зависит от того, на чет написано. например на node.js есть отличная тема - config, позволяет определять конфиги самому разрабу и говорить какие значения в конфигах будут соответствовать каким переменным. в итоге разраб может сам наколхозить конфиги (именно значащие значения) для всех сред, а секреты приедут в ENV-переменные

зависит от того, на чет написано. например на node.js есть отличная тема - config, позволяет определять конфиги самому разрабу и говорить какие значения в конфигах будут соответствовать каким переменным. в итоге разраб может сам наколхозить конфиги (именно значащие значения) для всех сред, а секреты приедут в ENV-переменные

Ну env можно в любое приложение пробросить. Но вопрос в том, как они управляются в мире кубера? где они хранятся и как разворачиваются

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

Отдельно где? Не могу понять, как их хранить. Например, для Amazon я храню многое в Ansible Vault

как управлять секретами - дело личное, я знаю людей которые держат секреты в репо (с закрытым доступом) и тоже по CI-пайплайну их катают

Ок. Ну, по крайней мере я понял что env можно отдельно / параллельно накатывать на поды, так?

не, внутри кубера есть такая абстракция как секрет, а уж откуда она возьмется - это как удобнее

потом этот секрет можно замапить на env в поде

Ну мне напрашивается все равно ansible vault из которого создается секрет кубера... Или какие стандартные варианты хранения? Или часто как-раз кубер и хранит эти секреты изначально? (а люди их вручную задают в кубер?)

Ребята кто fluent-bit пользуется для доставки логов?

Есть пара вопросов

очень рекомендую https://www.youtube.com/watch?v=vTgQLzeBfRU

кое каких опций для kubelet \ kube-apiserver не хватает в инсталяции из kubespray. плюс видео убедило начать использовать network policy =))

А кто как сайты в k8s прогревает? Мне пока это видится как readiness probe которая проходится по списку страниц при первом запуске, а при следующих сразу выдает exit code 0.

не совсем уж вырубать его, хотя бы что то проверять на readiness нужно обязательно

звучит логично. т.е. common хранит общие конфиги а сами ветки dev/prod хранят только переменные? Как в таком случае секретами управлять?

Мы не храним, при деплое проверяется есть ли секрет, если нет - сгенерировать и создать. Секрет потом используется самим приложением и другими, кому оно надо (скажем пароль от базы данных). Но это работает только если у вас все в кубе

А кто как сайты в k8s прогревает? Мне пока это видится как readiness probe которая проходится по списку страниц при первом запуске, а при следующих сразу выдает exit code 0.

Да, так и надо.

кое каких опций для kubelet \ kube-apiserver не хватает в инсталяции из kubespray. плюс видео убедило начать использовать network policy =))

Там еще есть видео от rackn, которое имеет ненулевой шанс убедить не использовать kubespray :) узнал из него о digital rebar, буду смотреть как заменить им свой наколеночный pxe + dhcp

Там еще есть видео от rackn, которое имеет ненулевой шанс убедить не использовать kubespray :) узнал из него о digital rebar, буду смотреть как заменить им свой наколеночный pxe + dhcp

Что не так с kubespray?

Что не так с kubespray?

Религиозный вопрос. Лично для меня: он не решает ни одной задачи, которую нельзя было бы решить другими более простыми средствами. С появлением bootkube, все что нужно это запустить kubelet на всех нодах и запустить bootkube один раз на одной. Ну etcd, но на CoreOS это можно сказать из коробки.

Кластер должен уметь описывать и поддерживать сам себя. Ребята пилят ClusterAPI , вот это правильное направление. Хочу апгрейд ОС на всех нодах, с корректными ребутами, проверками и роллбэком, через kubectl apply

Кластер должен уметь описывать и поддерживать сам себя. Ребята пилят ClusterAPI , вот это правильное направление. Хочу апгрейд ОС на всех нодах, с корректными ребутами, проверками и роллбэком, через kubectl apply

Ну тут не поспоришь

А что сейчас наиболее прогрессивное для сети? flannel?

А что сейчас наиболее прогрессивное для сети? flannel?

мы с flannel на calico перешли, пока без нареканий

А что не устраивало? или наоборот какие плюсы в calico?

У calico с network policy получше, для flannel нужен canal насколько я помню

Кто с helm'ом живет, вы чарты внутри проектов храните или выносите отдельно как в kubernetes/charts?

чарты внешних (типа форк монги) в отдельной репе, чарты внутренних сервисов запакованы в один универсальный чарт во внешней репе, сервисы деплоются через values.yml которые в каждой репе сервиса свои

А что сейчас наиболее прогрессивное для сети? flannel?

Голый calico. Но не совсем "наиболее прогрессивное", просто хорошо работающее

Голый calico. Но не совсем "наиболее прогрессивное", просто хорошо работающее

чей-то не прогрессивное?

а serviceName-version.tgz во внешней универсальной репе хранится? или в нутри проекта сохраняется?

а serviceName-version.tgz во внешней универсальной репе хранится? или в нутри проекта сохраняется?

git clone при деплое в chart/charts

чей-то не прогрессивное?

Ну на острие атаки сейчас всякие Cilium или вон родной CNI от AWS

git clone при деплое в chart/charts

То есть как то так: 1. Обновили/Добавли чарт 2. сгенерили новый index.yaml 3. git add/commit/push (as github pages например)

Ну на острие атаки сейчас всякие Cilium или вон родной CNI от AWS

че-то cilium выглядит как комбайн)

То есть как то так: 1. Обновили/Добавли чарт 2. сгенерили новый index.yaml 3. git add/commit/push (as github pages например)

Нафиг мне этот секс неестественный? Просто git clone :)

че-то cilium выглядит как комбайн)

Просили прогрессивное

Нафиг мне этот секс неестественный? Просто git clone :)

Что бы можно было добавить как репозиторий helm repo add https://addresRepo разве нет?

А что не устраивало? или наоборот какие плюсы в calico?

Одним компонентом меньше, меньше чего может сломаться, поменять конфиг несовместимо и проч.

Что бы можно было добавить как репозиторий helm repo add https://addresRepo разве нет?

Это так хелм хочет, я считаю они больные на голову. Делаю так (когда есть черт вообще), есть приложение app, в нем ничего, только зависимость на generic-app. Что бы generic-app не публиковать дедовскими способами, оно перед деплоем клонируется в chart/charts

Те. перед вызовом helm template, структура такая: - /chart/Chart.yaml - /chart/values.yaml - /chart/charts/generic-app/.git

У нас тесты и деплой разъединены, например. Не собираем чарт, если тесты не прошли локально. На случай роллбэка храним все в helm сервере. Т.е. схема такая: пуш в бранч -> юниты -> сборка нового контейнера -> сборка нового чарта -> мерж -> деплой.

У нас тесты и деплой разъединены, например. Не собираем чарт, если тесты не прошли локально. На случай роллбэка храним все в helm сервере. Т.е. схема такая: пуш в бранч -> юниты -> сборка нового контейнера -> сборка нового чарта -> мерж -> деплой.

> сборка нового чарта а что на этом этапе делаете? генерите чарт и его же деплоите или коммитите во внешний репозиторий и уже из него деплоите?

Генерим и коммитим в свой helm repo. А деплоим из него на стадии деплоя

У нас тесты и деплой разъединены, например. Не собираем чарт, если тесты не прошли локально. На случай роллбэка храним все в helm сервере. Т.е. схема такая: пуш в бранч -> юниты -> сборка нового контейнера -> сборка нового чарта -> мерж -> деплой.

Хм, а какой смысл? Чем сборка нового черта зависит от тестов?

Зачем собирать новый чарт, если юниты не прошли? Увеличивать энтропию только.

что изменяется в чарте между сборками?

ERROR: S client not available

Имя контейнера, иногда - переменные какие-то, если это нужно. У нас есть сервисы, где, например, сервис не принимает реплицированную монгу, отдаем нереплицированный урл флагом. Когда допишут - просто опцию поменяем. Где флагов становится много, разработчики переезжают на конфиги - добавляются конфигмап темплейты в чарты. Где-то сервис ведет себя как кажется немного странно но локально не видно почему - пробрасываем facility level другой в чарт. Как только ты руками на кластере ничего не меняешь, оказывается, что на любой чих меняется чарт.

Но сам по себе новый чарт просто тянет новый код. С этим можно делать роллбэк - а именно роллбэк и апгрейд и есть часть того, почему все хотят k8s, а не, скажем, OpenStack

Имя контейнера, иногда - переменные какие-то, если это нужно. У нас есть сервисы, где, например, сервис не принимает реплицированную монгу, отдаем нереплицированный урл флагом. Когда допишут - просто опцию поменяем. Где флагов становится много, разработчики переезжают на конфиги - добавляются конфигмап темплейты в чарты. Где-то сервис ведет себя как кажется немного странно но локально не видно почему - пробрасываем facility level другой в чарт. Как только ты руками на кластере ничего не меняешь, оказывается, что на любой чих меняется чарт.

Ну так держите черт кодом, зачем его "пересобирать"?

Что значит "держите чарт кодом"?

У тебя код приезжает в реджистри же в итоге. Я прод с "latest" не тяну.

*рядом с кодом

Ну держишь ты его рядом с кодом. А доставку кода ты как организовываешь?

Вот выкатили в прод новую версию, оказалось, что есть проблема. Как делать роллбэк, ждать, пока разрабы регрессию пофиксят?

Мы не храним, при деплое проверяется есть ли секрет, если нет - сгенерировать и создать. Секрет потом используется самим приложением и другими, кому оно надо (скажем пароль от базы данных). Но это работает только если у вас все в кубе

Ну а как быть с секретами внешних сервисов ?

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

Ну а как быть с секретами внешних сервисов ?

Я из переменных окружения беру --set API_TOKEN=$API_TOKEN

Я из переменных окружения беру --set API_TOKEN=$API_TOKEN

Да блин. А как они туда попадают?

Да блин. А как они туда попадают?

Конкретно у меня они в gitlab variables хранятся

в circleci собственно так же

Понял. То есть любой кто имеет доступ к этому проекту может прочитать переменные

Ну, в теории

Понял. То есть любой кто имеет доступ к этому проекту может прочитать переменные

Конкретно в gitlab их могут видеть только админы, обычные девелоперы их не видят

Конкретно в gitlab их могут видеть только админы, обычные девелоперы их не видят

а как же echo $VAR в проекте (во время сборки)?

а как же echo $VAR в проекте (во время сборки)?

у нас конфиги лежат в ops папке и есть git server-hook который проверяет права тех кто его менял + gitlab variables можно поставить флаг protected тогда она будет доступна только в protected ветках/тегах которые создает мастер/овнер

Ааа, хорошо. Уже несколько раз такую стратегию вижу, когда защищенная ветка хранит конфиги сборки ?

Потому что я все в отдельной репе храню, и почти всегда это работает. Но иногда хочется чего-то лучше...

Потому что я все в отдельной репе храню, и почти всегда это работает. Но иногда хочется чего-то лучше...

Есть еще vault если по уму

Спасибо всем в чатике. Базу прям хорошо внушили)))

Вдохновляет возможность задеплоить с нуля ваще ВСЕ. "Дай мне ip 2х сервантов, сделаю че надо".. И минимальный риск косяков среды, т.к. все контейнеризированоо

Вдохновляет возможность задеплоить с нуля ваще ВСЕ. "Дай мне ip 2х сервантов, сделаю че надо".. И минимальный риск косяков среды, т.к. все контейнеризированоо

Вообще рай

?

Ребят, тут кто-то давече писал про Bootkube, я что-то по диагонали не нашел как он реаизовывает HA мастер

сразу говорю я особо не вчитывался, бегло с ходу не нашел

Ребят, тут кто-то давече писал про Bootkube, я что-то по диагонали не нашел как он реаизовывает HA мастер

Я писал, bootkube ничего не реализовывает, он создает и загружает в кластер то, что вы подсунете ему в директории manifests