f9874afb2b
Envoy перехватывает исходящий трафик через iptables-правила, которые ставит init-контейнер istio-init. Правила появляются раньше, чем envoy начинает слушать, поэтому приложение, дёрнувшее сеть в первые секунды, получает не таймаут, а connection refused — пакет уже завёрнут на порт envoy, а там ещё никого нет. Так падал workflows-api: контейнер стартовал и умирал в ту же секунду, INFO Starting workflows migrations INFO init database connection... FATAL [dial tcp 10.43.195.4:5432: connect: connection refused] при restartCount=0 у istio-proxy. Со второй попытки envoy успевал, и дальше всё работало — то есть симптомом был ровно один рестарт на старте, который легко списать на случайность. Настройка сделана на уровне mesh, а не аннотацией на поде: уязвимы все, кто ходит в БД или брокер сразу при запуске, а это почти каждый бэкенд контура — django катит migrate первым делом, celery подключается к rabbitmq, workspaces-api и engine-low к postgres. Они не падали не потому, что устроены иначе, а потому что успевали. Цена — каждый под стартует на время готовности envoy дольше, обычно секунду-две: istio добавляет в sidecar postStart-хук, блокирующий запуск остальных контейнеров. На Job'ы не влияет, у них инжекция отключена. Действует в момент инжекции, поэтому на уже запущенные поды не распространяется — хук появится при следующем пересоздании.
9 lines
216 B
YAML
9 lines
216 B
YAML
---
|
|
apiVersion: kustomize.config.k8s.io/v1beta1
|
|
kind: Kustomization
|
|
resources:
|
|
- ../base
|
|
patches:
|
|
# holdApplicationUntilProxyStarts — обоснование в шапке файла.
|
|
- path: istio-pilot.yaml
|