Kubernetes, sieci i znajdowanie oprogramowania VMware natywnego dla chmury

Thomas Graf jest współzałożycielem i CTO firmy Izowalentnyoraz twórca popularnej technologii sieciowej typu open source (i natywnej dla chmury) o nazwie Migawka. Cilium jest zbudowany na technologii Linux na poziomie jądra o nazwie eGMP.

W tym wywiadzie Graf omawia role, jakie Cilium i eBPF odgrywają w rozwijającym się ekosystemie sieciowym natywnym dla chmury, a także niektóre szersze trendy związane z przyjęciem i ewolucją Kubernetes. Wyjaśnia, kto używa i kupuje Kubernetes w dużych przedsiębiorstwach, gdzie infrastruktura natywna dla chmury wciąż wymaga poprawy i jak pragnienie standaryzacji napędza innowacje.

---

PRZYSZŁOŚĆ: Jak powinniśmy myśleć o eBPF i Cilium ogólnie w kontekście informatyki i sieci, a następnie konkretnie w kontekście natywny ekosystem chmury?

TOMASZ GRAF: Ogólnie rzecz biorąc, eBPF jest technologią i jest bardzo niski. Został zaprojektowany dla programistów jądra, a moje doświadczenie dotyczy rozwoju jądra. eBPF jest dla jądra, dla systemu operacyjnego tym, czym JavaScript dla przeglądarki. Sprawia, że ​​system operacyjny jest programowalny, podobnie jak JavaScript sprawia, że ​​programowalna jest przeglądarka. W przeszłości musieliśmy aktualizować nasze wersje przeglądarek, aby rzeczywiście korzystać z niektórych witryn. A potem pojawił się JavaScript i nagle zespoły aplikacji i programiści mogli tworzyć ogromne aplikacje — do tego stopnia, że ​​najpopularniejsza aplikacja do edycji tekstu została zastąpiona aplikacją w przeglądarce. Doprowadziło to do ogromnej fali innowacji. 

To samo dzieje się z eBPF, chociaż na poziomie systemu operacyjnego, ponieważ nagle możemy robić rzeczy na poziomie jądra lub systemu operacyjnego, gdzie wszystko widzimy i kontrolujemy — co jest bardzo ważne dla bezpieczeństwa — bez konieczności zmiany jądra kod źródłowy. Zasadniczo możemy załadować programy do jądra, aby rozszerzyć jego funkcjonalność i wprowadzić do niego nowe możliwości. To również odblokowało ogromną falę innowacji. Osoby zajmujące się hiperskalowaniem, takie jak Facebook, Google i Netflix, używają tego samodzielnie, bezpośrednio, we własnych zespołach jądra. 

To, co Cilium wnosi do tabeli, to wykorzystanie niskopoziomowej technologii eBPF, aby zasadniczo zapewnić nową falę infrastruktury oprogramowania, szczególnie dla fali natywnej dla chmury. Pomyśl o tym jak o sieciach definiowanych programowo i o tym, co Nicira, która stała się VMware NSX, zrobiła dla branży wirtualizacji. To samo robimy w przypadku natywnej chmury, gdzie jest to połączenie dostawcy chmury lub infrastruktury chmury publicznej, a także infrastruktury lokalnej. Rozwiązujemy przypadki użycia sieci, bezpieczeństwa i obserwowalności za pomocą tego w warstwie infrastruktury.

A Cilium Service Mesh, który właśnie został wydany, jest ewolucją tych możliwości?

To, co dzieje się obecnie, od około roku, to zderzenie tych dwóch przestrzeni. To, co Cilium robi do tej pory, koncentruje się na sieciach, sieciach zwirtualizowanych, a następnie sieciach natywnych w chmurze — ale nadal sieci. Ale potem, idąc od góry do dołu, robiły to zespoły aplikacji na Twitterze i Google siatka serwisowa rzeczy — najpierw w aplikacji, a potem w modelu opartym na sidecar, model oparty na proxy, czyli to, co lubią projekty Podobnie dostarczyć. A teraz te dwie warstwy zbliżają się, ponieważ tradycyjne przedsiębiorstwa wkraczają w natywny świat chmury i mają wymagania dotyczące sieci korporacyjnych, ale ich zespoły zajmujące się aplikacjami również chcą mieć siatkę usług. 

Gartner nazywa tę nową warstwę „łącznością usługową” — zobaczymy, czy ten termin się przyjmie — ale zasadniczo jest to warstwa, która zawiera element sieci korporacyjnej i element siatki usług, który pochodzi od zespołów aplikacyjnych. A ponieważ tego wymagają klienci, dodaliśmy te możliwości do samego Cilium. Zasadniczo Cilium idzie w górę od strony sieci korporacyjnej, a siatki usług przechodzą w dół w kierunku sieci.

Dlaczego tak bardzo skupia się na poziomie sieci i sieci usług stosu Kubernetes?

Ponieważ z chęcią działania w wielu chmurach i dzielenia aplikacji na kontenery, warstwa łączności stała się centralna. To, co kiedyś było być może komunikacją między procesami i oprogramowaniem pośredniczącym, jest teraz siecią, więc sieć staje się absolutnie niezbędna, aby aplikacje mogły się ze sobą komunikować i przepływać danych. 

A w szczególności w wersji cloud native multicloud staje się absolutnie niezbędny. Wszyscy dostawcy chmury mają własne warstwy sieciowe, ale oczywiście dostosowane do własnych chmur. Mają oferty lokalne, ale tak naprawdę nie działają w wielu chmurach. Cilium i eBPF wprowadzają na stół wielochmurową, agnostyczną warstwę. Zachowuje się dokładnie tak samo lokalnie, jak w chmurze publicznej. Kilku dostawców chmury publicznej używa Cilium pod maską do swoich zarządzanych ofert Kubernetes, a operatorzy telekomunikacyjni używają go do lokalnej infrastruktury 5G. Chodzi o mówienie w obu językach i łączenie tych światów.

Dlatego tak bardzo się na tym skupiamy: ponieważ jednym z najłatwiejszych sposobów, w jaki dostawcy usług w chmurze mogą zablokować klientów, jest posiadanie tej warstwy łączności. Myślę, że z perspektywy infrastruktury strategicznej, tak jak warstwa wirtualizacji była kluczowa, teraz warstwa łączności i sieci jest absolutnie kluczowa.

Źródłem [przyszłych] innowacji będzie oprogramowanie typu open source, a klientami i użytkownikami napędzającymi popyt będą firmy o jeden poziom niżej od hiperskalerów — już duże firmy, które nadal są wysoce destrukcyjne.

Kubernetes jest obecnie dość powszechnie akceptowany i przyjęty, ale w niektórych kręgach wciąż mówi się o przesadzeniu. Jak myślisz, dla kogo jest Kubernetes i ogólnie ekosystem natywny dla chmury?

To dla nowoczesnych zespołów aplikacyjnych. Myślę, że uświadomienie sobie, że jeśli chcesz przyciągnąć nowoczesne zespoły aplikacji i mieć możliwość szybkiego wejścia na rynek, musisz zapewnić im natywną infrastrukturę chmurową. Często widzimy prototypowanie — wstępne, przed MVP, a nawet sprawdzanie koncepcji lub sprzedaż wewnętrznie — na bezserwerowym, czymś takim jak Lambda. A potem na Kubernetes, ponieważ zespoły zajmujące się aplikacjami mogą bezpośrednio posiadać infrastrukturę. A następnie, gdy przechodzi do produkcji, przechodzą do korporacyjnych, lokalnych dystrybucji Kubernetes. Ale w rzeczywistości jest to stosunkowo niewielka część całej infrastruktury, może jedno- lub dwucyfrowy procent. 

Z pewnością będzie to jednak nowy standard. Podobnie jak przyjęcie wirtualizacji było początkowo bardzo powolne i ludzie mówili, że to przesada – ale z czasem oczywiście zaczęła zastępować większość rzeczy – zobaczymy to samo tutaj. Lub tak jak we współczesnych językach. Ludzie mówili, że Java to przesada i prawdopodobnie nadal jest dla wielu aplikacji, ale był czas, w którym tworzenie aplikacji poza Javą stało się bardzo trudne, ponieważ większość programistów aplikacji może w tym pisać. być prawdziwe dla nowoczesnych zespołów aplikacji: będą oczekiwać, że Kubernetes będzie w pobliżu, aby rozwijać się bardziej sprawnie i szybko wprowadzać produkt na rynek.

Po stronie infrastruktury może to być trochę przesada, ale jeśli alternatywą jest przepisanie aplikacji z bezserwerowej na lokalną, jest to ogromne zadanie. Tak więc Kubernetes jest tam środkiem pośrednim, co jest bardzo atrakcyjne. 

A co z pomysłem, że Kubernetes wciąż potrzebuje lepszego doświadczenia programisty?

Jeśli spojrzymy na oryginalny OpenShift, zanim przekształcił się w Kubernetes, to było to. Był jeszcze bliżej zespołu aplikacji i był jeszcze lepszym doświadczeniem dla programistów aplikacji. Mógłbyś wypchnąć do Gita, a on automatycznie się wdroży. Heroku też tego próbował, ale oparty na SaaS. 

Kubernetes cofnął się o krok i powiedział: „Musimy zachować w nim pewne aspekty operacyjne i nieco zbliżyć go do tego, czego oczekiwałby administrator. Nie możemy być dostosowani tylko do aplikacji.” Jest to środek: musi być wystarczająco atrakcyjny dla zespołów aplikacji, ale nadal musi być możliwe uruchamianie tej aplikacji poza określonym środowiskiem i zarządzanie nią przez osoby inne niż programiści aplikacji.

Powiedziałbym, że największym krokiem między Dockerem a Kubernetes było to, że Docker dotyczył wyłącznie doświadczenia programisty. To rozwiązało tę część, ale nie rozwiązało części ekosystemu chmury publicznej.

Jak doszliśmy do tego punktu? Czy była to naturalna ewolucja od platformy jako usługi (PaaS) i kontenerów aplikacji?

Były to obrazy Dockera i aspekt pakowania Dockera. Stara szkoła polegała na wdrażaniu na maszynach wirtualnych, a wokół tego było wiele rodzajów automatyzacji. A potem było to, co Facebook robił z Tupperware – bardzo niestandardowym i na naprawdę dużą skalę. A potem pojawił się Docker i zasadniczo dostarczył ten obraz kontenera i każdy mógł go traktować jak miniaturową maszynę wirtualną. Mogę teraz rozpowszechniać moją aplikację i zamiast obrazu wirtualnego o wielkości 600 MB, jest to teraz kontener 10 MB. Ale możesz traktować go tak samo, ma wszystko, czego potrzebuje. 

To odblokowało możliwość wprowadzenia koordynatora, takiego jak Kubernetes, który nadal pozwala traktować aplikacje jak mini maszyny wirtualne, ale także pójść o krok dalej i faktycznie traktować je jako mikrousługi. Pozwala to zrobić jedno i drugie.

Powiedziałbym, że największym krokiem między Dockerem a Kubernetes było to, że Docker dotyczył wyłącznie doświadczenia programisty. To rozwiązało tę część, ale nie rozwiązało części ekosystemu chmury publicznej. Nie miał ani nie koniecznie chciał ścisłej integracji z dostawcami chmury. Kubernetes to rozwiązał. 

Kogo widzisz kierującego Kubernetes w firmach? Czy to indywidualne zespoły aplikacyjne?

Jest ciekawa zmiana, która nastąpiła w przypadku natywnych rozwiązań w chmurze, a mianowicie, że mamy do czynienia z rozwojem „zespołu platformowego”, ja to nazwałbym. Nie są inżynierami aplikacji. Mają trochę wiedzy na temat operacji sieciowych i mają całkiem sporo wiedzy o bezpieczeństwie. Mają wiedzę na temat SRE i wiedzą, jak wykonać automatyzację w chmurze. Dostarczają platformę dla zespołów aplikacyjnych i traktują te zespoły aplikacyjne jak swoich klientów.

Zespoły platformowe to te, które kupują Kubernetes i powiązane technologie, których używają, ponieważ ich zadaniem jest zapewnienie infrastruktury nowej generacji, aby uszczęśliwić nowoczesne zespoły aplikacji.

Myślę, że na pewno jest miejsce na bezserwerowe, w szczególności na bardzo szybkie tworzenie aplikacji. Jednak w przedsiębiorstwach natywna chmura jest postrzegana jako nowa warstwa na szczycie wirtualizacji

Czy to nowy nabywca netto, czy nowy zespół? A może zespoły platformowe to coś, co istnieje w miejscach takich jak Google czy Facebook, a teraz wchodzi do głównego nurtu?

To głównie nowy zespół. Myślę, że do pewnego stopnia przypominają zespoły SRE w Google i Facebooku. Jednak zespoły aplikacyjne prawdopodobnie są właścicielami większej liczby wdrożeń aplikacji w przedsiębiorstwach, ponieważ przedsiębiorstwa nie mają tak wyraźnego rozróżnienia między inżynierami oprogramowania a SRE, takimi jak Google i Facebook. Powiedziałbym, że ta ewolucja jest bardzo podobna do tego, w jaki sposób miałeś zespoły wirtualizacji, a następnie wiele operacji sieciowych migrowało z — lub ewoluowało lub rozwijało się — dotyczyło sieci sprzęt komputerowy do bycia w sieci wirtualizacja. I te zespoły, na przykład, zaczęły obsługiwać VMware NSX. To samo dzieje się tutaj. 

Chociaż niekoniecznie jest to nowy budżet. Widzimy, że budżety przesuwają się z bezpieczeństwa i sieci do tego zespołu platformy, na przykład, gdy wydatki na chmurę rosną, a mniej na sprzęt sieciowy. Często współpracują z zespołem ds. bezpieczeństwa i zespołem ds. sieci, aby uzyskać wpisowe, ale w rzeczywistości posiadają dość znaczną część budżetu.

Jak widzisz Fundacja Cloud Native Computing ewoluuje i czy Kubernetes zawsze będzie w centrum tego — czy ogólnie w ruchu natywnym dla chmury?

Kubernetes jest tym, co zainicjowało CNCF, a przez pierwsze kilka lat chodziło o Kubernetes i chmurę publiczną. To, co widzieliśmy od około roku, to to, że teraz nie chodzi już tylko o Kubernetes, ale bardziej o natywną chmurę Zasady. W rzeczywistości oznacza to, że niekoniecznie jest to już chmura, nawet prywatna chmura. Często jest to nawet tradycyjna sieć korporacyjna, nudna infrastruktura lokalna, serwery bare-metal i wszystko to, ale z wbudowanymi zasadami natywnymi dla chmury. 

Nowa norma jest teraz hybrydowa i obejmuje wielu dostawców chmury publicznej, a także infrastrukturę lokalną. Firmy chcą zapewnić taką samą elastyczność dla programistów aplikacji, zapewnić możliwość obserwowania za pomocą nowoczesnych narzędzi natywnych dla chmury lub zapewnić bezpieczeństwo za pomocą nowoczesnych narzędzi natywnych dla chmury — na przykład uwierzytelnianie zamiast tylko segmentacji lub egzekwowania opartego na tożsamości — wszystkie te nowe koncepcje natywne dla chmury istniejąca infrastruktura. 

Widzimy bardzo silne zapotrzebowanie, aby nadal łączyć się ze starym światem i rozmawiać MPLS, VLAN, sFlow i NetFlow — cały istniejący zestaw wymagań korporacyjnych. Żaden z nich nie odszedł.

Po mniej więcej dekadzie natywna przestrzeń dla chmury nie wydaje się być chwilową modą. Ile jest miejsca, aby dalej ewoluować?

Na pewno był czas, w którym brzmiało: „Och, Kubernetes jest prawdopodobnie krótkotrwały, a następną warstwą będzie bezserwerowy”. Lub „Kubernetes jest podobny do OpenStack. Lub: „Zniknie i będzie to szczegół wdrożenia”. I tak się nie stało. 

Myślę, że na pewno jest miejsce na bezserwerowe, w szczególności na bardzo szybkie tworzenie aplikacji. Jednak w przedsiębiorstwach postrzegamy chmurę natywną jako nową warstwę poza wirtualizacją i uważamy, że ma ona podobny okres trwałości jak wirtualizacja. Co oznacza, że ​​jesteśmy na samym początku migracji natywnej do chmury.

Jakie duże problemy należy jeszcze rozwiązać na poziomie infrastruktury?

Widzimy przedsiębiorstwa w sytuacji, w której nagle, czy tego chcą, czy nie, potrzebują strategii multicloud. Ponieważ mają również infrastrukturę lokalną, potrzebują teraz dodatkowo strategii chmury hybrydowej. Muszą też dowiedzieć się, jak stosować zabezpieczenia i inne funkcje uniwersalnie w tej infrastrukturze bez zamykania się w konkretnej chmurze publicznej. 

A więc jest to kolejne duże wyzwanie: kto będzie tą warstwą agnostyczną dla multi-cloud i cloud native, jak to, czym stało się VMware? Kto będzie VMware natywnym dla chmury?

Myślę, że uświadomienie sobie, że jeśli chcesz przyciągnąć nowoczesne zespoły aplikacji i mieć możliwość szybkiego wejścia na rynek, musisz zapewnić im natywną infrastrukturę chmurową.

I chociaż adopcja natywnych rozwiązań chmurowych mogła być stosunkowo łatwa dla nowoczesnych firm internetowych, które wcześniej ją wdrażały, wyzwaniem z Twojej perspektywy jest zbudowanie nowych technologii, które wypełnią lukę między współczesnym światem a istniejącymi narzędziami i systemami dla przedsiębiorstw?

Najtrudniejsze jest to, że nowoczesne zespoły aplikacji są przyzwyczajone do tego, że warstwa infrastruktury ewoluuje tak szybko, jak one. A to zmusiło warstwę infrastruktury do jeszcze większej programowalności i większej elastyczności. Dlatego właśnie widzimy warstwę sieciową i warstwę bezpieczeństwa nad warstwą sieci w chmurze. Ale teraz pojawiają się przedsiębiorstwa i widzimy bardzo duże zapotrzebowanie, aby nadal łączyć się ze starym światem i rozmawiać MPLS, VLAN, sFlow i NetFlow — cały istniejący zestaw wymagań korporacyjnych. Żadne z nich nie zniknęło, wszystkie zasady zgodności są nadal takie same. I nawet niektóre nowoczesne firmy SaaS stają w obliczu tych wyzwań, gdy się rozrastają i dbają o zgodność i tak dalej. 

Z punktu widzenia technologii chodzi o to, jak połączyć ten nowy natywny świat chmury z istniejącymi wymaganiami przedsiębiorstwa. Ponieważ wiele z tych problemów zostało ukrytych przez dostawców chmury publicznej. Dostawcy chmury publicznej rozwiązali problemy ze zgodnością, ale nie udostępnili ani nie opublikowali żadnego z nich; rozwiązali to sami. To część wartości chmury. Przedsiębiorstwa muszą teraz je odbudować i kupić, jeśli nie chcą zamykać się w ofertach chmury publicznej.

Skąd widzisz następną falę innowacji natywnych dla chmury? Czy nadal pochodzi od firmy takiej jak Google, czy też istnieje nowy rodzaj firmy prowadzącej opłatę?

To bardzo interesujące. Powiedziałbym, że prawdopodobnie nie pochodzi z Google'a i Facebooka. Źródłem innowacji będzie oprogramowanie typu open source, a klientami i użytkownikami napędzającymi popyt będą firmy o jeden poziom niżej od hiperskalerów — już duże firmy, które nadal są bardzo destrukcyjne, takie jak Adobe, Shopify czy GitHub. Ale także firmy narażone na zakłócenia spowodowane technologią, takie jak usługi finansowe, ubezpieczyciele i operatorzy telekomunikacyjni. Wszystkie te firmy mają wspólny interes w standaryzacji infrastruktury za pomocą powtarzalnych modeli rozwoju i infrastruktury.

Opublikowano 26 lipca 2022