#azure #kubernetes #azure-aks #azure-container-instances
#лазурь #кубернетес #лазурный-акс #экземпляры контейнеров azure
Вопрос:
Я пытаюсь развернуть SFTP-сервер с помощью python / paramiko в AKS.
Это успешно развернуто на сервере разработки с голым металлом, однако у меня возникли проблемы с развертыванием этого в AKS.
Проблема возникает при создании службы балансировки нагрузки, это вызывает поток TCP-трафика на целевом порту, что делает SFTP — сервер бесполезным.
Ожидается ли это? Я нахожусь на пределе того, как работают внутренние компоненты AKS, поэтому я не хочу предполагать, что это ошибка, но я хотел бы знать, где я могу ошибаться.
Приведенный ниже код воспроизводит проблему в недавно подготовленной среде AKS с использованием nast сетевого анализатора. Выполните первую команду для запуска nast, а затем создайте службу балансировки нагрузки с помощью отдельной консоли:
kubectl run -it --rm --restart=Never --image=ubuntu --labels="app=debug-pod" debug-pod -- bash -c "apt-get update amp;amp; apt-get install -y nast amp;amp; nast" cat lt;lt;EOF | kubectl apply -f - apiVersion: v1 kind: Service metadata: name: debug-service namespace: default spec: type: LoadBalancer selector: app: debug-pod ports: - name: sftp protocol: TCP port: 34567 targetPort: 45678 EOF Пример трафика, наблюдаемого через ~ 10 секунд после создания балансировщика нагрузки, со скоростью несколько раз в секунду:
Nast V. 0.2.0 Sniffing on: - Device: eth0 - MAC address: 66:4E:3B:41:F3:7B - IP address: 10.244.0.61 - Netmask: 255.255.255.0 - Promisc mode: Set - Filter: None - Logging: None ---[ ARP ]----------------------------------------------------------- 2A:8E:A8:C9:D3:1E -gt; 66:4E:3B:41:F3:7B Type: ARP request: Who has 10.244.0.61? Tell 10.244.0.1 Hardware size: 6 - Protocol size: 4 Packet Number: 1 ---[ ARP ]----------------------------------------------------------- 66:4E:3B:41:F3:7B -gt; 2A:8E:A8:C9:D3:1E Type: ARP reply: 10.244.0.61 is at 66:4E:3B:41:F3:7B Hardware size: 6 - Protocol size: 4 Packet Number: 2 ---[ TCP ]----------------------------------------------------------- 10.240.0.7:64618(unknown) -gt; 10.244.0.61:45678(unknown) TTL: 126 Window: 8192 Version: 4 Length: 52 FLAGS: -S----- SEQ: 2330618374 - ACK: 0 Packet Number: 5 ---[ TCP ]----------------------------------------------------------- 10.244.0.61:45678(unknown) -gt; 10.240.0.7:64618(unknown) TTL: 64 Window: 0 Version: 4 Length: 40 FLAGS: --R-A-- SEQ: 0 - ACK: 2330618375 Packet Number: 6 ---[ TCP ]----------------------------------------------------------- 10.240.0.7:31026(unknown) -gt; 10.244.0.61:45678(unknown) TTL: 126 Window: 8192 Version: 4 Length: 52 FLAGS: -S----- SEQ: 2330618374 - ACK: 0 Packet Number: 7 ---[ TCP ]----------------------------------------------------------- 10.244.0.61:45678(unknown) -gt; 10.240.0.7:31026(unknown) TTL: 64 Window: 0 Version: 4 Length: 40 FLAGS: --R-A-- SEQ: 0 - ACK: 2330618375 Packet Number: 8 ---[ TCP ]----------------------------------------------------------- 10.240.0.7:52540(unknown) -gt; 10.244.0.61:45678(unknown) TTL: 126 Window: 8192 Version: 4 Length: 48 FLAGS: -S----- SEQ: 2330618374 - ACK: 0 Packet Number: 9 ---[ TCP ]----------------------------------------------------------- 10.244.0.61:45678(unknown) -gt; 10.240.0.7:52540(unknown) TTL: 64 Window: 0 Version: 4 Length: 40 FLAGS: --R-A-- SEQ: 0 - ACK: 2330618375 Packet Number: 10 ---[ TCP ]----------------------------------------------------------- 10.240.0.6:32242(unknown) -gt; 10.244.0.61:45678(unknown) TTL: 126 Window: 8192 Version: 4 Length: 52 FLAGS: -S----- SEQ: 2102210393 - ACK: 0 Packet Number: 11 ---[ TCP ]----------------------------------------------------------- 10.244.0.61:45678(unknown) -gt; 10.240.0.6:32242(unknown) TTL: 64 Window: 0 Version: 4 Length: 40 FLAGS: --R-A-- SEQ: 0 - ACK: 2102210394 Packet Number: 12 ---[ TCP ]----------------------------------------------------------- 10.240.0.6:27550(unknown) -gt; 10.244.0.61:45678(unknown) TTL: 126 Window: 8192 Version: 4 Length: 52 FLAGS: -S----- SEQ: 2102210393 - ACK: 0 Packet Number: 13 ---[ TCP ]----------------------------------------------------------- 10.244.0.61:45678(unknown) -gt; 10.240.0.6:27550(unknown) TTL: 64 Window: 0 Version: 4 Length: 40 FLAGS: --R-A-- SEQ: 0 - ACK: 2102210394 Packet Number: 14 ---[ TCP ]----------------------------------------------------------- 10.240.0.6:65391(unknown) -gt; 10.244.0.61:45678(unknown) TTL: 126 Window: 8192 Version: 4 Length: 48 FLAGS: -S----- SEQ: 2102210393 - ACK: 0 Packet Number: 15 ---[ TCP ]----------------------------------------------------------- 10.244.0.61:45678(unknown) -gt; 10.240.0.6:65391(unknown) TTL: 64 Window: 0 Version: 4 Length: 40 FLAGS: --R-A-- SEQ: 0 - ACK: 2102210394 Packet Number: 16 ---[ TCP ]----------------------------------------------------------- 10.240.0.7:18224(unknown) -gt; 10.244.0.61:45678(unknown) TTL: 126 Window: 8192 Version: 4 Length: 52 FLAGS: -S----- SEQ: 2517447963 - ACK: 0 Packet Number: 17 ---[ TCP ]----------------------------------------------------------- 10.244.0.61:45678(unknown) -gt; 10.240.0.7:18224(unknown) TTL: 64 Window: 0 Version: 4 Length: 40 FLAGS: --R-A-- SEQ: 0 - ACK: 2517447964 Packet Number: 18 Ответ №1:
Хост в 10.240.0.7 пытается подключиться к порту 45678 IP 10.240.0.7. Этот хост сообщает, что порт не открыт. Процесс повторяется.
Ваша проблема в том, что процесс не прослушивает порт 45678.
Комментарии:
1. Спасибо. У меня есть несколько дополнительных вопросов. 10.240.0.7-это IP-адрес одного из узлов кластера. Мне любопытно, почему узел пытается связаться с помощью этой службы, поскольку я этого не ожидаю. Кроме того, почему это должно произойти на AKS, а не на моем кластере с голым металлом?
2. @BellyBuster — Исходя из информации в вашем вопросе, я не могу ответить, почему происходит трафик. У вас есть процесс, который пытается подключиться к порту 45678, но ничто не прослушивает эти попытки подключения.
Ответ №2:
Я решил эту проблему, установив externalTrafficPolicy: Local в службе балансировки нагрузки, а не значение по умолчанию Cluster .