GKE CNI Performance benchmark(2021-06-10)

 

 

목차 :

1. 들어가기 전에
2. GKE에서 사용할 수 있는 CNI 플러그인
3. Benchmark
4. 요약
5. 결과

 

 

1. 들어가기 전에

 

쿠버네티스의 네트워크 계층을 구현하기 위해서는 CNI(Container Network Interface) 플러그인이 꼭 필요합니다.

 

하지만 선택할 수 있는 CNI 플러그인의 종류가 너무 많기 때문에 ( https://kubernetes.io/ko/docs/concepts/cluster-administration/networking/ 참고) 선택에 있어 많은 어려움이 따르기도 합니다.

 

많은 블로그와 아티클에서 k8s에서 사용할 수 있는 CNI 플러그인의 기능, 명세를 비교했지만, 실제 CNI 플러그인을 사용했을 때 나타나는 GKE에서의 성능 비교를 볼 수 있는 글은 오래되었거나, 관련 정보를 찾을 수 없었습니다.

 

특히 GKE 환경에서 사용할 수 있는 CNI 플러그인 별 성능 지표는 다루고 있는 글이 없었기 때문에 직접 환경을 구축하고 비교함으로써 성능에 대한 지표를 비교해보고자 합니다.

 

본 글에서 비교하는 GKE 환경은 모두 3 node cluster의 기본값을 기준으로 하며, GCP network 밖에서 일어나는 요인은 다루지 않았습니다.

 

또한 CNI 플러그인이 제공하는 기능(암호화, 제어 등..)을 제외한 순수 성능만을 비교했다는 점, 작은 cluster size에서 벤치마크를 진행했다는 한계가 있기 때문에 절대적인 선택의 기준이 아닌 참고용으로 사용하시면 좋을 것 갗습니다.

 

Benchmark에 사용한 툴은 "k8s-bench-suite"를 사용했습니다.

(https://github.com/InfraBuilder/k8s-bench-suite)

 

 

 

 

2. GKE에서 사용할 수 있는 CNI 플러그인

 

GKE 환경에서 제공되는 네트워크 플러그인 옵션은 총 3가지가 존재합니다.

 

1. Kubenet (CNI X)

2. Calico

3. Cilium

 

Kubenet 플러그인은 매우 간단하고 기본적인 네트워크 플러그인입니다. 때문에 네트워크 정책, 암호화와 같은 기능을 전혀 제공하지 않습니다. GKE에서는 아무런 CNI 플러그인을 선택하지 않았을 시 기본적으로 선택되는 네트워크 플러그인입니다. CNI 플러그인을 사용하지 않았을 때의 기준을 두기 위해 Kubenet을 비교군에 넣었습니다.

 

Calico는 가장 대중적이고 널리 사용되는 K8S CNI 플러그인입니다. Network policy같은 보안 기능과 더불어 뛰어난 성능을 제공해 보안, 성능 면에서 가장 좋은 선택이 될 수 있습니다. 특히 GKE의 VPC-native mode, Alias IP 등의 기능과 통합되어 있기 때문에 GKE의 Network policy 기능 사용 시 기본적으로 선택되는 CNI 플러그인입니다.

 

Cilium은 더 강력한 Network policy와 암호화를 제공하는 CNI 플러그인입니다. network visibility 기능을 제공해 높은 투명성을 제공합니다. GKE에서는 Dataplane V2라는 이름으로 해당 옵션을 선택하면 사용할 수 있습니다. 

 

 

 

 

 

3. Benchmark

 

성능 측정에 사용한 GKE 클러스터 환경 명세입니다.

 

VPC network MTU : 1460

k8s version : v1.19.9-gke.1400

Node instance spec : Intel(R) Xeon(R) CPU @ 2.00 GHz, 4 GB mem

 

벤치마크를 수행할 비교군은 다음과 같습니다.

 

1. GKE with kubenet (NO CNI plugin)

2. GKE with Calico

3. GKE with Cilium

4. GCE with Calico

 

GKE에서 제공하는 3가지 CNI 옵션(kubenet, Calico, Cilium) 외에, 관리형 K8S가 아닌 Self-managed 형태의 GCE k8s cluster를 비교군에 넣었습니다.

 

 

 

 

3.1. Idle 

 

 

첫 번째로 비교할 대상은 아무런 트래픽 이동이 없는 Idle 상태에서의 자원 소모량입니다.

 

 

 

 

 

3.1. Pod2Pod 

 

 

다음 시나리오는 노드 간 Server pod와 Client pod 트래픽 이동 시 자원 소모량 및 대역폭입니다.

대역폭은 Network performance를 나타내는 지표로 사용될 수 있으며 TCP와 UDP 2가지 경우로 나누어 테스트했습니다.

 

 

3.1.1 Bandwidth

 

3.1.2 TCP CPU,Ram  

 

3.1.3 UDP CPU,Ram 

 

 

 

 

3.2. Pod2service

 

 

마지막 시나리오는 노드와 서비스 간 트래픽 이동 시 자원 소모량 및 대역폭입니다.

Pod2Pod의 경우보다 더 실제 환경에서 많이 일어나는 시나리오입니다.

마찬가지로 TCP와 UDP 통신의 경우로 나누어 테스트했습니다.

 

 

3.2.1 Bandwidth

 

 

3.2.2 TCP CPU,Ram 

 

 

3.2.3 UDP CPU,Ram 

 

 

 

 

 

4. 요약

 

벤치마크 결과 Idle 상태에서 CPU 소모량이 가장 적은 CNI 플러그인은 Cilium, RAM 소모량이 가장 적은 CNI 플러그인은 Cailco로 나타났습니다. Cilium을 설치한 클러스터는 CNI 플러그인을 사용하지 않은 GKE with kubenet과 비교해도 CPU 사용량에 큰 차이가 없었습니다. 반면 Cilium은 비교군 중 가장 많은 RAM 자원을 소모한 것으로 나타났습니다. 이 같은 결과는 Cilium이 큰 사이즈의 클러스터를 타겟으로 한 CNI 플러그인이라는 점, 많은 기능과 암호화를 제공한다는 점이 작용한 것으로 보입니다.

 

Pod2Pod 통신에서 네트워크 대역폭이 가장 높은 CNI 플러그인은 Cailco로 나타났습니다. TCP 통신에선 GKE의 모든 비교군이 큰 차이를 보이지 않았지만, UDP 통신에선 유의미한 차이를 볼 수 있습니다. Calico는 Cilium보다 UDP 통신 시 더 높은 네트워크 성능을 보여주고 있습니다.
자원 소모량에서 RAM은 Calico가 압도적으로 적지만 CPU는 Cilium이 근소하게 더 적은 것으로 나타났습니다. Pod간 통신에서 자원 소모량은 Idle 상태에서 보여준 추이와 비슷한 것을 볼 수 있습니다.

 

Pod2service 통신에서 네트워크 대역폭이 가장 높은 CNI 플러그인은 Calico로 나타났습니다. Calico를 설치한 환경이  Pod2pod, Pod2service 통신 모두 가장 높은 네트워크 성능을 발휘할 수 있었습니다. Calico는 Pod2Pod와 마찬가지로 TCP 통신에서는 큰 차이가 없었지만, UDP에서 Cilium보다 높은 성능을 보여줬습니다.

자원 소모량이 가장 적은 CNI 플러그인 또한 Calico로 나타났습니다. Pod2Pod 경우와 달리 Cailco는 CPU와 RAM 모두 GKE CNI 플러그인 중 가장 적은 자원을 소모했습니다. 실제로 TCP 통신에서 CPU 사용량은 Cilium이 근소하게 더 낮았지만 오차범위 이내(+-0.1%)로 동일하다고 봐도 무방했습니다.

 

 

Calico는 가장 대중적인 CNI 플러그인답게 GKE 환경에서도 적절한 벤치마크 결과를 보여줬습니다. 대부분의 테스트에서 좋은 지표를 내놨으며 성능과는 별개로 뛰어난 보안, 제어 기능까지 가지고 있어 프로덕션 환경에서 적절하게 사용할 수 있음을 이번 실험에서 증명했습니다.

 

Cilium은 벤치마크 결과가 좋게 나오지는 않았지만, 지표로 볼 수 없는 많은 기능들을 제공하고 있기 때문에 여전히 매력적인 선택지입니다. 특히 GKE 환경에서 Cilium을 CNI 플러그인으로 선택 시 kernel 단에서 동작하는 eBPF 기능을 사용할 수 있기 때문에 보안 면에서 뛰어나기도 합니다. 

 

GCE를 사용한 Self-managed cluster 환경(with Calico)은 GKE보다 전체적으로 낮은 성능을 보여줬으며, 자원 소모량 면에서도 크게 뛰어난 모습을 보여주지 못했습니다. 이로써 성능 및 자원의 면에서나, 관리성 면에서나 GKE가 k8s를 운영하기 더 좋은 환경이란 것을 알 수 있었습니다.

 

 

 

 

5. 정리

 

 

 

 

CNI는 CNCF의 프로젝트 중 하나로 컨테이너 간 네트워킹의 표준을 제시했습니다.

덕분에 많은 오픈소스 CNI 프로젝트가 진행되어 우리는 다양한 선택지를 가질 수 있었습니다. 

때문에 GKE를 사용하는 환경이든, 혹은 다른 k8s 클러스터를 운영하는 환경이든 CNI의 선택은 난감합니다.

이번 글에서는 GKE에서 native 하게 제공하는 CNI만을 비교했지만, 설치할 수 있는 CNI의 종류는 훨씬 더 많습니다.

각 CNI가 제공하는 기능도 중요하지만, 실제 벤치마크 결과로 나타나는 지표를 기준으로 선택의 기준을 세우는 것도 좋은 방법인 것 같습니다.