EKS Network

🔠EKS Network란?
- Kubernetes 클러스터 내의 컨테이너 간 통신과 클러스터 내부 및 외부 리소스 간 통신을 관리하는 것을 의미

1. 클러스터 내 네트워킹
   • EKS는 기본적으로 Kubernetes 네트워크 모델을 따름
   • 클러스터 내의 모든 노드 및 컨테이너 간 통신은 Kubernetes CNI(Container Network Interface) 플러그인을 통해 관리
   • 일반적으로는 Amazon VPC (Virtual Private Cloud) CNI 플러그인을 사용하여 클러스터 내 통신을 처리
2. 클러스터 외부 네트워킹
   • EKS 클러스터는 외부 서비스와의 통신을 위해 인터넷 게이트웨이, NAT 게이트웨이 등의 AWS 리소스를 사용가능
   • AWS PrivateLink를 통해 외부 서비스와의 프라이빗 네트워크 통신을 설정 가능
3. 로드 밸런싱
   • EKS는 로드 밸런서 서비스를 통해 클러스터 내부 및 외부에서 발생하는 트래픽을 관리(서비스의 가용성과 확장성 확보)
4. 보안 그룹 및 네트워크 정책
   • AWS 보안 그룹과 네트워크 ACL(Access Control List) 등을 사용하여 EKS 클러스터의 보안을 강화
     (특정 리소스에 대한 접근 제어 및 네트워크 트래픽 필터링이 가능)

CNI (Container Network Interface)

1. 컨테이너 네트워크 설정
   • CNI는 컨테이너를 시작하거나 중지할 때 네트워크 인터페이스를 설정하고 관리
   • 컨테이너가 호스트 또는 다른 컨테이너와 통신할 수 있도록 해줌.
2. IP 주소 할당
   • CNI는 컨테이너에 IP 주소를 할당하고 관리
   • 컨테이너가 네트워크 상에서 고유하게 식별
3. 라우팅 설정
   • CNI는 컨테이너 간 및 컨테이너와 호스트 간의 라우팅을 설정
   • 컨테이너 간 통신 및 외부와의 통신이 가능
4. 보안 그룹 및 ACL 관리
   • 일부 CNI 구현체는 네트워크 보안 그룹이나 ACL(Access Control List)을 통해 네트워크 트래픽을 필터링하고 보호할 수 있는 기능을 제공합니다.
5. 다양한 네트워크 토폴로지 지원
   • CNI는 다양한 네트워크 토폴로지를 지원하여 컨테이너 환경의 유연성을 향상시킵니다.
   • 이는 다중 호스트, 가상 네트워크, 서비스 메시 등의 구성이 가능함을 의미합니다.

💡CNI 적용시 고려 사항

클라우드 네이티브 애플리케이션 시대가 도래함에 따라 네트워킹 아키텍처에 대한 새로운 접근 방식이 등장했습니다. Kubernetes 네트워킹은 호스트 포트에 컨테이너 포트를 매핑할 필요 없이 깨끗하고 하위 호환성 있는 모델로 설계되었습니다. 이를 지원하기 위해 Kubernetes는 파드 네트워크, 서비스, 클러스터 IP, 컨테이너 포트, 호스트 포트 및 노드 포트와 같은 네트워킹을 위한 많은 기본 개념을 도입하여 사용자를 기존 인프라로부터 추상화했습니다.
그러나 Kubernetes에서는 인프라에 대해 중립적인 구조를 만들기 위해 의도적으로 여러 공백을 남겼습니다. 네트워킹의 이러한 공백 대부분은 네트워킹 플러그인을 통해 채워지며, 이러한 플러그인은 컨테이너 네트워크 인터페이스(CNI)를 통해 Kubernetes와 상호 작용합니다.
CNI 플러그인의 일반적인 제한 사항에는 다음과 같은 것들이 있습니다:
소프트웨어 정의 네트워킹(SDN)에 대한 의존: 대부분의 CNI 플러그인은 소프트웨어 정의 네트워킹(SDN)을 사용하며, 이는 다양한 복잡성을 추가합니다.
클러스터 외부로 애플리케이션 노출: 대부분의 네트워킹 솔루션은 L3 네트워킹을 사용하므로 파드 IP의 존재는 클러스터 내부에 있습니다.
호스트 네트워크를 통한 모든 트래픽 라우팅: “NodePort” 또는 “LoadBalancer”를 사용하면 모든 트래픽이 호스트 네트워크 인터페이스를 통해 라우팅됩니다.
Traffic Isolation: 대부분의 Kubernetes 네트워킹 솔루션은 모든 종류의 트래픽에 대해 동일한 물리적 네트워크(호스트 네트워크) 인터페이스를 사용합니다.
부하 분산의 문제: 여러 파드가 동일한 노드에서 실행될 경우 외부 부하 분산기로의 라우팅이 문제가 될 수 있습니다.
추가 호핑: 외부 액세스는 항상 노드 자체에 있는 인터페이스나 포트를 통해 이루어지므로 성능과 지연 시간에 영향을 줄 수 있습니다.
다중 홈 네트워크: 많은 경우 애플리케이션은 다른 고립된 네트워크/서브넷에 연결해야 할 수 있습니다.
정적 엔드포인트 프로비저닝: Kubernetes의 파드 IP는 동적이며, 대부분의 CNI 플러그인은 파드에 정적 엔드포인트 또는 IP를 할당하는 기능을 지원하지 않습니다.
주변 간섭 및 성능 SLA: 가상 환경에서 여러 애플리케이션을 실행할 경우 모든 애플리케이션의 트래픽이 동일한 네트워크 파이프를 통해 흐릅니다.
멀티존 지원: 고가용성은 프로덕션 Kubernetes 배포에 중요하며, 다양한 장애 도메인에 환경을 분산할 수 있어야 합니다.
저장 트래픽 분리: 대부분의 CNI 플러그인은 저장 트래픽과 일반 트래픽을 구분하지 못합니다.
네트워킹의 이러한 한계를 극복하기 위해 Diamanti는 고유한 네트워크 아키텍처로 CNI 플러그인의 대부분의 단점을 해결합니다. Diamanti의 데이터 플레인 솔루션은 하드웨어 오프로드 스마트 NIC를 사용하여 내장된 L2 네트워킹 지원을 제공합니다. 이는 외부 라우팅 가능 네트워크에 각 파드에 실제 L2 MAC 주소를 할당하여 네트워킹을 훨씬 더 쉽게 만들어줍니다. 또한, VLAN/VXLAN 세분화, 다중 홈 네트워킹, 정적 엔드포인트 프로비저닝, 네트워크 인식 스케줄링, 보장된 SLA 및 기타 독특한 기능을 지원합니다.
Kubernetes의 네트워킹 스택은 기업 프로덕션 배포에서 가장 중요한 아키텍처 결정 중 하나입니다. 인프라에 적합한 CNI 플러그인을 선택할 때는 해당 제한 사항을 주의깊게 고려하여 결정해야 합니다.
– 아래 참고
https://thenewstack.io/top-considerations-when-selecting-cni-plugins-for-kubernetes/

[Calico CNI] VS [AWS VPC CNI]

Pod 생성 후 추가되는 Routing Table

Pod traffic

Worker Node 최대 할당 IP 개수

• 인스턴스 타입 별 ENI 최대 갯수와 할당 가능한 최대 IP 갯수에 따라서 파드 배치 갯수가 결정됨
• 단, aws-node 와 kube-proxy 파드는 호스트의 IP를 사용함으로 최대 갯수에서 제외함

💡최대 파드 생성 개수 = 인스턴스 유형당 네트워크 인터페이스 수 × (네트워크 인터페이스 당 IP 주소 수 - 1) + 2

위의 공식에서 마지막에 2를 더하는 이유는 아래와 같다.

1. Primary ENI와 Secondary ENI:
   • AWS에서는 EC2 인스턴스에 기본적으로 1개의 Primary ENI가 할당
   • 인스턴스를 시작하면 자동으로 생성되며, 인스턴스의 기본 네트워크 인터페이스 역할
   • 인스턴스 유형에 따라 추가적인 Secondary ENI가 할당될 수 있으며, 추가 ENI는 보통 네트워크 확장이나 특정 기능을 위해 사용
2. Kubernetes 서비스 및 네트워크 플러그인 요구 사항:
   • Kubernetes 클러스터 내에서는 기본적으로 각 노드에 서비스를 위한 IP 주소 및 네트워크 플러그인을 위한 IP 주소가 필요
   • 이러한 요구 사항으로 인해 각 노드에는 기본적으로 2개의 IP 주소가 필요