Kaj je Kubernetes? Vse, kar mora vedeti vaše podjetje

Kaj je Kubernetes?

Opredelitev Kubernetesa se nenehno spreminja, ker Kubernetes nenehno raste in spreminja svet okoli sebe. Tukaj je izdaja za jesen 2019: Kubernetes je mehanizem porazdelitve delovne obremenitve in orkestracije za strežnike v gručah v podatkovnem centru, ki zagotavlja razpoložljivost virov, dostopnost in uravnoteženo izvajanje za več storitev hkrati.

V tej shemi Kubernetes omogoča poljubnemu številu strežnikov različnih vrst hkrati, ločenih s poljubno razdaljo, za skupno rabo delovnih obremenitev za skupnega najemnika. Nato te delovne obremenitve odjemalcem predstavi kot storitve – kar pomeni, da lahko odjemalski sistem stopi v stik z njimi prek omrežja jim posredujte nekaj podatkov in po trenutku ali dveh čakanja zberite a odgovor.

Gre za porazdeljeno obdelavo podatkov, ki je prej potekala v okviru enega samega, monolitna aplikacija. Kubernetes ta celoten proces izpostavlja opazovanju in obvladljivosti.

Pri upravljanju teh storitev Kubernetes po potrebi spremeni postavitev omrežja. Ko več odjemalcev poda zahteve za določeno vrsto ali razred delovne obremenitve, orkestrator da na voljo več replik; prav tako, ko se zahteve zmanjšajo, zmanjša število replik. To je proces, ki je prinesel Kubernetes do slave, ki ga operaterji IT imenujejo skaliranje oziroma skaliranje. Ko so storitve razdeljene na posamezne funkcije ali mikrostoritve, ki se povezujejo prek omrežja namesto prek pomnilnika in procesorja, ki bi si jih sicer delili, lahko Kubernetes razširite posamezne mikrostoritve in jih zmanjšajte nazaj, ko povpraševanje narašča in pada, enako kot če bi bile popolne aplikacije.

Poslovni primer za Kubernetes

Platforme informacijske tehnologije, na katerih so zgrajena naša podjetja, naši trgovinski sistemi in precejšnji deli naše družbe, kažejo svojo starost. Njihova zamenjava je vprašanje prednosti, ki prevladajo nad stroški. Kot kateri koli ponudnik telekomunikacijskih storitev, ki se spopada s prehodom na brezžično omrežje 5G bo potrdil, da organizacija težko upraviči stroške zamenjave svoje celotne infrastrukture, razen če se lahko njen kratkoročni poslovni model približa zagotavljanju donosnosti.

Kubernetes ne navaja samo argumentov za dobičkonosnost poslovanja, ampak nabira nekaj testnih primerov, da se dokaže. V njen prid je vedno več dokazov, da vedno večji stroški, ki jih organizacije danes plačujejo za vzdrževanje svojih obstoječih infrastruktur, postajajo vse manj upravičeni:

• Oblak temelji na virtualizaciji prve generacije, ki bo postal zastarel in morda sčasoma nepomemben. Slika programske opreme, ki bi bila običajno nameščena na glavnem trdem disku strežnika, je upodobljen v pomnilniku in shrambi oddaljenega strežnika, tako da lahko programska oprema deluje tam kot vedno prej. Zdaj ni več potrebe, da bi programska oprema delovala tako kot vedno. Poslovni primer za nadaljevanje proizvodnje monolitnih aplikacij je izpuhtel, tudi v primeru množična spletna igra za več igralcevkaterih osnovne, lastniške platforme so ekskluzivne domene njihovih proizvajalcev.
• Internet je preslikan z domenskim sistemom ki preslika naslove na njihove registrirane lastnike in ne na funkcije in storitve, ki se uporabljajo. Servisne mreže te zemljevide prekrivajo z bolj ustreznimi, kar omogoča porazdeljenim aplikacijam, da se najdejo v zelo razpršenih omrežjih. In te storitvene mreže so tesno povezane s Kubernetesom in zagotavljajo drugo najpomembnejšo storitev sistema po orkestraciji delovne obremenitve.
• Mobilne naprave so odvisne od mobilnih aplikacij ki distribuirajo "pametno" funkcionalnost na stran odjemalca, predvsem za zmanjšanje informacij, izmenjanih med odjemalci in strežniki. Ker brezžična pasovna širina ni več prvovrstna dobrina, bo morda postalo bolj praktično in stroškovno učinkovito prestaviti to funkcionalnost nazaj na stran strežnika, kar bo omogočilo novo razred naprav, ki so občutno »neumnejše« od svojih predhodnikov – čeprav z res odličnimi kamerami – vendar opravljajo enake naloge pri verjetno večji hitrosti.
• Javni podatkovni centri v oblaku so masivni, "hiperscale" objekti ki oskrbujejo več deset tisoč najemnikov hkrati, pogosto z razdalje več sto milj. Z bolj distribucijskim računalništvom bo morda postalo bolj praktično in bolj zaželeno imeti večje število precej manjših podatkovnih centrov, razpršenih v neposredni bližini svojih uporabnikov.
• Umetna inteligenca predstavlja višji razred programske opreme, predvsem zaradi relativno visoki stroški pomnilnika, pomnilnika in drugih virov. Z uporabo porazdeljenih servisnih modelov, ki obsegajo nešteto vsebnikov, od katerih ima vsak veliko manjši odtis, lahko umetna inteligenca postane veliko bolj običajna, do te mere, da programska oprema, ki bolje sklepa (npr. "Pazi na tisto drevo 30 jardov stran!"), se ne bo imenovala "pametna" toliko kot "standardno delovanje opremo."
• Kontejnerizacija olajša upravljanje poslovne programske opreme. V kontekstu strežniškega računalništva je vsebnik paket, ki omogoča virtualizacijo delovnih obremenitev (prenosen, samostojen, deluje ločeno), medtem ko ga še vedno gosti operacijski sistem (v nasprotju z hipervizor). Sodobne aplikacije postanejo prenosljive med strežniki tako, da se pospravijo v vsebnike, pri čemer ne gre le za uvedbo paketov. V kontejnerskem okolju se koda za programsko opremo pridobi ali "potegne" iz skladišč (nekatera javna, druga zasebna), nato pa se takoj uvede in izvaja v produkcijskem okolju. Ta samodejna metoda uvajanja omogoča, da se programska oprema izboljša ne le vsakih osemnajst mesecev ali tako, ampak potencialno vsak dan, ne samo s strani avtorjev, ampak tudi s strani uporabnikov. To pa dramatično izboljša celovitost sistema podatkovnega centra in varnost.

Kaj pomeni "orkestracija".

Orkestracija je učinkovito upravljanje in izvajanje več delovnih obremenitev, ki soobstajajo na platformi IT. V primeru Kubernetesa lahko določene delovne obremenitve prispejo na platformo, ki je že bila razdeljena na mikrostoritve. Še vedno delujejo skupaj, vendar kot samostojne enote. Orkestracija Kubernetes omogoča, da se te enote pomnožijo in prerazporedijo po potrebi ter postopno opustijo, ko niso več v uporabi.

Kot dirigent orkestra?

Napačna analogija. Dirigent poskrbi, da je skladba izvedena v pravem času in ritmu. V podatkovnem centru operacijski sistem še naprej igra to vlogo -- Kubernetes tega ne spremeni. Orkestrat usklajuje izvedbo vseh delov v kompoziciji za maksimalno učinkovitost in gladkost performans, tako da en del ne more preglasiti drugega in vsi deli igrajo svojo prispevajočo vlogo učinkovito. Ker so lahko ti deli široko porazdeljeni med več lokacijami, orkestrator zbere tudi vse vire, ki jih deli morda potrebujejo za prispevanje k isti nalogi.

Razlika med orkestratorjem in operacijskim sistemom

Operacijski sistem v računalniku med drugim omogoča varno in pričakovano izvajanje programa s procesorjem. Kubernetes izpolnjuje to vlogo za več delovnih obremenitev hkrati, ki so porazdeljene med več strežnikov v gruči.

To ne pomeni, da je Kubernetes operacijski sistem, ki je povečan. OS še vedno igra vlogo usklajevanja izvajanja vsakega programa. In v kontejnerskem okolju (vsaj njegovem izvornem okolju, kot je bilo prvotno zasnovano) vsak gostitelj vsebnika ni hipervizor, kot je to pri vSphere ali KVM, temveč OS.

V enem pogledu pa je to, kar je operacijski sistem za en računalnik, orkestrator za gručo strežnikov: nadzoruje izvajanje programske opreme v sistemu, katerega infrastrukturni viri – procesorska moč, pomnilnik, shranjevanje in omrežne zmogljivosti – so bili vsi združeno. Kubernetes je v izjemno kratkem času rešil vprašanje, kateri orkestrator bi podatkovni center želel, kot so zavezniške čete osvobodile Kuvajt. Tako kot operacija Desert Shield je imel tudi Kubernetes preprosto strategijo, ki je bila hitro izvedena.

Kam gre vsa programska oprema?

V sodobnem podatkovnem centru programske opreme ni treba »nameščati« na računalnik. Namesto tega je bolj podobna knjigi, ki si jo izposodijo v knjižnici, le tisti, ki je sposobna izdati knjigo, preden jo izposodijo. Na področju kontejnerizacije se ta knjižnica imenuje register. Odprtokodni paketi, izposojeni iz registra, so v popolnoma sestavljenih vsebnikih. Dejanje, s katerim je aplikacija ali storitev na voljo prek registra za uvedbo v okolje, ki ga upravlja Kubernetes, se imenuje uvedba. Torej, ko govorimo o »uvajanju delovnih obremenitev«, mislimo na dejanje priprave programske opreme za dostavo v strežniško gručo, kjer se upravlja in orkestrira.

Kubernetes je zgrajen za pridobivanje paketov delovne obremenitve iz registrov, njihovo postavljanje v čakalno vrsto za uvedbo v sistem, upravljanje njihovo porazdelitev med grozde, ki jih nadzorujejo, in urejajo njihov dostop do virov, ki so na voljo prek teh grozdi.

Zakaj je kontejnerizacija tako pomembna, če ima lahko tako zanič ime?

Kontejnerizacija je trend, ki ga je uradno začel Docker Inc., nato pa ga je Google pognal v warp hitrost, zdaj pa se mu je pridružila večina drugih v prostoru platforme, vključno z Microsoftom in VMware. Pred štirimi leti so nam povedali, da gre za ezoteričen vidik upravljanja podatkovnega centra, ki ga vsakdanji uporabnik ne bo opazil. Toda vsak gledalec Netflixa in Amazon Prime ter vsak uporabnik Alexa in Siri je ta vpliv občutil na lastni koži, čeprav ni bil sposoben prepoznati njegovega vira. Premik fokusa upravljanja podatkovnega centra s strojev na delovne obremenitve je spremenil način zagotavljanja aplikacij in storitev.

Namesto "kontejnerizacije", ki zveni kot način za industrializacijo Tupperware zabave, bi lahko imenovano "revolucija delovne obremenitve". Omrežja so zdaj usmerjena k funkcijam in ne k stroji. Težko je videti pomen te ideje v praksi brez zadostne analogije iz resničnega sveta: Koliko telefonskih številk si prikličete na pamet? Ali imate v mislih več ali manj vzorcev števk, zdaj ko imajo pametni telefoni sezname stikov in se lahko odzivajo na vaš glas?

Kaj je vsa ta "delovna obremenitev"?

Program, ki se izvaja v računalniku, je še vedno "programska oprema", kar pomeni izraz, ki so ga Nasini inženirji prvotno skovali v dobi Apolla kot besedna igra. In aplikacija je še vedno program, zasnovan tako, da ga upravlja več uporabnikov in se nanj nanaša po imenu.

Za primerjavo, "delovna obremenitev" je nekoliko bolj nejasna. Sestavljen je iz enega ali več kosov programske opreme. Lahko uporablja bazo podatkov, čeprav je to lahko ista baza podatkov, ki jo uporabljajo druge delovne obremenitve. Lahko je sestavljen iz več kot enega paketa v registru, ki se sproti sestavlja in deli funkcionalnost znotraj gruče. Vendar ima običajno en glavni namen in lahko deluje kot ena kohezivna enota, tudi če ima poljubno število sestavljenih delov.

Razvijalci programske opreme običajno ne sedejo za svojo mizo in ne sestavljajo delovnih obremenitev. Še vedno pišejo programe. Toda v procesu uvajanja vsebnikov, sestavljenih okoli teh programov, navodila, dana orkestratorju, kot je Kubernetes, na koncu razglasijo delovne parametre aktivne delovne obremenitve. Torej v dejanju uvajanja programska oprema postane delovna obremenitev. Njegove učinke na porabo virov v podatkovnem centru je mogoče izmeriti in ublažiti, tako kot učinke delovne obremenitve v vsakdanjem svetu ljudi in stvari, je mogoče izmeriti in ublažiti zaposlenih.

V redu, kaj je potem "storitev?"

Storitev v sodobnem podatkovnem centru je zelo drugačna stvar od aplikacije. To se morda ne zdi smiselno, saj so aplikacije pogosto opisane kot tiste, ki izvajajo uporabne storitve. Toda z arhitekturnega vidika je storitev programska oprema, ki glede na določene vnose in usmerjena na ustrezne podatke ustvari predvidljiv nabor izhodov. Po podatkovnih bazah se pogosto poizveduje s storitvami.

Aplikacija svojemu uporabniku nudi okolje (običajno vizualno), v katerem lahko uporablja storitve. Storitvi ni treba skrbeti za to funkcijo.

Danes je večina orkestriranih, kontejnerskih programov storitev. Lahko opravljajo najpomembnejše posle aplikacije, vendar so neodvisne enote. Mikrostoritve so samozadostne, individualne, neodvisne storitve, ki so ponavadi majhne (čeprav so nedavno arhitekti programske opreme trdili, da ni nujno, da so). Orkestrator lahko prikliče (ali "instancira") toliko klonov mikrostoritev, kolikor je potrebnih ali dovoljenih, da se odzovejo na zahteve, ki so jim poslane.

API (prvotno okrajšava za "Application Program Interface") je nabor storitev z določenim komunikacijskim protokolom. V omrežnem računalništvu je API zasnovan tako, da se z njim vzpostavi stik na daljavo, običajno prek spletnega brskalnika, z uporabo URL-ja, oblikovanega za posredovanje ukaza ali izjave prejemnemu strežniku. Ta ukaz lahko med potjo naloži tudi paket podatkov. Odziv na ta ukaz je storitev. Kubernetesova prednost je orkestriranje storitev.

Da, storitev je vrsta delovne obremenitve. Morda najvidnejši primer sodobne storitvene arhitekture je tako imenovana funkcija brez strežnika. Imenuje se tako, ker njenega vira – strežnika ali gruče strežnikov, ki jo gosti – ni treba naslavljati po imenu ali celo posredno, da bi ga priklicala druga storitev ali njen uporabnik. Namesto tega se te podrobnosti izpolnijo v imenu vlagatelja zahteve, rezultat pa je, da se lahko uporabnik te funkcije pretvarja, da obstaja lokalno na odjemalcu. Podobno kot seznam stikov na vašem pametnem telefonu vas napeljuje na razmišljanje, da so številke postale nepomembne.

Komponente Kubernetesa

Morda ste opazili, da je ta članek pobegnil skozi prvih deset odstavkov, ne da bi uporabil besedo "vsebnik" ali še manj samoumevna beseda "kontejnerizacija". Ločitev Kubernetesa od vsebnikov je ena najbolj nepričakovanih sprememb obsega v zadnjih mesecih. od Kubernetesa. Čez nekaj trenutkov boste razumeli, zakaj.

Eden od ključnih ciljev orkestracije je dati stvari na voljo v omrežju. Do zdaj smo te stvari večinoma imenovali "kontejnerji", čeprav smo opazili, da od na svojih začetkih se je Kubernetes skliceval na entitete, ki jih koordinira in učinkovito orkestrira stroki V tem kontekstu je bil izraz "pod" definiran preprosto kot "skupina vsebnikov".

Stroki in viri na nadzorni ravnini

Vsak strežnik (fizični ali virtualni) v gruči Kubernetes se imenuje vozlišče. Če gosti nekatere vidike Kubernetesa in je naslovljiv prek omrežja, ki ga vzdržuje orkestrator, je to vozlišče. Obstaja glavno vozlišče in poljubno število delovnih vozlišč (včasih imenovanih minioni). Omrežje komponent, odgovornih za krmiljenje sistema, je ločeno od vseh drugih omrežij in tvori nadzorno ravnino. Na tem ekskluzivnem letalu boste našli tri komponente:

• Strežnik API(kube-apiserver), ki preverja vse dohodne zahteve, vključno s storitvami, ki se izvajajo znotraj sklopov.
• Vodja krmilnika(kube-controller-manager). Posamezne komponente Kubernetesa, ki so neposredno odgovorne za upravljanje nekaterih virov v sistemu, se imenujejo krmilniki. Zagotavljanje opravila za storitev, ki temelji na podu, je na primer naloga krmilnika opravil. Tukaj stvari postanejo zanimive: Kubernetes se lahko razširi z dodajanjem nadaljnjih krmilnikov, zaradi česar postane orkestrator stvari, ki niso le vsebniki.
• Razporejevalnik (kube-scheduler), pri čemer ne gre toliko za čas kot za prenos delovnih obremenitev na pods. Ko je pod omogočen, ga razporejevalnik prenese na delovno vozlišče, ki je najprimernejše za njegovo obravnavo glede na njegovo trenutno stanje razpoložljivosti.

Krmilniki se nahajajo znotraj nadzorne ravnine Kubernetes. Pri tistih, ki so dobavljeni s Kubernetesom, je njihova glavna funkcija spremljanje stanja virov v omrežni infrastrukturi v iskanju morebitnih sprememb. Potreben je dogodek -- signal takšne spremembe -- da sproži ocenjevalno funkcijo, ki določa, kako se najbolje odzvati. Razred storitve, ki mu je lahko dodeljena naloga odzivanja, je operater. Storitveni arhitekt bi dodal, da bi lahko orkestrator avtomatiziral bolj zapletene sisteme krmilniki v nadzorno ravnino, da sprejemajo odločitve, in operaterji na zadnji strani, da nanje ukrepajo odločitve.

Viri po meri

Prav razširljivost te sheme krmilnika je lahko na koncu mojstrska poteza, ki utrjuje položaj Kubernetesa v podatkovnem centru. Kot rezultat arhitekturnega dodatka, imenovanega definicije virov po meri (CRD), Kubernetes lahko orkestrira stvari, ki niso ti vsebniki. Povedano drugače, če lahko izdelate krmilnik, ki Kubernetes učinkovito nauči prepoznati nekaj drugega kot orkestriran vir, bo to tudi storil. O čem govorimo tukaj -- kaj bi lahko bilo "nekaj drugega"?

• Virtualni stroji (VM) -- Klasične entitete, ki jih poganja hipervizor, ki podpirajo večino delovnih obremenitev svetovnih podjetij. VMware, katerega platforma vSphere je prevladujoča komercialna vodilna družba za upravljanje VM, je je že začel projekt, da Kubernetes postane njegov glavni orkestrator VM.
• Ogromne baze podatkov katerih motorji in nadzorna opravila so se v zadnjih letih preselili v namenske sisteme, kot sta Hadoop in Apache Spark - in ki bi lahko domnevno umakniti se s teh platform, če bodo razvijalci spet lahko pisali delovne obremenitve z uporabo jezikov, ki niso izbrani, kot so Java, Scala in R.
• Delovne obremenitve visokozmogljivega računalništva (HPC). za superračunalnike, ki so jih v zgodovini urejali namenski razporejevalniki, kot je Slurm in pred kratkim, Apache Mesos. Njihova vrlina v podatkovnem centru kot časovno usmerjenih agentov za razporejanje je zdaj postavljena pod vprašaj, ko se Kubernetes približuje skoraj vseprisotnosti.
• Modeli strojnega učenja, ki zahtevajo velike količine podatkov z vzporednim dostopom, kot tudi deterministično razporejanje. Morda mislite, da bi samo ti dejavniki diskvalificirali Kubernetes kot orkestratorja ali pospeševalca infrastrukture, vendar obstajajo projekti, kot je npr. Kubeflow kjer ponudnike baz podatkov in razporejevalnike, ki zagotavljajo te funkcije, sami zagotavlja Kubernetes.

Objekti na podatkovni ravnini

Vsi ti razredi entitet, ki nosijo delovno obremenitev, ki se zberejo v pode, in karkoli drugega, kar bo Kubernetes morda na koncu orkestriral v prihodnosti, postanejo predmeti, v pomanjkanju boljše besede.

Tisto, kar orkestratorju pojasni enega od teh predmetov, je datoteka, ki služi kot njegovi identifikacijski dokumenti, imenovana manifest. To je element kode, napisan z uporabo jezika, imenovanega YAML, ki navaja vire, ki jih objekt pričakuje, da bo uporabil. Tukaj lahko krmilnik predogleda, koliko goriva, če želite, bo objekt porabil -- koliko prostora za shranjevanje, kateri razredi baz podatkov, katera vrata v omrežju. Krmilnik se po najboljših močeh trudi izpolniti te zahteve, saj se zaveda, da če je gruča že preobremenjena, bo morda moral narediti vse, kar lahko, s tem, kar ima.

Znotraj vsakega od sklopov je oddaljeni agent, imenovan kubelet, ki sprejema zahteve operaterja in upravlja komponente poda. V običajnem sistemu, ki temelji na zabojnikih, je kubelet ki sproži procese za vsebniški motor. Tukaj je imel Docker rezervirano mesto za Kubernetesovo mizo - nekoč je bil de facto ekskluzivni ponudnik motorjev kontejnerjev. Ustvaril je celo univerzalno izvajalno okolje, imenovano tečiC (izgovarja se "teči · glej") in ga izdal odprtokodni skupnosti. Zdaj je projekt Kubernetes ustvaril svojo alternativo, imenovano CRI-O ("jok · O," čeprav se občasno reče kot "kreolščina"), ki je prednostni vsebniški pogon Platforme, ki temeljijo na Kubernetesu, kot je Red Hat OpenShift.

Kubernetesovi premagani konkurenti

Preden je velik del tehnološkega tiska prišel do kolektivnega spoznanja, da je prostor za orkestracijo strežniških gruč najbolj vroče bojišče v sodobnem podatkovnem centru, je bila bitka že končana. Blagovni trgi redko dolgo tolerirajo konkurenčne standarde. Zato obstaja en HTML, en Facebook in en Kubernetes.

Docker Swarm

Docker Inc., podjetje, katerega inženirji so bili odgovorni za sprožitev kontejnerske revolucije, je ustanovilo podjetje filozofija na začetku, ki temelji na komercializaciji obsežnega uvajanja, varnosti in podpore za brezplačno in odprtokodno jedro. Prihodki bi izvirali iz priključkov in ojačitev jedra Dockerja, ki so bili pod blagovno znamko Docker, vendar so bili nadomestki zanje splošno dostopni, za poslovni model, imenovan »Baterije Vključeno, a zamenljivo.« Vodje podjetja Docker so trdili, da če bi zabojniki postali vseprisotni, ne bi smel imeti nobenih intelektualnih ali kakršnih koli zahtevkov nad stvarjo, zaradi katere so zabojniki blago. Družba je verjela, da bi širši trg vodil do večjega števila voljnih strank.

V ta namen je leta 2015 Docker podprl ustanovitev pobude Open Container (OCI, prvotno Open Container Project ali Open Container Foundation, čeprav bo zaradi številnih razlogov kmalu zahtevala spremembo imena), pod okriljem Linux Foundation. Ob objavi na konferenci podjetja, je svojemu občinstvu povedal takratni tehnični direktor Solomon Hykes ni maral standardnih vojn, ki jih je opisal kot prepiranje o "podrobnostih, kot sta velikost in oblika škatle." Zaradi tega med drugi, Hykes je napovedal zamenjavo izvajalne komponente vsebnikov Docker -- dela, zaradi katerega lahko delujejo prek omrežja -- z tečiC.

V istem tednu je veliko istih ustanovnih članov OCI objavilo ustanovitev Cloud Native Computing Foundation, še en projekt fundacije Linux. Navidezno bi bil mandat CNCF spodbujanje in pospeševanje uporabe odprtokodnih tehnologij za uvajanje aplikacij. Prvi projekt bi CNCF vodil z začetkom naslednjega marca, bi bil Kubernetes, projekt, ki izvira iz Googla.

Medtem, po nekaj poskusih z manj vsestranskimi in občasno, nerodni poskusi namestitvenih platform, je Swarm postal Dockerjev orkestrator. Po večini računov je bil Swarm vreden tekmec. Skrbniki so rekli, da je bilo veliko manj zastrašujoče krivulje učenja. Njegov prekrivni omrežni model, ki je ločil medkontejnerski promet od gostiteljskega prometa, vsak v svoji ravnini z most med njima, je bil razumljen kot pameten, zlasti v primerjavi s Kubernetesovim modelom prekrivnega ploščatega omrežja. V modelu uvedbe v več oblakih bi lahko gručo vsebnikov Swarm delegirali v počasnejši javni oblak, medtem ko bi lahko promet na nadzorni ravnini tesneje omejili na gručo z nižjo zakasnitvijo. Kar zadeva zmogljivost in vodljivost, so strokovnjaki počasi izbirali favorite.

Če bi samo zmogljivost določala izid tehnoloških bitk, bi Sun Microsystems že zdavnaj osvojil namizne računalnike in vsi bi o tem govorili na naših BlackBerryjih.

CNCF si je zadal poslanstvo napredovati in spodbujati široko uporabo celotnega odprtokodnega ekosistema, vključno z spremljanje zmogljivosti, odkrivanje storitev, upravljanje obsega podatkov in varnost, vse osredotočeno na uvedbo ene delovne obremenitve motor. Docker je že začel lansirati svoj model razširljivosti, vendar takoj zapletel v ezoterično, filozofsko močvirje o tem, ali je razširljiva arhitektura kršila določeno dogmo oblikovanja aplikacij, imenovano "apatridija".

V istem času, medtem ko je bil Kubernetes zastavljen kot povsem neodvisna od prodajalca platforma, je Google v tistih zgodnjih dneh dal vso svojo težo in mišice za svojim trženjem, prilagajanje teme in dosledno predstavo tako potrošnikom kot novinarjem, hkrati pa vpletanje imena Kubernetes blagovna znamka. Skozi leto 2017 so podjetja, ki so ocenjevala Kubernetes, to dojemala kot Googlov izdelek. Ko so jim razložili zakonitosti in formalnosti, so mnogi zamahali z njimi, češ da ni pomembno, dokler je končni rezultat nekaj, kar se imenuje Google Kubernetes Engine. Med več kot nekaj pogovori, v katerih sem sodeloval, so mi skrbniki IT in drugi strokovni delavci v podjetjih povedali, če gre za Google vs. Docker, kaj za vraga je Sam Hill Docker?

Vendar Google ni mogel dolgo ohraniti videza edinega zagovornika vere orkestracije. Davnega leta 2015, Red Hat je sprejel pomembno odločitev zamenjati motor svoje platforme za uvajanje vsebnikov OpenShift s Kubernetesom. Do leta 2017 se je ta odločitev obrestovala v vedra. Red Hat je postal vrhunski sodelavec Kubernetesa. Na severu je Microsoft v prizadevanju, da prepreči možnost, da bi bil izključen iz novega vala sprememb v podjetju, najel dva najvidnejša inženirja odprtokodne skupnosti: Gabe Monroy, ki je bil soustanovitelj in tehnični direktor podjetja Deis, ključnega dejavnika v ekosistemu Kubernetes za gradnjo in uvajanje kontejnerskih aplikacij (branik, ki ga je Docker upal braniti za sam); in Brendan Burns, eden od Googlovih inženirjev, ki so ustvarili Borg, prototip Kubernetes [PDF]. Tokrat Microsoft svojih najnovejših zaposlenih ne bi skrival v zadnji omari nekega stranskega projekta raziskovalnega oddelka. Prevzeli so vodstvo pri predelavi pomembnega dela Azure v podobi Kubernetes.

Jez se je trgal, in to na več mestih hkrati.

Apache Mesos

Uveljavljeni vodja na področju razporejanja delovne obremenitve za porazdeljene gruče strežnikov je bil Apache Mesos. Uvedel je arhitekturo glavni/delavec (čeprav je Mesos za "delavca" uporabil drugo besedo) in je bil eden prvih načrtovalcev, ki so ga razširili v zasebno platformo PaaS, imenovano Marathon. Mesosova prva večja uvedba je bila na Twitterju, kjer je bil Ben Hindman inženir. Leta 2013 je Hindman odšel, da bi ustanovil Mesosovega glavnega komercialnega prodajalca, Mesosphere. V sodelovanju z Microsoftom je Mesosphere izdelal enega prvih javnih PaaS v oblaku, ki omogoča orkestrirane, hibridizirane uvedbe: DC/OS, kar je bilo videti, kot da bo postalo izbrana platforma za uvajanje delovne obremenitve za Azure. Mesos je imel vrlino večletnih izkušenj z uvajanjem, tako da je bila platforma, ki je ni bilo treba vsem razumeti od začetka.

Toda dosedanji Mesos se ni mogel izogniti učinkom uporniškega izzivalca s polno glavo. Avgusta 2017 je VMware izkoristil vire svojega sestrskega podjetja Pivotal za lansiranje platformo Kubernetes v oblaku, imenovano Pivotal Container Service, z avtomatiziranim mehanizmom za uvajanje, imenovanim Kubo, ki je prišel skozi lestvice iz Cloud Foundry. Kmalu je temu sledil tudi Azure, ki je svoj projekt DC/OS dejansko opustil. Nato junija 2018, stalwart Amazon je predal svoj obrambni položaj, ki odpira svojo platformo za uvajanje Kubernetes. In končno, malokdo verjame v to IBM-ov prevzem podjetja Red Hat, ki je bil zaprt julija lani, je govoril o tem, da IBM potrebuje boljšo distribucijo Linuxa. OpenShift je že utrl poti v porazdeljeni podatkovni center, za katere je IBM ugotovil, da jih ni več treba znova tlakovati.

Poraz je bil tako popoln, da Mesosphere ni mogla več poslovati s tem imenom, lani avgusta se je preimenovala v D2IQ, in obljubil, da bo ustanovil lastno "Ksphere". In v začetku oktobra, Docker je predlagal da njegovi uporabniki poskušajo zagnati Kubernetes in Swarm vzporedno. "Novi uporabniki veliko lažje razumejo Docker Swarm," se glasi objava na blogu podjetja. "Vendar se je Kubernetes razvil in dodal veliko funkcionalnosti."

Od kod naprej gre Kubernetes

Do zdaj se je veliko razprav o prenovi arhitekture podatkovnega centra osredotočalo na temo selitve starih delovnih obremenitev na nove modele. Aplikacije, kot smo jih poznali, so bile imenovane "monoliti" ker so, tako kot skrivnostni predmet v filmu "2001," edinstveni, praktično trdni in prav tako nerazložljivi po štiriurnem sedenju v gledališču, kot so bili na začetku. Sestavljeni so iz kode, ki jo ve, kako spremeniti le njen ustvarjalec.

Prehod na Kubernetes je bil opisan kot proces selitve monolitov. Nekateri so rekli, da je to mogoče storiti le z obnovo omrežij mikrostoritev, ki se obnašajo kot njihovi monolitni predhodniki, vendar jih v celoti nadomestijo. Drugi pravijo, da je mogoče API oviti okoli monolitne storitve in ta API distribuirati prek omrežja na način mikrostoritev. To bi bilo lažje narediti in ne bi vključevalo toliko truda pri podvajanju iste funkcionalnosti, ki jo podjetja že imajo.

Zdaj, zahvaljujoč Kubernetesovemu CRD, če parafraziram Arla Guthrieja, obstaja še tretja možnost, na katero nihče niti ni računal: Kubernetes sam se lahko preseli, da zadosti potrebam obstoječih delovnih obremenitev. Ker je Kubernetes morda najbolj dejaven projekt odprtokodne programske opreme na svetu, ga vzdržuje dobesedno na stotine strokovnjakov inženirji, ki bi lahko pomagali podjetjem pri oblikovanju ali prilagajanju krmilnikov in operaterjev, ki bi jih potrebovali za avtomatizacijo svoje programske opreme dobavne verige.

Ljudje, ki so ustvarili Kubernetes, so pred nekaj leti rekli, da bo prišel čas, ko bo njihova stvaritev postala tako zelo del podatkovnih centrov vseh, da bi bili dolgočasni in o njih nihče ne bi prebral članka to. Kolikor sem priča, je do tega dne še najmanj nekaj let.

Izvedite več -- iz interaktivnega omrežja CBS

• Naslednji korak Kubernetesa bi lahko bil poskus orkestriranja vsega drugega avtor Scott M. Fulton, III, ZDNet
• 5G je odvisen od Kubernetesa v oblaku avtor Steven J. Vaughan-Nichols, ZDNet Linux in odprta koda
• Zakaj Red Hat vidi Knative kot odgovor na Kubernetesovo orkestracijo avtor James Sanders, TechRepublic Cloud

drugje

• Definicije virov po meri Kubernetes: razlaga CRD-jev avtor BMC Software
• Arhitektura Kubernetes 101 podjetja Aqua Container Security
• Razumevanje arhitekture Kubernetes od Edureka