есть связка: deployment, service, ingress, все стандартно. В деплойменте висит веб сервис и все это зацеплено за БД на бекэнде.
В фронт, помимо стандартных хттп запросов приходят еще и апдейты по схеме. Такой апдейт меняет настройки БД и чтоб рефрешнуть веб сервис, его надо рестартовать, чтоб он считал стейт из БД.
Для рестарта все сделано очень просто - апдейт схемы заодно меняет настройку в гите, что триггерит рестарт из аргоцд.
С одной репликой все работает отлично - делаем апдейт, во время рестарта пода есть пара секунд 502, а потом новая схема и новый аутпут.
С двумя происходит херня:
$ while true; do curl https://my-ingress.domain.com; done
old data
old data
old data
old data
<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>
old data
NEW DATA
old data
old data
NEW DATA
NEW DATA
<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
</body>
</html>
<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
</body>
</html>
NEW DATA
NEW DATA
NEW DATA
NEW DATA
Я ожидал что рестарт по дефолтной rollout policy позволит обойтись вообще без провалов сервиса, даже если в начале будет возвращать old data какое то время. Что я упускаю?
добавил readiness и liveness, теперь 504 не попадается, но 502 во время фейловера в течении пары секунд есть. я так понимаю сервис то ли цепляет еще не поднявшийся под то ли не успевает отключить старый под когда он уже в дауне. Как бы точно отследить?
Обсуждают сегодня