[가시다's AEWS] 2주차 EKS Networking

목차

 

AWS VPC CNI

 - L-IPAM이란?

 - k8s cni 와 비교

노드의 기본 네트워크

노드 간 파드 통신

파드에서 외부 통신

노드에서 파드 생성 개수 제한

Service 와  AWS LBC

Ingress

Network Policies with VPC CNI

 

---

 

AWS VPC CNI

EKS 클러스터는 VPC 내부에 구현되어 AWS 네트워크 환경에 영향을 받는다. 따라서, 파드가 클러스터가 구현된 서브넷 대역에 해당하는 IP를 할당받는다. 이걸 가능하게 만드는 것이 AWS VPC CNI(Container Networking Interface)로, AWS VPC 네트워크와 EKS 네트워크 간 인터페이스 역할을 수행해준다.

 

파드의 IP 네트워크 대역과 노드(워커)의 IP 대역이 같아서 직접 통신이 가능하다

 

L-IPAM이란?

L-IPAM(Local IP Address Manager)은 네트워크 내의 IP 주소를 관리, 할당 및 추적하는 소프트웨어 도구이다. 이 시스템은 네트워크 관리자가 IP 주소 공간을 효율적으로 사용하고 중복을 방지할 수 있도록 지원한다. 또한, 네트워크 장치 및 사용자에 대한 IP 할당 내역을 시각적으로 표시하고, IP 주소 변경이나 업데이트를 쉽게 관리할 수 있게 해 준다.

 

AWS VPC CNI는 EKS Addon 으로 제공되며, aws_node 라는 DaemonSet으로 모든 노드에 배포되는데, aws-node의 일부로 L-IPAM(Local IP Address Manager)을 설치하여 이를 통해 파드의 IP를 할당받는 방식을 사용한다.

 

각 노드에서 사용 가능한 보조 IP 주소의 warm-pool을 유지하기 위해 L-IPAM을 실행하며, Kubelet에서 파드를 추가하라는 요청을 받을 때마다 L-IPAM이 warm-pool에서 즉시 사용 가능한 보조 IP 주소 하나를 가져와서 파드에 할당한다.

 

 

L-IPAM은 노드(인스턴스)의 관련 정보인 메타데이터를 통해 사용 가능한 ENI와 보조 IP 주소를 파악하고, DaemonSet이 재시작될 때마다 Kubelet을 통해 파드 이름, 네임스페이스, IP 주소와 같은 현재 실행 중인 파드의 정보를 가져와서 warm-pool을 구축한다.

 

실제 동작으로 예시를 들자면, 최초 노드 생성 후 파드를 배포하지 않은 경우 특정 파드(kube-proxy, aws-node)를 제외한 나머지(coredns와 같은) 파드가 새로 배포되면 L-IPAM은 Secondary ENI를 생성한다.

L-IPAM은 Secodary ENI의 보조 Private IPv4 주소를 관리하는 warm-pool에서 즉시 사용 가능한 IP 주소를 가져와서 새로 배포된 파드에 할당한다.

k8s cni 와 비교

AWS VPC CNI의 경우 네트워크 통신의 최적화(성능, 지연)를 위해서 노드와 파드의 네트워크 대역을 동일하게 설정한다. 

 

파드간 통신 시 일반적으로 K8S CNI는 오버레이(VXLAN, IP-IP 등) 통신을 하고, AWS VPC CNI는 동일 대역으로 직접 통신을 한다. 즉, K8S 기반 CNI의 경우 Overlay를 통한 패킷의 캡슐화 과정을 필요로 하여 통신을 위한 자원이 소모되며, AWS VPC CNI의 경우 캡슐화에 필요한 자원의 소모를 줄일 수 있고, 지연시간이 짧아지므로 네트워크 성능이 향상된다. 

 

 

 

노드의 기본 네트워크

 

• 네트워크 네임스페이스는 호스트(Root)와 파드 별(Per Pod)로 구분된다. 호스트의 경우 호스트 ip 를 그대로 사용하지만, 파드별 ip는 보조 프라이빗 ip 가 할당된다.
• kube-proxy, aws-node 는 호스트의 ip 를 그대로 사용한다. 
• ENI0, ENI1 으로 2개의 ENI는 자신의 IP 이외에 추가적으로 5개의 보조 프라이빗 IP를 가질수 있다
• coredns 파드는 veth 으로 호스트에는 eniY@ifN 인터페이스와 파드에 eth0 과 연결되어 있다.

파드의 Host Network 옵션 확인 :

https://xn--vj5b11biyw.kr/306

노드 간 파드 통신

파드간 통신 시 tcpdump 내용을 확인해보면, 별도의 오버레이(Overlay) 통신 기술 없이, VPC Native 하게 파드간 직접 통신이 가능한 것을 확인할 수 있다. 같은 VPC 내의 통신이여서 별도의 Nat를 타지도 않는다. 

Pod-2 -> Pod-1 로 통신될때에는 워커노드1의 ip 가 확인된다.

# 파드 IP 변수 지정
PODIP1=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[0].status.podIP})
PODIP2=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[1].status.podIP})
PODIP3=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[2].status.podIP})

# 파드1 Shell 에서 파드2로 ping 테스트
kubectl exec -it $PODNAME1 -- ping -c 2 $PODIP2

# 파드2 Shell 에서 파드3로 ping 테스트
kubectl exec -it $PODNAME2 -- ping -c 2 $PODIP3

# 파드3 Shell 에서 파드1로 ping 테스트
kubectl exec -it $PODNAME3 -- ping -c 2 $PODIP1

# 워커 노드 EC2 : TCPDUMP 확인
sudo tcpdump -i any -nn icmp
sudo tcpdump -i eth1 -nn icmp
sudo tcpdump -i eth0 -nn icmp
sudo tcpdump -i eniYYYYYYYY -nn icmp

[워커 노드1]
# routing policy database management 확인
ip rule

# routing table management 확인
ip route show table local

# 디폴트 네트워크 정보를 eth0 을 통해서 빠져나간다
ip route show table main
default via 192.168.1.1 dev eth0
...

 

파드간 통신 시 과정 참고

 

파드에서 외부 통신

파드에서 외부 통신 흐름은 iptable 에 SNAT 을 통하여 노드의 eth0 IP로 변경되어서 외부와 통신된다.

* SNAT(Source Network Address Translation) : 내부 네트워크의 프라이빗 IP를 공용 IP로 변환해 외부와 통신 가능하게 하며, 내부 주소를 숨기는 네트워크 주소 변환 기술

VPC CNI 의 External source network address translation (SNAT) 설정에 따라, 외부(인터넷) 통신 시 SNAT 하거나 혹은 SNAT 없이 통신을 할 수 있다

노드에서 파드 생성 개수 제한

인스턴스 유형에 최대 ENI 갯수와 할당 가능 IP 수를 조합하여 Secondary IPv4 addresses에 맞추어 제한된다. 단, aws-node 와 kube-proxy 파드는 호스트의 IP를 사용함으로 최대 갯수에서 제외한다. 

 

t3.medium은 ENI가 총 3개 가능하며, 각 ENI당 5개씩 Secondary IP 를 가질 수 있어, 총 15개의 파드가 가능하다. (aws-node 와 kube-proxy 제외)

 

계산 식은 아래와 같다.

 

최대 파드 생성 갯수 : (Number of network interfaces for the instance type × (the number of IP addressess per network interface - 1)) + 2

 

이걸 늘리는 방법은 Prefix Delegation, WARM & MIN IP/Prefix Targets, Custom Network 으로 가능하다.

Service 

ClusterIP 타입

 

NodePort 타입

 

LoadBalancer 타입 (기본 모드) : NLB 인스턴스 유형

Service (LoadBalancer Controller) : AWS Load Balancer Controller + NLB IP 모드 동작 with AWS VPC CNI

NLB 모드 전체 정리

1. 인스턴스 유형
   1. externalTrafficPolicy : ClusterIP ⇒ 2번 분산 및 SNAT으로 Client IP 확인 불가능 ← LoadBalancer 타입 (기본 모드) 동작
   2. externalTrafficPolicy : Local ⇒ 1번 분산 및 ClientIP 유지, 워커 노드의 iptables 사용함
2. IP 유형 ⇒ 반드시 AWS LoadBalancer 컨트롤러 파드 및 정책 설정이 필요함!
   1. Proxy Protocol v2 비활성화 ⇒ NLB에서 바로 파드로 인입, 단 ClientIP가 NLB로 SNAT 되어 Client IP 확인 불가능
   2. Proxy Protocol v2 활성화 ⇒ NLB에서 바로 파드로 인입 및 ClientIP 확인 가능(→ 단 PPv2 를 애플리케이션이 인지할 수 있게 설정 필요)

Ingress

클러스터 내부의 서비스(ClusterIP, NodePort, Loadbalancer)를 외부로 노출(HTTP/HTTPS) 시킨다. L7 의 역할

AWS Load Balancer Controller + Ingress (ALB) IP 모드 동작 with AWS VPC CNI

Network Policies with VPC CNI

Network Policy 는 클러스터 내의 포드 간 통신을 제어하고 관리하는 데 사용되는 규칙 세트이다. 이를 통해 사용자는 특정 포드가 다른 포드, 네트워크 세그먼트 또는 IP 주소 범위와 통신할 수 있는지 여부를 세밀하게 제어할 수 있다. EKS 에서는 꽤 최근에 적용되었는데, 사용하기 위한 조건은 아래와 같다.

• EKS 1.25 버전 이상
• AWS VPC CNI 1.14 이상
• OS 커널 5.10 이상 EKS 최적화 AMI(AL2, Bottlerocket, Ubuntu)

EKS 에서 Network Policy 는 크게 3가지를 통해 동작한다.

• Network Policy Controller : EKS 버전 1.25 이상에서는 Network Policy Controller가 자동으로 설치된다. 이 컨트롤러는 네트워크 통제 정책을 모니터링하고, 해당 정책에 따라 필요한 eBPF 프로그램을 생성하거나 업데이트하도록 Node Agent에 지시한다.
• Node Agent : AWS VPC CNI와 함께 번들로 제공되는 ipamd 플러그인과 함께 설치되며, aws-node 데몬셋 형태로 존재한다. Node Agent의 주된 역할은 eBPF 프로그램을 관리하는 것이다. 이러한 관리 작업에는 프로그램의 설치, 업데이트 및 삭제가 포함된다.
• eBPF SDK : AWS VPC CNI에 포함된 eBPF SDK는 노드에서 eBPF 프로그램과 상호 작용할 수 있는 기능을 제공한다. 이 SDK를 통해 개발자는 eBPF 실행을 런타임에서 검사, 추적 및 분석할 수 있다. 이는 네트워크 정책의 효과를 모니터링하고 최적화하는 데 유용하다.

* eBPF : Linux 커널에서 직접 실행되는 안전하고 효율적인 프로그램을 개발할 수 있는 기술로, 네트워킹, 보안, 성능 모니터링 등 다양한 시스템 레벨 작업을 가능하게 합니다. 이를 통해 사용자 공간에서 커널 공간의 동작을 프로그래밍적으로 확장하고 제어할 수 있습니다​