Ssoon
[3주차] Pod ↔ Pod 통신 본문
CloudNet@ 가시다님이 진행하는 쿠버네티스 네트워크 스터디 3기
✅ Pod 생성 전 Node (k8s-w1) 기본 정보 확인
🧿 tunl0은 터널링(Tunneling) 인터페이스로, IP 패킷을 터널을 통해 다른 네트워크로 전송
- ipip any remote any local any ttl inherit nopmtudisc: IPIP 터널이 모든 원격 및 로컬 주소를 허용
- inet 172.16.158.0/32 scope global tunl0: 172.16.158.0이라는 IP 주소가 tunl0 인터페이스에 할당
- calicb4ed55b4b9, cali2be985c66eb, calia0e6ec9deb6이라는 세 개의 네트워크 인터페이스에 대한 정보를 제공합니다. 각각의 인터페이스는 특정 네트워크 네임스페이스에 속하며, 링크-로컬 IPv6 주소를 가지고 있습니다.
root@k8s-w1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 02:61:e5:44:e0:63 brd ff:ff:ff:ff:ff:ff
altname enp0s5
inet 192.168.10.101/24 metric 100 brd 192.168.10.255 scope global dynamic ens5
valid_lft 3516sec preferred_lft 3516sec
inet6 fe80::61:e5ff:fe44:e063/64 scope link
valid_lft forever preferred_lft forever
3: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 8981 qdisc noqueue state UNKNOWN group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
inet 172.16.158.0/32 scope global tunl0
valid_lft forever preferred_lft forever
6: calicb4ed55b4b9@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8981 qdisc noqueue state UP group default qlen 1000
link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netns cni-d93700f6-c577-7867-f375-a357486a62a6
inet6 fe80::ecee:eeff:feee:eeee/64 scope link
valid_lft forever preferred_lft forever
7: cali2be985c66eb@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8981 qdisc noqueue state UP group default qlen 1000
link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netns cni-d18e3294-ab32-7eb5-c9f6-98442e7b0aa9
inet6 fe80::ecee:eeff:feee:eeee/64 scope link
valid_lft forever preferred_lft forever
8: calia0e6ec9deb6@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8981 qdisc noqueue state UP group default qlen 1000
link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netns cni-4e0bcb88-8caa-eaba-c794-da08b8a18d84
inet6 fe80::ecee:eeff:feee:eeee/64 scope link
valid_lft forever preferred_lft forever- 현재 활성화된 네트워크 네임스페이스를 확인합니다.
root@k8s-w1:~# lsns -t net
NS TYPE NPROCS PID USER NETNSID NSFS COMMAND
4026531840 net 136 1 root unassigned /sbin/init
4026532280 net 2 4172 65535 2 /run/netns/cni-4e0bcb88-8caa-eaba-c794-da08b8a18d84 /pause
4026532337 net 2 4067 65535 1 /run/netns/cni-d18e3294-ab32-7eb5-c9f6-98442e7b0aa9 /pause
4026532388 net 2 3962 65535 0 /run/netns/cni-d93700f6-c577-7867-f375-a357486a62a6 /pause
- 172.16.34.0/24 via 192.168.20.100 dev tunl0 proto bird onlink
- 172.16.34.0/24 네트워크로 가는 트래픽은 192.168.20.100을 경유해 tunl0 인터페이스를 통해 전달됨.
- 172.16.116.0/24 via 192.168.10.10 dev tunl0 proto bird onlink
- 172.16.116.0/24 네트워크로 가는 트래픽은 192.168.10.10을 경유해 tunl0 인터페이스를 통해 전달됨.
- blackhole 172.16.158.0/24 proto bird
- 172.16.158.0/24 네트워크로의 모든 트래픽은 무시됨 (블랙홀).
- 172.16.184.0/24 via 192.168.10.102 dev tunl0 proto bird onlink
- 172.16.184.0/24 네트워크로 가는 트래픽은 192.168.10.102을 경유해 tunl0 인터페이스를 통해 전달됨.
root@k8s-w1:~# ip -c route | grep bird
172.16.34.0/24 via 192.168.20.100 dev tunl0 proto bird onlink
172.16.116.0/24 via 192.168.10.10 dev tunl0 proto bird onlink
blackhole 172.16.158.0/24 proto bird
172.16.184.0/24 via 192.168.10.102 dev tunl0 proto bird onlink
- 172.16.34.0 192.168.20.100 255.255.255.0 UG 0 0 0 tunl0
- 172.16.34.0/24 네트워크로의 트래픽은 192.168.20.100을 게이트웨이로 사용하여 tunl0 인터페이스를 통해 전달
- 172.16.116.0 192.168.10.10 255.255.255.0 UG 0 0 0 tunl0
- 172.16.116.0/24 네트워크로의 트래픽은 192.168.10.10을 게이트웨이로 사용하여 tunl0 인터페이스를 통해 전달
- 172.16.158.1 0.0.0.0 255.255.255.255 UH 0 0 0 calicb4ed55b4b9
- 172.16.158.1 IP 주소는 calicb4ed55b4b9 인터페이스를 통해 직접 연결됨 (특정 호스트용 경로).
- 172.16.158.2 0.0.0.0 255.255.255.255 UH 0 0 0 cali2be985c66eb
- 172.16.158.2 IP 주소는 cali2be985c66eb 인터페이스를 통해 직접 연결됨 (특정 호스트용 경로).
- 172.16.158.3 0.0.0.0 255.255.255.255 UH 0 0 0 calia0e6ec9deb6
- 172.16.158.3 IP 주소는 calia0e6ec9deb6 인터페이스를 통해 직접 연결됨 (특정 호스트용 경로).
- 172.16.184.0 192.168.10.102 255.255.255.0 UG 0 0 0 tunl0
- 172.16.184.0/24 네트워크로의 트래픽은 192.168.10.102을 게이트웨이로 사용하여 tunl0 인터페이스를 통해 전달
root@k8s-w1:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.10.1 0.0.0.0 UG 100 0 0 ens5
172.16.34.0 192.168.20.100 255.255.255.0 UG 0 0 0 tunl0
172.16.116.0 192.168.10.10 255.255.255.0 UG 0 0 0 tunl0
172.16.158.0 0.0.0.0 255.255.255.0 U 0 0 0 *
172.16.158.1 0.0.0.0 255.255.255.255 UH 0 0 0 calicb4ed55b4b9
172.16.158.2 0.0.0.0 255.255.255.255 UH 0 0 0 cali2be985c66eb
172.16.158.3 0.0.0.0 255.255.255.255 UH 0 0 0 calia0e6ec9deb6
172.16.184.0 192.168.10.102 255.255.255.0 UG 0 0 0 tunl0
192.168.0.2 192.168.10.1 255.255.255.255 UGH 100 0 0 ens5
192.168.10.0 0.0.0.0 255.255.255.0 U 100 0 0 ens5
192.168.10.1 0.0.0.0 255.255.255.255 UH 100 0 0 ens5✅ Pod 배포 후 상태 확인
- Node (k8s-w1)에 파드 2개 생성
(⎈|SsoonLab:N/A) root@k8s-m:~# cat node1-pod2.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod1
spec:
nodeName: k8s-w1 # 노드의 호스트이름을 직접 지정했습니다
containers:
- name: pod1
image: nicolaka/netshoot # 이미지는 네트워크 장애 처리에 유용한 이미지를 사용합니다
command: ["tail"]
args: ["-f", "/dev/null"]
terminationGracePeriodSeconds: 0
---
apiVersion: v1
kind: Pod
metadata:
name: pod2
spec:
nodeName: k8s-w1
containers:
- name: pod2
image: nicolaka/netshoot
command: ["tail"]
args: ["-f", "/dev/null"]
terminationGracePeriodSeconds: 0- k8s-w1 노드에서 실행 중인 두 개의 파드(pod1과 pod2)에 대한 네트워크 설정
(⎈|SsoonLab:N/A) root@k8s-m:~# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod1 1/1 Running 0 48s 172.16.158.4 k8s-w1 <none> <none>
pod2 1/1 Running 0 48s 172.16.158.5 k8s-w1 <none> <none>
(⎈|SsoonLab:N/A) root@k8s-m:~# calicoctl get workloadEndpoint
WORKLOAD NODE NETWORKS INTERFACE
pod1 k8s-w1 172.16.158.4/32 calice0906292e2
pod2 k8s-w1 172.16.158.5/32 calibd2348b4f67- Kubernetes 클러스터 내에서 생성된 두 개의 네트워크 인터페이스(calice0906292e2와 calibd2348b4f67)의 상태와 설정을 확인합니다.
- 두 인터페이스 모두 활성화되어 있으며, 브로드캐스트 및 멀티캐스트를 지원하고, 각 인터페이스는 고유한 네트워크 네임스페이스에 속해 있습니다
root@k8s-w1:~# ip -c link
...
9: calice0906292e2@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8981 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netns cni-4155a966-a6ea-9af1-27af-761cef31e313
10: calibd2348b4f67@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8981 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netns cni-b8882b29-e9f4-2b1f-fc53-c4bd9e4c336a- 두 개의 네트워크 네임스페이스가 생성되었으며, 각 네임스페이스는 특정 컨테이너(또는 파드)의 네트워크 환경을 관리하고 있습니다. 각 네임스페이스는 독립적으로 네트워크 설정을 갖추고 있으며, 해당 네임스페이스 내에서 pause 프로세스가 실행되고 있습니다.
root@k8s-w1:~# lsns -t net
NS TYPE NPROCS PID USER NETNSID NSFS COMMAND
...
4026532230 net 2 36194 65535 3 /run/netns/cni-4155a966-a6ea-9af1-27af-761cef31e313 /pause
4026532472 net 2 36209 65535 4 /run/netns/cni-b8882b29-e9f4-2b1f-fc53-c4bd9e4c336a /pause🧿 Pod1 에 접속하여 네트워크 인터페이스 정보를 확인
- tunl0: 비활성 상태의 IP-in-IP 터널 인터페이스입니다.
- eth0: 활성화된 네트워크 인터페이스로, 브로드캐스트와 멀티캐스트를 지원하며, IP 주소 172.16.158.4 할당되어 있습니다.
(⎈|SsoonLab:N/A) root@k8s-m:~# kubectl exec pod1 -it -- zsh
dP dP dP
88 88 88
88d888b. .d8888b. d8888P .d8888b. 88d888b. .d8888b. .d8888b. d8888P
88' `88 88ooood8 88 Y8ooooo. 88' `88 88' `88 88' `88 88
88 88 88. ... 88 88 88 88 88. .88 88. .88 88
dP dP `88888P' dP `88888P' dP dP `88888P' `88888P' dP
Welcome to Netshoot! (github.com/nicolaka/netshoot)
Version: 0.13
pod1 ~ ip -c addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host proto kernel_lo
valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
3: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8981 qdisc noqueue state UP group default qlen 1000
link/ether fe:cd:4a:af:3c:68 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.16.158.4/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::fccd:4aff:feaf:3c68/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever- 0.0.0.0 169.254.1.1 0.0.0.0 UG 0 0 0 eth0
- 모든 트래픽은 169.254.1.1 게이트웨이를 통해 eth0 인터페이스로 전송됩니다.
- 169.254.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
- 169.254.1.1 주소로의 트래픽은 eth0 인터페이스를 통해 직접 처리됩니다.
- 169.254.1.1
- 링크 로컬 주소의 범위에 속합니다. 이 주소는 일반적으로 APIPA (Automatic Private IP Addressing) 라고도 불리며, 특정 상황에서 자동으로 할당됩니다.
- 주소 범위: 169.254.0.0부터 169.254.255.255까지
- 네트워크에서 DHCP 서버가 없거나 IP 주소를 받을 수 없을 때 자동으로 할당되는 주소입니다.
- 네트워크 장비가 네트워크에 연결되었지만 DHCP 서버로부터 IP 주소를 받지 못했을 때, 장비는 이 링크 로컬 범위의 IP 주소를 자동으로 할당하여 기본적인 통신을 시도합니다.
- ARP 정보가 없음을 확인합니다.
pod1 ~ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 169.254.1.1 0.0.0.0 UG 0 0 0 eth0
169.254.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
pod1 ~ ip -c neigh
🧿 Pod2 에 접속하여 네트워크 인터페이스 정보를 확인
- tunl0: 비활성 상태의 IP-in-IP 터널 인터페이스입니다.
- eth0: 활성화된 네트워크 인터페이스로, 브로드캐스트와 멀티캐스트를 지원하며, IP 주소 172.16.158.5 할당되어 있습니다.
(⎈|SsoonLab:N/A) root@k8s-m:~# kubectl exec pod2 -it -- zsh
dP dP dP
88 88 88
88d888b. .d8888b. d8888P .d8888b. 88d888b. .d8888b. .d8888b. d8888P
88' `88 88ooood8 88 Y8ooooo. 88' `88 88' `88 88' `88 88
88 88 88. ... 88 88 88 88 88. .88 88. .88 88
dP dP `88888P' dP `88888P' dP dP `88888P' `88888P' dP
Welcome to Netshoot! (github.com/nicolaka/netshoot)
Version: 0.13
pod2 ~ ip -c addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host proto kernel_lo
valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
3: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8981 qdisc noqueue state UP group default qlen 1000
link/ether 06:04:aa:76:08:73 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.16.158.5/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::404:aaff:fe76:873/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever- 모든 트래픽이 169.254.1.1을 게이트웨이로 하여 eth0 인터페이스를 통해 전송됩니다.
- ARP 정보가 없음을 확인합니다.
pod2 ~ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 169.254.1.1 0.0.0.0 UG 0 0 0 eth0
169.254.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
pod2 ~ ip neighbor show✅Pod 간 통신 실행 및 확인
- pod1과 pod2 에 대해 각각의 가상 이더넷 인터페이스 이름을 찾고, 이를 VETH1과 VETH2라는 변수에 저장하여 출력
(⎈|SsoonLab:N/A) root@k8s-m:~# VETH1=$(calicoctl get workloadEndpoint | grep pod1 | awk '{print $4}')
(⎈|SsoonLab:N/A) root@k8s-m:~# echo $VETH1
calice0906292e2
(⎈|SsoonLab:N/A) root@k8s-m:~# VETH2=$(calicoctl get workloadEndpoint | grep pod2 | awk '{print $4}')
(⎈|SsoonLab:N/A) root@k8s-m:~# echo $VETH2
calibd2348b4f67- VETH1과 VETH2라는 두 개의 변수를 설정하여, 각각 VETH(가상 이더넷) 인터페이스의 이름을 저장합니다.
root@k8s-w1:~# VETH1=calice0906292e2
root@k8s-w1:~# VETH2=calibd2348b4f67- 두 개의 가상 이더넷 인터페이스에 대해 proxy_arp 설정을 확인하는 작업을 수행합니다.
- proxy_arp는 ARP 요청에 대한 응답을 제어하는 네트워크 설정입니다.
- 두 VETH 인터페이스(calice0906292e2와 calibd2348b4f67) 모두 proxy_arp가 활성화(1)되어 있습니다.
- 이는 이 인터페이스들이 ARP 요청에 대해 다른 네트워크의 주소를 대신 응답할 수 있도록 설정되어 있다는 것을 의미합니다
root@k8s-w1:~# cat /proc/sys/net/ipv4/conf/$VETH1/proxy_arp
1
root@k8s-w1:~# cat /proc/sys/net/ipv4/conf/$VETH2/proxy_arp
1- pod1에서 pod2(172.16.158.5)로 5개의 핑(ping) 요청을 보내고 응답을 확인하는 작업을 수행합니다.
pod1 ~ ping -c 5 172.16.158.5
PING 172.16.158.5 (172.16.158.5) 56(84) bytes of data.
64 bytes from 172.16.158.5: icmp_seq=1 ttl=63 time=0.149 ms
64 bytes from 172.16.158.5: icmp_seq=2 ttl=63 time=0.100 ms
64 bytes from 172.16.158.5: icmp_seq=3 ttl=63 time=0.106 ms
64 bytes from 172.16.158.5: icmp_seq=4 ttl=63 time=0.084 ms
64 bytes from 172.16.158.5: icmp_seq=5 ttl=63 time=0.078 ms
--- 172.16.158.5 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4080ms
rtt min/avg/max/mdev = 0.078/0.103/0.149/0.024 ms- Pod1(172.16.158.4)와 Pod2(172.16.158.5) 간의 핑 통신이 정상적으로 이루어지고 있음을 확인합니다.
root@k8s-w1:~# tcpdump -i $VETH1 -nn
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on calice0906292e2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:25:58.270193 ARP, Request who-has 169.254.1.1 tell 172.16.158.4, length 28
12:25:58.270225 ARP, Reply 169.254.1.1 is-at ee:ee:ee:ee:ee:ee, length 28
12:25:58.270228 IP 172.16.158.4 > 172.16.158.5: ICMP echo request, id 205, seq 1, length 64
12:25:58.270326 IP 172.16.158.5 > 172.16.158.4: ICMP echo reply, id 205, seq 1, length 64
12:25:59.278635 IP 172.16.158.4 > 172.16.158.5: ICMP echo request, id 205, seq 2, length 64
12:25:59.278712 IP 172.16.158.5 > 172.16.158.4: ICMP echo reply, id 205, seq 2, length 64
12:26:00.302632 IP 172.16.158.4 > 172.16.158.5: ICMP echo request, id 205, seq 3, length 64
12:26:00.302689 IP 172.16.158.5 > 172.16.158.4: ICMP echo reply, id 205, seq 3, length 64
12:26:01.326587 IP 172.16.158.4 > 172.16.158.5: ICMP echo request, id 205, seq 4, length 64
12:26:01.326640 IP 172.16.158.5 > 172.16.158.4: ICMP echo reply, id 205, seq 4, length 64
12:26:02.350596 IP 172.16.158.4 > 172.16.158.5: ICMP echo request, id 205, seq 5, length 64
12:26:02.350650 IP 172.16.158.5 > 172.16.158.4: ICMP echo reply, id 205, seq 5, length 64
12:26:03.342544 ARP, Request who-has 172.16.158.4 tell 192.168.10.101, length 28
12:26:03.342600 ARP, Reply 172.16.158.4 is-at fe:cd:4a:af:3c:68, length 28- 169.254.1.1과 192.168.10.101 두 IP 주소에 대해 eth0 인터페이스의 ARP 캐시가 표시되고 있습니다.
pod1 ~ ip -c -s neigh
169.254.1.1 dev eth0 lladdr ee:ee:ee:ee:ee:ee used 45/45/13probes 4 STALE
192.168.10.101 dev eth0 lladdr ee:ee:ee:ee:ee:ee used 40/100/40probes 0 STALE- iptables를 사용하여 FORWARD 체인의 규칙을 나열하고, 특정 패턴(cali-FORWARD 또는 pkts)과 일치하는 항목만 필터링하여 출력하는 작업을 수행합니다.
- cali-FORWARD: Calico 네트워크 플러그인에 의해 설정된 FORWARD 체인 규칙을 나타냅니다. 이 규칙은 패킷이 네트워크를 통해 전달될 때 적용됩니다.
- pkts 와 bytes 수가 0: 현재까지 이 규칙이 적용된 패킷 수와 바이트 수가 없음을 나타냅니다.
(⎈|SsoonLab:N/A) root@k8s-m:~# iptables -v --numeric --table filter --list FORWARD | egrep '(cali-FORWARD|pkts)'
pkts bytes target prot opt in out source destination
0 0 cali-FORWARD all -- * * 0.0.0.0/0 0.0.0.0/0 /* cali:wUHhoiAYhphO9Mso */- ARP, Request who-has 172.16.158.4 tell 192.168.10.101, length 28
- IP 주소 172.16.158.4의 MAC 주소를 묻는 ARP 요청이 192.168.10.101에서 발생했습니다.
- ARP, Request who-has 169.254.1.1 tell 172.16.158.4, length 28
- IP 주소 169.254.1.1의 MAC 주소를 묻는 ARP 요청이 172.16.158.4에서 발생했습니다.
- ARP, Reply 169.254.1.1 is-at ee:ee:ee:ee:ee:ee, length 28
- IP 주소 169.254.1.1의 MAC 주소가 ee:ee:ee:ee:ee:ee라는 ARP 응답합니다.
- ARP, Reply 172.16.158.4 is-at fe:cd:4a:af:3c:68, length 28
- IP 주소 172.16.158.4의 MAC 주소가 fe:cd:4a:af:3c:68라는 ARP 응답합니다.
root@k8s-w1:~# tcpdump -i $VETH1 -nn
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on calice0906292e2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:16:23.214016 IP 172.16.158.4 > 172.16.158.5: ICMP echo request, id 234, seq 1, length 64
13:16:23.214094 IP 172.16.158.5 > 172.16.158.4: ICMP echo reply, id 234, seq 1, length 64
13:16:28.238538 ARP, Request who-has 172.16.158.4 tell 192.168.10.101, length 28
13:16:28.238573 ARP, Request who-has 169.254.1.1 tell 172.16.158.4, length 28
13:16:28.238611 ARP, Reply 169.254.1.1 is-at ee:ee:ee:ee:ee:ee, length 28
13:16:28.238602 ARP, Reply 172.16.158.4 is-at fe:cd:4a:af:3c:68, length 28Calico 가상 라우터는 Calico 네트워킹에서 각 노드에 배치되는 가상 라우팅 기능을 의미합니다. Kubernetes 클러스터에서 네트워크 트래픽을 효율적으로 관리하고, Pod 간 또는 노드 간 통신을 가능하게 하기 위해 사용됩니다.
Calico는 기본적으로 3계층(Layer 3) 네트워크 모델을 사용하여 Kubernetes의 Pod 간 통신을 처리합니다. 여기서 가상 라우터는 각 노드에 설정되어, Pod 간의 트래픽을 전달하고 라우팅하는 역할을 합니다.
가상 라우터의 역할:
- Pod 간 트래픽 라우팅:
- Kubernetes에서 각 Pod는 고유한 IP 주소를 가지며, 이러한 IP 주소는 다른 Pod와 통신하기 위한 기본 수단입니다. Calico 가상 라우터는 Pod가 서로 다른 노드에 있을 때도 올바르게 통신할 수 있도록 네트워크 경로를 설정합니다.
- 예를 들어, 노드 A에 있는 Pod가 노드 B에 있는 Pod로 데이터를 보내려면, 각 노드의 가상 라우터가 데이터를 목적지로 라우팅해 줍니다.
- BGP (Border Gateway Protocol)를 통한 라우팅:
- Calico는 BGP라는 라우팅 프로토콜을 사용하여 노드 간 경로 정보를 동적으로 교환합니다. BGP는 인터넷에서 주로 사용하는 프로토콜이지만, Calico에서는 클러스터 내부에서 노드 간 네트워크 경로를 설정하는 데 사용됩니다.
- 이를 통해 각 노드의 가상 라우터는 클러스터의 다른 노드들로부터 경로 정보를 받고, 트래픽이 최적의 경로로 전달될 수 있도록 돕습니다.
- 정책 기반 라우팅:
- Calico는 **네트워크 정책(Network Policy)**을 통해 특정 트래픽만 허용하거나 차단할 수 있습니다. 가상 라우터는 이러한 정책을 기반으로, 특정 Pod 간의 통신이 허용되는지 여부를 확인하고, 허용된 트래픽만 라우팅합니다.
- 인터넷 및 외부 네트워크와의 통신:
- 클러스터 내부에서만 통신하는 것이 아니라, 클러스터 외부 또는 인터넷과 통신할 때도 가상 라우터는 트래픽을 라우팅할 수 있습니다. 특히 NAT(네트워크 주소 변환) 기능을 통해 내부 Pod가 외부와 안전하게 통신할 수 있도록 돕습니다.
가상 라우터의 구조:
- 각 노드의 calico-node 데몬은 가상 라우터 역할을 합니다. 이 데몬은 각 노드에 설치되어, 해당 노드에서 실행되는 모든 Pod의 네트워크 트래픽을 처리합니다.
- 가상 라우터는 Pod 네트워크 인터페이스와 연결되어 있어, Pod로부터 나오는 패킷을 받아 목적지 IP 주소에 맞는 경로로 패킷을 전달합니다.
'쿠버네티스 네트워크 스터디 3기' 카테고리의 다른 글
| [3주차] 다른 Node 에서 Pod ↔ Pod 간 통신 (0) | 2024.09.13 |
|---|---|
| [3주차] Pod ↔ 외부(인터넷) 통신 (0) | 2024.09.13 |
| [3주차] Calico CNI 설치 (0) | 2024.09.13 |
| [3주차] Calico CNI (1) | 2024.09.10 |
| [2주차] Pause Container 란 ? (1) | 2024.09.04 |
'쿠버네티스 네트워크 스터디 3기' Related Articles
more
Comments