10Gbps 네트워크에 대한 CNI(Kubernetes 네트워크 플러그인) 벤치마크 결과(업데이트: 2019년 XNUMX월)

이건 내 업데이트야 이전 벤치마크, 현재 1.14년 2019월 현재 최신 CNI 버전이 포함된 Kubernetes XNUMX에서 실행됩니다.

우선 Cilium 팀에 감사의 말씀을 전하고 싶습니다. 이 팀은 메트릭 모니터링 스크립트를 확인하고 수정하는 데 도움을 주었습니다.

2018년 XNUMX월 이후 달라진 점

그 이후로 변경된 내용은 다음과 같습니다(관심 있는 경우).

Flannel은 가장 빠르고 간단한 CNI 인터페이스로 남아 있지만 여전히 네트워크 정책 및 암호화를 지원하지 않습니다.

Romana는 더 이상 지원되지 않으므로 벤치마크에서 제거했습니다.

WeaveNet은 이제 Ingress 및 Egress에 대한 네트워크 정책을 지원합니다! 그러나 생산성은 감소했습니다.

Calico에서는 최상의 성능을 위해 최대 패킷 크기(MTU)를 수동으로 구성해야 합니다. Calico는 CNI 설치를 위한 두 가지 옵션을 제공하므로 별도의 ETCD 저장소 없이도 수행할 수 있습니다.

• Kubernetes API에 상태를 데이터 저장소로 저장합니다(클러스터 크기 < 50개 노드).
• K8S API의 부하를 완화하기 위해 Typha 프록시를 사용하여 Kubernetes API에 상태를 데이터 저장소로 저장합니다(클러스터 크기 > 50노드).

Calico는 지원을 발표했습니다. 애플리케이션 수준 정책 애플리케이션 수준 보안을 위해 Istio 위에 있습니다.

Cilium은 이제 암호화를 지원합니다! Cilium은 IPSec 터널을 통한 암호화를 제공하고 암호화된 WeaveNet 네트워크에 대한 대안을 제공합니다. 그러나 WeaveNet은 암호화가 활성화된 Cilium보다 빠릅니다.

이제 내장된 ETCD 연산자 덕분에 Cilium을 배포하기가 더 쉬워졌습니다.

Cilium 팀은 메모리 소비와 CPU 비용을 줄여 CNI의 무게를 일부 줄이려고 노력했지만 경쟁업체는 여전히 더 가볍습니다.

벤치마크 컨텍스트

벤치마크는 10Gb Supermicro 스위치를 갖춘 가상화되지 않은 Supermicro 서버 9000대에서 실행되었습니다. 서버는 패시브 DAC SFP+ 케이블을 통해 스위치에 직접 연결되며 점보 프레임(MTU XNUMX)을 사용하여 동일한 VLAN에 구성됩니다.

Docker 1.14.0(이 릴리스의 기본 Docker 버전)가 포함된 Ubuntu 18.04 LTS에 설치된 Kubernetes 18.09.2.

재현성을 높이기 위해 우리는 항상 첫 번째 노드에 마스터를 구성하고 벤치마크의 서버 부분을 두 번째 서버에 배치하고 클라이언트 부분을 세 번째 서버에 배치하기로 결정했습니다. 이를 위해 Kubernetes 배포에서 NodeSelector를 사용합니다.

벤치마크 결과를 다음과 같은 규모로 설명하겠습니다.

벤치마크를 위한 CNI 선택

이는 섹션 목록의 CNI에 대한 벤치마크입니다. kubeadm을 사용하여 하나의 마스터 클러스터를 생성하는 방법 공식 Kubernetes 문서를 참조하세요. 9개의 CNI 중에서 6개만 선택합니다. 문서(Romana, Contiv-VPP 및 JuniperContrail/TungstenFabric)에 따라 설치하기 어렵거나 구성 없이 작동하지 않는 CNI는 제외합니다.

다음 CNI를 비교해 보겠습니다.

• 옥양목 v3.6
• Canal v3.6(기본적으로 네트워킹을 위한 Flannel + 방화벽으로서의 Calico)
• 섬모 1.4.2
• 플란넬 0.11.0
• 큐브 라우터 0.2.5
• 위브넷 2.5.1

설치

CNI 설치가 쉬울수록 첫인상이 더 좋아질 것입니다. 벤치마크의 모든 CNI는 설치가 매우 쉽습니다(하나 또는 두 개의 명령 사용).

앞에서 말했듯이 서버와 스위치는 점보 프레임이 활성화된 상태로 구성됩니다(MTU를 9000으로 설정). CNI가 어댑터 구성을 기반으로 MTU를 자동으로 결정한다면 기쁘겠습니다. 그러나 Cilium과 Flannel만이 이를 관리했습니다. 나머지 CNI에는 GitHub에 자동 MTU 검색을 추가하라는 요청이 있지만 Calico, Canal 및 Kube-router에 대한 ConfigMap을 변경하거나 WeaveNet에 대한 환경 변수를 전달하여 수동으로 구성하겠습니다.

잘못된 MTU의 문제점은 무엇입니까? 이 다이어그램은 기본 MTU가 활성화된 WeaveNet과 점보 프레임 간의 차이점을 보여줍니다.

MTU는 처리량에 어떤 영향을 미치나요?

MTU가 성능에 얼마나 중요한지 살펴보았습니다. 이제 CNI가 MTU를 자동으로 결정하는 방법을 살펴보겠습니다.

CNI는 MTU를 자동으로 감지합니다.

그래프는 최적의 성능을 위해 Calico, Canal, Kube-router 및 WeaveNet에 대한 MTU를 구성해야 함을 보여줍니다. Cilium과 Flannel은 아무런 설정 없이도 MTU 자체를 올바르게 결정할 수 있었습니다.

Безопасность

전송된 데이터를 암호화하는 기능과 Kubernetes 네트워크 정책 구현(문서가 아닌 실제 테스트 기반)이라는 두 가지 측면에서 CNI 보안을 비교할 것입니다.

두 개의 CNI만이 데이터를 암호화합니다: Cilium과 WeaveNet. 암호화 위브넷 암호화 비밀번호를 CNI 환경 변수로 설정하여 활성화합니다. 안에 선적 서류 비치 WeaveNet에서는 이를 복잡하게 설명하지만 모든 작업은 간단하게 이루어집니다. 암호화 섬모 Kubernetes 비밀 생성 및 daemonSet 수정을 통해 명령으로 구성됩니다(WeaveNet보다 조금 더 복잡하지만 Cilium은 단계별로 명령).

네트워크 정책 구현에 있어서는 성공했습니다. Calico, Canal, Cilium 및 WeaveNet에서 수신 및 송신 규칙을 구성할 수 있습니다. 을 위한 큐브 라우터 Ingress에만 규칙이 있습니다. 플란넬 네트워크 정책이 전혀 없습니다.

전체 결과는 다음과 같습니다.

안전 성능 벤치마크 결과

Производительность

이 벤치마크는 각 테스트를 3회 이상 실행하는 동안의 평균 처리량을 보여줍니다. 우리는 TCP 및 UDP(iperfXNUMX 사용), HTTP(Nginx 및 컬 사용) 또는 FTP(vsftpd 및 컬 사용)와 같은 실제 애플리케이션, 마지막으로 SCP 기반 암호화(클라이언트 및 서버 OpenSSH 사용)를 사용하여 애플리케이션 성능을 테스트합니다.

모든 테스트에 대해 베어메탈 벤치마크(녹색 선)를 수행하여 CNI 성능과 기본 네트워크 성능을 비교했습니다. 여기서는 동일한 스케일을 사용하지만 색상은 다음과 같습니다.

• 노란색 = 아주 좋음
• 주황색 = 좋음
• 파란색 = 그저그렇다
• 빨간색 = 나쁨

잘못 구성된 CNI는 사용하지 않으며 올바른 MTU가 있는 CNI에 대한 결과만 표시합니다. (참고: Cilium은 암호화를 활성화한 경우 MTU를 올바르게 계산하지 않으므로 버전 8900에서는 MTU를 수동으로 1.4으로 줄여야 합니다. 다음 버전인 1.5에서는 이 작업을 자동으로 수행합니다.)

결과는 다음과 같습니다.

TCP 성능

모든 CNI는 TCP 벤치마크에서 좋은 성능을 보였습니다. 암호화를 사용한 CNI는 암호화 비용이 많이 들기 때문에 훨씬 뒤처집니다.

UDP 성능

여기에서도 모든 CNI가 잘 지내고 있습니다. 암호화를 적용한 CNI도 거의 동일한 결과를 보여주었습니다. Cilium은 경쟁사에 비해 조금 뒤쳐지지만 베어메탈 대비 2,3%에 불과하니 나쁜 결과는 아닙니다. Cilium과 Flannel만이 MTU를 스스로 올바르게 결정했으며 이는 추가 구성 없이 얻은 결과라는 점을 잊지 마십시오.

실제 응용 프로그램은 어떻습니까? 보시다시피 HTTP의 전반적인 성능은 TCP보다 약간 낮습니다. TCP와 함께 HTTP를 사용하는 경우에도 HTTP 벤치마크에 영향을 미칠 수 있는 느린 시작을 방지하기 위해 TCP 벤치마크에서 iperf3을 구성했습니다. 여기서 다들 수고하셨어요. Kube-router는 분명한 장점이 있지만 WeaveNet은 베어메탈보다 약 20% 정도 성능이 좋지 않았습니다. 암호화 기능을 갖춘 Cilium과 WeaveNet은 정말 안타깝습니다.

또 다른 TCP 기반 프로토콜인 FTP를 사용하면 결과가 다양해집니다. Flannel과 Kube-router가 작업을 수행하지만 Calico, Canal 및 Cilium은 약간 뒤쳐져 있으며 베어 메탈보다 약 10% 느립니다. WeaveNet은 17%나 뒤처져 있지만 암호화된 WeaveNet은 암호화된 Cilium보다 40% 앞서 있습니다.

SCP를 사용하면 SSH 암호화 비용이 얼마나 드는지 즉시 확인할 수 있습니다. 거의 모든 CNI가 잘하고 있지만 WeaveNet은 다시 뒤쳐져 있습니다. 암호화를 적용한 Cilium과 WeaveNet은 이중 암호화(SSH+CNI)로 인해 최악이 예상됩니다.

다음은 결과가 포함된 요약 표입니다.

자원 소비

이제 CNI가 과부하(TCP 전송 중, 10Gbps)에서 리소스를 어떻게 소비하는지 비교해 보겠습니다. 성능 테스트에서는 CNI를 베어 메탈(녹색 선)과 비교합니다. 리소스 소비의 경우 CNI가 없는 순수 Kubernetes(보라색 선)를 표시하고 CNI가 소비하는 추가 리소스 수를 살펴보겠습니다.

기억부터 시작해보자. 다음은 전송 중 노드 RAM(버퍼 및 캐시 제외)의 평균 값(MB)입니다.

메모리 소비

Flannel과 Kube-router는 50MB에 불과한 뛰어난 결과를 보여주었습니다. Calico와 Canal은 각각 70MB를 사용합니다. WeaveNet은 분명히 다른 것보다 더 많은 130MB를 소비하고 Cilium은 400MB를 사용합니다.
이제 CPU 시간 소비를 확인해 보겠습니다. 주목할만한: 다이어그램에는 백분율이 표시되어 있지 않지만, "순철"의 경우 ppm, 즉 38ppm은 3,8%입니다. 결과는 다음과 같습니다.

CPU 소비

Calico, Canal, Flannel 및 Kube-router는 CPU 효율이 매우 높습니다. CNI가 없는 Kubernetes보다 2%만 더 높습니다. WeaveNet은 추가 5%로 훨씬 뒤쳐져 있으며 Cilium이 7%로 그 뒤를 따릅니다.

리소스 소비를 요약하면 다음과 같습니다.

결과

모든 결과가 포함된 표:

일반 벤치마크 결과

결론

마지막 부분에서는 결과에 대한 주관적인 의견을 표현하겠습니다. 이 벤치마크는 매우 작은 클러스터(노드 3개)에서 단일 연결의 처리량만 테스트한다는 점을 기억하세요. 대규모 클러스터(노드 50개 미만) 또는 병렬 연결에는 적용되지 않습니다.

시나리오에 따라 다음 CNI를 사용하는 것이 좋습니다.

• 클러스터에 있습니까? 리소스가 거의 없는 노드 (수 GB RAM, 여러 코어) 보안 기능이 필요하지 않은 경우 - 선택 플란넬. 이는 가장 비용 효율적인 CNI 중 하나입니다. 또한 다양한 아키텍처(amd64, arm, arm64 등)와 호환됩니다. 또한 이는 MTU를 자동으로 결정할 수 있는 두 가지(다른 하나는 Cilium) CNI 중 하나이므로 아무것도 구성할 필요가 없습니다. Kube-router도 적합하지만 표준이 아니므로 MTU를 수동으로 구성해야 합니다.
• 필요한 경우 네트워크를 암호화하다 안전을 위해 가져가세요 위브넷. 점보 프레임을 사용하는 경우 MTU 크기를 지정하고 환경 변수를 통해 비밀번호를 지정하여 암호화를 활성화하는 것을 잊지 마십시오. 그러나 성능은 잊어버리는 것이 좋습니다. 이는 암호화 비용입니다.
• 에 정상적인 사용 나는 조언한다 옥양목. 이 CNI는 다양한 Kubernetes 배포 도구(Kops, Kubespray, Rancher 등)에서 널리 사용됩니다. WeaveNet과 마찬가지로 점보 프레임을 사용하는 경우 ConfigMap에서 MTU를 구성해야 합니다. 리소스 소비, 성능 및 보안 측면에서 효율적인 다기능 도구입니다.

마지막으로 개발을 따르라고 조언합니다. 섬모. 이 CNI에는 제품(기능, 리소스 절약, 성능, 보안, 클러스터링...)에 대해 많은 작업을 수행하는 매우 활동적인 팀이 있으며 매우 흥미로운 계획을 가지고 있습니다.

CNI 선택을 위한 시각적 다이어그램

출처 : habr.com