Čo je Kubernetes? Všetko, čo vaša firma potrebuje vedieť

Čo je Kubernetes?

Definícia Kubernetes sa neustále mení, pretože ako neustále rastie, Kubernetes mení svet okolo seba. Tu je vydanie na jeseň 2019: Kubernetes je a mechanizmus distribúcie pracovného zaťaženia a orchestrácie pre klastrované servery v dátovom centre, čím sa zabezpečí dostupnosť zdrojov, prístupnosť a vyvážené vykonávanie pre viacero služieb súčasne.

V tejto schéme Kubernetes umožňuje ľubovoľnému počtu serverov mnohých druhov súčasne, oddelených ľubovoľnou vzdialenosťou, zdieľať pracovné zaťaženie pre spoločného nájomníka. Potom tieto úlohy prezentuje klientom ako služby – čo znamená, že klientsky systém ich môže kontaktovať cez sieť, odovzdajte im nejaké údaje a po chvíli alebo dvoch čakania zozbierajte a odpoveď.

Ide o distribuované spracovanie údajov, ktoré sa kedysi uskutočňovalo v rámci jedného, monolitická aplikácia. Kubernetes vystavuje celý tento proces pozorovateľnosti a spravovateľnosti.

Pri správe týchto služieb Kubernetes podľa potreby mení rozloženie siete. Čím viac klientov podáva požiadavky určitého typu alebo triedy pracovného zaťaženia, orchestrátor sprístupňuje viac jeho replík; rovnako, ako požiadavky ustupujú, znižuje počet replík. Toto je proces, ktorý priniesol Kubernetes slávu, čo IT operátori nazývajú škálovanie a škálovanie späť. Keď sú služby rozdelené na jednotlivé funkcie, alebo mikroslužby, ktoré sa navzájom kontaktujú cez sieť namiesto cez pamäť a procesor, ktoré by inak zdieľali, môže Kubernetes škálovať jednotlivé mikroslužby a škálovať ich späť, keď dopyt rastie a klesá, rovnako ako keby boli dokončené aplikácie.

Obchodný prípad pre Kubernetes

Platformy informačných technológií, na ktorých sú postavené naše podniky, naše obchodné systémy a značná časť našej spoločnosti, ukazujú svoj vek. Ich výmena je otázkou výhod, ktoré prevažujú nad nákladmi. Ako akéhokoľvek poskytovateľa telekomunikačných služieb, ktorý zápasí s prechodom na bezdrôtovú sieť 5G potvrdzuje, že pre organizáciu je ťažké zdôvodniť náklady na výmenu celej infraštruktúry, pokiaľ sa jej krátkodobý obchodný model nemôže priblížiť k zaručeniu ziskovosti.

Kubernetes nielenže argumentuje ziskovosťou podnikania, ale pripravuje niekoľko testovacích prípadov, aby sa dokázal. V jeho prospech je narastajúce množstvo dôkazov, že neustále rastúce náklady, ktoré dnes organizácie platia za udržiavanie existujúcej infraštruktúry, sú čoraz menej opodstatnené:

• Cloud je založený na virtualizácii prvej generácie, ktorý sa stáva zastaraným a možno časom irelevantným. Obraz softvéru, ktorý by bol normálne nainštalovaný na hlavný pevný disk servera, je vykreslený v pamäti a úložisku vzdialeného servera, takže softvér tam môže bežať ako vždy predtým. Teraz už nie je potrebné vytvárať softvér, aby fungoval ako vždy predtým. Obchodný dôvod pokračovať vo výrobe monolitických aplikácií sa vyparil, a to aj v prípade masívna online hra pre viacerých hráčovs, ktorých základné, proprietárne platformy sú výhradnými doménami ich výrobcov.
• Internet je mapovaný pomocou doménového systému ktorý mapuje adresy na ich registrovaných vlastníkov a nie na používané funkcie a služby. Servisné siete prekrývajú tieto mapy relevantnejšími mapami, čo umožňuje distribuovaným aplikáciám nájsť sa navzájom v značne rozptýlených sieťach. A tieto servisné siete sú pevne zviazané s Kubernetes a poskytujú druhú najrelevantnejšiu službu systému po orchestrácii pracovného zaťaženia.
• Mobilné zariadenia sú závislé od mobilných aplikácií ktoré distribuujú "inteligentné" funkcie na stranu klienta, hlavne na minimalizáciu informácií vymieňaných medzi klientmi a servermi. Keďže bezdrôtová šírka pásma už nie je prémiovou komoditou, môže byť praktickejšie a nákladovo efektívnejšie presunúť túto funkčnosť späť na stranu servera, čo umožní nové triedu zariadení, ktoré sú výrazne „hlúpejšie“ ako ich predchodcovia – aj keď so skutočne skvelými fotoaparátmi – a napriek tomu plnia rovnaké úlohy pri oveľa lepšej rýchlosti.
• Verejné cloudové dátové centrá sú masívne, „hyperscale“ zariadenia ktoré obsluhujú desaťtisíce nájomníkov súčasne, často zo vzdialeností niekoľko stoviek kilometrov. S väčšou distribuovateľnou výpočtovou technikou sa môže stať praktickejším a žiadanejším mať väčší počet oveľa menších dátových centier roztrúsených v tesnejšej blízkosti ich používateľov.
• Umelá inteligencia zahŕňa vyššiu triedu softvéru, a to najmä kvôli jeho relatívne vysoké náklady na pamäť, úložisko a iné zdroje. Použitím modelov distribuovaných služieb, ktoré zahŕňajú nespočetné množstvo kontajnerov, z ktorých každý má oveľa menšiu stopu, sa AI môže stať oveľa bežnejšou do tej miery, softvér, ktorý vyvodzuje lepšie závery (napr. „Pozor na ten strom vo vzdialenosti 30 yardov!“), sa nebude nazývať „inteligentným“ ani tak ako „štandardná prevádzka“. vybavenie."
• Kontajnerizácia uľahčuje správu podnikového softvéru. V kontexte serverových výpočtov je kontajner balík, ktorý umožňuje virtualizáciu pracovných záťaží (prenosné, samostatné, bežiace v izolácii), zatiaľ čo je stále hosťované operačným systémom (na rozdiel od hypervízor). Moderné aplikácie sa stávajú prenosnými medzi servermi ich kontajnerizáciou, čo nie je len o nasadení v balení. V kontajnerovom prostredí sa kód pre softvér získa alebo „vytiahne“ z repozitárov (niektoré verejné, iné súkromné), potom sa okamžite nasadí a spustí v produkčnom prostredí. Táto metóda automatizovaného nasadenia umožňuje vylepšovať softvér nielen každých osemnásť mesiacov, ale potenciálne každý deň, a to nielen zo strany jeho tvorcov, ale aj zo strany používateľov. To zase dramaticky zlepšuje integritu systému dátového centra, ako aj bezpečnosť.

Čo znamená „orchestrácia“.

Orchestracia je efektívna správa a realizácia viacerých pracovných záťaží na IT platforme. V prípade Kubernetes môžu na platformu doraziť určité pracovné zaťaženia, ktoré už boli rozdelené na mikroslužby. Stále spolupracujú, ale ako nezávislé jednotky. Orchesterizácia Kubernetes umožňuje tieto jednotky množiť a prerozdeľovať podľa potreby a postupne vyraďovať, keď sa už nepoužívajú.

Ako dirigent orchestra?

Nesprávna analógia. Dirigent zabezpečuje, že skladba je vykonaná v správnom čase a rytme. V dátovom centre túto úlohu naďalej zohráva operačný systém – Kubernetes to nemení. Orchestrátor koordinuje prevedenie všetkých častí v skladbe pre maximálnu efektivitu a plynulosť predstavenie, takže jedna časť nemôže prehlušiť druhú a všetky časti hrajú svoje prispievajúce úlohy efektívne. Pretože tieto časti môžu byť rozmiestnené na viacerých miestach, orchestrátor tiež zhromažďuje všetky zdroje, ktoré môžu časti vyžadovať, aby prispeli k rovnakej úlohe.

Porovnanie orchestrátora od operačného systému

Operačný systém v počítači okrem iného umožňuje, aby bol program spustený jeho procesorom bezpečne a podľa očakávania. Kubernetes plní túto úlohu pri viacerých pracovných zaťaženiach súčasne, ktoré sú distribuované medzi viacero serverov v klastri.

To neznamená, že Kubernetes je operačný systém, ktorý je rozšírený. OS stále hrá úlohu zoraďovania vykonávania každého programu. A v kontajnerovom prostredí (aspoň jeho natívnom prostredí, ako bolo pôvodne navrhnuté) nie je hostiteľom každého kontajnera hypervízor, ako je to v prípade vSphere alebo KVM, ale skôr OS.

V jednom ohľade však platí, že čím je operačný systém pre jeden počítač, tým je orchestrátor pre skupinu serverov: dohliada na vykonávanie softvéru v systéme, ktorého infraštruktúrne zdroje – jeho výpočtový výkon, pamäť, úložisko a sieťové zariadenia – boli všetky zlúčené. Kubernetes vyriešil otázku, ktorého orchestrátora by dátové centrum uprednostnilo, v extrémne krátkom čase, ako napríklad spojenecké jednotky, ktoré oslobodili Kuvajt. Rovnako ako operácia Desert Shield, aj Kubernetes mal jednoduchú stratégiu, ktorá bola rýchlo vykonaná.

Kam ide všetok softvér?

V modernom dátovom centre nie je potrebné softvér „inštalovať“ do počítača. Skôr je to ako kniha, ktorá je vypožičaná z knižnice, iba z tej, ktorá je schopná vydať knihu pred jej vypožičaním. V oblasti kontajnerizácie sa táto knižnica nazýva register. Balíky s otvoreným zdrojovým kódom zapožičané z registra sa dodávajú v plne zostavených kontajneroch. Akt sprístupnenia aplikácie alebo služby prostredníctvom registra na zavedenie do prostredia spravovaného Kubernetes sa nazýva nasadenie. Takže keď hovoríme o „nasadzovaní pracovných záťaží“, máme na mysli akt prípravy softvéru na doručenie do serverového klastra, kde je riadený a organizovaný.

Kubernetes je navrhnutý tak, aby získaval balíky pracovného zaťaženia z registrov, radil ich do frontu na nasadenie v systéme, spravoval ich distribúciu medzi zoskupeniami, na ktoré dohliadajú, a riadia ich prístup k zdrojom sprístupneným prostredníctvom nich klastre.

Prečo je kontajnerizácia taká dôležitá, ak môže mať taký mizerný názov?

Kontajnerizácia je trendom, ktorý oficiálne začala spoločnosť Docker Inc., potom spoločnosť Google poháňala rýchlosť warpu a teraz sa k nemu pridala väčšina ostatných v priestore platformy vrátane spoločností Microsoft a VMware. Pred štyrmi rokmi nám bolo povedané, že ide o ezoterický aspekt správy dátového centra, ktorý si bežný používateľ nevšimne. Napriek tomu každý divák Netflixu a Amazon Prime a každý používateľ Alexa a Siri pocítil tento vplyv z prvej ruky, aj keď nebola schopná identifikovať jeho zdroj. Presun zamerania správy dátového centra zo strojov na pracovné zaťaženie spôsobil revolúciu v spôsobe poskytovania aplikácií a služieb.

Skôr ako „kontajnerizácia“, ktorá znie ako spôsob industrializácie večierka Tupperware, by to mohlo byť nazývaná „revolúcia pracovného zaťaženia“. Siete sú teraz smerované skôr k funkciám ako k nim stroje. Je ťažké pochopiť dôležitosť tejto myšlienky v praxi bez dostatočnej analógie z reálneho sveta: Koľko telefónnych čísel si pamätáte z hlavy? Máte vo svojej mysli viac alebo menej vzorov číslic, keď teraz majú smartfóny zoznamy kontaktov a dokážu reagovať na váš hlas?

Čo je to za „pracovnú záťaž“?

Program, ktorý beží na počítači, je stále „softvér“, pričom sa odvoláva na termín, ktorý inžinieri NASA pôvodne vytvorili počas éry Apolla ako slovnú hračku. A aplikácia je stále program navrhnutý na ovládanie viacerými používateľmi a označovaný menom.

Na porovnanie, „pracovná záťaž“ je o niečo nejasnejšia. Skladá sa z jedného alebo viacerých častí softvéru. Môže používať databázu, hoci to môže byť tá istá databáza, ktorú používajú iné pracovné zaťaženia. Môže pozostávať z viac ako jedného balíka v registri, zostaveného za chodu a zdieľania funkcií v rámci klastra. Ale zvyčajne má jeden hlavný účel a je schopný fungovať ako jedna súdržná jednotka, aj keď má ľubovoľný počet kompozitných častí.

Vývojári softvéru zvyčajne nesedia za stolom a neskladajú úlohy. Stále píšu programy. Ale v procese nasadzovania kontajnerov zostavených okolo týchto programov, pokyny poskytnuté orchestrátorovi, ako je Kubernetes, nakoniec deklarujú pracovné parametre aktívneho pracovného zaťaženia. Takže v akte nasadenia sa softvér stáva pracovnou záťažou. Jeho účinky na spotrebu zdrojov dátového centra možno merať a zmierňovať, rovnako ako v prípade účinky pracovného zaťaženia v každodennej sfére ľudí a vecí možno merať a zmierňovať zamestnancov.

Dobre teda, čo je to "služba?"

Služba v modernom dátovom centre je úplne iná vec ako aplikácia. To sa nemusí zdať rozumné, pretože aplikácie sa často opisujú ako aplikácie vykonávajúce užitočné služby. Ale architektonicky povedané, služba je softvér, ktorý na základe špecifikovaných vstupov a nasmerovaných na relevantné údaje vytvára predvídateľný súbor výstupov. Databázy sa často vyhľadávajú pomocou služieb.

Aplikácia poskytuje svojmu používateľovi prostredie (zvyčajne vizuálne), v ktorom je možné využívať služby. Služba sa nemusí zaoberať touto funkciou.

Dnes sú väčšinou organizované, kontajnerové programy služby. Môžu vykonávať najdôležitejšiu činnosť aplikácie, ale sú nezávislými jednotkami. Mikroslužby sú samostatné, individuálne, sebestačné služby, ktoré majú tendenciu byť malé (hoci nedávno softvéroví architekti tvrdili, že nemusia byť). Orchestrátor môže vyvolať (alebo „inštanciovať“) toľko klonov mikroslužieb, koľko je potrebné alebo povolené, aby odpovedalo na požiadavky, ktoré mu boli adresované.

API (pôvodne skratka pre „Application Program Interface“) je súbor služieb so špecifikovaným komunikačným protokolom. V sieťovej výpočtovej technike je rozhranie API navrhnuté tak, aby sa dalo kontaktovať na diaľku, zvyčajne prostredníctvom webového prehliadača, pomocou adresy URL vytvorenej na prenos príkazu alebo príkazu na prijímajúci server. Tento príkaz môže zároveň nahrať dátový balík. Odpoveďou na tento príkaz je služba. Forte Kubernetes je organizovanie služieb.

Áno, služba je druh pracovného zaťaženia. Snáď najvýznamnejším príkladom modernej architektúry služieb je takzvaná funkcia bez servera. Nazýva sa to preto, lebo jeho zdroj – server alebo serverový klaster, ktorý ho hostí – nemusí byť adresovaný menom, alebo dokonca nepriamo, aby bol vyvolaný inou službou alebo jej používateľom. Namiesto toho sa tieto podrobnosti vyplnia v mene žiadateľa, výsledkom čoho je, že používateľ tejto funkcie môže predstierať, že existuje lokálne na klientovi. Rovnako ako zoznam kontaktov na vašom smartfóne vás vedie k myšlienke, že čísla sa stali irelevantnými.

Komponenty Kubernetes

Možno ste si všimli, že tento článok unikol cez prvých desať odsekov bez toho, aby použil slovo „kontajner“ alebo ešte menej samovysvetľujúce slovo „kontajnerizácia“. Oddelenie Kubernetes od kontajnerov je jednou z najneočakávanejších zmien v rozsahu pôsobnosti za posledné mesiace. spoločnosti Kubernetes. Za pár okamihov pochopíte prečo.

Jedným z kľúčových cieľov orchestrácie je sprístupniť veci v sieti. Doteraz sme tieto veci nazývali hlavne „kontajnery“, aj keď sme si to odvtedy všimli pri svojich začiatkoch Kubernetes označoval entity, ktoré koordinuje a efektívne riadi struky. V tomto kontexte bol pojem "pod" definovaný jednoducho ako "skupina nádob".

Moduly a zdroje na riadiacej rovine

Každý server (fyzický alebo virtuálny) v klastri Kubernetes sa nazýva uzol. Ak je hostiteľom nejakého aspektu Kubernetes a je adresovateľný prostredníctvom siete udržiavanej orchestrátorom, je to uzol. Existuje hlavný uzol a ľubovoľný počet pracovných uzlov (niekedy nazývaných prisluhovači). Sieť komponentov zodpovedných za riadenie systému je oddelená od všetkých ostatných sietí a tvorí tak riadiacu rovinu. V tejto exkluzívnej rovine nájdete tri komponenty:

• Server API(kube-apiserver), ktorý overuje všetky prichádzajúce požiadavky vrátane služieb bežiacich vo vnútri modulov.
• Správca kontrolóra(kube-controller-manager). Jednotlivé komponenty Kubernetes, ktoré majú priamu zodpovednosť za správu niektorých zdrojov v rámci systému, sa nazývajú kontroléry. Poskytovanie úlohy pre službu založenú na podu, ktorú má vykonať, je napríklad úlohou pre kontrolóra úloh. Tu sú veci zaujímavé: Kubernetes možno rozšíriť pridaním ďalších ovládačov, čím sa stane orchestrátorom vecí iných ako len kontajnerov.
• Plánovač (kube-scheduler), pri ktorom nejde ani tak o čas, ako o delegovanie úloh na pod. Keď je modul poskytnutý, plánovač ho deleguje na pracovný uzol, ktorý je najvhodnejší na jeho spracovanie vzhľadom na jeho aktuálny stav dostupnosti.

Ovládače sú umiestnené vo vnútri riadiacej roviny Kubernetes. V prípade tých, ktoré sa dodávajú s Kubernetes, je ich hlavnou funkciou monitorovanie stavu zdrojov v sieťovej infraštruktúre pri hľadaní akýchkoľvek zmien. Na spustenie hodnotiacej funkcie, ktorá určí, ako najlepšie reagovať, je potrebná udalosť – signál takejto zmeny. Triedou služby, ktorá môže byť poverená úlohou reagovať, je operátor. Architekt služieb by dodal, aby bolo možné pre orchestrátora automatizovať zložitejšie systémy ovládače do riadiacej roviny, aby mohli robiť rozhodnutia, a operátori na zadnej strane, aby podľa nich konali rozhodnutia.

Vlastné zdroje

Je to rozšíriteľnosť tejto schémy ovládača, ktorá môže byť nakoniec hlavným ťahom, ktorý upevňuje pozíciu Kubernetes v dátovom centre. V dôsledku architektonického doplnku nazývaného definície vlastných zdrojov (CRD), Kubernetes dokáže organizovať aj iné veci ako tieto kontajnery. Inak povedané, ak dokážete vytvoriť ovládač, ktorý efektívne naučí Kubernetes rozpoznať niečo iné ako riadený zdroj, urobí to. O čom sa tu bavíme -- čo by mohlo byť „niečo iné“?

• Virtuálne stroje (VM) - Klasické entity riadené hypervízorom, ktoré podporujú väčšinu celosvetových podnikových úloh. VMware, ktorého platforma vSphere je dominantným komerčným lídrom v správe VM, má už začal projekt, aby sa Kubernetes stal hlavným orchestrátorom VM.
• Masívne databázy ktorých motory a riadiace úlohy sa v posledných rokoch presunuli do špecializovaných systémov, ako sú Hadoop a Apache Spark - a ktoré by mohli presunúť sa z týchto platforiem, ak sa vývojári opäť uvoľnia pri písaní pracovných úloh pomocou iných jazykov, ako je niekoľko vybraných jazykov, ako je Java, Scala a R.
• Pracovné zaťaženie vysokovýkonných výpočtov (HPC). pre superpočítače, ktoré sa historicky riadili podľa špecializované plánovače, ako napríklad Slurm a nedávno, Apache Mesos. Ich prednosť v dátovom centre ako časovo orientovaných plánovacích agentov je teraz spochybňovaná, keď sa Kubernetes blíži k všadeprítomnosti.
• Modely strojového učenia, ktoré vyžadujú veľké objemy dát s paralelným prístupom, ako aj deterministické plánovanie. Možno si myslíte, že tieto faktory samotné diskvalifikujú Kubernetesa ako orchestrátora alebo facilitátora infraštruktúry, ale existujú projekty ako napr. Kubeflow kde poskytovatelia databáz a plánovači, ktorí tieto funkcie poskytujú, sú sami poskytovaní spoločnosťou Kubernetes.

Objekty na dátovej rovine

Všetky tieto triedy entít nesúcich pracovné zaťaženie, ktoré sa zhromažďujú do modulov, plus čokoľvek iné, čo môže Kubernetes v budúcnosti organizovať, sa stanú predmety, pre nedostatok lepšieho slova.

To, čo orchestrátorovi vysvetľuje jeden z týchto objektov, je súbor, ktorý slúži ako jeho identifikačné dokumenty, nazývaný manifest. Je to prvok kódu napísaný pomocou jazyka nazývaného YAML, ktorý deklaruje zdroje, ktoré objekt očakáva použitie. Toto je miesto, kde je kontrolér schopný zobraziť ukážku, koľko paliva, ak chcete, objekt spotrebuje - koľko úložného priestoru, ktoré triedy databáz, ktoré porty v sieti. Riadiaca jednotka sa maximálne snaží splniť tieto požiadavky, pričom vie, že ak je klaster už preťažený, možno bude musieť urobiť to najlepšie, čo môže s tým, čo má.

Vo vnútri každého z modulov je vzdialený agent tzv kubelet, ktorá prijíma požiadavky od operátora a spravuje komponenty modulu. V konvenčnom systéme založenom na kontajneroch je to tak kubelet ktorý vytvára procesy pre kontajnerový motor. To je miesto, kde mal Docker vyhradené miesto pri stole Kubernetes - bol to de facto výhradný poskytovateľ kontajnerových motorov. Dokonca vytvoril univerzálny runtime tzv runC (vyslovuje sa „run · see“) a vydal ho komunite s otvoreným zdrojovým kódom. Teraz projekt Kubernetes splodil svoju vlastnú alternatívu, tzv CRI-O ("plač · O," hoci sa občas hovorí ako "kreolčina"), čo je preferovaný kontajnerový motor Platformy založené na Kubernetes, ako je Red Hat OpenShift.

Kubernetesovi porazení konkurenti

Predtým, ako veľká časť technickej tlače dospela k spoločnému poznaniu, že priestor na orchestráciu klastrov serverov je najhorúcejším bojiskom v modernom dátovom centre, bitka sa už skončila. Komoditné trhy zriedka tolerujú konkurenčné štandardy veľmi dlho. Preto existuje jeden HTML, jeden Facebook a jeden Kubernetes.

Docker Swarm

Docker Inc., spoločnosť, ktorej inžinieri boli zodpovední za spustenie kontajnerovej revolúcie, založila firmu filozofia na začiatku založená na komercializácii rozsiahleho nasadenia, bezpečnosti a podpory pre bezplatný a otvorený zdroj jadro. Príjmy by pochádzali z príloh a zosilnení jadra Docker, ktoré mali značku Docker, ale pre ktoré boli bežne dostupné náhrady, pre obchodný model, ktorý sa nazýval „Batérie“. Zahrnuté, ale vymeniteľné." Ak by sa kontajnery mali stať všadeprítomnými, vodcovia Docker's tvrdili, nemali by mať žiadny intelektuálny alebo iný nárok na vec, ktorá robí kontajnery tovar. Širší trh by podľa spoločnosti viedol k väčšiemu počtu ochotných zákazníkov.

Za týmto účelom v roku 2015 Docker podporil vytvorenie Iniciatívy otvorených kontajnerov (OCI, pôvodne buď Open Container Project alebo Open Container Foundation, aj keď z mnohých dôvodov si čoskoro vyžiadala zmenu názvu), pod záštitou Linux Foundation. Pri vyhlásení počas firemnej konferencie, povedal svojim publikom vtedajší technický riaditeľ Solomon Hykes nemal rád štandardné vojny, ktoré opísal ako hádky kvôli „detailom ako veľkosť a tvar škatule“. Z toho dôvodu medzi iní, Hykes oznámil výmenu runtime komponentu kontajnerov Docker - časti, ktorá ich robí prevádzkyschopnými cez sieť - s runC.

V ten istý týždeň mnohí tí istí zakladajúci členovia OCI oznámili založenie Cloud Native Computing Foundation, ďalší projekt Linux Foundation. Zdanlivo by mandátom CNCF bolo podporovať a rozvíjať používanie technológií nasadzovania aplikácií s otvoreným zdrojom. Prvý projekt, ktorý by mal riadiť CNCF, sa začne v marci budúceho roka, bude Kubernetes, projekt, ktorý vznikol v spoločnosti Google.

Medzitým, po niekoľkých experimentoch s menej všestrannými a príležitostne, nešikovné pokusy o nasadzovacie platformy, Swarm sa stal Dockerovým orchestrátorom. Podľa väčšiny účtov bol Swarm dôstojným uchádzačom. Správcovia povedali, že to malo oveľa menej skľučujúcu krivku učenia. Jeho prekryvný sieťový model, ktorý oddeľoval medzikontajnerovú prevádzku od hostiteľskej prevádzky, každý vo svojej rovine s most medzi nimi, bol vnímaný ako šikovný, najmä v porovnaní s modelom prekrytia plochej siete Kubernetes. V multi-cloudovom modeli nasadenia by mohol byť kontajnerový klaster Swarm delegovaný do pomalšieho verejného cloudu, zatiaľ čo prevádzka na riadiacej rovine by mohla byť viac obmedzená na klastri s nižšou latenciou. Pokiaľ ide o výkon a ovládateľnosť, odborníci si pomaly vyberali obľúbené.

Ak by samotný výkon určoval výsledok technologických bojov, Sun Microsystems by už dávno dobyl desktop a všetci by sme o tom hovorili na našich BlackBerry.

CNCF si stanovilo za svoje poslanie napredovať a podporovať rozsiahle nasadenie celého open source ekosystému, vrátane monitorovanie výkonu, zisťovanie služieb, správa objemu údajov a bezpečnosť, to všetko sa sústreďuje okolo jedného nasadenia pracovného zaťaženia motora. Docker už začal spúšťať svoj model rozšíriteľnosti, ale okamžite sa zamotal do ezoterickej, filozofickej bažiny nad tým, či rozšíriteľná architektúra porušuje určitú dogmu dizajnu aplikácií nazývanú „bezstavovosť“.

V tom istom čase, zatiaľ čo Kubernetes bol obsadený ako platforma čisto nezávislá od dodávateľov, počas týchto prvých dní spoločnosť Google vložila svoju plnú váhu a svalstvo za jej marketingom, prispôsobenie témy a konzistentnej prezentácie spotrebiteľom aj novinárom a zároveň vtĺkaním názvu Kubernetes do svojho značky. V priebehu roka 2017 ho podniky hodnotiace Kubernetes vnímali ako produkt Google. Keď im boli vysvetlené zákonnosti a formality, mnohí ich mávli rukou a povedali, že na ničom z toho nezáleží, pokiaľ je konečným výsledkom niečo tzv. Google Kubernetes Engine. Počas viac ako niekoľkých rozhovorov, ktorých som sa zúčastnil, mi správcovia IT a ďalší odborníci z praxe v podnikaní povedali, či ide o Google vs. Docker, čo je Sam Hill Docker?

Napriek tomu si Google nemohol dlho udržať vzhľad jediného obhajcu viery v orchestráciu. Ešte v roku 2015, Red Hat urobil dôležité rozhodnutie nahradiť motor svojej platformy na nasadenie kontajnerov OpenShift za Kubernetes. Do roku 2017 sa toto rozhodnutie vyplácalo v vedrách. Red Hat sa stal špičkovým prispievateľom Kubernetes. Na severe Microsoft, v snahe odvrátiť možnosť, že bude vylúčený z ďalšej vlny zmien v podniku, najal dvoch najviditeľnejších inžinierov open-source komunity: Gabe Monroy, ktorý bol spoluzakladateľom a CTO spoločnosti Deis, kľúčového faktora v ekosystéme Kubernetes pre budovanie a nasadzovanie kontajnerových aplikácií (hrad Docker dúfal, že bude brániť sám); a Brendan Burns, jeden z inžinierov Google, ktorý vytvoril Borg, prototyp Kubernetes [PDF]. Tentoraz by Microsoft neskrýval svojich najnovších zamestnancov v zadnej skrini nejakého vedľajšieho projektu výskumnej divízie. Ujali sa vedenia v prerobení významného kusu Azure v obraze Kubernetes.

Hrádza sa pretrhávala, a to na viacerých miestach naraz.

Apache Mesos

Zavedený líder v plánovaní pracovného zaťaženia pre klastre distribuovaných serverov bol Apache Mesos. Bol priekopníkom architektúry master/worker (hoci Mesos používal iné slovo pre „worker“) a bol jedným z prvých plánovačov, ktoré boli rozšírené na súkromnú platformu PaaS, nazývanú Marathon. Mesos prvé veľké nasadenie bolo na Twitteri, kde bol Ben Hindman inžinierom. V roku 2013 odišiel Hindman, aby založil popredného komerčného predajcu Mesos, Mesosphere. V spolupráci so spoločnosťou Microsoft vytvorila spoločnosť Mesosphere jedno z prvých verejných cloudových PaaS, ktoré umožňuje riadené, hybridné nasadenia: DC/OS, ktorá vyzerala, že sa stane obľúbenou platformou nasadenia pracovnej záťaže pre Azure. Mesos mal prednosť niekoľkoročných skúseností s nasadzovaním, takže to bola platforma, ktorú od začiatku nemusel pochopiť každý.

No úradujúci Mesos nemohol uniknúť účinkom povstaleckého vyzývateľa s plnou parou. V auguste 2017 VMware na spustenie využila zdroje svojej sesterskej spoločnosti Pivotal cloudová platforma Kubernetes s názvom Pivotal Container Service, s automatickým mechanizmom nasadenia nazvaným Kubo, ktorý prišiel z radov Cloud Foundry. Čoskoro nasledovala Azure a účinne podporila svoj projekt DC/OS. Potom v júni 2018 stálica Amazon sa vzdal svojej obrannej pozície, čím sa otvára platforma nasadenia Kubernetes. A napokon, málokto tomu verí IBM akvizícia spoločnosti Red Hat, ktorá sa uzavrela vlani v júli, bol o tom, že IBM potrebuje lepšiu distribúciu Linuxu. OpenShift už vydláždil cesty do distribuovaného dátového centra, o ktorých IBM zistilo, že ich už nie je potrebné znova dláždiť.

Porážka bola taká úplná, že Mesosphere už nemohla podnikať s týmto menom, prekrstiť sa D2IQ vlani v augustea zaviazal sa založiť vlastnú „Ksphere“. A začiatkom októbra, navrhol Docker že jeho používatelia skúšajú spustiť Kubernetes a Swarm vedľa seba. „Noví používatelia pochopia Docker Swarm oveľa ľahšie,“ uvádza sa na blogu spoločnosti. "Kubernetes sa však vyvinul, aby pridal veľa funkcií."

Odkiaľ pochádza Kubernetes

Doteraz sa veľká časť diskusie o prestavbe dátového centra sústreďovala na tému migrácie starých pracovných záťaží na nové modely. Aplikácie, ako sme ich poznali, sa nazývali „monolity“ pretože, podobne ako záhadný objekt vo filme „2001“, sú jedinečné, prakticky pevné a rovnako nevysvetliteľné po tom, čo štyri hodiny sedeli v divadle, ako boli na začiatku. Pozostávajú z kódu, ktorý vie zmeniť iba jeho tvorca.

Prechod na Kubernetes bol opísaný ako proces migrácie monolitov. Niektorí povedali, že sa to dá dosiahnuť iba prestavbou sietí mikroslužieb, ktoré sa správajú ako ich monolitické predchodkyne, ale ktoré ich úplne nahradia. Iní hovoria, že je možné zabaliť API okolo monolitickej služby a distribuovať toto API cez sieť spôsobom mikroslužieb. Bolo by to jednoduchšie a nevyžadovalo by si toľko úsilia replikovať rovnakú funkčnosť, ktorú už podniky vlastnia.

Teraz, vďaka CRD od Kubernetes, aby sme parafrázovali Arlo Guthrieho, existuje tretia možnosť, s ktorou nikto ani nepočítal: samotný Kubernetes môže migrovať, aby vyhovoval potrebám existujúceho pracovného zaťaženia. Kubernetes, ktorý je možno najaktívnejším svetovým softvérovým projektom s otvoreným zdrojovým kódom, je udržiavaný doslova stovkami odborníkov inžinierov, ktorí by mohli pomôcť podnikom pri navrhovaní alebo prispôsobovaní ovládačov a operátorov, ktoré by potrebovali na automatizáciu svojho softvéru zásobovacie reťazce.

Ľudia, ktorí vytvorili Kubernetes, povedali pred niekoľkými rokmi, že príde čas, keď sa ich stvorenie stane natoľko súčasťou dátových centier každého človeka, že by boli nudné a nikto by nečítal článok o to. Podľa toho, čo som svedkom, ten deň je ešte minimálne niekoľko rokov vzdialený.

Viac informácií - z interaktívnej siete CBS

• Ďalším krokom Kubernetesa by mohla byť snaha zorganizovať všetko ostatné od Scotta M. Fulton, III, ZDNet
• 5G závisí od Kubernetes v cloude od Stevena J. Vaughan-Nichols, ZDNet Linux a Open Source
• Prečo Red Hat vidí Knative ako odpoveď na orchestráciu Kubernetes od Jamesa Sandersa, TechRepublic Cloud

Inde

• Definície vlastných zdrojov Kubernetes: Vysvetlenie CRD od BMC Software
• Kubernetes Architecture 101 od spoločnosti Aqua Container Security
• Pochopenie architektúry Kubernetes od Edureky