Kubernetes: LoadBalancer задерживает маршрутизацию к модулям после RollingUpdate

Созданный на 5 дек. 2016  ·  3Комментарии  ·  Источник: kubernetes/kubernetes

Это просьба о помощи? (Если да, воспользуйтесь нашим руководством по устранению неполадок и каналами поддержки сообщества, см. http://kubernetes.io/docs/troubleshooting/.):
Нет

По каким ключевым словам вы искали в проблемах Kubernetes, прежде чем отправить эту? (Если вы нашли какие-либо дубликаты, вы должны вместо этого ответить там.):

https://github.com/kubernetes/kubernetes/issues?page=3&q=is%3Aissue+is%3Aopen+loadbalancer+update&utf8=%E2%9C%93


Это ОТЧЕТ ОБ ОШИБКЕ или ЗАПРОС ФУНКЦИИ? (Выбери один):
Отчет об ошибке

Версия Kubernetes (используйте kubectl version ):
Клиент 1.4.4
Кластер 1.4.6

Окружающая среда :

  • Облачный провайдер или аппаратная конфигурация : GKE
  • ОС (например, из /etc/os-release):
  • Ядро (например, uname -a ):
  • Установить инструменты :
  • Другие :
    Кластер из 3 узлов

Что произошло :
Примените скользящее обновление, посмотрите, как новые модули переходят в состояние «Работает» и «Готово», а старые модули прекращают работу.
Приводит к тайм-аутам при попадании в балансировщик нагрузки. Подождите несколько минут, и трафик будет направлен правильно.

Что вы ожидали :
Трафик легко направляется на новые модули.

Как это воспроизвести (минимально и точно):
https://gist.github.com/1d668ba12b12f450e8feffb21383ba44

kubectl apply -f deployment.yaml
kubectl get svc , дождитесь появления внешнего IP-адреса.
Следите за тем, чтобы трафик направлялся правильно.

Отредактируйте что-нибудь (например, переменную среды)
kubectl apply -f deployment.yaml
Подождите, пока старые поды будут завершены. Соблюдайте тайм-ауты, пока балансировщик нагрузки не обновится.

Что еще нам нужно знать :

Самый полезный комментарий

Подтвержденный. Сочетание слива и проверки готовности привело к нулевому времени простоя:
https://gist.github.com/ac98158ccfd0c006de0bb0bc7d31a596

Извините за ошибочный отчет.

Все 3 Комментарий

Я думаю, что завершение работы pod’ов по умолчанию приведет к сбою запросов, поскольку в Kubernetes нет «слива соединения» — вам придется вручную переключать проверку готовности приложения «как раз вовремя»: https://github.com/RisingStack/ kubernetes-изящный-выключение-пример

Не уверен, что это ваша проблема (не видите источник вашего приложения/образа Docker).

Исходный код приложения:
https://gist.github.com/d68192f04e3ff50bf9bf7e90ee879077

Я попробую изменить исходный код, чтобы слить запросы. Имеет смысл, что это может быть проблемой.

Подтвержденный. Сочетание слива и проверки готовности привело к нулевому времени простоя:
https://gist.github.com/ac98158ccfd0c006de0bb0bc7d31a596

Извините за ошибочный отчет.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги