Što je Kubernetes? Sve što vaša tvrtka treba znati

Što je Kubernetes?

Definicija Kubernetesa stalno se mijenja jer kako raste, Kubernetes mijenja svijet oko sebe. Evo sada izdanja za jesen 2019.: Kubernetes je raspodjela radnog opterećenja i mehanizam orkestracije za klasterirane poslužitelje u podatkovnom centru, osiguravajući dostupnost resursa, pristupačnost i uravnoteženo izvođenje za više usluga istovremeno.

U ovoj shemi, Kubernetes omogućuje bilo kojem broju poslužitelja raznih vrsta u isto vrijeme, odvojenih bilo kojom udaljenošću, da dijele radna opterećenja za zajedničkog stanara. Zatim ta radna opterećenja predstavlja klijentima kao usluge -- što znači da ih klijentski sustav može kontaktirati kroz mrežu, proslijedite im neke podatke i nakon trenutak ili dva čekanja prikupite a odgovor.

Ovo je distribuirana obrada podataka, koja se nekada odvijala u granicama jednog, monolitna primjena. Kubernetes cijeli ovaj proces izlaže vidljivosti i upravljivosti.

U upravljanju tim uslugama, Kubernetes po potrebi mijenja raspored mreže. Što više klijenata postavlja zahtjeve određene vrste ili klase radnog opterećenja, orkestrator stavlja na raspolaganje više njegovih replika; isto tako, kako se zahtjevi smanjuju, smanjuje se broj replika. Ovo je proces koji je Kubernetes doveo do slave, a IT operateri ga nazivaju skaliranjem, odnosno skaliranjem. Kada se usluge dijele na pojedinačne funkcije ili mikroservisi, koji međusobno kontaktiraju putem mreže umjesto putem memorije i procesora koje bi inače dijelili, Kubernetes može skalirati pojedinačne mikroservise i smanjivati ​​ih, kako potražnja raste i pada, jednako kao da su cjeloviti aplikacije.

Poslovni slučaj za Kubernetes

Platforme informacijske tehnologije na kojima su izgrađena naša poduzeća, naši sustavi trgovine i znatni dijelovi našeg društva pokazuju svoju starost. Njihova zamjena pitanje je kada su koristi veće od troškova. Kao bilo kojeg pružatelja telekomunikacijskih usluga koji se bori s 5G bežičnom tranzicijom potvrdit će, organizaciji je teško opravdati trošak zamjene cijele infrastrukture osim ako se njezin kratkoročni poslovni model ne može približiti jamčenju profitabilnosti.

Kubernetes ne samo da iznosi argumente za profitabilnost poslovanja, već prikuplja i neke testne slučajeve kako bi se dokazao. U njegovu korist ide sve veći broj dokaza da sve veći troškovi koje organizacije danas plaćaju kako bi zadržale svoju postojeću infrastrukturu postaju sve manje opravdani:

• Cloud se temelji na virtualizaciji prve generacije, koji se smatra zastarjelim i možda, u dogledno vrijeme, nevažnim. Slika softvera koji bi inače bio instaliran na glavnom tvrdom disku poslužitelja je prikazano u memoriji i pohrani udaljenog poslužitelja tako da se softver tamo može izvoditi kao i uvijek prije. Sada više nema potrebe da softver radi kao i prije. Poslovni argumenti za nastavak proizvodnje monolitnih aplikacija su isparili, čak iu slučaju masovna mrežna igra za više igračačije su temeljne, vlasničke platforme ekskluzivne domene njihovih proizvođača.
• Internet je mapiran pomoću sustava domene koji preslikava adrese na njihove registrirane vlasnike, a ne na funkcije i usluge koje se koriste. Servisne mreže preklapaju te karte s relevantnijima, omogućujući distribuiranim aplikacijama da pronađu jedna drugu preko vrlo raspršenih mreža. A te mreže usluga čvrsto su povezane s Kubernetesom, pružajući drugu najrelevantniju uslugu sustava nakon orkestracije radnog opterećenja.
• Mobilni uređaji ovise o mobilnim aplikacijama koji distribuiraju "pametnu" funkcionalnost na strani klijenta, uglavnom kako bi minimizirali informacije koje se razmjenjuju između klijenata i poslužitelja. Budući da bežična propusnost više nije vrhunska roba, moglo bi postati praktičnije i isplativije prebaciti tu funkcionalnost natrag na stranu poslužitelja, omogućavajući novu klase uređaja koji su značajno "gluplji" od svojih prethodnika -- iako sa stvarno izvrsnim kamerama -- ali ispunjavaju iste zadatke uz znatno veću brzine.
• Javni podatkovni centri u oblaku su masivni objekti "hiperrazmjera". koji opslužuju desetke tisuća stanara istovremeno, često s udaljenosti od nekoliko stotina milja. Uz veću distributivnost računarstva, moglo bi postati praktičnije i poželjnije imati veći broj mnogo manjih podatkovnih centara, raštrkanih bliže njihovim korisnicima.
• Umjetna inteligencija čini višu klasu softvera, uglavnom zbog relativnog visoka cijena memorije, pohrane i drugih resursa. Koristeći modele distribuiranih usluga, koji se sastoje od mnoštva spremnika, od kojih svaki ima mnogo manji otisak, AI bi mogao postati daleko uobičajeniji, do te mjere da softver koji izvlači bolje zaključke (npr., "Pazi na ono stablo udaljeno 30 metara!") neće se zvati "pametnim" onoliko koliko se naziva "standardnim operativnim oprema."
• Kontejnerizacija olakšava upravljanje poslovnim softverom. U kontekstu računarstva temeljenog na poslužitelju, spremnik je paket koji omogućuje virtualizaciju radnih opterećenja (prijenosan, samostalan, radi u izolaciji) dok ga još uvijek hostira operativni sustav (za razliku od hipervizor). Moderne aplikacije postale su prenosive između poslužitelja tako što su ih spremile u kontejnere, što se ne odnosi samo na postavljanje paketa. U kontejnerskom okruženju, kod za softver se dohvaća ili "izvlači" iz repozitorija (nekih javnih, drugih privatnih), zatim odmah postavlja i pokreće u proizvodnom okruženju. Ova metoda automatizirane implementacije omogućuje poboljšanje softvera ne samo svakih osamnaest mjeseci, već potencijalno svaki dan, ne samo od strane njegovih autora nego i od strane njegovih korisnika. Zauzvrat, ovo dramatično poboljšava integritet sustava podatkovnog centra kao i sigurnost.

Što znači "orkestracija".

Orkestracija je učinkovito upravljanje i izvođenje višestrukih radnih opterećenja koja kohabitiraju na IT platformi. U slučaju Kubernetesa, određena radna opterećenja mogu stići na platformu nakon što su već podijeljena na mikroservise. I dalje rade zajedno, ali kao samostalne jedinice. Kubernetes orkestracija omogućuje umnožavanje i redistribuciju tih jedinica prema potrebi te postupno ukidanje kada se više ne koriste.

Kao dirigent orkestra?

Pogrešna analogija. Dirigent osigurava da se djelo izvede u pravom vremenu i ritmu. U podatkovnom centru operativni sustav nastavlja igrati tu ulogu -- Kubernetes to ne mijenja. Orkestar koordinira izvođenje svih dijelova u skladbi za maksimalnu učinkovitost i glatkoću izvedbe, tako da jedan dio ne može potisnuti drugi, a svi dijelovi igraju svoje doprinosne uloge učinkovito. Budući da ti dijelovi mogu biti široko raspoređeni na nekoliko lokacija, orkestrator također sastavlja sve resurse koji dijelovi mogu biti potrebni za doprinos istom zadatku koji je pri ruci.

Suprotstavljanje orkestratora i operativnog sustava

Operativni sustav na računalu, između ostalog, omogućuje sigurno i očekivano izvođenje programa pomoću procesora. Kubernetes ispunjava tu ulogu za više radnih opterećenja istovremeno, koja su raspoređena među više poslužitelja u klasteru.

To ne znači da je Kubernetes operacijski sustav koji se povećava. OS i dalje igra ulogu usmjeravanja izvršenja svakog programa. A u kontejnerskom okruženju (barem, izvornom okruženju kako je izvorno dizajnirano) svaki host spremnika nije hipervizor, kao što je to s vSphere ili KVM, već OS.

Međutim, s jedne strane, ono što je operativni sustav za jedno računalo, orkestrator je za klaster poslužitelja: nadzire izvođenje softvera u sustavu čiji su infrastrukturni resursi -- njegova procesorska snaga, memorija, pohrana i mrežni kapaciteti -- svi bili spojeno. Kubernetes je u iznimno kratkom roku riješio pitanje kojeg će orkestratora podatkovni centar preferirati, poput savezničkih trupa koje su oslobodile Kuvajt. Kao i operacija Pustinjski štit, Kubernetes je imao jednostavnu strategiju koja je brzo izvršena.

Gdje ide sav softver?

U modernom podatkovnom centru softver ne treba "instalirati" na računalo. Umjesto toga, to je više poput knjige koja se posuđuje iz knjižnice, samo one koja je sposobna objaviti knjigu prije nego što se posudi. U području kontejnerizacije, ova biblioteka se naziva registar. Paketi otvorenog koda posuđeni iz registra dolaze u potpuno sastavljenim spremnicima. Čin stavljanja aplikacije ili usluge na raspolaganje putem registra za uvođenje u okruženje kojim upravlja Kubernetes naziva se implementacija. Dakle, kada govorimo o "raspodjeli radnih opterećenja", mislimo na čin pripreme softvera za isporuku u klaster poslužitelja, gdje se njime upravlja i orkestrira.

Kubernetes je napravljen da dohvaća pakete radnog opterećenja iz registara, stavlja ih u red čekanja za implementaciju u sustavu, upravlja njihovu raspodjelu među klasterima koje nadziru i upravljaju svojim pristupom resursima koji su preko njih dostupni klasteri.

Zašto je kontejnerizacija toliko važna ako može imati tako bedno ime?

Kontejnerizacija je trend koji je službeno pokrenuo Docker Inc., zatim ga je Google tjerao u warp brzinu, a sada mu se pridružuje većina ostalih u prostoru platforme, uključujući Microsoft i VMware. Bio je to ezoteričan aspekt upravljanja podatkovnim centrom, rečeno nam je prije četiri godine, koji će proći nezapaženo od strane svakodnevnog korisnika. Ipak, svaki gledatelj Netflixa i Amazon Primea, i svaki korisnik Alexa i Siri, osjetio je ovaj utjecaj iz prve ruke, čak i ako nije bio u stanju identificirati njegov izvor. Prebacivanje fokusa upravljanja podatkovnim centrom sa strojeva na radna opterećenja revolucioniralo je način na koji se aplikacije i usluge isporučuju.

Umjesto "kontejnerizacije", koja zvuči kao način industrijalizacije Tupperware zabave, mogla bi biti nazvana "revolucija opterećenja". Mreže se sada usmjeravaju prema funkcijama, a ne prema strojevi. Teško je uvidjeti važnost ove ideje u praksi bez dovoljne analogije iz stvarnog svijeta: Koliko se telefonskih brojeva sjećate napamet? Postoje li veći ili manji uzorci znamenki u vašem umu, sada kada pametni telefoni imaju popise kontakata i mogu odgovoriti na vaš glas?

Kakvo je to "opterećenje" poslom?

Program koji radi na računalu još uvijek je "softver", pozivajući se na izraz koji su NASA-ini inženjeri izvorno skovali tijekom Apollo ere kao igru ​​riječi. A aplikacija je i dalje program koji je osmišljen da njime upravlja više korisnika i koji se naziva imenom.

Za usporedbu, "radno opterećenje" je malo nejasnije. Sastoji se od jednog ili više dijelova softvera. Može koristiti bazu podataka, iako to može biti ista baza podataka koju koriste druga radna opterećenja. Može se sastojati od više od jednog paketa u registru, koji se sastavlja u hodu i dijeli funkcionalnost unutar klastera. Ali obično ima jednu glavnu svrhu i može djelovati kao jedna kohezivna jedinica, čak i ako ima bilo koji broj složenih dijelova.

Programeri softvera obično ne sjede za svojim stolom i sastavljaju radna opterećenja. I dalje pišu programe. Ali u procesu postavljanja spremnika sastavljenih oko tih programa, upute dane orkestratoru kao što je Kubernetes završavaju deklariranjem radnih parametara aktivnog radnog opterećenja. Dakle, u činu implementacije, softver postaje radno opterećenje. Njegovi učinci na potrošnju resursa podatkovnog centra mogu se mjeriti i ublažiti, baš kao i učinci radnog opterećenja u svakodnevnom svijetu ljudi i stvari mogu se izmjeriti i ublažiti zaposlenici.

U redu, što je onda "usluga?"

Usluga u modernom podatkovnom centru vrlo je različita od aplikacije. To se možda ne čini razumnim jer se aplikacije često opisuju kao one koje obavljaju korisne usluge. No, arhitektonski govoreći, usluga je softver koji, uz određene ulaze i usmjeren na relevantne podatke, proizvodi predvidljiv skup izlaza. Bazama podataka često se postavljaju upiti korištenjem usluga.

Aplikacija korisniku pruža okruženje (obično vizualno) u kojem se usluge mogu koristiti. Usluga se ne mora baviti tom funkcijom.

Danas su većina orkestriranih, kontejnerskih programa usluge. Oni mogu obavljati najvažnije poslove aplikacije, ali su neovisne jedinice. Mikrousluge su samostalne, individualne, samostalne usluge koje su obično male (iako su nedavno softverski arhitekti tvrdili da ne moraju biti). Orkestrator može pozvati (ili "instancirati") onoliko klonova mikroservisa koliko je potrebno ili dopušteno da odgovori na zahtjeve koji su im upućeni.

API (izvorno skraćeno za "Application Program Interface") skup je usluga s određenim komunikacijskim protokolom. U umreženom računalstvu, API je dizajniran da se s njim kontaktira na daljinu, obično putem web-preglednika, pomoću URL-a izrađenog za prijenos naredbe ili izjave poslužitelju primatelja. Ta naredba usput može učitati i paket podataka. Odgovor na tu naredbu je servis. Kubernetesova jača strana je orkestriranje usluga.

Da, usluga je vrsta radnog opterećenja. Možda je najistaknutiji primjer moderne servisne arhitekture takozvana funkcija bez poslužitelja. Tako se zove jer se njegov izvor -- poslužitelj ili klaster poslužitelja koji ga ugošćuje -- ne mora adresirati imenom, pa čak ni neizravno, da bi ga pozvala druga usluga ili njezin korisnik. Umjesto toga, te se pojedinosti popunjavaju u ime podnositelja zahtjeva, a rezultat je da se korisnik te funkcije može pretvarati da ona postoji lokalno na klijentu. Poput popisa kontakata na vašem pametnom telefonu, navodi vas na pomisao da su brojevi postali nevažni.

Komponente Kubernetesa

Možda ste primijetili da je ovaj članak pobjegao kroz prvih deset paragrafa bez pozivanja na riječ "kontejner" ili još manje sama po sebi razumljiva riječ "kontejnerizacija". Odvajanje Kubernetesa od spremnika jedna je od najneočekivanijih promjena u opsegu posljednjih mjeseci od Kubernetesa. Za nekoliko trenutaka shvatit ćete zašto.

Jedan od ključnih ciljeva orkestracije je učiniti stvari dostupnima u mreži. Do sada smo te stvari uglavnom nazivali "kontejnerima", iako smo primijetili da od na svojim počecima, Kubernetes se odnosio na entitete kojima koordinira i učinkovito dirigira mahune U ovom kontekstu, izraz "mahuna" definiran je jednostavno kao "skupina spremnika".

Mahune i resursi na kontrolnoj ravni

Svaki poslužitelj (fizički ili virtualni) u Kubernetes klasteru naziva se čvor. Ako sadrži neki aspekt Kubernetesa i može se adresirati putem mreže koju održava orkestrator, to je čvor. Postoji glavni čvor i proizvoljan broj radnih čvorova (ponekad zvanih minioni). Mreža komponenti odgovornih za upravljanje sustavom odvojena je od svih ostalih mreža, kako bi se formirala kontrolna ravnina. Na ovom ekskluzivnom zrakoplovu pronaći ćete tri komponente:

• API poslužitelj(kube-apiserver), koji potvrđuje sve dolazne zahtjeve, uključujući usluge koje se izvode unutar podova.
• Voditelj kontrolora(kube-controller-manager). Pojedinačne komponente Kubernetesa koje imaju izravnu odgovornost za upravljanje nekim resursima unutar sustava nazivaju se kontroleri. Osiguravanje posla za poduzimanje usluge, na primjer, zadatak je kontrolora posla. Ovdje stvari postaju zanimljive: Kubernetes se može proširiti dodavanjem daljnjih kontrolera, što ga čini orkestratorom stvari koje nisu samo spremnici.
• Planer (kube-scheduler), što se ne odnosi toliko na vrijeme koliko na delegiranje radnih opterećenja na mahune. Kada je pod osiguran, planer ga delegira radnom čvoru koji je najprikladniji za rukovanje njime, s obzirom na njegovo trenutno stanje dostupnosti.

Kontroleri se nalaze unutar Kubernetes kontrolne ravnine. Za one koji se isporučuju s Kubernetesom, njihova glavna funkcija je praćenje stanja resursa na mrežnoj infrastrukturi, u potrazi za bilo kakvim promjenama. Potreban je događaj -- signal takve promjene -- da pokrene evaluativnu funkciju koja određuje kako najbolje odgovoriti. Klasa usluge kojoj se može delegirati zadatak odgovaranja je operater. Da bi orkestrator mogao automatizirati složenije sustave, dodao bi servisni arhitekt kontrolori u kontrolnu razinu kako bi donosili odluke, a operateri na stražnjoj strani kako bi djelovali na njih odluke.

Prilagođeni resursi

Proširljivost ove sheme kontrolera bi na kraju mogla biti majstorski potez koji učvršćuje Kubernetesovu poziciju u podatkovnom centru. Kao rezultat arhitektonskog dodatka koji se zove prilagođene definicije resursa (CRD), Kubernetes može orkestrirati i druge stvari osim ovih spremnika. Drugim riječima, ako možete izraditi kontroler koji učinkovito uči Kubernetes da prepozna nešto drugo kao orkestrirani resurs, on će to i učiniti. O čemu mi ovdje govorimo -- što bi moglo biti "nešto drugo"?

• Virtualni strojevi (VM) -- Klasični entiteti vođeni hipervizorom koji podržavaju većinu svjetskih poslovnih opterećenja. VMware, čija je vSphere platforma dominantan komercijalni lider u upravljanju VM-om, ima već je započeo projekt da Kubernetes postane njegov glavni VM orkestrator.
• Masivne baze podataka čiji su motori i kontrolni poslovi posljednjih godina premješteni na namjenske sustave kao što su Hadoop i Apache Spark -- i koji bi mogli zamisliti pomaknuti se s tih platformi ako programeri ponovo budu slobodni pisati radna opterećenja koristeći jezike koji nisu odabrani, kao što su Java, Scala i R.
• Radna opterećenja računalstva visokih performansi (HPC). za superračunala, kojima je kroz povijest upravljalo namjenski planeri kao što je Slurm i, u novije vrijeme, Apache Mesos. Njihova vrlina u podatkovnom centru kao vremenski orijentiranih agenata za raspoređivanje sada se dovodi u pitanje kako se Kubernetes približava gotovo sveprisutnosti.
• Modeli strojnog učenja, koji zahtijevaju velike količine podataka s paralelnim pristupom, kao i determinističko raspoređivanje. Možda mislite da bi ovi faktori sami po sebi diskvalificirali Kubernetes kao orkestratora ili pomagača infrastrukture, ali postoje projekti kao što su Kubeflow pri čemu pružatelje baza podataka i planere koji pružaju ove značajke sami osigurava Kubernetes.

Objekti na podatkovnoj ravni

Sve ove klase entiteta koji nose radno opterećenje koje se skupljaju u mahune, plus sve ostalo što bi Kubernetes mogao orkestrirati u budućnosti, postaju objekti, u nedostatku bolje riječi.

Ono što orkestratoru objašnjava jedan od ovih objekata je datoteka koja služi kao identifikacijski dokument, a zove se manifest. To je element koda, napisan korištenjem jezika zvanog YAML, koji deklarira resurse koje objekt očekuje koristiti. Ovdje je kontroler sposoban pregledati koliko će goriva, ako hoćete, objekt potrošiti -- koliko pohrane, koje klase baza podataka, koji portovi na mreži. Kontrolor daje sve od sebe da ispuni ove zahtjeve, znajući da ako je klaster već preopterećen, možda će morati učiniti najbolje što može s onim što ima.

Unutar svake od mahuna nalazi se udaljeni agent tzv kubelet, koji prima zahtjeve od operatera i upravlja komponentama mahune. U konvencionalnom sustavu koji se temelji na spremnicima, to je kubelet koji stvara procese za spremnik. Ovdje je Docker nekada imao rezervirano mjesto za Kubernetesovim stolom -- nekada je bio de facto ekskluzivni dobavljač kontejnerskih motora. Čak je stvorio univerzalno runtime tzv trčanjeC (izgovara se "trči · vidi") i pustio ga u zajednicu otvorenog koda. Sada je projekt Kubernetes iznjedrio svoju alternativu tzv CRI-O ("cry · O," iako se povremeno kaže kao "kreolski"), koji je preferirani spremnik motora Platforme temeljene na Kubernetesu kao što je Red Hat OpenShift.

Kubernetesovi poraženi konkurenti

Prije nego što je veći dio tehnološkog tiska došao do kolektivne spoznaje da je prostor za orkestraciju klastera poslužitelja najžešće bojno polje u modernom podatkovnom centru, bitka je već bila gotova. Tržišta roba rijetko dugo toleriraju konkurentne standarde. Zato postoji jedan HTML, jedan Facebook i jedan Kubernetes.

Docker Swarm

Docker Inc., tvrtka čiji su inženjeri zaslužni za pokretanje kontejnerske revolucije, osnovala je posao filozofija koja se rano temeljila na komercijalizaciji implementacije velikih razmjera, sigurnosti i podrške za besplatni i otvoreni izvor jezgra. Prihod bi dolazio od dodataka i pojačanja Docker jezgre koji su bili brendirani Dockerom, ali za koje su zamjene bile uobičajeno dostupne, za poslovni model koji se naziva "Baterije" Uključeno, ali zamjenjivo." Ako bi spremnici postali sveprisutni, tvrdili su Dockerovi čelnici, on ne bi trebao imati nikakva prava, intelektualna ili drugačija, na stvar koja kontejnere čini roba. Šire tržište bi, vjerovala je tvrtka, dovelo do većeg broja voljnih kupaca.

U tu je svrhu 2015. Docker podržao stvaranje Open Container Initiative (OCI, izvorno ili Open Container Project ili Open Container Foundation, iako je zbog mnoštva razloga uskoro potrebna promjena imena), pod okriljem Linux Foundationa. Objavljujući to tijekom konferencije tvrtke, rekao je tadašnji tehnički direktor Solomon Hykes svojoj publici nije volio ratove standardima, koje je opisao kao svađu oko "pojedinosti poput veličine i oblika kutije". Iz tog razloga, među drugi, Hykes je najavio zamjenu runtime komponente Docker spremnika -- dijela koji ih čini operativnim preko mreže -- s trčanjeC.

U istom tjednu, mnogi od istih članova osnivača OCI-ja objavili su osnivanje Cloud Native Computing Foundation, još jedan projekt Linux Foundationa. Navodno bi mandat CNCF-a bio promicanje i unaprjeđenje upotrebe tehnologija za implementaciju aplikacija otvorenog koda. Prvi projekt CNCF bi vodio, počevši od sljedećeg ožujka, bio bi Kubernetes, projekt koji je nastao u Googleu.

U međuvremenu, nakon nekoliko eksperimenata s manje svestranim i, povremeno, nespretni pokušaji implementacije platformi, Swarm je postao Dockerov orkestrator. Po većini računa, Swarm je bio dostojan natjecatelj. Administratori su rekli da ima mnogo manje zastrašujuću krivulju učenja. Njegov model umrežavanja preklapanja, koji je podijelio promet između kontejnera od prometa glavnog računala, svaki u svojoj ravnini most između njih, doživljen je kao pametan, posebno u usporedbi s Kubernetesovim modelom preklapanja ravne mreže. U modelu implementacije s više oblaka, klaster kontejnera Swarm mogao bi se delegirati sporijem javnom oblaku, dok bi promet na kontrolnoj ravni mogao biti bolje ograničen na klasteru s nižom latencijom. Što se tiče performansi i upravljivosti, stručnjaci su sporo birali favorite.

Da same performanse određuju ishod tehnoloških bitaka, Sun Microsystems bi već odavno osvojio stolna računala i svi bismo pričali o tome na našim BlackBerryjima.

CNCF je zadao svoju misiju da unaprijedi i promiče široku primjenu čitavog ekosustava otvorenog koda, uključujući praćenje performansi, otkrivanje usluga, upravljanje količinom podataka i sigurnost, sve usredotočeno na jednu implementaciju radnog opterećenja motor. Docker je već počeo lansirati svoj model proširivosti, ali odmah se zapleo u ezoterično, filozofsko blato o tome je li proširiva arhitektura prekršila određenu dogmu dizajna aplikacija koja se naziva "apatridnost".

U isto vrijeme, dok je Kubernetes bio zamišljen kao platforma koja ne ovisi samo o dobavljaču, tijekom tih ranih dana Google je stavio svoju punu težinu i mišićima iza svog marketinga, krojenjem teme i dosljednim predstavljanjem i potrošačima i novinarima, dok je ime Kubernetes utkano u svoj brendiranje. Tijekom 2017. godine poduzeća koja su ocjenjivala Kubernetes doživljavala su ga kao Googleov proizvod. Kad su im objašnjene zakonitosti i formalnosti, mnogi su odmahnuli rukom, govoreći da ništa od toga nije važno sve dok je konačni rezultat nešto tzv. Google Kubernetes Engine. Tijekom više od nekoliko razgovora u kojima sam sudjelovao, IT administratori i drugi stručnjaci iz poslovne prakse rekli su mi, ako se svede na Google vs. Docker, što je Sam Hill Docker?

Ipak, Google nije mogao dugo zadržati izgled jedinog branitelja vjere orkestracije. Daleke 2015. Red Hat je donio značajnu odluku da zamijeni motor svoje platforme za postavljanje kontejnera OpenShift Kubernetesom. Do 2017. ta se odluka višestruko isplatila. Red Hat je postao vrhunski suradnik Kubernetesa. Na sjeveru, Microsoft je, u nastojanju da spriječi mogućnost da bude isključen iz još jednog vala promjena u poduzeću, angažirao dva najvidljivija inženjera zajednice otvorenog koda: Gabe Monroy, koji je bio suosnivač i tehnički direktor tvrtke Deis, ključnog čimbenika u ekosustavu Kubernetes za izgradnju i implementaciju kontejnerskih aplikacija (bedem za koji se Docker nadao da će ga obraniti sebe); i Brendan Burns, jedan od Googleovih inženjera koji su stvorili Borg, prototip Kubernetesa [PDF]. Ovaj put, Microsoft ne bi skrivao svoje najnovije zaposlenike u stražnjem ormaru nekog sporednog projekta istraživačkog odjela. Preuzeli su vodstvo u ponovnoj izradi značajnog dijela Azurea u Kubernetesovoj slici.

Brana je pucala, i to na više mjesta odjednom.

Apache Mesos

Uspostavljeni lider u raspoređivanju radnog opterećenja za distribuirane klastere poslužitelja bio je Apache Mesos. Uveo je arhitekturu master/worker (iako je Mesos koristio drugu riječ za "radnika") i bio je jedan od prvih planera koji je proširen u privatnu PaaS platformu, nazvanu Marathon. Mesosova prva velika implementacija bila je na Twitteru, gdje je Ben Hindman bio inženjer. Godine 2013. Hindman je otišao kako bi osnovao Mesosov glavni komercijalni dobavljač, Mesosphere. U suradnji s Microsoftom, Mesosphere je proizveo jedan od prvih javnih PaaS-ova temeljenih na oblaku koji omogućuju orkestrirane, hibridizirane implementacije: DC/OS, što je izgledalo kao da će postati izbor platforme za implementaciju radnog opterećenja za Azure. Mesos je imao vrlinu nekoliko godina iskustva u postavljanju, tako da je to bila platforma koju nisu svi morali shvatiti od početka.

Ali sadašnji Mesos nije mogao izbjeći učinke pobunjeničkog izazivača s punom parom. U kolovozu 2017. VMware je iskoristio resurse svoje sestrinske tvrtke, Pivotal, za pokretanje platformu Kubernetes temeljenu na oblaku pod nazivom Pivotal Container Service, s automatiziranim mehanizmom za implementaciju pod nazivom Kubo koji je došao kroz redove iz Cloud Foundryja. Ubrzo je Azure slijedio taj primjer, učinkovito usporivši svoj DC/OS projekt. Potom je u lipnju 2018. stalwart Amazon je predao svoj obrambeni položaj, otvarajući svoju Kubernetes platformu za implementaciju. I na kraju, malo tko u to vjeruje IBM-ova akvizicija Red Hata, koja je zatvorena prošlog srpnja, govorio je o tome da IBM treba bolju distribuciju Linuxa. OpenShift je već popločao rute u distribuirani podatkovni centar za koje je IBM otkrio da ih više ne treba ponovno popločavati.

Poraz je bio toliko potpun da Mesosfera više nije mogla poslovati s tim imenom, prekrstivši se u D2IQ prošlog kolovoza, i obećavajući da će uspostaviti vlastitu "Ksphere". A početkom listopada, Docker je predložio da njegovi korisnici pokušaju pokrenuti Kubernetes i Swarm jedan pored drugog. "Novi korisnici smatraju da je mnogo lakše razumjeti Docker Swarm", piše u postu na blogu tvrtke. "Međutim, Kubernetes je evoluirao kako bi dodao puno funkcionalnosti."

Kubernetes ide dalje

Do sada se velik dio rasprava o re-arhitekturi podatkovnog centra vrtio oko teme migracije starih radnih opterećenja na nove modele. Aplikacije kakve smo upoznali nazivaju se "monoliti" jer, poput misterioznog objekta u filmu "2001," oni su jedinstveni, praktički čvrsti i jednako neobjašnjivi nakon četiri sata sjedenja u kinu kao što su bili na početku. Sastoje se od koda koji samo njegov kreator zna kako promijeniti.

Prelazak na Kubernetes opisan je kao proces migracije monolita. Neki su rekli da se to može učiniti samo ponovnom izgradnjom mreža mikroservisa koje se ponašaju kao njihovi monolitni prethodnici, ali koje ih u potpunosti zamjenjuju. Drugi kažu da je moguće omotati API oko monolitne usluge i distribuirati taj API kroz mrežu na način mikroservisa. To bi bilo lakše učiniti i ne bi uključivalo toliko truda u repliciranju iste funkcionalnosti koju tvrtke već posjeduju.

Sada, zahvaljujući Kubernetesovom CRD-u, da parafraziramo Arla Guthriea, postoji treća mogućnost na koju nitko nije ni računao: sam Kubernetes može migrirati kako bi zadovoljio potrebe postojećeg radnog opterećenja. Budući da je možda najaktivniji softverski projekt otvorenog koda na svijetu, Kubernetes održavaju doslovno stotine stručnjaka inženjeri koji bi mogli pomoći tvrtkama u osmišljavanju ili prilagodbi kontrolera i operatera koji bi im bili potrebni za automatizaciju svog softvera opskrbni lanci.

Ljudi koji su stvorili Kubernetes rekli su prije nekoliko godina da će doći vrijeme kada će njihova kreacija postati toliko dio svačijih podatkovnih centara da bi bili dosadni i da nitko ne bi pročitao članak o tome to. Koliko ja svjedočim, taj dan je udaljen još najmanje nekoliko godina.

Saznajte više -- iz CBS Interactive Network

• Kubernetesov sljedeći korak mogao bi biti da pokuša orkestrirati sve ostalo autor Scott M. Fulton, III, ZDNet
• 5G ovisi o Kubernetesu u oblaku napisao Steven J. Vaughan-Nichols, ZDNet Linux i otvoreni kod
• Zašto Red Hat vidi Knative kao odgovor na Kubernetes orkestraciju James Sanders, TechRepublic Cloud

Drugdje

• Kubernetes prilagođene definicije resursa: CRD objašnjenje od strane BMC Software
• Kubernetes arhitektura 101 od strane Aqua Container Security
• Razumijevanje Kubernetes arhitekture od Edureka