Проверка готовности и Apache Common Http Client

Question

У меня есть простая установка OpenShift с Сервисом, настроенным с 2 внутренними PODS. PODS настроен для проверки готовности. Сервис предоставляется через NodePort. Все эти настройки в порядке, он работает как положено. После сбоя проверки готовности службы помечают модуль как недоступный, и любые НОВЫЕ запросы не направляются в POD.

Сценарий 1: Я выполняю команду CURL для доступа к службам. Пока выполняется команда curl, я ввожу ошибку готовности Pod-1. Я вижу, что на Pod -1 не отправляются новые запросы. Это FINE

Сценарий 2: Я хава Java Клиент и использую клиентскую библиотеку Apache Commons Http для инициации соединения со службой Kubernetes. Соединение устанавливается и работает нормально. Проблема возникает, когда я представляю готовность к отказу от Pod-1. Я все еще вижу, что Клиент отправляет запросы только на Pod-1, хотя у Сервисов есть только конечная точка Pod-2.

Моя догадка, так как HttpClient использует постоянное соединение и службы при отображении через NodePorts, адрес назначения для соединения Http - это сам POD-1. Поэтому, даже если проверка готовности не пройдена, он все равно отправляет запросы в Pod-1.

Может кто-нибудь объяснить, почему это работает, как описано выше ??

Answer 1

kube-proxy (или, скорее, правила iptables, которые он генерирует) преднамеренно не закрывает существующие TCP-соединения при изменении сопоставления конечной точки (что и будет вызывать сбой проверки готовности). За многие годы это много обсуждалось на многих билетах, и, как правило, было мало единого мнения о том, следует ли изменить поведение. На данный момент лучше всего вместо этого использовать Ingress Controller для HTTP-трафика c, поскольку все они обновляют в реальном времени и обходят kube-proxy. Вы также можете отправить обратно Keep-Alive заголовок в ваших ответах и ​​разорвать постоянные соединения через N секунд или запросов, хотя это только сокращает окно для плохой работы.