AKS LoadBalancer 服务创建虚假网络流量

Question

我正在尝试使用 python / paramiko 将 SFTP 服务器部署到 AKS 中。

这已成功部署到裸机开发服务器中，但是我在将其部署到 AKS 中时遇到问题。

问题在创建 LoadBalancer 服务时开始，这会在目标端口上触发大量 TCP 流量，从而导致 SFTP 服务器无法使用。

这是预期的吗？我处于 AKS 内部工作方式的极限，所以我不想假设这是一个错误，但我想知道我可能哪里出错了。

下面的代码使用 nast 网络嗅探器在新配置的 AKS 环境中重现了该问题。运行第一个启动 nast 的命令，然后在单独的控制台中使用创建负载均衡器服务：

kubectl run -it --rm --restart=Never --image=ubuntu --labels="app=debug-pod" debug-pod -- bash -c "apt-get update && apt-get install -y nast && nast"

cat <<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

以每秒几个的速率创建 LoadBalancer ~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 -> 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 -> 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) -> 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) -> 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) -> 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) -> 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) -> 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) -> 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) -> 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) -> 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) -> 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) -> 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) -> 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) -> 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) -> 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) -> 10.240.0.7:18224(unknown)
TTL: 64         Window: 0       Version: 4      Length: 40
FLAGS: --R-A--  SEQ: 0 - ACK: 2517447964
Packet Number: 18

Answer 1

位于 10.240.0.7 的主机正在尝试连接到 IP 10.240.0.7 端口 45678。该主机报告该端口未打开。重复该过程。

你的问题是没有进程监听45678端口

Answer 2

我通过在 LoadBalancer 服务中设置 externalTrafficPolicy: Local 而不是默认值 Cluster 解决了这个问题。

AKS LoadBalancer 服务创建虚假网络流量

AKS LoadBalancer service creating spurious network traffic

azure

kubernetes

azure-container-instances

azure-aks