Нещодавно я працював над контентом PaaS, і щойно познайомився з Kubernetes, що стосується покриття мережі, тобто комунікації між крос-хост-контейнерами. Отже, з'явилася низка відкритих компонентів, таких як фланель, каліко, weave тощо. Тут переважно Calico та Fannel.
Принцип фланелевої
Flannel, проєкт, розроблений CoreOS, ймовірно, є найпрямішим і найпопулярнішим плагіном CNI. Це один із найзріліших прикладів архітектури мережі в системах оркестрації контейнерів і розроблений для забезпечення кращої міжконтейнерної та міжхостової мережі. З появою концепції CNI плагін Flannel CNI став одним із перших впроваджень.
Flannel відносно легко встановлювати та налаштовувати порівняно з іншими варіантами. Він упакований як єдиний бінарний FlannelD, і багато поширених інструментів розгортання кластерів Kubernetes та багато дистрибутивів Kubernetes можуть встановлювати Flannel за замовчуванням. Flannel може використовувати існуючий etcd-кластер кластера Kubernetes для зберігання інформації про стан через API, тому не потребує виділеного сховища даних.
Flannel налаштовує мережу накладання IPv4 рівня 3. Вона створює велику внутрішню мережу, яка охоплює всі вузли кластера. У цій накладній мережі кожен вузол має підмережу, яка використовується для внутрішнього призначення IP-адрес. Під час налаштування контейнера інтерфейс мосту Docker на кожному вузлі призначає адресу кожному новому контейнеру. Поди на одному хості можуть спілкуватися через мости Docker, тоді як поди на різних хостах використовують фланель, щоб інкапсулювати свій трафік у UDP-пакети, щоб їх можна було маршрутизувати до відповідного пункту призначення.
Flannel має кілька різних типів бекендів, які можна використовувати для інкапсуляції та маршрутизації. За замовчуванням і рекомендованим підходом є використання VXLAN, оскільки VXLAN працює краще і потребує менше ручного втручання.
Каліко-архітектура
Каліко включає такі важливі компоненти: Felix, etcd, BGP Client та BGP Route Reflector. Нижче наведено пояснення кожного з цих компонентів.
Фелікс: Головним чином відповідає за налаштування маршрутизації, налаштування правил ACLS та доставку, існує на кожному вузлі.
etcd: Розподілене сховище значення ключа, головним чином відповідальне за узгодженість метаданих мережі, забезпечення точності стану мережі Calico і може бути спільно використане з Kubernetes;
BGPClient (BIRD) головним чином відповідає за розподіл інформації про маршрутизацію, написану Феліксом, до ядра до поточної мережі Calico для забезпечення ефективності комунікації між робочими навантаженнями.
BGPRoute Reflector (BIRD) використовується у масштабних розгортаннях, відмовляючись від mesh-режиму з'єднання всіх вузлів і застосовуючи один або кілька BGPRoute Reflectors для централізованої маршрутизації та розподілу.
Принцип каліко
Як показано на наступній діаграмі, процес зображено від контейнера джерела через хост-джерело, через маршрутизацію дата-центру, і нарешті до хоста призначення, і нарешті призначається контейнеру призначення.
Контраст
З наведеного вище принципу видно, що фланель виконує операції розпакування пакетів на основі маршрутизації пересилання, що марнує обчислювальні ресурси процесора. Нижче наведена діаграма порівнює продуктивність різних компонентів відкритих мереж, знайдених онлайн. Видно, що за пропускною здатністю та затримкою мережі продуктивність Calico та хоста схожа.
|
Опубліковано 09.11.2020 11:23:01
|
|
|
|
