Kubernetes, verkkotoiminta ja Cloud Nativen VMwaren löytäminen

Thomas Graf on yksi perustajista ja teknologiajohtaja Isovalentti, ja luonut suositun avoimen lähdekoodin (ja pilvipohjaisen) verkkoteknologian nimeltä ripsi. Cilium on rakennettu ydintason Linux-teknologian päälle eGMP.

Tässä haastattelussa Graf käsittelee Ciliumin ja eBPF:n rooleja kasvavassa pilvipohjaisessa verkkoekosysteemissä sekä joitain laajempia trendejä Kubernetesin käyttöönoton ja kehityksen ympärillä. Hän selittää, kuka käyttää ja ostaa Kubernetesia suurissa yrityksissä, missä pilvipohjaista infrastruktuuria on vielä parannettava ja kuinka standardisointihalu edistää innovaatioita.

---

TULEVAISUUS: Miten meidän pitäisi ajatella eBPF:ää ja Ciliumia tietojenkäsittelyn ja verkkotoiminnan yhteydessä yleensä ja sitten erityisesti pilven natiivi ekosysteemi?

THOMAS GRAF: Kaiken kaikkiaan eBPF on tekniikkaa, ja se on erittäin alhainen. Se on suunniteltu ytimen kehittäjille, ja taustani on ytimen kehittämisessä. eBPF on ytimelle, käyttöjärjestelmälle, mitä JavaScript on selaimelle. Se tekee käyttöjärjestelmästä ohjelmoitavan, kuten JavaScript tekee selaimesta ohjelmoitavan. Aiemmin meidän piti päivittää selainversiomme käyttääksemme tiettyjä verkkosivustoja. Ja sitten JavaScript tuli, ja yhtäkkiä sovellustiimit ja -kehittäjät pystyivät rakentamaan massiivisia sovelluksia - pisteeseen, jossa suosituin tekstinkäsittelysovellus korvattiin selaimen sisäisellä sovelluksella. Se johti valtavaan innovaatioaaltoon. 

Sama tapahtuu eBPF:n kanssa, vaikkakin käyttöjärjestelmätasolla, koska yhtäkkiä voimme tehdä asioita ytimen tai käyttöjärjestelmän tasolla, jossa näemme kaiken ja hallitsemme kaikkea - mikä on erittäin tärkeää turvallisuuden kannalta - ilman, että joudumme vaihtamaan ydintä. lähdekoodi. Voimme käytännössä ladata ohjelmia ytimeen laajentaaksemme sen toimintoja ja tuodaksemme siihen uusia ominaisuuksia. Tämä on myös avannut valtavan innovaatioaallon. Hyperscalerit, kuten Facebook, Google ja Netflix, käyttävät tätä yksinään, suoraan omien ydintiimiensä kanssa. 

Mitä Cilium tuo pöytään, on se, että se käyttää matalan tason eBPF-tekniikkaa olennaisesti uuden ohjelmistoinfrastruktuurin aallon tarjoamiseen, erityisesti pilvipohjaiselle aallolle. Ajattele tätä kuin ohjelmiston määrittämää verkkoa ja sitä, mitä Nicira, josta tuli VMware NSX, teki virtualisointiteollisuudelle. Teemme samoin pilvipohjaiselle sovellukselle, jossa se on sekoitus pilvipalveluntarjoajaa tai julkista pilviinfrastruktuuria sekä paikallista infrastruktuuria. Ratkaisemme verkottumista, turvallisuutta ja havainnointia koskevia käyttötapauksia infrastruktuurikerroksen avulla.

Ja juuri julkaistu Cilium Service Mesh on näiden ominaisuuksien kehitystä?

Tällä hetkellä noin vuosi sitten tapahtuu, että kaksi tilaa törmäävät toisiinsa. Se, mitä Cilium on tähän mennessä tehnyt, on keskittynyt verkottumiseen, virtualisoituun verkottamiseen ja sitten pilvipohjaiseen verkkoon – mutta silti verkottumista. Mutta sitten, ylhäältä alaspäin, sovellusryhmät Twitterissä ja Googlessa tekivät huoltoverkko tavaraa – ensin sovelluksessa ja sitten sivuvaunupohjaisessa mallissa, välityspalvelinpohjaisessa mallissa, josta projektit pitävät Sama toimittaa. Ja nyt nämä kaksi kerrosta tulevat lähemmäksi, koska perinteiset yritykset ovat tulossa pilvipohjaiseen maailmaan, ja niillä on yritysten verkkovaatimukset, mutta heidän sovellustiiminsä haluavat myös palveluverkon. 

Gartner kutsuu tätä uutta kerrosta "palveluliitettävyydeksi" – katsotaan, tuleeko tämä termi kiinni – mutta se on pohjimmiltaan kerros, joka sisältää yrityksen verkko-osan ja sovellustiimeiltä tulevan palveluverkon. Ja koska asiakkaat sitä vaativat, olemme lisänneet ominaisuudet itse Ciliumiin. Joten pohjimmiltaan Cilium on menossa ylöspäin yritysverkkojen puolelta ja palveluverkot menevät alaspäin verkkopuolelle.

Miksi Kubernetes-pinon verkko- ja palveluverkkotasoon kiinnitetään niin paljon huomiota?

Koska halu ajaa useissa pilvissä ja jakaa sovelluksia erilleen kontteihin, yhteyskerroksesta on tullut keskeinen. Se, mikä ennen oli ehkä prosessien välistä viestintää ja väliohjelmistoa, on nyt verkko, joten verkosta on tulossa ehdottoman välttämätön sovellusten keskustelemiseksi toistensa kanssa ja tiedon virtaamiseksi. 

Ja varsinkin natiivipilvessä monipilvi on tulossa ehdottoman välttämättömäksi. Kaikilla pilvipalveluntarjoajilla on omat verkkotasonsa, mutta tietysti räätälöitynä omiin pilviinsä. Heillä on on-prem-tarjontaa, mutta ne eivät todellakaan ole monipilviä. Cilium ja eBPF tuovat pöytään tuon monipilven, agnostisen kerroksen. Se toimii täsmälleen samalla tavalla paikan päällä kuin julkisessa pilvessä. Useat julkiset pilvipalveluntarjoajat käyttävät Ciliumia hallinnassaan Kubernetes-tarjouksissaan, ja puhelinyhtiöt käyttävät sitä on-prem 5G-infrastruktuuriin. Kyse on molempien kielten puhumisesta ja näiden maailmojen yhdistämisestä.

Siksi tähän on kiinnitetty niin paljon huomiota: koska yksi helpoimmista tavoista pilvipalveluntarjoajille lukita asiakkaat sisään on omistaa yhteys. Mielestäni strategisen infrastruktuurin näkökulmasta, aivan kuten virtualisointikerros oli avainasemassa, nyt liitettävyys ja verkkokerros ovat ehdottoman tärkeitä.

[Tulevaisuuden] innovaatioiden lähde on avoimen lähdekoodin lähde, ja kysyntää ohjaavat asiakkaat ja käyttäjät ovat yhden tason alempana hyperskaalajista – jo ennestään suuria yrityksiä, jotka ovat edelleen erittäin häiritseviä.

Kubernetes on tällä hetkellä melko laajalti hyväksytty ja hyväksytty, mutta joissakin piireissä puhutaan edelleen sen ylivoimasta. Kenelle Kubernetes ja pilvipohjainen ekosysteemi ylipäänsä on tarkoitettu?

Se on tarkoitettu nykyaikaisille sovellusryhmille. Uskon, että oivallus on lähtenyt liikkeelle, että jos haluat houkutella nykyaikaisia ​​sovellustiimejä ja saada nopeat markkinoilletuloajat, sinun on tarjottava heille natiivi pilviinfrastruktuuri. Näemme usein prototyyppien - alkuperäisen, MVP:tä edeltävän, jopa konseptin todistavan tai sisäisen myynnin - palvelimettomalla, esimerkiksi Lambdalla. Ja sitten Kubernetes, koska sovellustiimit voivat omistaa infrastruktuurin suoraan. Ja sitten, kun se siirtyy tuotantoon, he siirtyvät yrityskäyttöön, on-prem Kubernetes-jakeluihin. Mutta se on itse asiassa suhteellisen pieni osa koko infrastruktuurista, ehkä yksi- tai pieni kaksinumeroinen prosenttiosuus. 

Se on kuitenkin selvästi uusi standardi. Aivan kuten virtualisoinnin käyttöönotto oli aluksi hyvin hidasta ja ihmiset sanoivat, että se oli ylivoimaista - mutta ajan myötä se tietysti alkoi korvata suurimman osan asioista - näemme saman täällä. Tai aivan kuten nykykielellä. Ihmiset sanoivat, että Java on ylivoimainen, ja se on luultavasti edelleenkin monille sovelluksille, mutta oli aika, jolloin oli erittäin vaikeaa tehdä mitään sovelluskehitystä Javan ulkopuolella, koska suurin osa sovelluskehittäjistä osasi kirjoittaa siihen. pitää paikkansa nykyaikaisille sovellustiimeille: he odottavat saavansa Kubernetesia, jotta he voivat kehittää ketterämpää ja tuoda tuotteen markkinoille nopeasti.

Infrastruktuurin puolella se saattaa olla hieman liioittelua, mutta jos vaihtoehto on kirjoittaa sovellus palvelimettomasta on-prem-sovellukseen, se on valtava tehtävä. Joten Kubernetes on siellä keskitie, mikä on erittäin houkutteleva. 

Entä ajatus, että Kubernetes tarvitsee edelleen paremman kehittäjäkokemuksen?

Jos katsomme alkuperäistä OpenShiftiä, ennen kuin se perustui Kubernetesiin, se oli tämä. Se oli vielä lähempänä sovellustiimiä ja oli vielä parempi sovelluskehityskokemus. Voit työntää Gitiin ja se otetaan käyttöön automaattisesti. Heroku kokeili myös tätä, mutta SaaS-pohjaista. 

Kubernetes otti askeleen taaksepäin ja sanoi: "Meidän täytyy säilyttää joitain toiminnallisia näkökohtia siinä ja tehdä siitä hieman lähempänä sitä, mitä järjestelmänvalvoja odottaa. Emme voi olla räätälöityjä vain sovelluksiin." Se on keskitie: Sen on oltava tarpeeksi houkutteleva sovellusryhmille, mutta sen on silti voitava käyttää kyseistä sovellusta tietyn ympäristön ulkopuolella ja olla muiden ihmisten kuin sovellusten kehittäjien hallinnassa.

Sanoisin, että suurin askel Dockerin ja Kubernetesin välillä oli, että Dockerissa oli kyse kehittäjäkokemuksesta. Se ratkaisi tämän osan, mutta ei ratkaissut julkisen pilven ekosysteemiosaa.

Kuinka pääsimme tähän pisteeseen? Oliko tämä luonnollinen kehitys alustana palveluna (PaaS) ja sovellussäiliöistä?

Se oli Docker-kuvat ja Dockerin pakkausnäkökohta. Vanha koulu oli tapa ottaa käyttöön virtuaalikoneita, ja sen ympärillä oli kaikenlaista automaatiota. Ja sitten oli se, mitä Facebook teki Tupperwaren kanssa – erittäin räätälöityjä ja todella suuressa mittakaavassa. Ja sitten Docker tuli ympärille ja toimitti pohjimmiltaan tämän konttikuvan, ja kaikki saattoivat käsitellä sitä pienois-VM:nä. Voin nyt jaella sovellustani, ja 600 Mt:n virtuaalisen kuvan sijaan se on nyt 10 Mt:n säilö. Mutta voit kohdella sitä samalla tavalla, siinä on kaikki mitä se tarvitsee. 

Tämä avasi mahdollisuuden tuoda sisään Kubernetesin kaltainen orkesteri, jonka avulla voit silti käsitellä sovelluksia, kuten mini-VM:itä, mutta ottaa sitten askeleen pidemmälle ja käsitellä niitä mikropalveluina. Sen avulla voit tehdä molemmat.

Sanoisin, että suurin askel Dockerin ja Kubernetesin välillä oli, että Dockerissa oli kyse kehittäjäkokemuksesta. Se ratkaisi tämän osan, mutta ei ratkaissut julkisen pilven ekosysteemiosaa. Sillä ei ollut tai välttämättä haluttu tiivistä integraatiota pilvipalveluntarjoajien kanssa. Kubernetes ratkaisi sen. 

Kenen näet Kubernetesin johtavan yritysten sisällä? Onko kyse yksittäisistä hakemusryhmistä?

Pilven natiivin kanssa tapahtui mielenkiintoinen muutos, mikä on, että meillä on "alustatiimin" nousu, kutsun sitä. He eivät ole sovellusinsinöörejä. Heillä on vähän verkkotoimintojen tietoa ja heillä on melko vähän tietoturvatietoa. Heillä on SRE-tietoa ja he osaavat tehdä pilviautomaatiota. He tarjoavat alustan sovellusryhmille ja kohtelevat näitä sovellusryhmiä asiakkainaan.

Alustatiimit ostavat Kubernetesia ja siihen liittyviä teknologioita, joita he käyttävät, koska niiden tehtävänä on tarjota seuraavan sukupolven infrastruktuuri, joka tekee nykyaikaisista sovellustiimistä onnellisia.

Uskon, että siellä on varmasti tilaa palvelimettomille, erityisesti erittäin nopealle sovellusten kehitykselle. Mutta yrityksissä näemme natiivin pilven uutena kerroksena virtualisoinnin päällä

Onko kyseessä nettouusi ostaja vai nettouusi tiimi? Vai ovatko alustatiimit sellaisia, jotka ovat olemassa Googlen tai Facebookin kaltaisissa paikoissa ja ovat nyt yleistymässä?

He ovat enimmäkseen uutta joukkuetta. Luulen, että he ovat jossain määrin kuin Googlen ja Facebookin SRE-tiimit. Sovellustiimit kuitenkin todennäköisesti omistavat enemmän sovellusten käyttöönotosta yrityksissä, koska yrityksillä ei ole tätä kovin selkeää eroa ohjelmistosuunnittelijoiden ja SRE:n välillä, kuten Google ja Facebook. Sanoisin, että tämä kehitys on hyvin samanlainen kuin teillä oli virtualisointitiimejä, ja sitten monet verkkotoiminnot siirtyivät verkosta – tai kehittyivät tai kehittyivät niistä. laitteisto verkostoitumista varten virtualisointi. Ja nämä tiimit esimerkiksi alkoivat käyttää VMware NSX:ää. Sama tapahtuu täällä. 

Se ei kuitenkaan välttämättä ole uusi budjetti. Näemme budjettien siirtyvän turvallisuudesta ja verkottumisesta esimerkiksi tälle alustatiimille, kun pilvikulut kasvavat ja verkkolaitteistoihin kuluu vähemmän. He työskentelevät usein turvallisuustiimin ja verkon operaatiotiimin kanssa saadakseen sisäänoston, mutta itse asiassa he omistavat melko suuren budjetin.

Miten näet Cloud Native Computing -säätiö kehittyy, ja tuleeko Kubernetes aina olemaan sen keskipisteessä – vai pilven natiiviliikkeessä yleisesti?

Kubernetes sai aikaan CNCF:n, ja parin ensimmäisen vuoden aikana kyse oli Kubernetesista ja julkisesta pilvestä. Olemme nähneet noin vuoden takaisesta, että nyt ei ole enää kyse vain Kubernetesista, vaan itse asiassa enemmän pilven natiivista. periaatteet. Tämä itse asiassa tarkoittaa, että se ei välttämättä ole enää pilvi, ei edes yksityinen pilvi. Se on usein jopa perinteistä yritysverkottumista, tylsää on-prem-infrastruktuuria, metallipalvelimia ja kaikkea muuta, mutta pilvipohjaiset periaatteet on sisäänrakennettu. 

Uusi normi on nyt hybridi ja sisältää useita julkisia pilvipalveluntarjoajia sekä paikallisen infrastruktuurin. Yritykset haluavat tarjota saman sovelluskehittäjän ketteryyden tai tarjota havaittavuuden nykyaikaisilla pilvipohjaisilla työkaluilla tai tehdä turvallisuutta nykyaikaisilla pilvipohjaisilla työkaluilla – esimerkiksi autentikoinnin, pelkän segmentoinnin tai identiteettipohjaisen pakotuksen sijaan – kaikki nämä uudet pilvipohjaiset konseptit olemassa olevaa infrastruktuuria. 

Näemme erittäin suuren kysynnän muodostaa edelleen yhteys vanhaan maailmaan ja puhua MPLS-, VLAN-, sFlow- ja NetFlow-sovelluksista – kaikki olemassa olevat yritysvaatimukset. Yksikään heistä ei ole poistunut.

Noin vuosikymmenen kuluttua pilven natiiviavaruus ei näytä olevan villitys. Kuinka paljon sillä on tilaa kehittyä edelleen?

Oli varmasti aika, jolloin se oli kuin "Voi, Kubernetes on todennäköisesti lyhytikäinen, ja palvelinton on seuraava kerros." Tai "Kubernetes on samanlainen kuin OpenStack. Tai "Se katoaa ja siitä tulee toteutusyksityiskohta." Ja niin ei ole tapahtunut. 

Uskon, että siellä on varmasti tilaa palvelimettomille, erityisesti erittäin nopealle sovellusten kehitykselle. Mutta yrityksissä näemme pilven natiivin uutena kerroksena virtualisoinnin päällä, ja uskomme, että sillä on samanlainen säilyvyys kuin virtualisoinnilla. Tämä tarkoittaa, että olemme pilvipohjaisen siirtymisen alussa.

Mitä suuria ongelmia on vielä ratkaistava infrastruktuurin tasolla?

Näemme yrityksiä tilanteessa, jossa yhtäkkiä, halusivatpa ne sitä tai eivät, he tarvitsevat monipilvistrategian. Koska heillä on myös paikan päällä oleva infrastruktuuri, he tarvitsevat nyt hybridipilvistrategian sen lisäksi. Heidän on myös selvitettävä, kuinka turvallisuus- ja muut toiminnot tehdään universaalisti tässä infrastruktuurissa lukittumatta tiettyyn julkiseen pilveen. 

Joten tämä on seuraava suuri haaste: Kuka tulee olemaan se agnostinen kerros monipilvelle ja pilvipohjaiselle sovellukselle, kuten VMwaresta tuli? Kuka tulee olemaan VMware for cloud natiivi?

Uskon, että oivallus on lähtenyt liikkeelle, että jos haluat houkutella nykyaikaisia ​​sovellustiimejä ja saada nopeat markkinoilletuloajat, sinun on tarjottava heille natiivi pilviinfrastruktuuri.

Ja vaikka pilvipalvelun käyttöönotto olisi saattanut olla suhteellisen helppoa nykyaikaisille verkkoyrityksille, jotka ottivat käyttöön varhain, haasteena sinun näkökulmastasi on rakentaa uusia teknologioita, jotka kurovat siltaa tämän modernin maailman ja olemassa olevien yritystyökalujen ja järjestelmien välillä?

Vaikeinta on, että nykyaikaiset sovellustiimit ovat tottuneet siihen, että infrastruktuurikerros kehittyy yhtä nopeasti kuin he. Ja tämä pakotti infrastruktuurikerroksen olemaan vieläkin ohjelmoitavampi, säädettävämpi. Siksi näemme itse asiassa verkkokerroksen ja suojauskerroksen pilviverkkokerroksen päällä. Mutta nyt meille on tulossa yrityksiä, ja näemme erittäin suuren kysynnän muodostaa edelleen yhteys vanhaan maailmaan ja puhua MPLS-, VLAN-, sFlow- ja NetFlow-sovelluksista – kaikki olemassa olevat yritysvaatimukset. Mikään niistä ei ole kadonnut, kaikki noudattamissäännöt ovat edelleen samat. Ja Jopa jotkin nykyaikaisista SaaS-yrityksistä kohtaavat nyt nämä haasteet kasvaessaan ja välittäessään vaatimustenmukaisuudesta ja niin edelleen. 

Teknologian näkökulmasta kyse on siitä, miten uusi pilvipohjainen maailma voidaan yhdistää olemassa oleviin yrityksen vaatimuksiin. Koska julkiset pilvipalveluntarjoajat piilottivat monet näistä ongelmista. Julkiset pilvipalveluntarjoajat ratkaisivat vaatimustenmukaisuusongelmat, mutta eivät avoimen lähdekoodin eivätkä julkaisseet mitään niistä; he ratkaisivat sen itse. Se on osa pilviarvoa. Yritysten on nyt rakennettava ja ostettava se uudelleen, jos ne eivät halua lukita itseään julkisiin pilvipalveluihin.

Mistä näet pilvipohjaisten innovaatioiden seuraavan aallon tulevan? Tuleeko se edelleen Googlen kaltaiselta yritykseltä vai onko vastuussa uudentyyppinen yritys?

Se on erittäin mielenkiintoista. Sanoisin, että se ei todennäköisesti tule Googlesta ja Facebookista. Innovaatioiden lähde on avoimen lähdekoodin lähde, ja kysyntää ohjaavat asiakkaat ja käyttäjät ovat yhden tason alapuolella hyperskaalaajia – jo nyt isoja yrityksiä, jotka ovat edelleen erittäin häiritseviä, kuten Adobe, Shopify tai GitHub. Mutta myös yritykset, jotka ovat vaarassa joutua häiriintymään tekniikan takia, kuten rahoituspalvelut, vakuutusyhtiöt ja puhelinyhtiöt. Kaikilla näillä yrityksillä on yhteinen intressi infrastruktuurin standardoimiseen toistettavien kehitys- ja infrastruktuurimallien avulla.

Lähetetty 26. heinäkuuta 2022