TL; DR: Всі CNI працюють як слід, за винятком Kube-Router і Kube-OVN, Calico за винятком автоматичного визначення MTU - найкраще.
Стаття-оновлення моїх минулих перевірок ( и ), на момент тестування я використовую Kubernetes 1.19 в Ubuntu 18.04 з оновленими CNI на серпень 2020 року.
Перш ніж зануритися в метрики.
Що нового з квітня 2019 року?
- Можна протестувати на власному кластері: можна запускати тести на власному кластері за допомогою нашого інструменту Kubernetes Network Benchmark:
- З'явилися нові учасники
- від VMware Tanzu
- від alauda.io
- Нові сценарії: поточні перевірки запускають тести продуктивності мережі "Pod-to-Pod", також додано новий сценарій "Pod-to-Service", який запускає тести, наближені до реальних умов. На практиці ваш Pod з API працює з базою у вигляді сервісу, а не через Pod ip-адресу (звичайно ми перевіряємо і TCP і UDP для обох сценаріїв).
- Споживання ресурсів: кожен тест має власне порівняння ресурсів
- Видалення тестів додатків: ми більше не робимо тести HTTP, FTP та SCP, оскільки наша плідна співпраця з спільнотою та супроводжуючими CNI виявила прогалину між результатами iperf по TCP та результатами curl через затримку у запуску CNI (перші кілька секунд при запуску Pod, що не характерно у реальних умовах).
- Відкритий вихідний код: всі джерела тестів (скрипти, налаштування yml та вихідні "сирі" дані) доступні
Еталонний протокол тестування
Протокол докладно описаний Зверніть увагу, що ця стаття присвячена Ubuntu 18.04 з ядром за замовчуванням.
Вибір CNI для оцінки
Це тестування має на меті порівняння CNI, що налаштовуються одним файлом yaml (тому виключені всі, що встановлюються скриптами, типу VPP та інших).
Вибрані нами CNI для порівняння:
- Antrea v.0.9.1
- Calico v3.16
- Canal v3.16 (Flannel network + Calico Network Policies)
- Cilium 1.8.2
- Flannel 0.12.0
- Kube-router latest (2020-08-25)
- WeaveNet 2.7.0
Налаштування MTU для CNI
Насамперед перевіряємо вплив автоматичного визначення MTU на продуктивність TCP:
Вплив MTU на продуктивність TCP
Ще більший розрив виявляється під час використання UDP:
Вплив MTU на продуктивність UDP
З урахуванням ВЕЛИЧЕЗНОГО впливу на продуктивність, розкритого в тестах, ми хотіли б надіслати лист-надію всім супроводжуючим CNI: будь ласка, додайте автоматичне визначення MTU в CNI. Ви врятуєте кошенят, одноріжок і навіть найсимпатичнішого: маленького девопсика.
Тим не менш, якщо вам по-любому треба взяти CNI без підтримки автоматичного визначення MTU — можна налаштувати його руками для отримання продуктивності. Зверніть увагу, що це стосується Calico, Canal і WeaveNet.
Моє маленьке прохання до супроводжуючих CNI…
Тестування CNI: необроблені дані
У цьому розділі ми порівняємо CNI з правильним MTU (визначеним автоматично або виставленим руками). Основна мета тут – показати у вигляді графіків необроблені дані.
Колірна легенда:
- сірий - зразок (тобто голе залізо)
- зелений - пропускна спроможність вище 9500 мбітс
- жовтий - пропускна здатність вище 9000 мбітс
- помаранчевий - пропускна здатність вище 8000 мбітс
- червоний - пропускна здатність нижче 8000 мбітс
- синій - нейтральний (не пов'язано з пропускною здатністю)
Споживання ресурсів без навантаження
Насамперед — перевірка споживання ресурсів, коли кластер "спить".
Споживання ресурсів без навантаження
Pod-to-Pod
Цей сценарій передбачає, що клієнтський Pod підключається безпосередньо до серверного Pod за його IP-адресою.
Сценарій Pod-to-Pod
TCP
Результати Pod-to-Pod TCP та відповідне споживання ресурсів:
UDP
Результати Pod-to-Pod UDP та відповідне споживання ресурсів:
Pod-to-Service
Цей розділ є актуальним для реальних випадків використання, клієнтський Pod з'єднується з серверним Pod через сервіс ClusterIP.
Сценарій Pod-to-Service
TCP
Результати Pod-to-Service TCP та відповідне споживання ресурсів:
UDP
Результати Pod-to-Service UDP та відповідне споживання ресурсів:
Підтримка політик мережі
Серед усіх перелічених вище, єдиний, який не підтримує політики, це Flannel. Решта правильно реалізують мережеві політики, включаючи вхідні і вихідні. Відмінна робота!
Шифрування CNI
Серед CNI, що перевіряються, є ті, що можуть шифрувати обмін по мережі між Pod:
- Antrea за допомогою IPsec
- Calico за допомогою wireguard
- Cilium за допомогою IPsec
- WeaveNet за допомогою IPsec
Пропускна здатність
Оскільки залишилося менше CNI - зведемо всі сценарії в один графік:
Споживання ресурсів
У цьому розділі ми будемо оцінювати ресурси, що використовуються при обробці зв'язку Pod-to-Pod у TCP та UDP. Нема рації малювати графік Pod-to-Service, оскільки він не дає додаткової інформації.
Зводимо все разом
Спробуймо повторити всі графіки, ми тут трохи привнесли суб'єктивності, замінюючи фактичні значення словами "vwry fast", "low" і т.п.
Висновок та мої висновки
Тут трохи суб'єктивно, оскільки я передаю власну інтерпретацію результатів.
Я радий, що з'явилися нові CNI, Antrea виступив непогано, реалізовано багато функцій навіть у ранніх версіях: автоматичне визначення MTU, шифрування та просте встановлення.
Якщо порівнювати продуктивність, всі CNI працюють добре, крім Kube-OVN і Kube-Router. Kube-Router також не зміг визначити MTU, я не знайшов ніде в документації способу його налаштування ( відкритий запит на цю тему).
Що стосується споживання ресурсів, то, як і раніше, Cilium використовує більше оперативної пам'яті, ніж інші, але компанія-виробник явно націлена на великі кластери, що явно не те саме, як тест на тривузловому кластері. Kube-OVN також споживає багато ресурсів процесорного часу та оперативної пам'яті, але це молодий CNI, заснований на Open vSwitch (як і Antrea, що працює краще та з меншим споживанням).
Мережеві політики є у всіх, окрім Flannel. Цілком ймовірно, що він ніколи не буде їх підтримувати, оскільки мета простіше пареної ріпи: чим легше, тим краще.
Також крім іншого, продуктивність шифрування налаштовує захоплення. Calico - один із найстаріших CNI, але шифрування було додано всього кілька тижнів тому. Вони вибрали wireguard замість IPsec, і простіше кажучи, все працює чудово і приголомшливо, повністю витісняючи інші CNI у цій частині тестування. Звичайно ж зростає споживання ресурсів через шифрування, але пропускна здатність того варта (Calico в тесті з шифруванням показав шестикратну перевагу в порівнянні з Cilium, що займає друге місце). Більш того, можна ввімкнути wireguard у будь-який час після розгортання Calico у кластері, а також, якщо забажаєте, можете відключити його на короткий час або назавжди. Це неймовірно зручно, але! Ми нагадуємо, що Calico не вміє зараз автоматично визначати MTU (ця функція запланована в наступних версіях), тому не забувайте налаштовувати MTU, якщо ваша мережа підтримує Jumbo Frames (MTU 9000).
Окрім іншого, зверніть увагу, що Cilium вміє шифрувати трафік між вузлами кластера (а не тільки між Pod), що може бути дуже актуальним для публічних вузлів кластера.
Як висновок я пропоную наступні варіанти використання:
- Потрібен CNI для сильно дрібного кластера, АБО мені не потрібна безпека: працюйте з Фланель, найбільш легким та стабільним CNI (він же один із найстаріших, його за легендою винайшов Homo Kubernautus чи Homo Contaitorus). Також вас можливо зацікавить геніальний проект , Перевірте!
- Потрібен CNI для звичайного кластера: коленкор - Ваш вибір, але не забувайте налаштувати MTU, якщо воно потрібне. Легко та невимушено можна грати з мережевими політиками, включати та вимикати шифрування тощо.
- Потрібен CNI для (дуже) великомасштабного кластера: ну, тест не показує поведінку великих кластерів, я був би радий провести тести, але у нас немає сотень серверів із підключенням 10гбітс. Так що найкращий варіант - запуск модифікованого тесту на ваших вузлах, хоча б з Calico та Cilium.
Джерело: habr.com