0부터 시작하는 AWS 공부 - EKS & AWS CNI

1. EKS

EKS 란

• EKS는 관리형 쿠버네티스 서비스로 컨트롤 노드를 직접 설치 & 운영 & 유지 보수할 필요 없이 쿠버네티스를 편리하게 사용할 수 있는 AWS의 쿠버네티스 서비스
• 컨트롤 노드는 CSP / 워커 노드는 사용자가 관리할 수 있지만, AWS 에서는 AWS Node Group으로 관리할 수 있다
• Node Group을 생성하면 AWS에서 Auto Scaling Group에 속한 EC2가 생성된다

EKS 장점

• 쿠버네티스 클러스터 구성 및 설치 소요 시간이 단축된다
• 컨트롤 노드가 자동 생성 & 구성 & 관리되므로 직접 접근으로 인한 문제점을 방지한다
• 클러스터 업그레이드 및 스케일링이 간단하다

---

Onpremise 와 비교

• Onpremise K8s 환경과 비교했을 때, 사용자가 관리해야 하는 부분은 위와 같다. EKS를 사용하면, 인프라부터 클러스터 단위까지의 생성 및 관리는 AWS에서 해준다

• EKS에서 인증은 AWS IAM을 사용한다

• Onpremise 환경에서 클러스터 업그레이드를 하려면, 메뉴얼대로 직접 수행하는 것에 비해, EKS의 경우 버튼 클릭만으로 업그레이드가 가능하기에 편리하다

• EKS는 네트워크 플러그인으로 AWS CNI를 사용한다. Onpremise는 오버레이 네트워크를 사용하지만, EKS는 VPC 네트워크를 직접 사용한다

---

2. AWS CNI

CNI 란

참조 : https://velog.io/@h13m0n/8

• 쿠버네티스에서 파드를 생성하면, 클러스터내의 가상 네트워크를 부여 받는다. 이 네트워크 플러그인은 Calico, Flannel 등 여러 종류가 있다. 파드는 해당 노드와 네트워크를 공유하며, 다른 노드에 위치한 파드와 Overlay Network를 통해 통신한다

CNI는 리눅스 컨테이너 간의 네트워킹을 제어할 수 있는 플러그인을 만들기 위한 표준이다. CNI는 라우팅, 터널링과 같이 각종 네트워크 기능들을 사용하게 해준다

• 라우팅 테이블, 라우팅, IP, 서브넷, 커널 라우팅, 브릿지, 터널링 등의 기능을 지원한다
• 즉, CNI는 어떤 컨테이너 런타임인지에 상관 없이, 리눅스 컨테이너에서 사용할 네트워크의 인터페이스를 정의한 것이다

이러한 CNI는 표준이므로, CNI를 활용하여 추가적인 기능 개발을 한 Calico와 같은 특정 서비스에 어울리는 서드 파티 CNI 플러그인이 존재한다

CNI 플러그인은 K8S에 Overlay Network를 구성해준다. 이러한 CNI를 통해 다른 노드에 있는 파드와도 통신을 할 수 있다

---

AWS CNI 란

참조 : https://kim-dragon.tistory.com/46
참조 : https://ikcoo.tistory.com/160

EKS는 AWS CNI를 사용한다. EKS는 클러스터의 네트워크 대역을 VPC로부터 할당 받는다. 따라서 파드는 클러스터가 위치한 VPC 내의 서브넷의 IP 주소를 할당 받는다

• 워커 인스턴스는 ENI를 통해 파드의 네트워크 주소를 관리한다
• 이로 인해 너무 많은 리소스를 생성하면, 부여할 IP 주소가 부족해질 수 있다

AWS CNI는 다음 통신을 지원한다

• 노드 내부에 파드 통신
• 다른 노드에 위치하는 파드 통신
• 파드 ~ AWS 서비스 통신
• 파드 ~온프레미스 통신
• 파드 ~ 인터넷 통신

---

ENI 란

참조 : https://kimjingo.tistory.com/197

탄력적 네트워크 인터페이스로 인스턴스가 AWS 서비스, 다른 인스턴스, 인터넷등 다른 네트워크 리소스와 통신하게 해주며, 인스턴스 내의 OS와도 통신할 수 있게 해주는 가상 네트워크 인터페이스 이다

• 인스턴스에 연결되어 네트워크 통신을 한다. 인스턴스 생성 시, 기본 ENI가 있다. 기본 ENI는 제거할 수 없다
• ENI는 인스턴스와 독립적이며, 따로 생성해서 인스턴스에 추가로 붙일 수 있다
• 인스턴스는 여러 개의 네트워크 인터페이스 연결 가능
• 네트워크 인터페이스에는 IP 와 MAC 주소가 할당된다
• 기본 네트워크 인터페이스와 보조 네트워크 인터페이스로 나뉜다

---

AWS CNI 장단점

물론, EKS 내에서 다른 CNI를 사용할 수 있다. 그렇다면, AWS CNI를 사용하는 이유는 무엇일까?

• POD에 VPC ENI 가 직접 붙는다
• 오버레이가 아닌 VPC 네트워크를 직접 사용하기에 오버헤드가 없다
• 보안 그룹으로 파드 네트워크를 제어할 수 있다
• ALB를 통해 파드의 IP로 직접 라우팅 가능

단점은 무엇일까?

• VPC의 설정이 파드의 네트워크 설정에 영향을 미친다
• 인스턴스별 제한된 IP 및 ENI 개수가 존재한다. 이를 초과해서 파드를 생성하지 못한다
• 네트워크 정책을 지원하지 않는다