TL; DR : Все CNI работают как надо, за исключением Kube-Router и Kube-OVN, Calico за исключением автоматического определения MTU — лучше всех.
Статья-обновление моих прошлых проверок ( и ), 테스트 당시 1.19년 18.04월 현재 CNI가 업데이트된 Ubuntu 2020에서 Kubernetes XNUMX를 사용하고 있습니다.
측정항목에 대해 알아보기 전에...
2019년 XNUMX월 이후 새로운 소식은 무엇인가요?
- Можно протестировать на собственном кластере: можно запускать тесты на собственном кластере с использованием нашего инструмента Kubernetes 네트워크 벤치마크:
- 새로운 멤버가 등장했어요
- от VMware Tanzu
- alauda.io에서
- Новые сценарии: текущие проверки запускают тесты производительности сети "Pod-to-Pod", также добавлен новый сценарий "Pod-to-Service", запускающий тесты, приближенные к реальным условиям. На практике ваш Pod с API работает с базой в виде сервиса, а не через Pod ip-адрес (конечно же мы проверяем и TCP и UDP для обоих сценариев).
- Потребление ресурсов: каждый тест сейчас имеет собственное сравнение ресурсов
- 애플리케이션 테스트 제거: 커뮤니티 및 CNI 유지보수 담당자와의 유익한 협력으로 CNI 시작 지연(Pod의 처음 몇 초)으로 인해 TCP를 통한 iperf 결과와 컬 결과 사이의 차이가 발견되었으므로 더 이상 HTTP, FTP 및 SCP 테스트를 수행하지 않습니다. 실제 조건에서는 일반적이지 않은 시작).
- Открытый исходный код: все источники тестов (скрипты, настройки yml и исходные "сырые" данные) доступны
Эталонный протокол тестирования
프로토콜이 자세히 설명되어 있습니다. , обратите внимание, что эта статья посвящена Ubuntu 18.04 с ядром по умолчанию.
평가를 위한 CNI 선택
Это тестирование нацелено на сравнение CNI, настраиваемых одним файлом yaml (поэтому исключены все, устанавливаемые скриптами, типа VPP и прочих).
Выбранные нами CNI для сравнения:
- 안트레아 v.0.9.1
- 옥양목 v3.16
- Canal v3.16(플란넬 네트워크 + Calico 네트워크 정책)
- 섬모 1.8.2
- 플란넬 0.12.0
- Kube 라우터 최신(2020–08–25)
- 위브넷 2.7.0
Настройка MTU для CNI
먼저 자동 MTU 감지가 TCP 성능에 미치는 영향을 확인합니다.
MTU가 TCP 성능에 미치는 영향
Еще больший разрыв обнаруживается при использовании UDP:
MTU가 UDP 성능에 미치는 영향
테스트에서 밝혀진 엄청난 성능 영향을 고려하여 모든 CNI 유지 관리자에게 희망의 편지를 보내고 싶습니다. CNI에 자동 MTU 감지를 추가하십시오. 새끼 고양이, 유니콘, 심지어 가장 귀여운 새끼 고양이, 데보프(Devop)까지 구할 수 있습니다.
그러나 자동 MTU 감지 지원 없이 CNI를 사용해야 하는 경우 수동으로 구성하여 성능을 얻을 수 있습니다. 이는 Calico, Canal 및 WeaveNet에 적용됩니다.
Моя маленькая просьба к сопровождающим CNI…
Тестирование CNI: необработанные данные
이 섹션에서는 CNI를 올바른 MTU(자동으로 결정되거나 수동으로 설정됨)와 비교합니다. 여기서 주요 목표는 원시 데이터를 그래프로 표시하는 것입니다.
Цветовая легенда:
- серый — образец (т.е. голое железо)
- зеленый — пропускная способность выше 9500 мбитс
- желтый — пропускная способность выше 9000 мбитс
- 주황색 - 8000Mbps 이상의 대역폭
- красный — пропускная способность ниже 8000 мбитс
- 파란색 - 중립(대역폭과 관련 없음)
Потребление ресурсов без нагрузки
우선, 클러스터가 "휴면" 상태일 때 리소스 소비를 확인합니다.
Потребление ресурсов без нагрузки
포드 간
이 시나리오에서는 클라이언트 Pod가 해당 IP 주소를 사용하여 서버 Pod에 직접 연결한다고 가정합니다.
Сценарий Pod-to-Pod
TCP
Pod 간 TCP 결과 및 해당 리소스 소비:
UDP
Pod 간 UDP 결과 및 해당 리소스 소비:
Pod-to-Service
이 섹션은 실제 사용 사례와 관련이 있으며, 클라이언트 포드는 ClusterIP 서비스를 통해 서버 포드에 연결됩니다.
포드-서비스 스크립트
TCP
Pod-to-Service TCP 결과 및 해당 리소스 소비:
UDP
Результаты Pod-to-Service UDP и соответствующее потребление ресурсов:
네트워크 정책 지원
위의 모든 것 중에서 정치를 지지하지 않는 유일한 것은 플란넬이다. 다른 모든 항목은 인바운드 및 아웃바운드를 포함하여 네트워크 정책을 올바르게 구현합니다. 잘 했어!
Шифрование CNI
확인된 CNI 중에는 Pod 간의 네트워크 교환을 암호화할 수 있는 CNI가 있습니다.
- Antrea с помощью IPsec
- 와이어가드를 사용하는 Calico
- Cilium с помощью IPsec
- IPsec을 사용하는 WeaveNet
처리량
남은 CNI 수가 적으므로 모든 시나리오를 하나의 그래프에 넣겠습니다.
자원 소비
В этом разделе мы будет оценивать ресурсы, используемые при обработке связи Pod-to-Pod в TCP и UDP. Нету смысла рисовать график Pod-to-Service, поскольку он не дает дополнительной информации.
Сводим все вместе
Давайте попробуем повторить все графики, мы тут немного привнесли субъективности, заменяя фактические значения словами "vwry fast", "low" и т.п.
결론과 나의 결론
결과에 대한 저만의 해석을 전달하는 것이기 때문에 다소 주관적입니다.
새로운 CNI가 등장하고 Antrea가 잘 작동하며 초기 버전에서도 자동 MTU 감지, 암호화 및 쉬운 설치 등 많은 기능이 구현되어 기쁩니다.
성능을 비교해 보면 Kube-OVN과 Kube-Router를 제외한 모든 CNI가 잘 작동합니다. Kube-Router는 또한 MTU를 감지할 수 없었으며 문서 어디에서도 MTU를 구성하는 방법을 찾지 못했습니다( открыт запрос на эту тему).
리소스 소비 측면에서 Cilium은 여전히 다른 제품보다 더 많은 RAM을 사용하지만 제조업체는 분명히 대규모 클러스터를 목표로 하고 있으며 이는 분명히 XNUMX노드 클러스터에 대한 테스트와 동일하지 않습니다. Kube-OVN도 CPU와 RAM 리소스를 많이 소비하지만 Open vSwitch를 기반으로 하는 젊은 CNI입니다(Antrea와 마찬가지로 성능이 더 좋고 소비도 적습니다).
Flannel을 제외한 모든 사람은 네트워크 정책을 가지고 있습니다. 목표는 찐 순무보다 간단하기 때문에 그가 결코 그들을 지원하지 않을 가능성이 매우 높습니다. 가벼울수록 좋습니다.
또한 무엇보다도 암호화 성능이 놀랍습니다. Calico는 가장 오래된 CNI 중 하나이지만 암호화는 불과 몇 주 전에 추가되었습니다. 그들은 IPsec 대신 Wireguard를 선택했으며 간단히 말해서 이 테스트 부분에서 다른 CNI를 완전히 압도하여 훌륭하고 놀랍게 작동합니다. 물론 암호화로 인해 리소스 소모는 늘어나지만 달성한 처리량은 그만한 가치가 있습니다(Calico는 암호화 테스트에서 9000위인 Cilium에 비해 XNUMX배 향상된 성능을 보였습니다). 또한 Calico를 클러스터에 배포한 후 언제든지 Wireguard를 활성화할 수 있으며 원할 경우 짧은 시간 동안 또는 영구적으로 비활성화할 수도 있습니다. 그래도 엄청나게 편리해요! Calico는 현재 MTU를 자동 감지하지 않으므로(이 기능은 향후 버전에서 계획됨) 네트워크가 점보 프레임(MTU XNUMX)을 지원하는 경우 MTU를 구성해야 합니다.
Кроме прочего, обратите внимание, что Cilium умеет шифровать трафик между узлами кластера (а не только между Pod), что может быть весьма актуально для публичных узлов кластера.
결론적으로 다음과 같은 사용 사례를 제안합니다.
- 매우 작은 클러스터에 CNI가 필요하거나 보안이 필요하지 않습니다.: работайте с 플란넬, наиболее легким и стабильным CNI (그는 또한 Homo Kubernautus 또는 Homo Contaitorus에 의해 발명되었다는 전설에 따르면 가장 오래된 것 중 하나입니다.). 당신은 또한 가장 독창적인 프로젝트에 관심이 있을 수도 있습니다 , 확인하다!
- 일반 클러스터에는 CNI가 필요합니다.: 옥양목 — ваш выбор, но не забывайте настроить MTU, если оно нужно. Легко и непринужденно можно играть с сетевыми политиками, включать и выключать шифрование и т.п.
- (매우) 대규모 클러스터에는 CNI가 필요합니다.: ну, тест не показывает поведение больших кластеров, я был бы рад провести тесты, но у нас нету сотен серверов с подключением 10гбитс. Так что лучший вариант — запуск модифицированного теста на ваших узлах, хотябы с Calico и Cilium.
출처 : habr.com