Mis on Kubernetes? Kõik, mida teie ettevõte peab teadma

Mis on Kubernetes?

Kubernetese määratlus muutub pidevalt, sest selle kasvades muudab Kubernetes ümbritsevat maailma. Siin on nüüd 2019. aasta sügisväljaanne: Kubernetes on a töökoormuse jaotamise ja orkestreerimise mehhanism rühmitatud serverite jaoks andmekeskuses, tagades ressursside kättesaadavuse, juurdepääsetavuse ja tasakaalustatud toimimise mitme teenuse jaoks samaaegselt.

Selles skeemis võimaldab Kubernetes samaaegselt mis tahes arvul mitut tüüpi servereid, mis on eraldatud mis tahes vahemaaga, jagada ühise rentniku jaoks töökoormust. Seejärel esitab see need töökoormused klientidele teenustena – see tähendab, et kliendisüsteem saab nendega ühendust võtta läbi võrgu, edastage neile mõned andmed ja pärast hetke või paari ootamist koguge a vastuseks.

See on hajutatud andmetöötlus, mis varem toimus ühe, monoliitne rakendus. Kubernetes muudab kogu selle protsessi jälgitavaks ja juhitavaks.

Nende teenuste haldamisel muudab Kubernetes vajadusel võrgu paigutust. Mida rohkem kliente esitab teatud tüüpi või töökoormuse klassi taotlusi, teeb orkestraator kättesaadavaks rohkem selle koopiaid; samuti vähendab see taotluste vaibudes koopiate arvu. See on protsess, mis tõi Kubernetesele kuulsuse, mida IT-operaatorid nimetavad vastavalt skaleerimiseks ja tagasi skaleerimiseks. Kui teenused on jagatud üksikud funktsioonid või mikroteenused, mis võtavad üksteisega ühendust võrgu kaudu, mitte mälu ja protsessori kaudu, mida nad muidu jagaksid, saab Kubernetes suurendage üksikuid mikroteenuseid ja vähendage neid, kui nõudlus suureneb ja väheneb, täpselt samamoodi nagu need oleksid täielikud rakendusi.

Kubernetese ärijuhtum

Infotehnoloogia platvormid, millele meie ettevõtted, meie kaubandussüsteemid ja suur osa ühiskonnast on üles ehitatud, näitavad oma vanust. Nende asendamine on küsimus, kas kasu kaalub üles kulud. Nagu iga telekommunikatsiooniteenuse pakkuja, kes võitleb 5G traadita ühenduse üleminekuga tunnistab, et organisatsioonil on raske õigustada kogu oma infrastruktuuri väljavahetamise kulusid, välja arvatud juhul, kui tema lähiaja ärimudel suudab peaaegu tagada kasumlikkuse.

Kubernetes ei esita mitte ainult argumenti ettevõtte kasumlikkuse kasuks, vaid kogub enda tõestamiseks katsejuhtumeid. Selle kasuks on kasvav hulk tõendeid selle kohta, et üha suurenevad kulud, mida organisatsioonid maksavad täna oma olemasoleva infrastruktuuri korrashoiu eest, on üha vähem õigustatud:

• Pilv põhineb esimese põlvkonna virtualiseerimisel, mis muutub aegunuks ja võib-olla aja jooksul ebaoluliseks. Tarkvara kujutis, mis tavaliselt oleks installitud serveri põhikõvakettale, on renderdatakse kaugserveri mällu ja salvestusruumi, et tarkvara saaks seal töötada nagu alati enne. Nüüd pole enam vaja tarkvara panna töötama nii, nagu see varem on tehtud. Äriline vajadus monoliitsete rakenduste tootmise jätkamiseks on haihtunud, isegi juhul massiliselt mitme mängijaga võrgumängs mille aluseks olevad patenteeritud platvormid on nende tootjate eksklusiivsed domeenid.
• Internet kaardistatakse domeenisüsteemi abil mis kaardistab aadressid nende registreeritud omanikele, mitte kasutatavatele funktsioonidele ja teenustele. Teenindusvõrgud katavad need kaardid asjakohasemate kaartidega, võimaldades hajutatud rakendustel üksteist tohutult hajutatud võrkude kaudu leida. Ja need teenindusvõrgud on Kubernetesiga tihedalt seotud, pakkudes töökoormuse orkestreerimise järel süsteemi tähtsuselt teist teenust.
• Mobiilseadmed sõltuvad mobiilirakendustest mis jagavad "nutikaid" funktsioone kliendi poolele, peamiselt selleks, et minimeerida klientide ja serverite vahel vahetatavat teavet. Kuna juhtmevaba ribalaius ei ole enam esmaklassiline kaup, võib osutuda praktilisemaks ja kulutõhusamaks viia see funktsioon tagasi serveri poolele, võimaldades uue klassi seadmeid, mis on oluliselt "rumalamad" kui nende eelkäijad – ehkki tõeliselt suurepäraste kaameratega –, kuid täidavad samu ülesandeid mõeldavalt suuremal hulgal kiirused.
• Avalikud pilvandmekeskused on massiivsed, "hüpermastaabilised" rajatised mis teenindavad samaaegselt kümneid tuhandeid üürnikke, sageli mitmesaja miili kauguselt. Laiemalt jaotatava andmetöötluse korral võib osutuda praktilisemaks ja soovitavamaks omada rohkem palju väiksemaid andmekeskusi, mis on hajutatud nende kasutajatele lähemale.
• Tehisintellekt hõlmab tarkvara kõrgemat klassi, peamiselt selle suhteliselt tõttu mälu, salvestusruumi ja muude ressursside kõrge hind. Kasutades hajutatud teenusemudeleid, mis koosnevad lugematul hulgal konteineritest, millest igaüks on palju väiksema jalajäljega, võib AI muutuda palju tavalisemaks, kuni Tarkvara, mis teeb paremaid järeldusi (nt "Vaadake seda puud 30 jardi kaugusel!"), ei nimetata "targaks" nii palju kui "standardseks tööks" varustus."
• Konteinerimine muudab äritarkvara hõlpsamini hallatavaks. Serveripõhise andmetöötluse kontekstis on konteiner pakett, mis võimaldab töökoormust virtualiseerida (kaasaskantav, iseseisev, isoleeritult töötav), samas kui seda hostib endiselt operatsioonisüsteem (erinevalt hüperviisor). Kaasaegsed rakendused on muudetud serverite vahel kaasaskantavaks, paigutades need konteinerisse, mis ei seisne ainult pakkimises. Konteinerikeskkonnas hangitakse või "tõmmatakse" tarkvara kood hoidlatest (mõned avalikud, teised privaatsed), seejärel kohe juurutatakse ja käitatakse tootmiskeskkonnas. See automatiseeritud juurutusmeetod võimaldab tarkvara täiustada mitte ainult umbes iga kaheksateistkümne kuu tagant, vaid potentsiaalselt iga päev, mitte ainult selle loojatel, vaid ka kasutajatel. See omakorda parandab märkimisväärselt andmekeskuse süsteemi terviklikkust ja turvalisust.

Mida tähendab "orkestreerimine".

Orkestreerimine on IT-platvormi kooselu mitme töökoormuse tõhus haldamine ja täitmine. Kubernetese puhul võivad platvormile jõuda teatud töökoormused, mis on juba mikroteenusteks jagatud. Nad töötavad endiselt koos, kuid iseseisvate üksustena. Kubernetese orkestreerimine võimaldab neid üksusi vajaduse korral korrutada ja ümber jagada ning järk-järgult kasutusest kõrvaldada, kui neid enam ei kasutata.

Nagu orkestri dirigent?

Vale analoogia. Dirigent hoolitseb selle eest, et teos esitataks õigel ajal ja rütmis. Andmekeskuses jätkab operatsioonisüsteem selle rolli täitmist – Kubernetes seda ei muuda. Orkester koordineerib kompositsiooni kõigi osade täitmist, et tagada maksimaalne tõhusus ja sujuvus esitus, nii et üks osa ei saa teist summutada ja kõik osad mängivad oma panustavat rolli tõhusalt. Kuna need osad võivad olla laialdaselt jaotatud mitme asukoha vahel, koondab orkestraator ka kõik ressursid, mida osad võivad vajada sama ülesande täitmiseks.

Operatsioonisüsteemi orkestraatori vastandamine

Muuhulgas võimaldab arvuti operatsioonisüsteem protsessori poolt programmi ohutult ja ootuspäraselt käivitada. Kubernetes täidab seda rolli korraga mitme töökoormuse jaoks, mis on jaotatud klastri paljude serverite vahel.

See ei tähenda, et Kubernetes on operatsioonisüsteem, mida on suurendatud. OS mängib endiselt iga programmi täitmise korraldamise rolli. Ja konteineris keskkonnas (vähemalt selle algses keskkonnas) ei ole iga konteineri host hüperviisor, nagu see on vSphere'i või KVM-i puhul, vaid pigem OS.

Ühes mõttes on aga see, mis on operatsioonisüsteem ühe arvuti jaoks, orkestraator serverite klastri jaoks: see jälgib täitmist. tarkvara süsteemis, mille infrastruktuuri ressursid – selle töötlemisvõimsus, mälu, salvestus- ja võrgurajatised – on kõik olnud liidetud. Kubernetes otsustas väga lühikese aja jooksul, millist orkestraatorit andmekeskus eelistaks, nagu Kuveidi vabastanud liitlasväed. Nagu operatsioonil Desert Shield, oli ka Kubernetesil lihtne strateegia, mis viidi kiiresti täide.

Kuhu kogu tarkvara kaob?

Kaasaegses andmekeskuses ei pea tarkvara arvutisse "installima". Pigem sarnaneb see raamatukogust laenutatud raamatuga, ainult sellisega, mis suudab selle raamatu välja anda enne, kui see välja laenutatakse. Konteinerite valdkonnas nimetatakse seda teeki registriks. Registrist laenatud avatud lähtekoodiga paketid on täielikult kokkupandud konteinerites. Rakenduse või teenuse registri kaudu kättesaadavaks tegemist Kubernetese hallatavasse keskkonda tutvustamiseks nimetatakse juurutamiseks. Nii et kui me räägime "töökoormuste juurutamisest", siis peame silmas tarkvara ettevalmistamist serveriklastrisse tarnimiseks, kus seda hallatakse ja juhitakse.

Kubernetes on loodud töökoormuse pakettide toomiseks registritest, nende järjekorda seadmiseks süsteemis juurutamiseks, haldamiseks nende jaotus klastrite vahel, mida nad jälgivad ja juhivad juurdepääsu nende kaudu kättesaadavaks tehtud ressurssidele klastrid.

Miks on konteinerisse paigutamine nii oluline, kui sellel võib olla nii närune nimi?

Konteineriseerimine on suundumus, mille ametlikult käivitas Docker Inc., mille seejärel käivitas Google ja nüüd on sellega liitunud enamik teisi platvormiruumis, sealhulgas Microsoft ja VMware. Meile öeldi neli aastat tagasi, et see oli andmekeskuste haldamise esoteeriline aspekt, mis jääb igapäevakasutajale märkamatuks. Kuid iga Netflixi ja Amazon Prime'i vaataja ning iga Alexa ja Siri kasutaja on seda mõju omal nahal tundnud, isegi kui ta ei suutnud selle allikat tuvastada. Andmekeskuse haldamise fookuse nihutamine masinatelt töökoormustele muutis rakenduste ja teenuste tarnimise viisi.

Selle asemel, et "konteinerdada", mis kõlab nagu viis Tupperware peo industrialiseerimiseks, võiks see olla nimetatakse "töökoormuse revolutsiooniks". Võrgud suunatakse nüüd pigem funktsioonide kui poole masinad. Selle idee olulisust on praktikas raske mõista ilma piisava reaalse analoogiata: mitu telefoninumbrit mäletate? Kas nüüd, mil nutitelefonidel on kontaktide loendid ja need võivad teie häälele reageerida, on teie meeles suurem või vähem numbrimustreid?

Mis asi see "töökoormus" on?

Programm, mis töötab arvutis, on endiselt "tarkvara", mis viitab terminile, mille NASA insenerid Apollo ajastul algselt välja mõtlesid. Ja rakendus on endiselt programm, mis on mõeldud kasutamiseks mitmele kasutajale ja millele viidatakse nimepidi.

Võrdluseks, "töökoormus" on natuke hägusem. See koosneb ühest või mitmest tarkvaraosast. See võib kasutada andmebaasi, kuigi see võib olla sama andmebaas, mida kasutavad teised töökoormused. See võib koosneda rohkem kui ühest registris olevast paketist, mis on kokku pandud käigu pealt ja jagab funktsioone klastris. Kuid sellel on tavaliselt üks peamine eesmärk ja see on võimeline töötama ühe sidusüksusena, isegi kui sellel on suvaline arv liitosi.

Tarkvaraarendajad tavaliselt ei istu laua taha ega koosta töökoormust. Nad kirjutavad ikka programme. Kuid nende programmide ümber kokkupandud konteinerite juurutamise protsessis deklareerivad orkestreerijale (nt Kubernetes) antud juhised aktiivse töökoormuse tööparameetrid. Seega muutub tarkvara juurutamise käigus töökoormuseks. Selle mõju andmekeskuse ressursitarbimisele saab mõõta ja leevendada, nagu ka töökoormuse mõju inimeste ja asjade igapäevases valdkonnas, saab mõõta ja leevendada töötajad.

Olgu, mis on siis "teenus?"

Kaasaegses andmekeskuses pakutav teenus on rakendusest väga erinev. See ei pruugi tunduda mõistlik, sest rakendusi kirjeldatakse sageli kui kasulikke teenuseid. Kuid arhitektuuriliselt on teenus tarkvara, mis konkreetsete sisendite ja asjakohastele andmetele osutades loob prognoositava väljundite komplekti. Andmebaasidest tehakse sageli päringuid teenuste abil.

Rakendus pakub oma kasutajale keskkonda (tavaliselt visuaalset), milles saab teenuseid kasutada. Teenus ei pea selle funktsiooniga tegelema.

Tänapäeval on enamik orkestreeritud konteinersaateid teenused. Nad võivad täita rakenduse kõige olulisemat tegevust, kuid nad on iseseisvad üksused. Mikroteenused on iseseisvad, individuaalsed, iseseisvad teenused, mis kipuvad olema väikesed (kuigi hiljuti on tarkvaraarhitektid väitnud, et nad ei pea olema). Orkester võib kutsuda (või "momenteerida") nii palju mikroteenuste kloone, kui on vajalik või lubatud, et vastata neile suunatud päringutele.

API (algselt lühend sõnadest "Application Program Interface") on määratud sideprotokolliga teenuste komplekt. Võrgupõhises andmetöötluses on API loodud kaugühenduse saamiseks, tavaliselt veebibrauseri kaudu, kasutades URL-i, mis on loodud käsu või avalduse edastamiseks vastuvõtvale serverile. See käsk võib teel ka andmepaketi üles laadida. Selle käsu vastaja on teenus. Kubernetese tugevuseks on orkestreerimisteenused.

Jah, teenus on teatud tüüpi töökoormus. Võib-olla on kaasaegse teenusearhitektuuri silmapaistvaim näide niinimetatud serverita funktsioon. Seda nimetatakse nii, kuna selle allikale – seda hostivale serverile või serveriklastrile – ei pea pöörduma nime või isegi kaudselt, et mõni muu teenus või selle kasutaja seda kutsuks. Selle asemel täidetakse need üksikasjad taotleja nimel, mille tulemusel saab selle funktsiooni kasutaja teeselda, et see on kliendil lokaalselt olemas. Nagu teie nutitelefoni kontaktide loend, paneb see teid mõtlema, et numbrid on muutunud ebaoluliseks.

Kubernetese komponendid

Võib-olla olete märganud, et see artikkel pääses läbi oma kümne esimese lõigu, ilma et oleks kasutatud sõna "konteiner" või veelgi vähem. iseenesestmõistetav sõna "konteinerimine". Kubernetese lahtisidumine konteineritest on viimaste kuude üks ootamatumaid muudatusi ulatuses Kubernetes. Mõne hetke pärast saate aru, miks.

Orkestreerimise üks põhieesmärke on teha asjad võrgus kättesaadavaks. Seni oleme nimetanud neid asju peamiselt "konteineriteks", kuigi oleme seda märkinud Kubernetes viitas oma algusest üksustele, mida ta koordineerib ja tõhusalt orkestreerib kaunad. Selles kontekstis on terminit "pod" määratletud lihtsalt kui "konteinerite rühma".

Kaunad ja ressursid juhttasandil

Iga Kubernetese klastri serverit (füüsilist või virtuaalset) nimetatakse sõlmeks. Kui see hostib mõnda Kubernetese aspekti ja on adresseeritav orkestraatori hallatava võrgu kaudu, on see sõlm. Seal on põhisõlm ja suvaline arv töötaja sõlmi (mõnikord nimetatakse neid käsilasteks). Süsteemi juhtimise eest vastutavate komponentide võrk on juhtimistasandi moodustamiseks kõigist teistest võrkudest eraldi. Sellel eksklusiivsel lennukil leiate kolm komponenti:

• API server(kube-apiserver), mis kinnitab kõik sissetulevad päringud, sealhulgas kaustades töötavate teenuste jaoks.
• Kontrolleri juht(kube-kontroller-haldur). Kubernetese üksikuid komponente, millel on otsene vastutus teatud süsteemi ressursside haldamise eest, nimetatakse kontrolleriteks. Näiteks pod-põhise teenuse jaoks töö pakkumine on töökontrolöri ülesanne. Siin muutuvad asjad huvitavaks: Kubernetesi saab laiendada täiendavate kontrollerite lisamisega, muutes selle muude asjade kui lihtsalt konteinerite korraldajaks.
• Planeerija (kube-planeerija), mis ei puuduta niivõrd aega, kuivõrd töökoormuste delegeerimist kaunadele. Kui pod on ette nähtud, delegeerib planeerija selle töötaja sõlmele, mis selle praegust saadavuse olekut arvestades kõige paremini sobib.

Kontrollerid asuvad Kubernetese juhttasandi sees. Kubernetesiga tarnitavate seadmete põhiülesanne on jälgida võrgu infrastruktuuri ressursside seisundit, otsides muudatusi. Vaja on sündmust – signaali sellisest muutusest –, et käivitada hindamisfunktsioon, mis määrab, kuidas kõige paremini reageerida. Teenuseklass, millele võib vastamise ülesande delegeerida, on operaator. Et orkestraatoril oleks võimalik keerukamaid süsteeme automatiseerida, lisab teenindusarhitekt kontrollerid juhttasandile, et teha otsuseid, ja operaatorid tagaotsas, et nende alusel tegutseda otsuseid.

Kohandatud ressursid

See on selle kontrolleri skeemi laiendatavus, mis võib lõppkokkuvõttes olla peamine käik, mis kinnitab Kubernetese positsiooni andmekeskuses. Arhitektuurilise lisandi, mida nimetatakse kohandatud ressursimääratlusteks (CRD), tulemusena Kubernetes saab orkestreerida muid asju peale nende konteinerite. Teisisõnu, kui suudate luua kontrolleri, mis õpetab Kubernetest tõhusalt midagi muud organiseeritud ressursina ära tundma, teeb see seda ka. Millest me siin räägime -- mis võiks olla see "miski muu"?

• Virtuaalsed masinad (VM) -- Klassikalised hüperviisoripõhised olemid, mis toetavad enamikku maailma ettevõtete töökoormusest. VMware, mille vSphere'i platvorm on VM-i haldamise valdav kommertsliider, on seda teinud juba alustanud projekti Kubernetesi peamiseks VM-i orkestraatoriks muutmiseks.
• Massiivsed andmebaasid mille mootorid ja juhtimistööd on viimastel aastatel kolinud spetsiaalsetesse süsteemidesse, nagu Hadoop ja Apache Spark – ja mis võiksid mõelda kolige neilt platvormidelt välja, kui arendajad saavad taas vabaks töökoormuse kirjutamiseks muudes keeltes peale mõne valitud keele, nagu Java, Scala ja R.
• Kõrgjõudlusega andmetöötluse (HPC) töökoormused superarvutite jaoks, mida on ajalooliselt juhtinud spetsiaalsed planeerijad, näiteks Slurm ja viimasel ajal Apache Mesos. Nende voorus andmekeskuses ajale orienteeritud sõiduplaanide agentidena on nüüd kahtluse alla seatud, kuna Kubernetes läheneb peaaegu kõikjale.
• Masinõppe mudelid, mis nõuavad suuri andmemahtusid paralleeljuurdepääsuga, samuti deterministlikku ajastamist. Võib arvata, et juba ainuüksi need tegurid diskvalifitseerivad Kubernetese orkestri või infrastruktuuri toetajana, kuid on selliseid projekte nagu Kubeflow Kubernetes pakub neid funktsioone pakkuvaid andmebaasi pakkujaid ja planeerijaid ise.

Objektid andmetasandil

Kõik need töökoormust kandvate üksuste klassid, mis kogutakse kaustadesse, ja kõik muu, mida Kubernetes võib tulevikus orkestreerida, saavad objektid, parema sõna puudumisel.

Mis selgitab üht neist objektidest orkestraatorile, on fail, mis toimib tema isikut tõendavate dokumentidena, mida nimetatakse manifestiks. See on koodielement, mis on kirjutatud YAML-nimelises keeles, mis deklareerib ressursid, mida objekt loodab kasutada. See on koht, kus kontroller saab soovi korral eelvaate vaadata, kui palju kütust objekt tarbib - kui palju salvestusruumi, millised andmebaaside klassid, millised võrgu pordid. Kontroller teeb kõik endast oleneva, et neid nõudeid täita, teades, et kui klaster on juba ülekoormatud, peab ta võib-olla andma endast parima, mis tal on.

Iga kauna sees on kaugagent nimega kubelet, mis võtab vastu operaatorilt päringuid ja haldab podi komponente. Tavapärases konteineripõhises süsteemis on see kubelet mis käivitab konteinerimootori jaoks protsessid. See on koht, kus Dockeril oli varem reserveeritud koht Kubernetese lauas – see oli varem de facto ainuõiguslik konteinermootorite pakkuja. See lõi isegi universaalse käitusaja nimega runC (hääldatakse "run · vaata") ja avaldas selle avatud lähtekoodiga kogukonnale. Nüüd on Kubernetese projekt loonud oma alternatiivi, nn CRI-O ("cry · O", kuigi mõnikord öeldakse nagu "kreool"), mis on eelistatud konteinermootor Kubernetesel põhinevad platvormid, nagu Red Hat OpenShift.

Kubernetese võidetud konkurendid

Enne kui suur osa tehnikaajakirjandusest jõudis ühisele arusaamisele, et serveriklastri orkestreerimisruum on kaasaegse andmekeskuse kuumim lahinguväli, oli lahing juba lõppenud. Toormeturud taluvad harva konkureerivaid standardeid väga kaua. Sellepärast on üks HTML, üks Facebook ja üks Kubernetes.

Docker Swarm

Docker Inc., ettevõte, mille insenerid vastutasid konteinerirevolutsiooni käivitamise eest, asutas ettevõtte varakult filosoofia, mis põhineb vaba ja avatud lähtekoodiga laiaulatusliku juurutamise, turvalisuse ja toe kommertsialiseerimisel tuum. Tulu tuleks Dockeri tuuma kinnitustest ja tugevdustest, mis olid Dockeri kaubamärgiga, kuid millele olid tavaliselt saadaval asendused, ärimudeli jaoks, mille nimi oli "Patareid". Kaasas, kuid asendatav." Dockeri juhid leidsid, et kui konteinerid peaksid muutuma üldlevinud, ei tohiks sellel olla ei intellektuaalseid ega muid pretensioone asjale, mis muudab konteinerid kaup. Laiem turg tooks ettevõtte arvates kaasa suurema hulga kliente.

Sel eesmärgil toetas Docker 2015. aastal avatud konteineri algatuse loomine (OCI, algselt kas Open Container Project või Open Container Foundation, ehkki paljudel põhjustel, mis nõuavad peagi nimevahetust), Linux Foundationi egiidi all. Ettevõtete konverentsi ajal teadaannet tehes ütles tollane tehnikadirektor Solomon Hykes oma publikule talle ei meeldinud standardisõjad, mida ta kirjeldas kui vaidlemist "detailide üle, nagu kasti suurus ja kuju". Sel põhjusel, hulgas teised teatasid Hykes Dockeri konteinerite käitusaegse komponendi asendamisest - osa, mis muudab need võrgu kaudu kasutatavaks - koos runC.

Samal nädalal teatasid paljud samad OCI asutajaliikmed Cloud Native Computing Foundationi asutamine, veel üks Linuxi fondi projekt. Näiliselt oleks CNCF-i ülesandeks edendada ja edendada avatud lähtekoodiga rakenduste juurutamise tehnoloogiate kasutamist. Esimene projekt CNCF juhiks alates järgmisest märtsist, oleks Kubernetes, projekt, mis sai alguse Google'ist.

Vahepeal, pärast mõnda katset vähem mitmekülgsete ja aeg-ajalt ebamugavad katsed juurutusplatvormidel, Swarmist sai Dockeri orkestrant. Enamiku hinnangute kohaselt oli Swarm väärt kandidaat. Administraatorid ütlesid, et sellel oli palju vähem heidutav õppimiskõver. Selle ülekattega võrgumudel, mis jagas konteineritevahelise liikluse hostiliiklusest, igaüks oma tasapinnas sild nende vahel, peeti nutikaks, eriti võrreldes Kubernetese lameda võrgukatte mudeliga. Mitme pilvega juurutusmudelis saab Swarmi konteineriklastri delegeerida aeglasemale avalikule pilvele, samas kui liiklust juhttasandil saaks paremini piirata madalama latentsusajaga klastris. Toimivuse ja juhitavuse osas olid eksperdid lemmikute valimisega aeglased.

Kui ainuüksi jõudlus määraks tehnoloogialahingute tulemuse, oleks Sun Microsystems töölaua juba ammu vallutanud ja me kõik räägiksime sellest oma BlackBerrydes.

CNCF võttis oma missiooniks edendada ja edendada kogu avatud lähtekoodiga ökosüsteemi laialdast kasutuselevõttu, sealhulgas jõudluse jälgimine, teenuse avastamine, andmemahu haldamine ja turvalisus – kõik keskendub ühele töökoormuse juurutamisele mootor. Docker oli juba alustanud oma laiendatavusmudeli turule toomist, kuid sattus kohe esoteerilisse, filosoofilisse mülkasse selle üle, kas laiendatav arhitektuur rikkus teatud rakenduse disaini dogmat, mida nimetatakse "kodakondsusetuks".

Samal ajal, kui Kubernetes oli kujundatud puhtalt müüja-agnostiliseks platvormiks, pani Google neil algusaegadel oma täie raskuse ja turunduse taga, kohandades nii tarbijatele kui ka ajakirjanikele sobivat teemat ja ühtset esitust, põimides samal ajal Kubernetese nime. bränding. Kogu 2017. aasta jooksul tajusid Kubernetest hindavad ettevõtted seda Google'i tootena. Kui neile seaduspärasusi ja formaalsusi selgitati, lehvitasid paljud neile, öeldes, et sellel pole tähtsust seni, kuni lõpptulemuseks on midagi nn. Google Kubernetes Engine. Rohkem kui mõne vestluse ajal, milles ma osalesin, ütlesid IT-administraatorid ja teised asjatundlikud ettevõtete praktikud mulle, kui see puudutab Google vs. Docker, mis Sam Hill on Docker?

Ometi ei suutnud Google kaua säilitada orkestratsiooniusu ainsa kaitsja välimust. Veidi tagasi aastal 2015, Red Hat tegi tähtsa otsuse asendada oma OpenShifti konteineri juurutusplatvormi mootor Kubernetesiga. 2017. aastaks tasus see otsus end ämbritega ära. Red Hatist oli saanud Kubernetese tipptegija. Põhja pool palkas Microsoft kaks avatud lähtekoodiga kogukonna kõige nähtavamat inseneri, püüdes ära hoida võimalust jääda kõrvale ettevõtte järjekordsest muutuste lainest: Gabe Monroy, kes oli ettevõtte Deis kaasasutaja ja tehnoloogiadirektor. Kubernetese ökosüsteemis oli võtmetähtsusega tegur konteinerrakenduste ehitamisel ja juurutamisel (sõlm Docker oli lootnud kaitsta ise); ja Brendan Burns, üks Google'i inseneridest, kes lõi Borgi, Kubernetese prototüübi [PDF]. Seekord ei varjaks Microsoft oma uusimaid töötajaid mõne uurimisosakonna kõrvalprojekti tagakappi. Nad asusid juhtima Kubernetese pildil olulise Azure'i osa ümbertegemisel.

Tamm purunes ja seda mitmest kohast korraga.

Apache Mesos

Hajutatud serveriklastrite töökoormuse ajastamise väljakujunenud liider oli Apache Mesos. See oli meistri/töölise arhitektuuri teerajaja (kuigi Mesos kasutas "töötaja" jaoks teist sõna) ja oli üks esimesi planeerijaid, mida laiendati privaatseks PaaS-i platvormiks, nimega Marathon. Mesose esimene suurem kasutuselevõtt toimus Twitteris, kus Ben Hindman oli insener. 2013. aastal lahkus Hindman, et asutada Mesose peamine kommertsmüüja Mesosphere. Koostöös Microsoftiga valmistas Mesosphere ühe esimese avaliku pilvepõhise PaaS-i, mis võimaldab korraldatud hübridiseeritud juurutusi: DC/OS, mis näis olevat saanud Azure'i jaoks valitud töökoormuse juurutamise platvormiks. Mesosel oli mitmeaastane juurutamiskogemus, nii et see oli platvorm, mida kõik ei pidanud algusest peale mõistma.

Kuid ametis olev Mesos ei pääsenud mässulise väljakutsuja tagajärgedest täie auruga. 2017. aasta augustis kasutas VMware oma sõsarettevõtte Pivotal ressursse, et käivitada pilvepõhine Kubernetese platvorm nimega Pivotal Container Serviceautomaatse juurutusmehhanismiga Kubo, mis tuli Cloud Foundry ridadesse. Peagi järgis Azure eeskuju, pannes tõhusalt oma DC/OS projekti tagasi. Siis juunis 2018 staar Amazon loovutas oma kaitsepositsiooni, avades oma Kubernetese juurutusplatvormi. Ja lõpuks, vähesed usuvad seda IBM ostis Red Hati, mis lõppes eelmise aasta juulis, rääkis sellest, et IBM vajab paremat Linuxi distributsiooni. OpenShift oli juba sillutanud marsruudid hajutatud andmekeskusesse, mida IBM leidis, et tal pole enam vaja uuesti sillutada.

Lüüasaamine oli nii täielik, et Mesosfäär ei saanud enam selle nimega äri ajada, ristis end mullu augustis ümber D2IQ-ksja lubades luua oma "Ksfääri". Ja oktoobri alguses soovitas Docker et selle kasutajad proovivad Kubernetes ja Swarm kõrvuti käivitada. "Uutel kasutajatel on Docker Swarmist palju lihtsam aru saada," seisis ettevõtte ajaveebi postituses. "Kuid Kubernetes on arenenud, et lisada palju funktsioone."

Kuhu Kubernetes siit edasi läheb

Seni on suur osa andmekeskuste ümberarhitektuuri aruteludest keskendunud vanade töökoormuste uutele mudelitele üleviimise teemale. Rakendusi, nagu oleme neid tundma õppinud, on nimetatud "monoliitideks" sest nagu salapärane objekt filmis "2001", on need ainsad, praktiliselt kindlad ja pärast neljatunnist kinos istumist sama seletamatud kui alguses. Need koosnevad koodist, mida ainult selle looja teab, kuidas muuta.

Kubernetesesse kolimist on kirjeldatud kui monoliitide rändamise protsessi. Mõned on öelnud, et seda saab teha ainult mikroteenuste võrkude ümberehitamise teel, mis käituvad nagu nende monoliitsed eelkäijad, kuid asendavad need täielikult. Teised ütlevad, et API on võimalik ümbritseda monoliitse teenusega ja levitada seda API-d võrgu kaudu mikroteenuste viisil. Seda oleks lihtsam teha ja see ei nõuaks nii palju pingutusi samade funktsioonide kopeerimiseks, mis ettevõtetel juba on.

Nüüd on tänu Kubernetese CRD-le, kui parafraseerida Arlo Guthrie'd, kolmas võimalus, millele keegi isegi ei lootnud: Kubernetes ise saab migreeruda, et rahuldada olemasoleva töökoormuse vajadusi. Kuna Kubernetes on võib-olla maailma kõige aktiivsem avatud lähtekoodiga tarkvaraprojekt, haldavad seda sõna otseses mõttes sajad eksperdid. insenerid, kes võiksid aidata ettevõtetel välja töötada või kohandada kontrollereid ja operaatoreid, mida nad vajavad oma tarkvara automatiseerimiseks tarneahelad.

Kubernetese loojad ütlesid paar aastat tagasi, et saabub aeg, mil nende loomingust saab niivõrd osa kõigi andmekeskustest, et neil oleks igav ja keegi ei loeks selleteemalist artiklit seda. Sellest, mida ma olen tunnistajaks, on see päev veel vähemalt mitme aasta kaugusel.

Lisateave – CBS interaktiivsest võrgust

• Kubernetese järgmine samm võiks olla proovida kõike muud orkestreerida autor Scott M. Fulton, III, ZDNet
• 5G sõltub Kubernetesest pilves autor Steven J. Vaughan-Nichols, ZDNet Linux ja avatud lähtekoodiga
• Miks Red Hat näeb Knative'i vastust Kubernetese orkestratsioonile James Sanders, TechRepublic Cloud

mujal

• Kubernetese kohandatud ressursside määratlused: CRD-de selgitamine BMC tarkvara poolt
• Kubernetes Architecture 101 Aqua Container Security poolt
• Kubernetese arhitektuuri mõistmine autor Edureka