Laat ons die Kubernetes-argitektuur in detail leer.
Ek neem aan dat u ‘n basiese begrip van Kubernetes het. Indien nie, kyk na die volgende inleidings- en installeringsartikels.
Hoe om Kubernetes op Ubuntu 18 te installeer?
Kubernetes volg meester-slawe-argitektuur. Kubernetes-argitektuur het ‘n meesternode en werkerknope. Daar is vier komponente van a meester node.
En, die werkerknoop het drie komponente.
Dit is hoe ‘n Kubernetes-argitektuur lyk:
Laat ek u breedvoerig oor die komponente van die hoofknooppunt en werkerknope vertel.
1 Meester Node
1.3 Kontroleur Bestuurder
Die hoofnode bestuur die Kubernetes-groepering, en dit is die ingangspunt vir al die administratiewe take. U kan met die hoofnode praat via die CLI, GUI of API. Vir die bereiking van fouttoleransie kan daar meer as een hoofnode in die groep bestaan. As ons meer as een hoofnode het, sal die modus beskikbaar wees met ‘n hoë beskikbaarheid en met een leier wat al die bewerkings uitvoer. Al die ander meesternodes is die volgelinge van die leiersmeesterknoop.
Om Kubernetes te bestuur, gebruik Kubernetes ook ens. Al die hoofnodusse word gekoppel aan etcd, wat ‘n verspreide sleutelwaarde-winkel is.
Laat ek u een vir een oor al hierdie komponente verduidelik.
API Server voer al die administratiewe take op die hoofnode uit. ‘N Gebruiker stuur die res-opdragte na die API-bediener, wat dan die versoeke bekragtig, verwerk en uitvoer. etcd slaan die gevolglike toestand van die groep as ‘n verspreide sleutelwaarde-winkel op.
Daarna het ons ‘n skeduleerder. Soos die naam aandui, skeduleer die skeduleerder die werk na verskillende werkerknope. Dit bevat die inligting oor die gebruik van hulpbronne vir elke werknemerknoop. Die skeduleerder oorweeg ook die gehalte van diensvereistes, datalokasie en vele ander sulke parameters. Daarna skeduleer die skeduleerder die werk in terme van peule en dienste.
Nie-beëindigende kontrolelusse wat die toestand van die Kubernetes-groep reguleer, word deur die Beheerbestuurder bestuur. Elkeen van hierdie beheerslusse weet nou van die gewenste toestand van die voorwerp wat hy bestuur, en kyk dan na hul huidige toestand deur die API-bedieners.
In ‘n beheerslus, as die gewenste toestand nie aan die huidige toestand van die voorwerp voldoen nie, word die regstellende stappe deur die beheerslus geneem om die huidige toestand dieselfde te maak as die gewenste toestand. Dus, die beheerderbestuurder sorg dat u huidige toestand dieselfde is as die gewenste toestand.
Die ens is ‘n verspreide sleutelwaarde-winkel wat gebruik word om die groepstatus te stoor. Dus moet dit óf deel uitmaak van die Kubernetes-meester, óf u kan dit ook ekstern konfigureer. ens is in die goLang geskryf, en dit is gebaseer op die Vlot konsensus algoritme.
Met die vlot kan die versameling van masjiene as ‘n samehangende groep werk wat die mislukkings van sommige van sy lede kan oorleef. Selfs as sommige van die lede nie werk nie, kan hierdie algoritme op enige gegewe tydstip steeds werk. Een van die nodusse in die groep is die meester, en die res daarvan sal die volgelinge wees.
Daar kan net een meester wees, en al die ander meesters moet die meester volg. Behalwe vir die stoor van die groepstatus, word etcd ook gebruik om die konfigurasiebesonderhede soos die subnette en die konfigurasiekaarte op te slaan.
‘N Werkernodus is ‘n virtuele of fisiese bediener wat die toepassings bestuur en deur die hoofnode beheer word. Die peule is op die werkerknope geskeduleer, met die nodige gereedskap om hulle te laat loop en aanmekaar te koppel. Peule is niks anders as ‘n versameling houers nie.
En om toegang tot die toepassings uit die eksterne wêreld te verkry, moet u aan die werkersknope en nie die hoofknooppunte koppel nie.
Kom ons ondersoek die werkknooppomponente.
Die houertyd word basies gebruik om ‘n deurlopende lewensiklus op die werkerknoop te bestuur en te bestuur. Enkele voorbeelde van houertyd wat ek u kan gee, is die houers rkt, lxc, ens. Daar word gereeld waargeneem dat docker ook verwys word as houertyd, maar om presies te wees, laat ek u sê dat docker ‘n platform is wat houers gebruik as die houertyd.
Kubelet is basies ‘n agent wat op elke werkerknoop werk en met die meesternode kommunikeer. Dus, as u tien werkerknope het, loop kubelet op elke werkerknoop. Dit ontvang die peul-definisie op verskillende maniere en bestuur die houers wat met die poort verband hou. Dit sorg ook dat die houers wat deel is van die peule altyd gesond is.
Die kubelet word met die gRPC-raamwerk met die houertyd gebruik. Die kubelet word gekoppel aan die houer runtime interface (CRI) om houers en beeldbewerkings uit te voer. Die beelddiens is verantwoordelik vir al die beeldverwante operasies, terwyl die runtime-diens verantwoordelik is vir al die pod- en houerverwante bedrywighede. Hierdie twee dienste het twee verskillende operasies om uit te voer.
Laat ek u iets interessants vertel, wat vroeër hardekodeer is in Kubernetes, maar met die ontwikkeling van CRI kan Kubernetes nou verskillende tydsduur van houers gebruik sonder om dit te herompompileer. Dus, enige houertyd wat CRI implementeer, kan deur Kubernetes gebruik word om peule, houers en houerbeelde te bestuur. Docker shim en CRI houers is twee voorbeelde van CRI shim. Met docker-afstand word houers geskep met behulp van docker wat op die werkersnodusse geïnstalleer is, en dan gebruik intern-docker ‘n houer om houers te skep en te bestuur
Kube-instaanbediener werk op elke werkerknoop as die netwerkmagtiging. Dit luister na die API-bediener vir elke skep of verwydering van dienspunte. Vir elke dienspunt stel kube-proxy die roetes in sodat dit daarheen kan kom.
Ek hoop dit help u om die Kubernetes-argitektuur op ‘n beter manier te verstaan. Kubernetes se vaardighede is altyd op aanvraag, en as u wil leer om die loopbaan te bou, gaan kyk gerus Udemy-kursus.
Ek het baie gehoor van Kubernetes, maar nie seker wat dit is nie? Contents1
Kry ‘n idee van die Docker-houer Docker is ‘n instrument wat houers gebruik om