Comments 3
Почему K8S продолжает их маршрутизировать на под, который сам же только что остановил? Ну, если коротко, то потому что Kubernetes так работает
Не очень удачная формулировка как мне кажется.
K8S то как раз сразу обновляет свою конфигурацию и говорит, что направлять трафик на завершающий работу pod не надо. Проблема в том, что k8s не ждет когда все компоненты применят эту конфигурацию, т.е. тут у нас eventual consistency в действии.
согласен, здесь дело именно в том, что кубер нельзя рассматривать как одно целое - это набор компонентов, между которыми как раз eventual consistency. один компонент обрабатывает запрос на остановку пода, другой - посылает сигнал процессу, третий - управляет трафиком. хотя с точки зрения каждого отдельного компонента он отработал корректно, с точки зрения внешнего наблюдателя это выглядит как рассинхронизированное состояние. но никто и не давал гарантий, что внутреннее состояние никогда таким не может быть
Браво! Проработка темы на высоте для обновления приложения с миграциями БД без простоя.
Самое ценное в "Итоге", то о чем особо не думают топ менеджмент и архитектора о сложности реализации и поддержки такого ПО. Часто это как Карго культ, потому что Garthner упомянали в брошюре или знакомый CTO из FAANG реализовал у себя ( не упомянув о стоимости внедрения и квалификации команды) а после этого этот же "цирк с конями" пытаются внедрить не учитывая реальную надобность и сложность. Наблюдал такое пару раз в своей практике.
Zero Downtime и Spring Boot. Апдейтим базу