EKS의 CNI비교 및 선택

EKS의 경우 클라우드답게 일반적으로 사용되는 CNI(flannel,calico등등)가 아닌 aws 자체 cni를 지원하며 이게 디폴트 값임

 

물론 타사 CNI를 못쓰는건 아니지만 aws-cni를 선택하게 되었는데 선택하게 된 장단점을 정리

 

가장큰 차이점은 aws-cni에서는 오버레이 네트워크를 사용하지 않는다는 점 이다

 

일반적으로 타사 cni의 경우 파드네트워크로 선언된 네트워크에 vxlan,ip-ip등을 통해 오버레이 네트워크를 구현 한다

 

많은 장단점이 있겠으나 당장 생각나는 부분만 정리하면

 

일반적인 cni사용시

 

장점

ip의 제한이나 네트워크의 제한없이 자유롭게 pod네트워크를 구성 할 수 있음

k8s의 networkpolicy지원(네트워크 정책도 k8s오브젝트로 컨트롤 할 수 있음)

패킷이 기본적으로 보호됨

지금까지 해왔던대로 그냥 사용하면 됨

 

단점

오버레이 네트워크다 보니 캡슐화에 따른 오버헤드가 분명 존재함

pod네트워크의 대역폭이 부족하다면 전체적인 속도저하 현상이 있음

오버레이 네트워크라 패킷의 흐름을 노드에서 직접적으로 쉽게 확인 할 수 없음

 

aws cni사용시

 

장점

vpc내 ip가 직접 노드→pod순으로 연결됨 (pod에 vpc eni가 직접 붙음)

오버레이가 아닌 vpc네트워크를 직접 쓰기때문에 이로 인한 오버헤드가 없음

파드 네트워크 패킷을 직접 확인 할 수 있음

sg로 파드네트워크를 직접 제어 가능

eni를 공유하는 파드는 극소수 이기때문 대역폭이 충분함

ALB와 같이 사용시 ALB에서 파드의 ip로 직접 라우팅이 가능함(불필요한 홉이 줄어듬)

 

단점

pod의 네트워크 설정이 vpc를 따라감

인스턴스 별 최대 사용가능한 ip/eni 갯수가 존재하는데 이것을 초과하여 pod를 배치하지 못함

networkpolicy사용 불가능

다른 cni가 지원하는 확장기능 전무

 

 

종합하여 판단 결과 다른 cni보다 aws cni가 쉽게 사용할수 있고 aws에서 직접 지원하기 때문에 안정성이 높다고 판단함

선택하기 망설여진 단점이 크게 네트워크 폴리시와 노드별 파드 제한 이였는데 후자는 특정 인스턴스 이상을 쓰면 어느정도 해소되고(완전한 해결은 안됨) 전자는 아쉽지만 sg를 이용하기로 하고 선택함

클러스터가 엄청 커지면(파드 500개이상) 서브넷을 추가하고 그룹을 나누는등의 작업 필요