서종호(가시다)님의 AWS EKS Workshop Study(AEWS) 2주차 학습 내용을 기반으로 합니다.
업무가 바빠 요약본으로 대체 합니다. 추후 시간 나는대로 실습 추가해서 수정예정입니다.
- AWS VPC CNI의 구조와 IP 주소 할당 메커니즘
AWS EKS 네트워킹의 가장 큰 특징은 쿠버네티스의 파드(Pod)가 워커 노드(EC2)가 위치한 VPC의 프라이빗 IP 주소를 그대로 할당받는다는 점입니다. K8s의 일반적인 오버레이 네트워크 구성 없이 VPC Native 라우팅을 사용하므로 통신 오버헤드가 적고 성능이 뛰어납니다. VPC CNI 플러그인(ipamd)은 노드의 ENI(Elastic Network Interface)를 관리하며, 파드 생성 속도를 높이기 위해 '웜 풀(Warm Pool)' 방식을 사용합니다.
WARM_ENI_TARGET: 현재 사용 중인 ENI 외에 여유 ENI를 통째로 미리 확보합니다. 파드 스케일아웃 시 IP 할당 속도가 가장 빠르지만, 사용하지 않는 IP 대역 낭비가 심할 수 있습니다.
WARM_IP_TARGET: ENI 단위가 아닌 개별 여유 IP 개수를 지정하여 유지합니다. IP 자원이 부족한 대규모 VPC 환경에서 세밀한 관리가 가능하여 권장되는 방식입니다.
MINIMUM_IP_TARGET: 노드 가동 시 최소한으로 확보할 IP 총량을 지정하여, 초기 대규모 트래픽 유입에 따른 파드 급증 시 할당 지연을 방지합니다.
2. 노드당 최대 파드 수(Max Pods) 제한과 Prefix Delegation
기본 보조 IP(Secondary IP) 모드에서는 EC2 인스턴스 타입에 따라 부착 가능한 최대 ENI 수와 ENI당 할당 가능한 IP 개수가 물리적으로 정해져 있습니다. 예를 들어 t3.medium 인스턴스는 (3개의 ENI * (6개의 IP - 1)) + 2 = 17개에서 호스트 네트워크를 사용하는 시스템 파드를 제외하면 노드당 최대 15개의 파드만 띄울 수 있는 밀도 제한(Pod Density limit)이 발생합니다.
이를 해결하기 위해 IPv4 접두사 위임(Prefix Delegation) 기능을 활용합니다. 이 모드를 활성화하면 개별 IP 대신 /28 단위의 서브넷 대역(IP 16개)을 ENI에 통째로 위임하여 할당합니다. 결과적으로 AWS Nitro 기반 인스턴스에서 하나의 노드에 훨씬 더 많은 수(권장 최대 110개 또는 250개)의 파드를 배치할 수 있어 컴퓨팅 리소스의 효율성을 극대화할 수 있습니다.
3. 파드 트래픽 흐름과 iptables 라우팅
파드 간 통신 (Pod-to-Pod): 파드 내에서 발생한 트래픽은 veth pair 인터페이스를 통해 호스트 네임스페이스로 전달되며, 노드의 메인 라우팅 테이블 및 ENI별 전용 라우팅 테이블(Policy Routing)을 거쳐 대상 파드로 직접 전달됩니다. 이때 별도의 NAT 변환은 발생하지 않습니다.
외부 통신 (Pod-to-External): 파드가 VPC 외부(인터넷 등)로 통신할 때는 노드의 iptables 규칙 중 AWS-SNAT-CHAIN을 거칩니다. 패킷의 목적지가 VPC 내부 대역(예: 192.168.0.0/16)이 아닐 경우, 트래픽은 노드의 주 ENI(eth0) IP 주소로 Source NAT(SNAT) 처리되어 외부망으로 빠져나갑니다.
4. AWS Load Balancer Controller (LBC)와 트래픽 분산
외부 트래픽을 EKS 내부로 인입시키기 위해 AWS LBC를 배포하며, 보안 베스트 프랙티스에 따라 IRSA(IAM Roles for Service Accounts)를 통해 LBC 파드에 AWS ELB 제어 권한을 부여합니다.
Service (L4 - NLB): LoadBalancer 타입으로 배포하며, aws-load-balancer-nlb-target-type: ip 어노테이션을 설정하면 NLB가 워커 노드의 NodePort를 거치지 않고 파드의 IP로 직접 트래픽을 라우팅(Direct Routing)합니다.
Ingress (L7 - ALB): HTTP/HTTPS 트래픽 처리를 담당하며, 하나의 ALB로 여러 서비스에 대한 호스트 도메인 및 경로(Path) 기반 라우팅을 제공합니다.
5. 차세대 라우팅 표준: Gateway API
기존 Ingress는 클러스터 운영자와 애플리케이션 개발자 간의 권한 분리가 어렵고, 트래픽 제어를 위해 복잡한 커스텀 어노테이션에 의존해야 하는 한계가 있었습니다. 이를 대체하기 위해 등장한 Gateway API는 GatewayClass, Gateway, HTTPRoute 등으로 리소스 객체를 역할별로 명확히 분리합니다. AWS LBC 설정에서 --feature-gates=NLBGatewayAPI=true,ALBGatewayAPI=true를 활성화하면, 인프라 담당자는 Gateway를 생성하고, 개발자는 HTTPRoute 리소스만 관리하여 헤더 매칭, 가중치 기반 트래픽 분산 등을 안전하게 통제할 수 있습니다.
6. 도메인 자동화 및 DNS 최적화 (ExternalDNS & CoreDNS)
ExternalDNS: K8s의 Service, Ingress, Gateway 리소스를 지속적으로 감지하여 AWS Route 53에 A 레코드나 TXT 레코드를 자동으로 동기화(Sync)합니다. 사용자는 K8s 매니페스트 배포만으로 도메인 연결을 자동화할 수 있습니다.
CoreDNS 최적화: 클러스터 내부 도메인 질의를 처리하는 CoreDNS는 노드 종료나 파드 재시작 시 쿼리 실패를 유발할 수 있습니다. 이를 막기 위해 lameduck 옵션(종료 지연 시간)을 설정하고, HTTP 검사에 /health 대신 /ready 프로브를 활용합니다. 또한 캐시 용량 튜닝과 topologySpreadConstraints를 적용하여 다중 가용 영역(Multi-AZ) 환경에서 DNS 인스턴스를 고르게 분산 배치하여 고가용성을 확보해야 합니다.