platforma omogoča poenostavitev ustvarjanja , vključno z infrastrukturo ponudnikov storitev v oblaku, na platformah za virtualizacijo ali v golih sistemih. Da bi ustvarili resnično platformo, ki temelji na oblaku, smo morali prevzeti strog nadzor nad vsemi uporabljenimi elementi in tako povečati zanesljivost zapletenega procesa avtomatizacije.
Očitna rešitev je bila uporaba Red Hat Enterprise Linux CoreOS (različica Red Hat Enterprise Linux) in CRI-O kot standarda, in tukaj je zakaj ...
Ker je tema jadranja zelo dobra za iskanje analogij pri razlagi dela Kubernetes in kontejnerjev, poskusimo na primeru spregovoriti o poslovnih težavah, ki jih rešujeta CoreOS in CRI-O. . Leta 1803 je bil Marc Brunel zadolžen za proizvodnjo 100 blokov vrvi za potrebe rastoče britanske mornarice. Blok vrvi je vrsta vrvi, ki se uporablja za pritrditev vrvi na jadra. Do samega začetka 19. stoletja so te bloke izdelovali ročno, vendar je Brunel uspel avtomatizirati proizvodnjo in začel proizvajati standardizirane bloke s strojnimi orodji. Avtomatizacija tega procesa je pomenila, da so bili nastali bloki v bistvu identični, da jih je bilo mogoče zlahka zamenjati, če so polomljeni, in jih je bilo mogoče proizvajati v velikih količinah.
Zdaj pa si predstavljajte, če bi moral Brunel opraviti to delo za 20 različnih modelov ladij (različice Kubernetes) in za pet različnih planetov s popolnoma različnimi morskimi tokovi in vetrovi (ponudniki oblakov). Poleg tega je bilo zahtevano, da se vse ladje (grozdi OpenShift), ne glede na planete, na katerih se izvaja navigacija, z vidika kapitanov (operaterjev, ki upravljajo z delovanjem grozdov) obnašajo enako. Če nadaljujemo s pomorsko analogijo, kapitanov ladij sploh ne zanima, kakšne bloke vrvi (CRI-O) uporabljajo na svojih ladjah - zanje je glavno, da so ti bloki močni in zanesljivi.
OpenShift 4 se kot platforma v oblaku sooča z zelo podobnim poslovnim izzivom. Nova vozlišča je treba ustvariti ob ustvarjanju gruče, v primeru okvare enega od vozlišč ali pri skaliranju gruče. Ko je novo vozlišče ustvarjeno in inicializirano, je treba kritične gostiteljske komponente, vključno s CRI-O, ustrezno konfigurirati. Kot pri vsaki drugi proizvodnji, je treba na začetku zagotoviti »surovine«. Pri ladjah sta surovini kovina in les. Vendar pa morate v primeru ustvarjanja gostitelja za uvajanje vsebnikov v gruči OpenShift 4 kot vhod imeti konfiguracijske datoteke in strežnike, ki jih ponuja API. OpenShift bo nato zagotovil zahtevano raven avtomatizacije v celotnem življenjskem ciklu, ponudil potrebno podporo za izdelke končnim uporabnikom in tako povrnil naložbo v platformo.
OpenShift 4 je bil ustvarjen tako, da zagotavlja možnost priročnega posodabljanja sistema v celotnem življenjskem ciklu platforme (za različice 4.X) za vse glavne ponudnike računalništva v oblaku, platforme za virtualizacijo in celo gole kovinske sisteme. Za to je treba ustvariti vozlišča na podlagi zamenljivih elementov. Ko gruča zahteva novo različico Kubernetesa, prejme tudi ustrezno različico CRI-O v sistemu CoreOS. Ker je različica CRI-O neposredno povezana s Kubernetesom, to močno poenostavi vse permutacije za namene testiranja, odpravljanja težav ali podpore. Poleg tega ta pristop zmanjšuje stroške za končne uporabnike in Red Hat.
To je bistveno nov način razmišljanja o gručah Kubernetes in postavlja temelje za načrtovanje nekaterih zelo uporabnih in privlačnih novih funkcij. CRI-O (Container Runtime Interface - Open Container Initiative, skrajšano CRI-OCI) se je izkazal za najuspešnejšo izbiro za množično ustvarjanje vozlišč, ki so nujna za delo z OpenShift. CRI-O bo nadomestil prej uporabljen motor Docker in uporabnikom ponudil OpenShift – da, prav ste slišali – dolgočasen kontejnerski motor, ustvarjen posebej za delo s Kubernetesom.
Svet odprtih zabojnikov
Svet se že dolgo usmerja k odprtim kontejnerjem. V Kubernetesu ali na nižjih ravneh, ima za posledico ekosistem inovacij na vseh ravneh.
Vse se je začelo z ustanovitvijo pobude Open Containers . V tej zgodnji fazi dela so bile oblikovane specifikacije kontejnerjev и . To je zagotovilo, da lahko orodja uporabljajo en sam standard in enoten format za delo z njimi. Specifikacije so bile dodane pozneje , ki uporabnikom omogoča enostavno skupno rabo .
Skupnost Kubernetes je nato razvila enoten standard za vtični vmesnik, imenovan . Zahvaljujoč temu so lahko uporabniki Kubernetesa poleg Dockerja povezali različne motorje za delo s kontejnerji.
Inženirji pri Red Hat in Google so opazili tržno potrebo po vsebniškem mehanizmu, ki bi lahko sprejemal zahteve Kubelet prek protokola CRI, in predstavili vsebnike, ki so bili združljivi z zgoraj omenjenimi specifikacijami OCI. torej . Toda oprostite, ali nismo rekli, da bo to gradivo posvečeno CRI-O? Pravzaprav je, samo z izdajo projekt se je preimenoval v CRI-O.
Sl. 1.
Inovacija s CRI-O in CoreOS
Z lansiranjem platforme OpenShift 4 se je spremenilo , ki se privzeto uporablja v platformi, Docker pa je nadomestil CRI-O, ki ponuja stroškovno učinkovito, stabilno, preprosto in dolgočasno okolje za izvajanje vsebnika, ki se razvija vzporedno s Kubernetesom. To močno poenostavi podporo in konfiguracijo gruče. Konfiguracija mehanizma vsebnika in gostitelja ter njuno upravljanje postane avtomatizirano znotraj OpenShift 4.
Počakaj, kako je to?
Tako je, s prihodom OpenShift 4 ni več potrebe po povezovanju s posameznimi gostitelji in nameščanju vsebniškega mehanizma, konfiguriranju prostora za shranjevanje, konfiguriranju iskalnih strežnikov ali konfiguraciji omrežja. Platforma OpenShift 4 je bila popolnoma preoblikovana za uporabo ne samo v smislu aplikacij za končne uporabnike, temveč tudi v smislu osnovnih operacij na ravni platforme, kot so uvajanje slik, konfiguracija sistema ali namestitev posodobitev.
Kubernetes je uporabnikom vedno omogočal upravljanje aplikacij z definiranjem želenega stanja in uporabo , da zagotovite, da se dejansko stanje čim bolj ujema s ciljnim stanjem. to odpira velike priložnosti tako z razvojnega kot operativnega vidika. Razvijalci lahko določijo zahtevano stanje z operaterju v obliki datoteke YAML ali JSON, nato pa lahko operater ustvari zahtevani primerek aplikacije v produkcijskem okolju in stanje delovanja tega primerka bo popolnoma ustrezalo podanemu.
Z uporabo operaterjev v platformi OpenShift 4 prinaša to novo paradigmo (z uporabo koncepta nabora in dejanskega stanja) v upravljanje RHEL CoreOS in CRI-O. Naloge konfiguriranja in upravljanja različic operacijskega sistema in pogona vsebnika so avtomatizirane s pomočjo t.i. . MCO močno poenostavi delo skrbnika gruče, saj v bistvu avtomatizira zadnje faze namestitve, kot tudi kasnejše ponamestitvene operacije (operacije dan dva). Zaradi vsega tega je OpenShift 4 prava platforma v oblaku. To bomo obravnavali malo kasneje.
Tekoči kontejnerji
Uporabniki so imeli možnost uporabljati motor CRI-O v platformi OpenShift od različice 3.7 v statusu Tech Preview in od različice 3.9 v statusu Generally Available (trenutno podprto). Poleg tega Red Hat množično uporablja v OpenShift Online od različice 3.10. Vse to je ekipi, ki je delala na CRI-O, omogočilo, da je pridobila obsežne izkušnje pri masovnem izstrelitvi vsebnikov na velikih gručah Kubernetes. Da bi dobili osnovno razumevanje, kako Kubernetes uporablja CRI-O, si oglejmo naslednjo ilustracijo, ki prikazuje, kako deluje arhitektura.
riž. 2. Kako vsebniki delujejo v gruči Kubernetes
CRI-O poenostavi ustvarjanje novih gostiteljev vsebnika s sinhronizacijo celotne najvišje ravni pri inicializaciji novih vozlišč in ob izdaji novih različic platforme OpenShift. Revizija celotne platforme omogoča transakcijske posodobitve/povrnitve nazaj in tudi preprečuje zastoje v odvisnostih med jedrom repa vsebnika, mehanizmom vsebnika, vozlišči (Kubelets) in glavnim vozliščem Kubernetes. S centralnim upravljanjem vseh komponent platforme z nadzorom in različicami je vedno jasna pot od stanja A do stanja B. To poenostavi postopek posodabljanja, izboljša varnost, izboljša poročanje o uspešnosti in pomaga zmanjšati stroške posodobitev in namestitev novih različic .
Dokazovanje moči nadomestnih elementov
Kot smo že omenili, uporaba strojnega konfiguracijskega operaterja za upravljanje gostitelja vsebnika in vsebniškega mehanizma v OpenShift 4 zagotavlja novo raven avtomatizacije, ki prej ni bila mogoča na platformi Kubernetes. Za predstavitev novih funkcij bomo pokazali, kako lahko spremenite datoteko crio.conf. Da se izognete zmedi zaradi terminologije, se poskusite osredotočiti na rezultate.
Najprej ustvarimo tako imenovano konfiguracijo izvajalnega okolja vsebnika – Container Runtime Config. Predstavljajte si to kot vir Kubernetes, ki predstavlja konfiguracijo za CRI-O. V resnici gre za specializirano različico nečesa, kar se imenuje MachineConfig, kar je katera koli konfiguracija, ki je nameščena na stroj RHEL CoreOS kot del gruče OpenShift.
Ta vir po meri, imenovan ContainerRuntimeConfig, je bil ustvarjen, da skrbnikom gruče olajša konfiguracijo CRI-O. To orodje je dovolj zmogljivo, da ga je mogoče uporabiti samo za določena vozlišča, odvisno od nastavitev MachineConfigPool. Predstavljajte si to kot skupino strojev, ki služijo istemu namenu.
Bodite pozorni na zadnji dve vrstici, ki ju bomo spremenili v datoteki /etc/crio/crio.conf. Ti dve vrstici sta zelo podobni vrsticam v datoteki crio.conf:
vi ContainerRuntimeConfig.yaml
Zaključek:
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: set-log-and-pid
spec:
machineConfigPoolSelector:
matchLabels:
debug-crio: config-log-and-pid
containerRuntimeConfig:
pidsLimit: 2048
logLevel: debug
Zdaj pa potisnimo to datoteko v gručo Kubernetes in preverimo, ali je bila dejansko ustvarjena. Upoštevajte, da je postopek popolnoma enak kot pri vseh drugih virih Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Zaključek:
NAME AGE
set-log-and-pid 22h
Ko ustvarimo ContainerRuntimeConfig, moramo spremeniti enega od MachineConfigPools, da sporoči Kubernetesu, da želimo to konfiguracijo uporabiti za določeno skupino strojev v gruči. V tem primeru bomo spremenili MachineConfigPool za glavna vozlišča:
oc edit MachineConfigPool/master
Zaključek (zaradi jasnosti ostane glavno bistvo):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Na tej točki MCO začne ustvarjati novo datoteko crio.conf za gručo. V tem primeru si lahko popolnoma dokončano konfiguracijsko datoteko ogledate s pomočjo API-ja Kubernetes. Ne pozabite, da je ContainerRuntimeConfig samo specializirana različica MachineConfig, tako da lahko vidimo rezultat tako, da pogledamo ustrezne vrstice v MachineConfigs:
oc get MachineConfigs | grep rendered
Zaključek:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
Upoštevajte, da je nastala konfiguracijska datoteka za glavna vozlišča novejša različica od prvotnih konfiguracij. Če si ga želite ogledati, zaženite naslednji ukaz. Mimogrede ugotavljamo, da je to morda ena najboljših enovrstičnih v zgodovini Kubernetesa:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
Zaključek:
pids_limit = 2048
Zdaj pa se prepričajmo, da je bila konfiguracija uporabljena za vsa glavna vozlišča. Najprej dobimo seznam vozlišč v gruči:
oc get node | grep master
Output:
ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
Zdaj pa poglejmo nameščeno datoteko. Videli boste, da je bila datoteka posodobljena z novimi vrednostmi za direktive pid in debug, ki smo jih podali v viru ContainerRuntimeConfig. Sama eleganca:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Zaključek:
...
pids_limit = 2048
...
log_level = "debug"
...
Vse te spremembe v gruči so bile izvedene brez izvajanja SSH. Vse delo je bilo opravljeno z dostopom do glavnega vozlišča Kuberentes. To pomeni, da so bili ti novi parametri konfigurirani samo na glavnih vozliščih. Delavna vozlišča se niso spremenila, kar dokazuje prednosti metodologije Kubernetes uporabe določenih in dejanskih stanj v zvezi z gostitelji vsebnikov in motorji vsebnikov z zamenljivimi elementi.
Zgornji primer prikazuje možnost spreminjanja majhne gruče OpenShift Container Platform 4 s tremi proizvodnimi vozlišči ali velike proizvodne gruče s 3000 vozlišči. V vsakem primeru bo obseg dela enak - in zelo majhen - samo konfigurirajte datoteko ContainerRuntimeConfig in spremenite eno oznako v MachineConfigPool. In to lahko storite s katero koli različico platforme OpenShift Container Platform 4.X, ki izvaja Kubernetes v celotnem življenjskem ciklu.
Pogosto se tehnološka podjetja razvijajo tako hitro, da ne moremo pojasniti, zakaj izberemo določene tehnologije za osnovne komponente. Kontejnerski motorji so bili v preteklosti komponenta, s katero uporabniki neposredno komunicirajo. Ker se je priljubljenost kontejnerjev seveda začela s pojavom kontejnerskih motorjev, se uporabniki pogosto zanimajo zanje. To je še en razlog, zakaj je Red Hat izbral CRI-O. Vsebniki se razvijajo s poudarkom na orkestraciji in ugotovili smo, da CRI-O zagotavlja najboljšo izkušnjo pri delu z OpenShift 4.
Vir: www.habr.com