[MeetUp][2nd] 오리뎅이의_쿠버네티스_네트워킹_v1.2

3 Table을 알면 LAN 통신이 보인다
➢ 3 Table이란?
✓ Routing Table
✓ ARP Table
✓ MAC Table
❖ ARP Table과 MAC Table은 같다? X

PC to PC 직접 통신
➢ IP (over Ethernet) 통신을 하기 위해서 할 일은?
✓ IP 설정 : IP 와 Subnet Mask
❖ Gateway는 설정 불필요
❖ Subnet Mask 꼭 설정해 주어야 되나? 용도는???
/ MAC0 / MAC1

Subnet Mask는 무엇에 쓰는 물건인고?
➢ Subnet Mask의 용도는?
✓ 직접 통신 가능한 subnet 범위를 지정
✓ Routing table에 connected (연결됨) entry 생성
3 Table?
✓ Routing Table : yes
✓ ARP Table : yes
✓ MAC Table : no
192.168.0.1/30 192.168.0.2/30

L2 Communication (동일 subnet host)
➢ IP 설정 : IP 와 Subnet Mask (Host 설정은 direct 연결과 달라 지는 것이 없음)
✓ Gateway는 설정 불필요
✓ 직접 통신 가능한 subnet 범위를 지정
✓ Routing table에 connected(연결됨) entry 생성
❖ 직접 통신이란? MAC address로 통신한다는 얘기는 절대 아님!! IP 없으면 깡통!!
✓ 통신 상대가 같은 네트워크(Subnet)에 있어서 직접 ARP Request 보내서 MAC Learning을 해서 직접 Ethernet Frame을 보낸다는 의미
✓ 간접 통신은? 통신 상대가 다른 네트워크(Subnet)에 있어서 Gateway를 통해서 간접 전달해야 됨을 의미
3 Table?
✓ ARP Table : yes
✓ MAC Table : yes

L3 Communication (다른 subnet host)
➢ IP 설정 : IP 와 Subnet Mask, Gateway 설정
✓ 통신 상대가 다른 네트워크(subnet) 있으면, 직접 통신이 안됨
✓ Routing 장비를 통해서 간접 전달해야 함
✓ Routing 장비를 통해서 간접 전달하기 위해서 Gateway 설정 필수
3 Table?
✓ ARP Table : yes
✓ MAC Table : no
192.168.0.2/24 192.168.1.2/24
192.168.0.1/24 192.168.1.1/24
/ MAC0 / MAC1
MAC2 MAC3

서로 다른 subnet은 라우터를 통해야만 한다
192.168.2.0/24
192.168.1.2
192.168.1.0/24
192.168.1.3 192.168.1.4 192.168.2.2 192.168.2.3 192.168.2.4
192.168.2.1192.168.1.1
라우터(L3)를 통과할 때마다 Ethernet Header(MAC Address)가 변경된다. ARP Resolution을 새로 해야 한다.

Proxy ARP
192.168.2.0/24
192.168.1.2/22
192.168.1.0/24
192.168.1.3 192.168.1.4 192.168.2.2 192.168.2.3 192.168.2.4
192.168.2.1192.168.1.1
➢ Subnet Mask를 255.255.252.0 (22) 로 잘 못 설정할 경우
✓ L3 장비에 Proxy ARP Enable 되어 있으면 다른 subnet과 통신 가능
✓ Calico
✓ Cloud

Host Subnet Mask : 255.255.255.255 (/32)
192.168.2.0/24
192.168.1.2/32
192.168.1.0/24
192.168.1.3 192.168.1.4 192.168.2.2 192.168.2.3 192.168.2.4
192.168.2.1192.168.1.1
➢ Subnet Mask를 255.255.255.255 (/32) 로 설정할 경우
✓ L2 통신할 수 있는 대상이 없음. L3 통신만 가능
✓ Calico
✓ Cilium

Docker Networking
➢ 모든 node에서 동일한 container subnet 사용 : NAT 필수
✓ Source tracing 안됨
✓ 최소 unit : Container

K8S Networking Requirements
➢ NAT 없이 모든 container들과 node들이 서로 통신할 수 있어야 한다
➢ Service cluster IP range는 각 node의 pod IP range와 overlap 되지 않아야 한다
Kubernetes imposes the following fundamental requirements on any networking
Implementation (barring any intentional network segmentation policies):
• All containers can communicate with all other containers without NAT
• All nodes can communication with all containers (and vice-versa) without NAT
• The IP that a container sees itself as is the same IP that others see it as
• IP range from which to assign service cluster IPs.
This must not overlap with any IP ranges assigned to nodes for pods

Node1
root namespace
pod1 namespace
c1pause
pod2 namespace
c2pause
eth0 eth0
veth0 veth1
eth0
cbr0host
Node2
root namespace
pod3 namespace
c1pause
pod4 namespace
c2pause
eth0 eth0
veth0 veth1
eth0
cbr0host
internet
iptables iptables
K8S Network 토폴로지
✓ Container
✓ Pod : 최소 unit
✓ Namespace
✓ Node
pause container
- pod network(IP) 생성
- pod의 모든 container가 공유
Virtual Ethernet I/F
- tap57c4692
- veth86f57b2
- cali77ab12c
default namespace default namespace

Node1
root namespace
pod1 namespace
c1pause
pod2 namespace
c2pause
eth0 eth0
veth0 veth1
eth0
cbr0host
Node2
root namespace
pod3 namespace
c1pause
pod4 namespace
c2pause
eth0 eth0
veth0 veth1
eth0
cbr0host
internet
iptables iptables
K8S Network IP Ranges
Node IP range
Service IP range
Pod IP range
Cluster IP range
Pod IP range

동일 pod 내에서 Container간 통신
✓ IPC 통신 가능
✓ localhost 통신 가능
✓ Port 충돌 고려 필요
Node1
root namespace
pod1 namespace
c2
pod2 namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
Node2
root namespace
pod3 namespace pod4 namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
internet
c1 c2c1 c3c1 c4c2

CNI(Container Network Interface) plug in
➢ CNI가 하는 일
✓ K8S의 virtual network (L2 or L3 or overlay) 구성
• virtual device (switch, router, tunnel 등) 생성
• virtual device network 설정
✓ pod interface 생성 및 IP/subnet/routing table 설정
• virtual interface pair(veth pair 또는 tap)를 만들어 pod와 virtual network device 연결
• L2 통신 또는 L3 통신 또는 overlay 통신 등의 정책에 따라 pod routing table 설정
✓ Proxy ARP
• 필요 시 pod의 ARP Request에 proxy 응답 (calico, cilium 등)
➢ CNI 3대장
✓ Calico, Flannel, Weavenet
✓ Public Could는 자체 CNI도 있음
• AWS CNI, Azure CNI, GKE CNI
✓ Openstack Kuryr CNI
• Pod Multiple interface 가능
✓ Multus CNI

동일 node 내에서 pod간 통신
Node1
root namespace
pod1 namespace
c2
pod2 namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
Node2
root namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
internet
c1 c2c1 c3c1 c4c2
➢ L2 Switch
✓ K8S native, Flannel : linux bridge
- docker0, cbr0
✓ Kuryr, OVN : Open vSwitch (OVS)
- br-int, br-eno0, br0
➢ L2 통신 or L3 통신
✓ L2 통신 : K8S native, Flannel, Kuryr
✓ L3 통신 : Calico, Cilium, EKS CNI,
GKE CNI

다른 node에 있는 pod간 통신
➢ L2 통신 or L3 통신 or Overlay 통신
✓ L2 통신 : Kuryr
✓ L3 통신 : K8S, Flannel, Calico, Cilium
✓ Overlay : Calico(IPIP), Flanel(VxLAN)
Node1
root namespace
pod1 namespace
c2
pod2 namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
Node2
root namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
internet
c1 c2c1 c3c1 c4c2
✓ Overlay 통신 : Calico IPIP, Flannel VxLAN

Pod Interface – Troubleshooting tips
✓ Troubleshooting 하고자 하는 pod가 어떤 bridge interface 연결 되었는지 확인하는 방법
1. Pod IP 조회
1) Kubectl get pods –all-namespace –o wide [pod_name]
2. MAC address 확인
1) Node에서 pod에 ping 수행 // node에서 모든 pod로 ping이 되어야 함
2) arp –a // pod IP address/MAC address 확인
3. Pod가 연결된 Interface 확인
3.1 Linux bridge interface 확인 (K8S)
1) brctl show bridge_name // interface 확인
2) brctl showmacs bridge_name // pod MAC address의 port no 확인
3) brctl showstp bridge_name // port no의 vethxxx interface name
3.2. Open vSwitch interface 확인 (SCP)
1) ovs-vsctl show br-int // interface 확인
2) ovs-appctl fdb/show br-int // pod MAC address의 port no 확인
3) ovs-vsctl -- --columns=name,ofport list Interface // port no의 tapxxx interface name
3.3. Kernel router interface 확인 (Calico)
1) route –n // pod IP의 calixxx interface name
✓ 확인 된 pod의 bridge interface에 tcpdump 로 패킷 dump
실행 예 Appendix 참조

Proxy
• Forward Proxy vs Reverse Proxy

L4 Load Balancer
FTP Server Web Server MySQL Server
10.10.10.1
10.10.9.2 10.10.9.3 10.10.10.2 10.10.10.3 10.10.11.2 10.10.11.3
10.10.11.253L4 LB
10.10.10.510.10.10.4
Internet
10.10.1.2
IBR
10.10.1.1
10.10.11.110.10.9.1 L4 LB
App Server
17.11.1.5

FTP Service
FTP Server MySQL Server
10.10.10.1
10.10.9.2 10.10.9.3 10.10.10.2 10.10.10.3 10.10.11.2 10.10.11.3
10.10.11.253L4 LB
10.10.10.510.10.10.4
Internet
10.10.1.2
IBR
10.10.1.1
10.10.11.110.10.9.1
FTP Service
IP : 10.10.9.1 <= Internal Virtual IP
Port : 221222 <= LB open port
TargetPort : 22 <= Server open IP
EndPoints : 10.10.9.2:22, 10.10.9.3:22
L4 LB
Web Server App Server
17.11.1.5

Web Service
10.10.10.1
10.10.9.2 10.10.9.3 10.10.10.2 10.10.10.3 10.10.11.2 10.10.11.3
10.10.11.253L4 LB
10.10.10.510.10.10.4
Internet
10.10.1.2
IBR
10.10.1.1
Web Service
IP : 10.10.10.1
Port : 8080
TargetPort : 80
EndPoints : 10.10.10.2:80, 10.10.10.3:80
10.10.11.110.10.9.1 L4 LB
17.11.1.5

MySQL Service
10.10.10.1
10.10.9.2 10.10.9.3 10.10.10.2 10.10.10.3 10.10.11.2 10.10.11.3
10.10.11.253L4 LB
10.10.10.510.10.10.4
Internet
10.10.1.2
IBR
10.10.1.1
MySQL Service
IP : 10.10.11.1
Port : 3036
TargetPort : 3036
EndPoints : 10.10.11.2:3036, 10.10.11.3:3036
10.10.11.110.10.9.1 L4 LB
17.11.1.5

Service 외부 접속 방법 – Private IP
10.10.10.1
10.10.9.2 10.10.9.3 10.10.10.2 10.10.10.3 10.10.11.2 10.10.11.3
201.10.121.23L4 LB
10.10.10.510.10.10.4
Internet
10.10.1.2
IBR
10.10.1.1
10.10.11.110.10.9.1
10.10.1.2:30901 10.10.1.2:30311
FTP Service
IP : 10.10.9.1
Port : 22122
TargetPort : 22
Type : NodePort
NodePort : 30901
EndPoints : 10.10.9.2:22, 10.10.9.3:22
✓ Public IP에서 Node Private IP 특정 port로 load balancing
L4 LB
17.11.1.5

Service 외부 접속 방법 – Public IP
10.10.10.1
10.10.9.2 10.10.9.3 10.10.10.2 10.10.10.3 10.10.11.2 10.10.11.3
L4 LB
10.10.10.510.10.10.4
Internet
10.10.1.2
IBR
10.10.1.1
10.10.11.110.10.9.1
17.11.1.11
FTP Service
IP : 10.10.9.1
Port : 22
TargetPort : 22
Type : Loadbalancer
LoadbalancerIP : 17.11.1.11
EndPoints : 10.10.9.2:22, 10.10.9.3:22
201.10.121.23
✓ Public IP를 Loadbalancer external IP로 할당
L4 LB
17.11.1.5

Hairpin NAT
➢ Client와 Server가 동일 L2 subnet에 있는 경우
✓ DNAT(Destination NAT)만으로는 안됨. SNAT(Source NAT)도 해 주어야 함.
✓ 같은 L2 subnet에 서버가 있는 경우 SNAT을 하지 않으면, 응답을 직접 전달하기
때문에 Client는 요청한 IP와 Source IP가 다르므로 버림

Service resource
➢ K8S service resource(yaml file)는 L4 Load balancer 설정이다
✓ 기본형 Service Type
✓ ClusterIP : Service IP (Load balancer VIP)가 Private IP이기 때문에 외부에서 접속 불가
✓ Cluster 외부에서 service에 access 할 수 있는 Service Types
• NodePort : ClusterIP + NodePort (--service-node-port-range flag, default : 30000-32767)
- Node의 모든 Local IP(Local host interface IP : Loopback 포함) 이용할 수 있음
- Local IP를 지정해서 제한 할 수 있음
• LoadBalancer : ClusterIP + NodePort + LoadBanacer
- Public Cloud Provider의 경우 Cluster 외부 Load Balancer 이용
- On-Premise의 경우에는 load balancing 이 되도록 외부 장비 routing 설계 및 운영 해야 함.
• ExternalIPs : 외부에서 접속할 수 있는 IP들을 지정
- 외부 Router 또는 L3 Switch에서 ECMP Route로 Load Balancing 가능
✓ Headless Service : ClusterIP가 None
• Selector가 있는 경우 : DNS load balancing [service.namespace.svc.cluster.local]
• Selector가 없는 경우 : ExternalName type → Cluster 내부로 migration 안된 외부 Service

Service – ClusterIP Type
Node1
root namespace
pod1 namespace
c2
pod2 namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
Node2
root namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
internet
c1 c2c1 c3c1 c4c2
iptables iptables
➢ L4 LB reverse proxy 기능 수행
✓ ClusterIP = LB Internal VIP
➢ Hairpin NAT case
✓ Src pod = Dst pod
✓ pod1 c1 -> pod1 c2

Service – NodePort Type
Node1
root namespace
pod1 namespace
c2
pod2 namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
Node2
root namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
internet
c1 c2c1 c3c1 c4c2
iptables iptables
➢ 특정 Local IP range만 허용 가능
✓ Kube-proxy flag
✓ --nodeport-addresses=127.0.0.0/8
➢ ClusterIP + NodePort
✓ Default port range : 30000 ~ 32767
➢ Node의 모든 Local IP로 Access 가능
✓ Loopback IP
✓ Any Node IPs

Service – LoadBalancer Type (On-Premise)
Node1
root namespace
pod1 namespace
c2
pod2 namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
Node2
root namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
internet
c1 c2c1 c3c1 c4c2
iptables iptables
➢ ClusterIP + NodePort + LoadBalancer
➢ Loadbalnacer IP로 External IP 할당
✓ On-premise는 LB를 직접 설계 필요
➢ On-Premise LB 방안 검토
✓ 외부에 L4 LB를 배치 (물리 LB, VM,LVS)
• NodePort로 Load balancing
✓ ECMP Load balancing
• LoadbalancerIP를 목적지로 LB
✓ 내부에 L4 LB를 배치 (MetalLB, IPVS)
• ClusterIP를 목적지로 LB

Service – LoadBalancer Type (on-premise)
➢ 1개 Pod에 L2 LB가 생성됨
✓ High traffic 처리 시 성능 이슈
✓ Affinity 어려움
그림 출처 : https://kubernetes.github.io/ingress-nginx/deploy/baremetal/
➢ metalLB L2

Service – LoadBalancer Type (on-premise)
그림 출처 : https://qiita.com/MahoTakara/items/a33c169b210fae2e8ec9
➢ Data Center Fabric
✓ BGP – BFD ECMP
➢ metalLB L3

Service – LoadBalancer Type (On-Premise)
➢ externalIPs

Service – LoadBalancer Type (Public Cloud)
➢ GKE : TCP/UDP Load Balancer
➢ EKS : Network Load Balancer
➢ AKS : Standard Load Balancer
➢ Public Cloud는 자체 LB 사용
✓ K8S Cluster 외부에 LB 위치
✓ External IP 할당 및 DNS 연동
✓ Worker Node IP로 Load Balancing
✓ 직접 POD로 Load Balancing 하지
않는다
그림 출처 : https://kubernetes.github.io/ingress-nginx/deploy/baremetal/

Service – Performance Optimization
Node1
root namespace
pod1 namespace
c2
pod2 namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
Node2
root namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
internet
c1 c2c1 c3c1 c4c2
iptables iptables
➢ ExternalTrafficPolicy = local
✓ 다른 node로 routing 금지
➢ Health Check
✓ No live pod, no routing
➢ NodePort or Loadbalancer
✓ Load Balancing node 고정
✓ Node에 pod 고정
✓ affinity, taint/toleration

Service 구현체 (L4 Load Balancer Function)
➢ userspace/iptables/IPVS
✓ 현재 Kubernetes는 linux iptables을 default로 사용해서 service 구현
✓ 향후 성능 개선 및 다양한 LB 알고리즘 지원되는 IPVS (linux L4 LB)로 변경 예정
• 현재도 IPVS를 service로 사용할 수 있음
✓ usersapce는 초기에 사용했으나, 성능 issue로 iptables로 변경
• userspace 모드는 cpu가 직접 packet 처리를 수행하여 성능 저하 이슈가 있음
➢ Openstack Neutron LBaaSv2 API
✓ Openstack Kuryr는 Service를 LBaaSv2 API를 이용해서 구현
✓ 현재는 특정 node에 1개만 동작됨
• 성능 issue 예상됨
• Openstack Queens Octavia 서비스는 모든 노드에서 동작하는 Load balancer Service

Service 구현체 - iptables
Node1
root namespace
pod1 namespace
c2
pod2 namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
Node2
root namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
internet
c1 c2c1 c3c1 c4c2
iptables iptables
✓ Linux kernel iptables
• Master node 포함 모든 node에서 동작

iptables
➢ iptables : 4가지 table이 있음
✓ raw : contrack
✓ nat : NAT
✓ filter : FW
✓ mangle : QoS, packet manipulate
➢ Basic 5 chains
✓ PREROUTING, INPUT, FORWARD,
OUTPUT, POSTROUTING

root@sim-ubuntu:~# iptables -A FORWARD -i virbr0 -o enp4s0 -j ACCEPT
root@sim-ubuntu:~# iptables -t nat -A PREROUTING -p tcp --dport 30001 -j DNAT --to 192.168.122.10:30001
iptables 설정 방법
구글링 추천

➢ ClusterIP type
✓ PREROUTING -> KUBE-SERVICES -> KUBE-SVC-XXX -> KUBE-SEP-XXX -> Routing Decision
➢ NodePort type
✓ PREROUTING -> KUBE-SERVICES -> KUBE-NODEPORTS -> KUBE-SVC-XXX -> KUBE-SEP-XXX ->
Routing Decision
❖ KUBE-XLB-XXX : external_policy_local=true, 다른 node로 load balancing 하지 마라 (XLB)
➢ LoadBalancer type (On-Premise Only)
✓ PREROUTING -> KUBE-SERVICES -> KUBE-FW-XXX -> KUBE-SVC-XXX -> KUBE-SEP-XXX ->
Routing Decision
root@sim-ubuntu:~# iptables -t nat -L > nat.txt // 파일로 저장해서 vi editer에서 보면 분석이 용이
root@sim-ubuntu:~# iptables -t filter -L > filter.txt
KUBE-SVC-TFRZ6Y6WOLX5SOWZ
iptables 설정 확인 방법

Service Type 별 chain flow
출처 : https://ssup2.github.io/theory_analysis/Kubernetes_Service_Proxy/

➢ MASQURADE : SNAT
✓ Hair pin case : conn track이 nat을 기억하기 때문에 동일 pod가 src/dst인 경우만
✓ pod-cluster-cidr 이외의 source에서 수신 된 case
✓ KUBE-MARK-MASQ marking(0x4000)
✓ POSTROUTING chain에서 SNAT 수행
➢ DROP
✓ KUBE-MARK-DROP making(0x8000)
✓ FORWARD filter chain에서 drop
➢ DNAT
✓ Service IP는 pod IP로 DNAT
✓ PREROUTING Chain에서 DNAT 수행
➢ RETURN
✓ 현재 수행되고 있는 chain을 더 이상 진행하지 않고, 이전 chain으로 돌아가서 이전 chain의
다음 line rule을 수행.
✓ DROP과 같은 Action이 matching 되면, 그 packet에 대한 chain processin은 끝남.
✓ MARK 같은 Action이 matching 되면, 그 packet에 chain processing은 계속 진행됨.
iptables 분석 Tips

Service 구현체 – openstack LBaaSv2
✓ 특정 1개 VM에만 존재
✓ 외부 노출이 안됨
✓ ClusterIP type만 사용
❖ vRouter도 1개 VM에 존재
Node1
root namespace
pod1 namespace
c2
pod2 namespace
eth0 eth0
veth0 veth1
eth0
br0host
Node2
root namespace
eth0 eth0
veth0 veth1
eth0
br0host
internet
c1 c2c1 c3c1 c4c2
iptables iptables
Node3
LBaaSv2eth0

Ingress
• K8S ingress resource(yaml file)는 L7 Load Balancer 설정이다
— Ingress controller(L7 Load Balancer Function)를 K8S cluster 내부 또는 외부 중에
어느 위치에 두는가에 따라서 packet flow 및 routing hop count가 달라짐.
• Ingress Controller
— L7 Load Balancer 구현체 : North –> South Traffic에 대한 L7 Load Balancing
— NGINX, HAProxy, ENVOY, AWS ALB, Istio Ingress Gateway (ENVOY)
— Azure API Gateway, KONG API Gateway(NGINX), Ambassador API Gateway (ENVOY)
• Ingress Controller 위치
— On-premise 위치는? Inside the cluster, on pods (* F5 HW LB는 cluster 외부)
— Public Cloud 위치는? Outside of the cluster

Why Ingress (L7 Load Balancer)?
• Service(L4 Load Balancer) 로는 무엇이 부족한가?
— NodePort Type은 Well Known port 사용 불가
• Public IP 사용하여 외부 Expose 하는 것은 보안 위협이 되므로 사용을 권고하지 않음
— LoadBalancer Type은 service마다 External IP가 필요.
• IP는 돈이다
• Public Cloud는 service마다 LB가 하나씩 생성되는데, LB마다 과금
— Service는 pod로 load balancing
• Ingress 로는 무엇이 가능한가?
— IP 하나만 사용해서 여러 개의 service로 load balancing 가능
— SSL Termination
— Virtual Host based routing or URL based routing
— Ingress는 service로 load balancing

L4 vs L7
• L7 Load Balancer는 TCP Session을 Termination 한다
출처 : https://flylib.com/books/en/3.269.1.46/1/
TCP 3way handshake에는 Contents(HTTP) 정보가 없어서 서버 선택 불가

Ingress vs Istio Gateway vs API Gateway
출처 : https://medium.com/@zhaohuabing/which-one-is-the-right-choice-for-the-ingress-gateway-of-your-service-mesh-21a280d4a29c

Ingress Controller (L7 Load Balancer Function)
➢ On-Premise Ingress Controller
✓ K8S cluster 내부 pod에 위치
✓ NGINX, HAProxy, Istio/Envoy
✓ Ingress Controller pod를 여러 개 띄울 수 있음
Node1
root namespace
pod1 namespace
c2
pod2 namespace
eth0 eth0
veth0 veth1
eth0
cbr0host
Node2
root namespace
Ingress controller
eth0 eth0
veth0 veth1
eth0
cbr0host
internet
c1 c2c1 NGINX c4c3
iptables iptables

➢ Public Cloud Ingress Controller
✓ 자체 L7 사용하는 경우 K8S cluster 외부에 위치
✓ AWS ALB, GKE HTTP(S) LB, Azure Application Gateway
그림 출처 : https://aws.amazon.com/ko/blogs/opensource/kubernetes-ingress-aws-alb-ingress-controller/

➢ Public Cloud Ingress Controller
✓ General Ingress Controller (Nginx) 사용하는 경우
K8S cluster 내부 pod에 위치

Istio – Ingress Gateway (North – South traffic)
출처 : https://blog.jayway.com/2018/10/22/understanding-istio-ingress-gateway-in-kubernetes/

Istio – Ingress Gateway
➢ Ingressgateway - Service
➢ Ingressgateway pod에 대한 외부 노출 service
➢ NodePort Type or LoadBalanser Type
➢ Ingressgateway – Pods
➢ Ingressgateway controller가 running 하고 있는 pods
➢ Gateway
➢ Ingressgateway controller에서 수신 할 protocol & port 설정.
➢ VirtualService
➢ Ingressgateway controller에 L4 Rule(Matching Rule and Destination Rule) 설정

Istio – Service Mesh (West – East Traffic)
출처 : https://blog.jayway.com/2018/10/22/understanding-istio-ingress-gateway-in-kubernetes/
kubectl create namespace bubble-bubble
kubectl label namespace bubble-bubble istio-injection=enabled

✓ Response route도 동일
Istio Bookinfo Demo & Packet Flow

Appendix – 1
Linux bridge troubleshooting

Linux bridge troubleshooting tips
✓ brctl show
- 전체 bridge interface 조회
✓ brctl show [bridge_name]
- bridge_name inteface 조회
✓ brctl showmacs [bridge_name]
- MAC Table 조회

✓ brctl showstp [bridge_name]
- interface – port no mapping 조회

✓ node에서 ping 수행 후 ARP Table 확인
- pod의 mac address와 IP mapping을
확인해서 bridge interface 확인 가능

✓ bridge interface tcpdump

Appendix – 2
OVS troubleshooting

Open vSwitch troubleshooting tips
Node2
root namespace
Ingress controller
eth0 eth0
tapx
x
tapy
y
em2
host
NGIN
X
c4c3
P1P1 P1P2em1
br-p1p2
em2
phy-br-em2
int-br-p1p1 int-br-p1p2
phy-br-p1p2
pr-p1p1
phy-br-p1p1
br-int
br-p1p1 br-p1p2
int-br-em2
br-int
ccnet
p1p1 p1p2br-em2
br-em2
iptables
172.21.20.0/22128.0.0.0/24 10.43.0.0/16 10.0.10.0/24
128.0.0.5
10.43.0.5
c2c1
default namespace

✓ ovs-vsctl show : Node 전체 bridge interface 확인
✓ ovs-vsctl fdb/show br-int
: br-int bridge MAC Table 확인

✓ ovs-vsctl -- --columns=name,ofport list Interface
: interface – port no mapping 조회
✓ pod IP 확인

✓ MAC address - port no 확인
✓ port no - interface 확인
✓ Interface를 tcpdump

Appendix – 3
Calico troubleshooting

Calico CNI troubleshooting tips
Node1
root namespace
pod1 namespace
c2
pod2 namespace
eth0 eth0
cali0 cali1
eth0
Routerhost
Node2
root namespace
Istio ingressgateway
pod namespace pod4 namespace
eth0 eth0
cali0 cali1
eth0
Routerhost
Envoy c2Envoy c3Envoy c4Envoy
iptables iptables
ens1f0 ens1f0
vlan2042 vlan2032
vlan2042 vlan2032
172.20.42.111 172.20.32.223 10.251.201.126 172.20.42.112 172.20.32.224 10.251.201.127
tunl0 tunl0
calixxx interface에는 IP가 없는데, SNAT
IP는 무엇으로? 라우터 IP 10.251.201.12x

✓ Pod IP를 확인하고, pod가 있는 node에서 routing table 확인

✓ Calixxx interface 확인하고, interface를 tcpdump

Appendix – 4
Kubernetes 튜토리얼 활용

Kubernetes 대화형 튜토리얼
https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive/

Port : 내부 및 외부 VIP port
외부 접속 : LoadBalancerIP:Port
내부 접속 : ClusterIP:Port
NodePort : Node port
외부 접속 : Node IP:NodePort
노드 접속 : Localhost:NodePort
TargetPort : Pod open port
Endpoints = Pod IP:TargetPort
Container Port = TargetPort
External Traffic Policy : Cluster

[MeetUp][2nd] 오리뎅이의_쿠버네티스_네트워킹_v1.2

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie [MeetUp][2nd] 오리뎅이의_쿠버네티스_네트워킹_v1.2

Ähnlich wie [MeetUp][2nd] 오리뎅이의_쿠버네티스_네트워킹_v1.2 (20)

Mehr von InfraEngineer

Mehr von InfraEngineer (18)

[MeetUp][2nd] 오리뎅이의_쿠버네티스_네트워킹_v1.2