Контекст:
Недавно я столкнулся с проблемой, из-за которой модуль kubernetes (черный ящик-экспортер) будет получать пустой ответ всякий раз, когда он пытается вызвать входной URL-адрес модуля, который находится в том же узле, что и он сам. Это отражалось в виде периодически выходящего из строя датчика на приборной панели.
В качестве входного контроллера используется ingress-nginx, который находится за AWS NLB.
Пример:
узел 1: 192.168.20.2
узел2: 192.168.20.3
узел 3: 192.166.20.4
blackbox-exporter (развернут в node1, с clusterIP 10.244.2.21)
foo-pod (развернут в node1, с IP-адресом кластера 10.244.2.22)
foo-pod (развернут в node2, с IP-адресом кластера 10.244.2.23)
foo-pod (развернут в node3, с IP-адресом кластера 10.244.2.24)
Логи Ingress-контроллера:
192.168.20.3 - - [21/Jun/2021:15:15:07 +0000] "GET /metrics HTTP/1.1" 200 29973 "-" "curl/7.47.0" 90 0,005 [foo-pod] [] 10,32 .0.2:3000 30015 0,004 200 e39022b47e857cc48eb6a127a7b8ce24
192.168.20.4 - - [21/Jun/2021:15:16:00 +0000] "GET /metrics HTTP/1.1" 200 29973 "-" "curl/7.47.0" 90 0,005 [foo-pod] [] 10,32 .0.2:3000 30015 0,004 200 e39022b47e857cc48eb6a127a7b8ce24
192.168.20.3 - - [21/Jun/2021:15:16:30 +0000] "GET /metrics HTTP/1.1" 200 29973 "-" "curl/7.47.0" 90 0,005 [foo-pod] [] 10,32 .0.2:3000 30015 0,004 200 e39022b47e857cc48eb6a127a7b8ce24
Отслеживание журналов контроллера входящего трафика показало, что «пустой ответ» (время ожидания после 5 с) возникает только в том случае, если модуль, выполняющий входящий вызов URL-адреса, развернут на том же узле, что и целевой модуль, который должен отвечать на этот вызов.
Вывод был сделан на основании того факта, что всякий раз, когда был получен «пустой ответ», никогда не существует журнала с IP-адресом источника, совпадающим с IP-адресом узла, в котором находится черный ящик-экспортер, в данном случае это должен быть node1. 192.168.20.2.
Подозревая, что это связано с «неправильным» исходным IP-адресом, и в результате целевой модуль не знает, как вернуть ответ, я переключился на использование AWS Classic L7 LB, и проблема решена.
Теперь журналы показали, что исходный IP-адрес заменен фактическим ClusterIP-адресом пода, и все пробные вызовы от Blackbox-Exporter прошли успешно.
10.244.2.21 - - [21/Jun/2021:15:15:07 +0000] "GET /metrics HTTP/1.1" 200 29973 "-" "curl/7.47.0" 90 0,005 [foo-pod] [] 10,32 .0.2:3000 30015 0,004 200 e39022b47e857cc48eb6a127a7b8ce24
10.244.2.21 - - [21/Jun/2021:15:16:00 +0000] "GET /metrics HTTP/1.1" 200 29973 "-" "curl/7.47.0" 90 0,005 [foo-pod] [] 10,32 .0.2:3000 30015 0,004 200 e39022b47e857cc48eb6a127a7b8ce24
10.244.2.21 - - [21/Jun/2021:15:16:30 +0000] "GET /metrics HTTP/1.1" 200 29973 "-" "curl/7.47.0" 90 0,005 [foo-pod] [] 10,32 .0.2:3000 30015 0,004 200 e39022b47e857cc48eb6a127a7b8ce24
Дополнительная информация:
Версия кластера: AWS EKS v1.19
Вопрос:
Сеть Linux/kubernetes не является моей сильной стороной, поэтому я хотел бы спросить, что именно здесь происходит?
Почему переход на использование балансировщика нагрузки AWS Classic L7 решает проблему?
могут ли какие-либо другие компоненты (kubernetes ИЛИ linux) влиять на это?
