Имеется набор доменов, нужно что бы по всем ним был редирект на основной Как настроить Ingress?

Вообщем, я согласен, что все должно накатываться из пайплайна, что база etcd должна быть отделена и так далее. Но бекап я делал и буду делать, потому что мне так намного спокойнее.

Так а хоть раз была ситуация, что кто-то зачем-то в etcd заходил? Опять же вопрос проверки разворачивания бекапа непрост - надо или тестировать вот прям сразу же после создания, чтоб воркеры смогли скачать все образы и т.д., либо получается тестирование сферического коня в вакууме. Тогда как cd пайплайны тестируются при каждом использовании. Так что бекапу etcd я лично не доверяю, а вот скриптам развертывания кластера с нуля (т.к стейджи им пересоздаю регулярно) и пайпам, которые в кластер все выкатывают - доверяю. И если че, то новый мастер, в него все деплои дальше воркеров по-очереди к нему переподключить имхо намного надежнее

@zuzzas а вы хелмом деплоите?

Вот только потом тебе нужно будем размышлять о том, в каком порядке всё это восстанавливать. А ещё неизбежно возникнут проблемы с metadata и status field'ами, которые Kubernetes по-разному внутри использует, а ещё что-то нарушено в порядке Custom Resources будет. И вместо всего этого *тупого* головняка, может, просто etcd бэкап снять?

кстати status и не применится - это сабресурс его нужно определенным способом подпихивать

Так а хоть раз была ситуация, что кто-то зачем-то в etcd заходил? Опять же вопрос проверки разворачивания бекапа непрост - надо или тестировать вот прям сразу же после создания, чтоб воркеры смогли скачать все образы и т.д., либо получается тестирование сферического коня в вакууме. Тогда как cd пайплайны тестируются при каждом использовании. Так что бекапу etcd я лично не доверяю, а вот скриптам развертывания кластера с нуля (т.к стейджи им пересоздаю регулярно) и пайпам, которые в кластер все выкатывают - доверяю. И если че, то новый мастер, в него все деплои дальше воркеров по-очереди к нему переподключить имхо намного надежнее

Плюсую, но как быть с PV? - информация о них хранится в etcd, если её потерять то ты получаешь просто пачку томов с какими-то данными :)

Да. И stateless мы kind of легко сможем парой кнопок в GitLab развернуть обратно, но что делать с кучей хитростей внутри Kubernetes... Нет, даже думать не хочу, бэкапим etcd везде.

Вот только потом тебе нужно будем размышлять о том, в каком порядке всё это восстанавливать. А ещё неизбежно возникнут проблемы с metadata и status field'ами, которые Kubernetes по-разному внутри использует, а ещё что-то нарушено в порядке Custom Resources будет. И вместо всего этого *тупого* головняка, может, просто etcd бэкап снять?

Интересный вопрос. А если еще и кластер большой с кучей неймспейсов, ролей, биндингов, контроллеров и т.д. То нужно огромную кучу пайплайнов выката запустить в нужном порядке. Бэкапить pv и loadbalaner'ы можно, но если поспрашивать, то кто это реально делает?

Loadbalancer как минимум на AWS нормально бэкапятся

А как же status?

Я вот подумываю начать, т.к. задеплоить отдельные PV из json'а явно проще чем развернуть бэкап etcd и пытаться оттуда что-то выковыривать

А всякие настройки на уровне кластера, например ingress контроллеры, оверлей сеть, роли, операторы, сами неймспейсы и сервис аккаунты для них и т.д. У вас хранятся в отдельной репе? Которая выкатывается тоже пайплайном, туда и бэкапить pv и loadbalaner'ы планируете?

В основной всё красивенько в jsonnet описанно, не хочется её засорять

Уже вопрос по другой теме, а как выкатываете основную репу? Инетересуют бест практики на этот счет. У меня пока совсем колхоз, так как с кубом я недавно. Если упрощенно то оно выглядет примерно так: find ./ -name '*.yaml' -exec kubectl apply -f {} \;

Я буду об этом доклад делать :) http://devopsconf.io/moscow/2019/abstracts/5505

А это не ваш доклад, про kubernetes на bare-metal? Там еще про linstor говорилось

Все забывают про сайд-эффекты, которые неизбежно возникают, когда разные контроллеры в кубе взаимодействуют с окружающим миром. Видимо, реальных проблем у них ни разу ещё не возникало, а когда отвалится 40 EBS и 21 LoadBalancer в AWS, так посмотрю я на их развёртывание " с нуля" и скорость этого процесса.

мой)

Уже вопрос по другой теме, а как выкатываете основную репу? Инетересуют бест практики на этот счет. У меня пока совсем колхоз, так как с кубом я недавно. Если упрощенно то оно выглядет примерно так: find ./ -name '*.yaml' -exec kubectl apply -f {} \;

отличный доклад, спасибо. Я как раз выбирал под storage provider что-то, а всякие ceph и glusterfs мне показались слишком тормозными и сложными, и про linstor я не слышал, и тут на мой взгляд неплохое и довольно надежное решение для bare-metal

Потом стейтфулсеты все погасить и подредактировать новые PV на старые EBS volumes. Убить старые ELB и новые ebs volumes

отличный доклад, спасибо. Я как раз выбирал под storage provider что-то, а всякие ceph и glusterfs мне показались слишком тормозными и сложными, и про linstor я не слышал, и тут на мой взгляд неплохое и довольно надежное решение для bare-metal

А чего где смотреть?

На самом деле всё просто, внутри репы есть несколько директорий: /dockerfiles docker images, каждый имеет отдельную директорию, собираются при любом изменени в /dockerfiles с тэгом из git describe для последнего коммита в /dockerfiles, таким образом выполнив git-describe в определённой директории можно всегда получить актуальный тэг для имаджа. /deploy здесь лежат описанные в ksonnet/qbec приложения, каждое приложениие имеет отдельную директорию, и несколько environments. каждый environemnt - это отдельный инстанс приложения задеплоенный в каком-либо кластере. Конкретно сейчас мы имеем два окружения: staging и prod соответсвенно каждое приложение имеет кофигурацию описанную для каждого из них, дальше всё просто: есть две ветки: master и staging. При мердже в стейджинг происходит деплой всего в стейджинг, при мердже в мастер происходит деплой всего в прод.

Интересно, сделано. /deploy - содержит все приложения кластеров? То есть у вас репы самих приложений отдельно, а репа для их деплоя в куб только одна на всех?

Можно бэкапить PV/PVC а при восстановлении их просто залить в etcd-кластер, тогда не нужно будет шаманить с запуском/остановкой statefulset'ов, все они просто подхватят уже существующие PVC

Не уверен, сейтфулсет генерирует PVC из темплейта - как старый PVC подхватится?

Люди, а в чем может быть проблема. Есть 2 namespace внутри каждого своя версия приклада. У каждой версии есть service,ingress, объеденяет их только url по которому они доступны. В одноим из ингресов описано canary : true, canary-wight: 100 в другом этих аннатаций нет, так вот трафик идет на поды, в которых нет аннтаций canary

если убрать uid из claimRef, то подхватит чисто по имени и неймспейсу

Выходит нужно бекапить только PV но не PVC всё таки?

Но ведь pvc старые стейтфулсет не подхватит?