%EC%9D%98%20%EA%B8%B0%EC%9D%B4%ED%95%A8%EC%9D%84%20%EA%B0%96%EC%B6%98%20Azure%20Kubernetes%20Service.png)
AKS Pod/컨테이너를 온프레미스 네트워크에 연결하는 데 몇 가지 문제가 있습니다.
172.16.20.0/22
및 네임스페이스 에 가상 네트워크가 있습니다 172.16.24.0/29
. 여기에는 2개의 서브넷이 있으며 각 서브넷에는 위 범위 중 하나가 서브넷 범위로 포함됩니다.
AKS 클러스터는 172.16.20.0/22
서브넷에 바인딩되어 있으며 각 노드와 Pod는 해당 범위의 IP 주소를 가져옵니다. 또한 임시 디버깅을 위해 이 서브넷에 일반 VM을 추가했습니다.
서브넷 에는 172.16.24.0/29
해당 서브넷을 온프레미스 네트워크에 연결하는 가상 네트워크 게이트웨이(이 서브넷에 IP가 없음)가 있습니다. VN 게이트웨이에는 주소 공간과 일치하는 로컬 네트워크 게이트웨이가 있습니다 172.17.151.0/24
. 로컬 네트워크에는 172.17.151.254
포트 25에서 수신 대기하는 SMTP 서버가 있습니다.
디버깅을 위해 가동한 VM에서는 SMTP 서버에 문제 없이 연결할 수 있습니다. 또한 문제 없이 SMTP 서버에서 VM을 ping할 수도 있습니다. 그러나 포드에서 SMTP에 연결할 수 없으며(으로 테스트 netcat -zv 172.17.151.254 25
) SMTP 서버에서 포드의 IP 주소를 ping할 수도 없습니다.
두 서브넷 모두 NSG(네트워크 보안 그룹)가 연결되어 있지 않으므로 잘못 구성된 NSG 규칙일 수 없습니다. 연결 실패의 원인이 될 수 있는 또 다른 요인은 무엇입니까? 포드는 서브넷의 DHCP 서버에서 동일한 기본 네트워크 구성을 가져옵니다.
- 172.16.20.0/22 IP 주소
- 172.16.20.1을 기본 게이트웨이로 사용
Azure VNG에 연결되는 온프레미스 장치를 유지 관리하는 외부 IT 직원은 디버깅에 도움을 주었습니다. 그들은 SMTP 연결을 시작할 때 172.17.151.254
패킷이 도착하고 서버의 응답 패키지가 VPN 터널로 돌아가는 것을 볼 수 있다고 말합니다. 그래서 응답 패킷이 Azure 어딘가에서 삭제되는 것 같습니다.
편집: IT 직원과의 추가 디버그 세션 동안 우리는 오작동하는 포드에서 나오는 패킷의 소스 IP가 172.17.20.5
대신 이라는 것을 확인했습니다 172.16.20.21
. 172.17.20.5
는 포드가 실행 중인 VMSS 노드의 IP이므로 의미가 있을 수 있지만 이는 해당 노드의 내부 라우팅이 올바르게 구성되지 않았음을 의미합니다.
아니면 이것이 실패하게 만드는 kubernetes와 관련된 문제입니까?
내가 지금까지 시도한 것 :
- VM에서:
172.16.20.21
(포드)에 대한 핑: 잘 작동합니다. - VM에서: ping to
172.17.151.254
: 잘 작동함 - VM에서:
tracert 172.17.151.254
1개의 홉에서 성공(기본 게이트웨이를 통과할 때 최소한 2개의 홉을 표시해야 합니까?) - 포드에서:
172.16.20.4
(vm)에 대한 핑: 잘 작동합니다. - 포드에서: ping 대상
172.17.151.254
: 실패 - 포드에서:
traceroute 172.17.151.254
홉이 표시되지 않고 실패함 - 온프레미스 VPN 장치에서:
172.16.20.4
(vm)에 대한 핑: 잘 작동함 - 온프레미스 VPN 장치:
172.16.20.21
(포드)에 대한 ping: 실패
추가 정보:
ifconfig -a
포드에서:
eth0: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet 172.16.20.21 netmask 255.255.252.0 broadcast 0.0.0.0
ether de:c7:74:e3:c5:24 txqueuelen 1000 (Ethernet)
RX packets 386868 bytes 35746728 (34.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 511891 bytes 43865660 (41.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 5 bytes 504 (504.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5 bytes 504 (504.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
route
포드의 출력:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.20.1 0.0.0.0 UG 0 0 0 eth0
172.16.20.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
ipconfig /all
디버그 VM에서:
Windows IP Configuration
Host Name . . . . . . . . . . . . : debug-vm
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : nedz0ha4spbubmi5cnxgsnswdh.ax.internal.cloudapp.net
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . : nedz0ha4spbubmi5cnxgsnswdh.ax.internal.cloudapp.net
Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Physical Address. . . . . . . . . : 00-0D-3A-2D-DC-BA
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::e9bb:fede:66cc:398c%6(Preferred)
IPv4 Address. . . . . . . . . . . : 172.16.20.4(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.252.0
Lease Obtained. . . . . . . . . . : Friday, August 28, 2020 7:15:08 AM
Lease Expires . . . . . . . . . . : Friday, October 8, 2156 1:20:49 PM
Default Gateway . . . . . . . . . : 172.16.20.1
DHCP Server . . . . . . . . . . . : 168.63.129.16
DHCPv6 IAID . . . . . . . . . . . : 100666682
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-26-DA-67-54-00-0D-3A-2D-DC-BA
DNS Servers . . . . . . . . . . . : 168.63.129.16
NetBIOS over Tcpip. . . . . . . . : Enabled
route print
디버그 VM에서:
===========================================================================
Interface List
6...00 0d 3a 2d dc ba ......Microsoft Hyper-V Network Adapter
1...........................Software Loopback Interface 1
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.20.1 172.16.20.4 10
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
168.63.129.16 255.255.255.255 172.16.20.1 172.16.20.4 11
169.254.169.254 255.255.255.255 172.16.20.1 172.16.20.4 11
172.16.20.0 255.255.252.0 On-link 172.16.20.4 266
172.16.20.4 255.255.255.255 On-link 172.16.20.4 266
172.16.23.255 255.255.255.255 On-link 172.16.20.4 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 172.16.20.4 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 172.16.20.4 266
===========================================================================
Persistent Routes:
None
IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
1 331 ::1/128 On-link
6 266 fe80::/64 On-link
6 266 fe80::e9bb:fede:66cc:398c/128
On-link
1 331 ff00::/8 On-link
6 266 ff00::/8 On-link
===========================================================================
Persistent Routes:
None
답변1
이 문제는 Microsoft 지원의 도움을 받아 광범위한 문제 해결 후에 발견되었습니다.
근본 원인은 에 있는 SMTP 서버(VPN 엔드포인트)의 IP 주소였으며 , 이는 K8S 노드에 구성된 172.17.151.254
기본 도커 브리지 네트워크와 겹칩니다 . 172.17.0.0/16
내가 시작한 디버그 VM에는 이 측면이 없었기 때문에 문제가 나타나지 않았습니다.
교훈: 172.17.0.0/16
AKS를 사용할 때 사격장 에서 멀리 떨어지십시오.