И респосибилити размазан

Накостылят автоматизированного говна, а потом состояние инфраструктуры наглухо переплетено с состоянием приложения

Господа, а чтобы исходящий из подов  в интернет трафик завернуть в http proxy, куда нужно прописать настройки? в обычном случае работает с /root/.docker/config.json. Это корректный путь, или в кубе не так?

Накостылят автоматизированного говна, а потом состояние инфраструктуры наглухо переплетено с состоянием приложения

Тема та же самая -- вы лезете автоматизированной тулзой в источник истины о состоянии инфраструктуры

да даже не автоматически. У меня прогеры бывает навертят такого, что без тегов, они своими силами просто не могут привести ветку к виду, как она была в прошлой версии. 500 коммитов недавно вот выкатили 😁.

Если откат = откат кода в репозоитории до прошлого состояния. То как это сделать, если они даже не знают, на каком комите было прошлое состояние?
Каким образом тегировать образы? Или любимое imagePullPolicy: Always + timestamp в env?

Сори, я видимо не совсем понял всю задумку целиком, если распишешь как это в целом выглядит, будет круто. На примере одного сервиса
1) как организованы репы
2) Как происходит сборка образов , тегирование, и пуш их в registry
3) Как происходит деплой и откат на предыдущую версию

да даже не автоматически. У меня прогеры бывает навертят такого, что без тегов, они своими силами просто не могут привести ветку к виду, как она была в прошлой версии. 500 коммитов недавно вот выкатили 😁.

Если откат = откат кода в репозоитории до прошлого состояния. То как это сделать, если они даже не знают, на каком комите было прошлое состояние?
Каким образом тегировать образы? Или любимое imagePullPolicy: Always + timestamp в env?

Сори, я видимо не совсем понял всю задумку целиком, если распишешь как это в целом выглядит, будет круто. На примере одного сервиса
1) как организованы репы
2) Как происходит сборка образов , тегирование, и пуш их в registry
3) Как происходит деплой и откат на предыдущую версию

Либо в каждый под прописывай энв http_proxy

Для этого автосквош есть :) Но кодеры вообще тут не при чём. У вас должно быть две репы, для инфраструктуры и для кода, отдельно

1) Кодер херачит код в мастер
2) Ставит новый тег
3) Идёт и выставляет в репе инфры новый тег
4) Коммитит
5) CI запускает деплой
6) Если во время деплоя возникают проблемы, то загорается alert
7) Дежурный разработчик лезет смотреть что сломалось
8) По завершении дебага делает реверт в гите инфраструктуры

Для этого автосквош есть :) Но кодеры вообще тут не при чём. У вас должно быть две репы, для инфраструктуры и для кода, отдельно

1) Кодер херачит код в мастер
2) Ставит новый тег
3) Идёт и выставляет в репе инфры новый тег
4) Коммитит
5) CI запускает деплой
6) Если во время деплоя возникают проблемы, то загорается alert
7) Дежурный разработчик лезет смотреть что сломалось
8) По завершении дебага делает реверт в гите инфраструктуры

Пункт 8 должен раньше отработать

Любители gitdb предлагают 6-8 заменить на ссаного робота, который ничего не дебажит, а просто откатывает