Kubernetes, мережі та пошук VMware Cloud Native

Томас Граф є співзасновником і технічним директором Ізовалентнийі творець популярної мережевої технології з відкритим вихідним кодом (і хмарної) під назвою Циліум. Cilium побудовано на основі технології Linux на рівні ядра під назвою eGMP.

У цьому інтерв’ю Граф обговорює роль, яку Cilium і eBPF відіграють у зростаючій хмарній мережевій екосистемі, а також деякі ширші тенденції щодо впровадження та еволюції Kubernetes. Він пояснює, хто використовує та купує Kubernetes у великих підприємствах, де хмарна інфраструктура все ще потребує вдосконалення та як прагнення до стандартизації стимулює інновації.

---

МАЙБУТНЄ: Як ми маємо думати про eBPF і Cilium у контексті обчислень і мереж, загалом, а потім конкретно в контексті рідна екосистема хмари?

ТОМАС ГРАФ: Загалом, eBPF — це технологія, і вона надзвичайно низького рівня. Його розроблено для розробників ядра, і я маю досвід розробки ядра. eBPF – це для ядра, для операційної системи, те ж саме, що JavaScript для браузера. Це робить операційну систему програмованою так само, як JavaScript робить браузер програмованим. Раніше нам доводилося оновлювати версії наших веб-переглядачів, щоб реально використовувати певні веб-сайти. А потім з’явився JavaScript, і раптом команди додатків і розробники змогли створювати величезні додатки — до того моменту, коли найпопулярнішу програму для обробки тексту замінили додатком у браузері. Це призвело до величезної хвилі інновацій. 

Те ж саме відбувається з eBPF, хоча на рівні операційної системи, тому що раптом ми можемо робити речі на рівні ядра або операційної системи, де ми бачимо все та контролюємо все — що дуже важливо для безпеки — без необхідності змінювати ядро вихідний код. По суті, ми можемо завантажувати програми в ядро, щоб розширити його функціональність і додати нові можливості. Це також відкрило масову хвилю інновацій. Такі гіпермасштабувальники, як Facebook, Google і Netflix, використовують це самостійно, напряму, зі своїми власними командами ядра. 

Cilium використовує технологію eBPF низького рівня, щоб по суті забезпечити нову хвилю інфраструктури програмного забезпечення, особливо для хмарної власної хвилі. Подумайте про це як про програмно-визначену мережу та про те, що Nicira, яка стала VMware NSX, зробила для галузі віртуалізації. Ми робимо те саме для нативної хмари, де це поєднання хмарної інфраструктури або загальнодоступної хмарної інфраструктури, а також локальної інфраструктури. І ми вирішуємо випадки використання мереж, безпеки та спостережливості на рівні інфраструктури.

А щойно випущений Cilium Service Mesh є розвитком цих можливостей?

Те, що зараз відбувається, приблизно рік тому, це те, що два простори стикаються. Те, що Cilium робив досі, зосереджено на мережах, віртуалізованих мережах, а потім на хмарних мережах — але все одно мережах. Але потім, переходячи до цього зверху вниз, чим займалися команди прикладних програм у Twitter і Google сервісна сітка речі — спочатку в додатку, а потім у моделі на основі сайдколаса, моделі на основі проксі, що є тим, що проекти люблять Істіо доставити. І тепер ці два шари зближуються, тому що традиційні підприємства приходять у рідний світ хмари, і вони мають корпоративні мережеві вимоги, але їхні команди додатків також хочуть сітку сервісу. 

Gartner називає цей новий рівень «сервісним підключенням» — ми побачимо, чи цей термін заживе, — але по суті це рівень, який включає корпоративну мережеву частину та службову мережеву частину, яка надходить від команд програм. І оскільки клієнти вимагають саме цього, ми додали ці можливості в сам Cilium. Таким чином, по суті, Cilium йде вгору з корпоративної мережевої сторони, а сервісні сітки опускаються до більшої частини мережевої сторони.

Чому стільки уваги приділяється мережевим і сервісним сітчастим рівням стеку Kubernetes?

Оскільки з бажанням працювати в кількох хмарах і розділяти програми на контейнери, рівень зв’язку став центральним. Те, що раніше було, можливо, міжпроцесним зв’язком і проміжним програмним забезпеченням, тепер є мережею, тому мережа стає абсолютно необхідною для спілкування програм між собою та для потоку даних. 

Зокрема, у хмарі, мультихмарність стає абсолютно необхідною. Усі хмарні постачальники мають власні мережеві рівні, але, звичайно, адаптовані до власних хмар. У них є локальні пропозиції, але вони не є справді мультихмарними. Cilium і eBPF створюють багатохмарний агностичний рівень. Він поводиться точно так само локально, як і в загальнодоступній хмарі. Кілька провайдерів загальнодоступних хмарних технологій використовують Cilium під капотом для своїх керованих пропозицій Kubernetes, а телекомунікаційні компанії використовують його для локальної інфраструктури 5G. Йдеться про спілкування обома мовами та об’єднання цих світів.

Ось чому на цьому так багато уваги: ​​адже один із найпростіших способів для хмарних провайдерів заблокувати клієнтів — це володіти цим рівнем підключення. Я думаю, що з точки зору стратегічної інфраструктури, так само, як рівень віртуалізації був ключовим, тепер рівень зв’язку та мережевий рівень є абсолютно ключовим.

Джерелом [майбутніх] інновацій буде відкритий вихідний код, а клієнтами та користувачами, які керуватимуть попитом, будуть компанії, що знаходяться на один рівень нижче від гіпермасштабувальників — і без того значні компанії, які все ще є дуже руйнівними.

На даний момент Kubernetes досить широко прийнятий і прийнятий, але в деяких колах все ще говорять, що це надмірність. Як ви думаєте, для кого призначений Kubernetes і хмарна екосистема загалом?

Це для сучасних команд прикладних програм. Я вважаю, що усвідомлення того, що якщо ви хочете залучити сучасні команди додатків і мати можливість швидко вийти на ринок, вам потрібно надати їм рідну хмарну інфраструктуру. Ми часто бачимо прототипування — початкове, перед MVP, навіть перевірку концепції або внутрішній продаж — на безсерверній основі, щось на зразок Lambda. А потім на Kubernetes, оскільки команди програми можуть безпосередньо володіти інфраструктурою. А потім, коли він переходить у виробництво, вони переходять до корпоративних локальних дистрибутивів Kubernetes. Але насправді це відносно невелика частина всієї інфраструктури, можливо, один або невеликий двозначний відсоток. 

Однак це явно буде новий стандарт. Подібно до того, як впровадження віртуалізації спочатку було дуже повільним, і люди казали, що це надмірно — але з часом, звичайно, вона почала замінювати більшість речей — ми побачимо те саме тут. Або як із сучасними мовами. Люди казали, що Java надмірна, і, ймовірно, вона все ще є для багатьох програм, але був час, коли було дуже важко розробляти будь-яку програму поза Java, тому що це те, що більшість розробників програм могли писати. Те саме буде бути вірним для сучасних команд розробки додатків: вони очікують наявності Kubernetes, щоб розвивати гнучкість і швидко виводити продукт на ринок.

З точки зору інфраструктури це може бути трохи надмірним, але якщо альтернативою є переписати програму з безсерверної на локальну, це величезне завдання. Тож Kubernetes — це золота середина, що дуже привабливо. 

А як щодо ідеї, що Kubernetes усе ще потребує кращого досвіду розробника?

Якщо ми подивимося на оригінальний OpenShift, до того, як він перебазувався на Kubernetes, це було так. Це було ще ближче до команди додатків і було ще кращим досвідом для розробників додатків. Ви можете надіслати Git, і він автоматично розгорнеться. Heroku також спробував це, але на основі SaaS. 

Kubernetes зробив крок назад і сказав: «Нам потрібно зберегти в ньому деякі операційні аспекти та зробити його трохи ближчим до того, чого очікує системний адміністратор. Ми не можемо бути адаптованими лише до програм». Це золота середина: вона повинна бути достатньо привабливою для команд додатків, але все одно повинна бути можливість запускати цю програму поза певним середовищем і щоб нею керували люди, не розробники програм.

Я б сказав, що найбільшим кроком між Docker і Kubernetes було те, що Docker був пов’язаний із досвідом розробника. Це вирішило цю частину, але не вирішило частину екосистеми публічної хмари.

Як ми дійшли до цього моменту? Чи це була природна еволюція від платформи як послуги (PaaS) і контейнерів додатків?

Це були зображення Docker і аспект упаковки Docker. Стара школа полягала в тому, як розгортати на віртуальних машинах, і навколо цього були всі види автоматизації. А ще було те, що Facebook робив із Tupperware — дуже спеціально розробленим і для справді великого масштабу. А потім з’явився Docker і, по суті, надав цей образ контейнера, і кожен міг розглядати його як мініатюрну віртуальну машину. Тепер я можу розповсюджувати свою програму, і замість віртуального зображення розміром 600 МБ тепер це контейнер розміром 10 МБ. Але ви можете ставитися до нього так само, у нього є все необхідне. 

Це розблокувало можливість запровадити такий оркестровник, як Kubernetes, який усе ще дозволяє обробляти програми як міні-ВМ, але потім також зробити ще один крок далі та фактично розглядати їх як мікросервіси. Це дозволяє робити і те, і інше.

Я б сказав, що найбільшим кроком між Docker і Kubernetes було те, що Docker був пов’язаний із досвідом розробника. Це вирішило цю частину, але не вирішило частину екосистеми публічної хмари. Він не мав тісної інтеграції з хмарними провайдерами або обов’язково бажав її. Kubernetes вирішив це. 

Хто, на вашу думку, керує Kubernetes у компаніях? Це окремі групи заявок?

Є цікава зміна, яка відбулася з нативною хмарою, яка полягає в тому, що ми маємо підйом «команди платформи», я її називаю. Вони не інженери додатків. Вони мають трохи знань про мережеві операції та мають достатньо знань про безпеку. Вони мають знання SRE і знають, як автоматизувати хмару. Вони надають платформу для команд додатків і розглядають ці команди додатків як своїх клієнтів.

Команди платформ – це ті, хто купує Kubernetes і пов’язані технології, які вони використовують, оскільки їм доручено забезпечити інфраструктуру наступного покоління, щоб зробити сучасні команди додатків щасливими.

Я думаю, що безсумнівно є простір для безсерверної роботи, зокрема для дуже швидкої розробки додатків. Але на підприємствах ми бачимо нативну хмару як новий рівень віртуалізації

Це чистий новий покупець чи чиста нова команда? Або команди платформ схожі на те, що існує в таких місцях, як Google або Facebook, і зараз стає мейнстрімом?

Вони переважно нова команда. Я думаю, що вони певною мірою схожі на команди SRE у Google і Facebook. Однак команди програмного забезпечення, ймовірно, більшою мірою займаються розгортанням додатків на підприємствах, оскільки підприємства не мають такого чіткого розмежування між розробниками програмного забезпечення та SRE, як у Google і Facebook. Я б сказав, що ця еволюція дуже схожа на те, як у вас були команди віртуалізації, а потім багато мережевих операцій перейшли з — або еволюціонували, або вдосконалювалися — з мережі апаратні засоби бути про мережу віртуалізації. І ці команди, наприклад, почали працювати з VMware NSX. Те ж саме відбувається і тут. 

Хоча це не обов’язково новий бюджет. Наприклад, ми бачимо, що бюджети переміщуються від безпеки та мереж до команди цієї платформи, оскільки витрати на хмару збільшуються та менше витрачається на мережеве обладнання. Вони часто співпрацюють із командою безпеки та командою мережевих операцій, щоб отримати бай-ін, але насправді вони володіють досить значним розміром бюджету.

Як ви бачите Фонд хмарних нативних обчислень еволюція, і чи завжди Kubernetes буде в центрі цього — чи в цілому хмарного руху?

Kubernetes – це те, що спровокувало CNCF, і в перші пару років усе було пов’язано з Kubernetes і публічною хмарою. Те, що ми побачили приблизно рік тому, це те, що тепер мова йде не лише про Kubernetes, це насправді більше про рідну хмару Принципи. Фактично це означає, що це вже не обов’язково хмара, навіть не приватна хмара. Часто це навіть традиційні корпоративні мережі, нудна локальна інфраструктура, «голі» сервери та все таке, але з вбудованими принципами хмари. 

Нова норма тепер є гібридною та включає кілька публічних хмарних провайдерів, а також локальну інфраструктуру. Компанії хочуть забезпечити таку саму гнучкість розробника додатків, або забезпечити спостережливість за допомогою сучасних хмарних інструментів, або забезпечити безпеку за допомогою сучасних хмарних інструментів — наприклад, автентифікація, а не просто сегментація чи контроль на основі ідентичності — усі ці нові хмарні власні концепції на наявна інфраструктура. 

Ми бачимо дуже сильний попит на підключення до старого світу та спілкування MPLS, VLAN, sFlow і NetFlow — увесь існуючий набір корпоративних вимог. Ніхто з них не пішов.

Приблизно через десять років хмарний рідний простір не здається примхою. Скільки є можливості для подальшого розвитку?

Безумовно, був час, коли це було так: «О, Kubernetes, ймовірно, недовговічний, і наступним рівнем стане безсерверний режим». Або: «Kubernetes схожий на OpenStack. Або: «Це зникне, і це буде деталь впровадження». І цього не сталося. 

Я думаю, що безсумнівно є простір для безсерверної роботи, зокрема для дуже швидкої розробки додатків. Але на підприємствах ми бачимо нативну хмару як новий рівень віртуалізації, і ми вважаємо, що вона має такий самий термін придатності, як віртуалізація. Це означає, що ми знаходимося на самому початку міграції в хмару.

Які великі проблеми ще потрібно вирішити на рівні інфраструктури?

Ми бачимо підприємства в ситуації, коли раптом, хочуть вони цього чи ні, їм потрібна багатохмарна стратегія. Оскільки вони також мають локальну інфраструктуру, їм тепер потрібна гібридна хмарна стратегія на додаток до цього. І їм потрібно з’ясувати, як забезпечити безпеку та інші функції універсально в цій інфраструктурі, не замикаючись у певній публічній хмарі. 

Отже, це наступне важливе завдання: хто буде тим агностичним рівнем для мультихмарних і хмарних нативних технологій, як це стало VMware? Хто стане вихідцем із VMware for cloud?

Я думаю, що усвідомлення того, що якщо ви хочете залучити сучасні команди додатків і мати можливість швидко вийти на ринок, вам потрібно надати їм рідну хмарну інфраструктуру.

І хоча сучасним веб-компаніям, які першими прийняли рішення, впровадження хмарних технологій було відносно легким, проблема, з вашої точки зору, полягає в створенні нових технологій, які подолають розрив між сучасним світом та існуючими корпоративними інструментами та системами?

Найважче те, що сучасні команди додатків звикли до того, що рівень інфраструктури розвивається так само швидко, як вони. І це змусило рівень інфраструктури бути ще більш програмованим, більш настроюваним. Ось чому ми фактично бачимо мережевий рівень і рівень безпеки поверх хмарного мережевого рівня. Але зараз до нас приходять підприємства, і ми бачимо дуже сильний попит на підключення до старого світу та спілкування з MPLS, VLAN, sFlow і NetFlow — усім існуючим набором корпоративних вимог. Жоден із них не зник, усі правила відповідності залишаються незмінними. І навіть деякі сучасні компанії SaaS зараз стикаються з цими проблемами, коли вони ростуть і піклуються про дотримання вимог і так далі. 

З технологічної точки зору мова йде про те, як підключити цей новий рідний хмарний світ до існуючих вимог підприємства. Оскільки багато з цих проблем були приховані постачальниками публічних хмар. Провайдери публічної хмари вирішили проблеми відповідності, але вони не відкрили вихідний код і не опублікували нічого з цього; вони вирішили це самостійно. Це частина значення хмари. Підприємствам тепер потрібно перебудувати та придбати це, якщо вони не хочуть замикатися в публічних хмарних пропозиціях.

Звідки ви бачите наступну хвилю хмарних інновацій? Чи все ще надходить від такої компанії, як Google, чи є компанія нового типу, яка лідирує?

Це дуже цікаво. Я б сказав, що це, мабуть, не від Google і Facebook. Джерелом інновацій буде відкритий вихідний код, а клієнтами та користувачами, які керуватимуть попитом, будуть компанії, які на один рівень нижче від гіпермасштабувальників — і без того значні компанії, які все ще є дуже руйнівними, як Adobe, Shopify або GitHub. Але також компанії, яким загрожує технологія, наприклад фінансові послуги, страхові компанії та телекомунікаційні компанії. Усі ці компанії мають спільний інтерес у стандартизації інфраструктури з повторюваними моделями розробки та інфраструктури.

Опубліковано 26 липня 2022 р