[44] ENI vs CNI

 

	Elasitc Network Interface	Container Network Interface
정체	AWS 네트워크 인터페이스 (리소스)	컨테이너 네트워크 표준/플러그인
레벨	인프라 (IaaS)	컨테이너 런타임 (K8s)
역할	IP + NIC 제공	Pod/Container에 네트워크 연결
ECS	직접 사용	내부적으로만
EKS	CNI가 ENI를 사용	핵심 구성요소

 

ENI구성요소

- private IP

- SG

- MAC address

- subnet

- Route table 영향

 

*컨테이너가 EC2없어도 VPC 네트워크 참여

* 직접 붙음

-----------------------------------

CNI는 장비가 아니라 인터페이스 표준 (규칙)

-> *CNI가 ENI를 생성하고 IP를 Pod에 할당

 

즉 Pod는 ENI를 직접 갖지 않는다

ENI의 Secondary IP 를 할당받는다

 

Kubernetes에서 역할

Pod 생성 시

1. Pod 생성 요청

2. kubelet 호출

3. CNI Plugin 실행

4. 네트워크 연결

 

-----------------------------------

 

ECS 철학

TASK = 독립 워크로드

- ENI 직접 부여

- SG 직접 적용

- LB 바로 연결

// 단순하고 직관적

Client
  ↓
ALB/NLB
  ↓
ENI (Task IP)
  ↓
Container

 

 

EKS철학

Pod = 클러스터 내부 자원

- Node기반 네트워크

- Pod는 논리적 엔드포인트

- CNI가 네트워크 관리

Client
  ↓
ALB / NLB / Ingress
  ↓
Service (ClusterIP / NodePort)
  ↓
Pod IP (CNI 할당)

 

ECS는 포트매핑을 Container Port로

EKS는 포트매핑을 Service Port로

 

LB연결은 ECS 태스크 직접 / EKS Service 경유

 

-----------------------------------------

 

보안 모델 차이

ECS : SG -> TASK직접 / 네트워크 격리 강함

EKS : SG -> Node ENI / Pod SG는 옵션

 

------------------------------------------

 

EKS CNI

Pod 대량 생성 유리 / ENI IP 재사용

but IP 고갈 가능 / subnet 설계 중요