platforma omogućuje pojednostavljenje stvaranja , uključujući u infrastrukturi pružatelja usluga u oblaku, na virtualizacijskim platformama ili u golim sustavima. Kako bismo stvorili doista platformu temeljenu na oblaku, morali smo strogo kontrolirati sve korištene elemente i tako povećati pouzdanost složenog procesa automatizacije.
Očigledno rješenje bilo je koristiti Red Hat Enterprise Linux CoreOS (varijanta Red Hat Enterprise Linuxa) i CRI-O kao standard, a evo i zašto...
Budući da je tema plovidbe vrlo dobra za pronalaženje analogija pri objašnjavanju rada Kubernetesa i kontejnera, pokušajmo na primjeru govoriti o poslovnim problemima koje CoreOS i CRI-O rješavaju . Godine 1803. Marc Brunel dobio je zadatak proizvesti 100 blokova opute za potrebe rastuće britanske mornarice. Blok opute je vrsta opute koja se koristi za pričvršćivanje užadi na jedra. Sve do samog početka 19. stoljeća ti su se blokovi izrađivali ručno, no Brunel je uspio automatizirati proizvodnju i počeo proizvoditi standardizirane blokove pomoću alatnih strojeva. Automatizacija ovog procesa značila je da su rezultirajući blokovi u biti identični, da se mogu lako zamijeniti ako se polome i da se mogu proizvoditi u velikim količinama.
Sada zamislite da Brunel mora obaviti ovaj posao za 20 različitih modela brodova (verzije Kubernetesa) i za pet različitih planeta s potpuno različitim morskim strujama i vjetrovima (pružatelji oblaka). Osim toga, zahtijevalo se da se svi brodovi (OpenShift klasteri), bez obzira na planete na kojima se vrši navigacija, sa stajališta kapetana (operatora koji upravljaju radom klastera) ponašaju jednako. Da nastavimo s pomorskom analogijom, kapetane brodova uopće nije briga kakve se blokove opute (CRI-O) koriste na njihovim brodovima - njima je glavno da su ti blokovi čvrsti i pouzdani.
OpenShift 4, kao platforma u oblaku, suočava se s vrlo sličnim poslovnim izazovom. Novi čvorovi moraju biti kreirani u trenutku stvaranja klastera, u slučaju kvara na jednom od čvorova ili prilikom skaliranja klastera. Kada se kreira i inicijalizira novi čvor, kritične komponente glavnog računala, uključujući CRI-O, moraju se konfigurirati u skladu s tim. Kao iu svakoj drugoj proizvodnji, “sirovine” moraju biti opskrbljene na početku. Kod brodova sirovine su metal i drvo. Međutim, u slučaju stvaranja glavnog računala za postavljanje spremnika u klasteru OpenShift 4, trebate imati konfiguracijske datoteke i poslužitelje koje pruža API kao ulaz. OpenShift će zatim osigurati potrebnu razinu automatizacije tijekom cijelog životnog ciklusa, nudeći potrebnu podršku za proizvod krajnjim korisnicima i tako nadoknaditi ulaganje u platformu.
OpenShift 4 stvoren je na takav način da pruži mogućnost prikladnog ažuriranja sustava tijekom cijelog životnog ciklusa platforme (za verzije 4.X) za sve glavne pružatelje usluga računalstva u oblaku, virtualizacijske platforme, pa čak i gole metalne sustave. Da biste to učinili, čvorovi moraju biti stvoreni na temelju izmjenjivih elemenata. Kada klaster zahtijeva novu verziju Kubernetesa, također prima odgovarajuću verziju CRI-O na CoreOS-u. Budući da je verzija CRI-O izravno povezana s Kubernetesom, to uvelike pojednostavljuje sve permutacije za potrebe testiranja, rješavanja problema ili podrške. Osim toga, ovaj pristup smanjuje troškove za krajnje korisnike i Red Hat.
Ovo je temeljno nov način razmišljanja o Kubernetes klasterima i postavlja temelje za planiranje nekih vrlo korisnih i uvjerljivih novih značajki. CRI-O (Container Runtime Interface - Open Container Initiative, skraćeno CRI-OCI) pokazao se kao najuspješniji izbor za masovnu izradu čvorova koji su neophodni za rad s OpenShift-om. CRI-O će zamijeniti prethodno korišten Docker motor, nudeći OpenShift korisnicima – da, dobro ste čuli – dosadni kontejnerski motor kreiran posebno za rad s Kubernetesom.
Svijet otvorenih kontejnera
Svijet se već dugo kreće prema otvorenim kontejnerima. Bilo u Kubernetesu ili na nižim razinama, rezultira ekosustavom inovacija na svim razinama.
Sve je počelo stvaranjem Inicijative otvorenih kontejnera . U ovoj ranoj fazi rada formirane su specifikacije spremnika и . To je osiguralo da alati mogu koristiti jedan standard te jedinstveni format za rad s njima. Kasnije su dodane specifikacije , omogućujući korisnicima jednostavno dijeljenje .
Kubernetes zajednica zatim je razvila jedinstveni standard za priključno sučelje, tzv . Zahvaljujući tome, korisnici Kubernetesa su uz Docker mogli povezati različite motore za rad s kontejnerima.
Inženjeri Red Hata i Googlea uvidjeli su tržišnu potrebu za spremnikom koji bi mogao prihvatiti Kubelet zahtjeve preko CRI protokola i uveli su spremnike koji su kompatibilni s gore spomenutim OCI specifikacijama. Tako . Ali oprostite, nismo li rekli da će ovaj materijal biti posvećen CRI-O? Zapravo i jest, samo s izdanjem projekt je preimenovan u CRI-O.
Slika. 1.
Inovacije s CRI-O i CoreOS
Lansiranjem platforme OpenShift 4 to je promijenjeno , koji se standardno koristi u platformi, a Docker je zamijenjen CRI-O, nudeći isplativo, stabilno, jednostavno i dosadno okruženje za pokretanje spremnika koji se razvija paralelno s Kubernetesom. Ovo uvelike pojednostavljuje podršku i konfiguraciju klastera. Konfiguracija spremnika i hosta, kao i njihovo upravljanje, postaje automatizirano unutar OpenShift 4.
Čekaj, kako je ovo?
Tako je, s dolaskom OpenShift 4, više nema potrebe za povezivanjem s pojedinačnim hostovima i instaliranjem spremnika, konfiguriranjem pohrane, konfiguriranjem poslužitelja za pretraživanje ili konfiguriranjem mreže. Platforma OpenShift 4 potpuno je redizajnirana za korištenje ne samo u smislu aplikacija za krajnje korisnike, već i u smislu osnovnih operacija na razini platforme kao što su postavljanje slika, konfiguracija sustava ili instaliranje ažuriranja.
Kubernetes je uvijek dopuštao korisnicima upravljanje aplikacijama definiranjem željenog stanja i korištenjem , kako bi se osiguralo da stvarno stanje odgovara ciljanom stanju što je moguće bliže. Ovaj otvara velike mogućnosti iz razvojne i operativne perspektive. Programeri mogu definirati traženo stanje pomoću operateru u obliku YAML ili JSON datoteke, a zatim operater može kreirati traženu instancu aplikacije u proizvodnom okruženju, a operativno stanje ove instance će u potpunosti odgovarati navedenoj.
Korištenjem operatora u platformi, OpenShift 4 donosi ovu novu paradigmu (koristeći koncept skupa i stvarnog stanja) u upravljanje RHEL CoreOS i CRI-O. Zadaci konfiguracije i upravljanja verzijama operativnog sustava i spremnika automatizirani su korištenjem tzv. . MCO uvelike pojednostavljuje rad administratora klastera, u osnovi automatizirajući posljednje faze instalacije, kao i naknadne postinstalacijske operacije (operacije dan dva). Sve to čini OpenShift 4 pravom platformom u oblaku. Ući ćemo u ovo malo kasnije.
Tekući kontejneri
Korisnici su imali priliku koristiti CRI-O motor u OpenShift platformi od verzije 3.7 u statusu Tech Preview i od verzije 3.9 u statusu Generally Available (trenutno podržano). Osim toga, Red Hat masovno koristi u OpenShift Online od verzije 3.10. Sve je to omogućilo timu koji radi na CRI-O da stekne veliko iskustvo u masovnom pokretanju spremnika na velikim Kubernetes klasterima. Da bismo stekli osnovno razumijevanje kako Kubernetes koristi CRI-O, pogledajmo sljedeću ilustraciju koja pokazuje kako arhitektura funkcionira.
Riža. 2. Kako spremnici rade u Kubernetes klasteru
CRI-O pojednostavljuje stvaranje novih hostova spremnika sinkronizacijom cijele gornje razine prilikom inicijalizacije novih čvorova i prilikom izdavanja novih verzija OpenShift platforme. Revizija cijele platforme omogućuje transakcijska ažuriranja/vraćanja, a također sprječava zastoje u ovisnostima između repne jezgre spremnika, pogona spremnika, čvorova (Kubelets) i glavnog čvora Kubernetes. Centralnim upravljanjem svim komponentama platforme, uz kontrolu i određivanje verzija, uvijek postoji jasan put od stanja A do stanja B. To pojednostavljuje proces ažuriranja, poboljšava sigurnost, poboljšava izvješćivanje o performansama i pomaže smanjiti troškove ažuriranja i instalacije novih verzija .
Pokazivanje snage zamjenskih elemenata
Kao što je ranije spomenuto, korištenje Machine Config Operatora za upravljanje hostom spremnika i spremnikom u OpenShift 4 pruža novu razinu automatizacije koja prije nije bila moguća na platformi Kubernetes. Da bismo demonstrirali nove značajke, pokazat ćemo kako možete napraviti promjene u datoteci crio.conf. Kako biste izbjegli zabunu s terminologijom, pokušajte se usredotočiti na rezultate.
Prvo, kreirajmo ono što se zove konfiguracija vremena izvođenja spremnika - Container Runtime Config. Zamislite to kao Kubernetes resurs koji predstavlja konfiguraciju za CRI-O. U stvarnosti, to je specijalizirana verzija nečega što se zove MachineConfig, što je bilo koja konfiguracija koja se postavlja na RHEL CoreOS stroj kao dio OpenShift klastera.
Ovaj prilagođeni resurs, nazvan ContainerRuntimeConfig, stvoren je kako bi administratorima klastera olakšao konfiguriranje CRI-O. Ovaj je alat dovoljno moćan da se može primijeniti samo na određene čvorove ovisno o postavkama MachineConfigPoola. Zamislite to kao skupinu strojeva koji služe istoj svrsi.
Primijetite posljednja dva retka koja ćemo promijeniti u datoteci /etc/crio/crio.conf. Ove dvije linije vrlo su slične linijama u crio.conf datoteci, to su:
vi ContainerRuntimeConfig.yaml
Zaključak:
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
Sada gurnimo ovu datoteku u Kubernetes klaster i provjerimo je li stvarno stvorena. Imajte na umu da je postupak potpuno isti kao i s bilo kojim drugim Kubernetes resursom:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Zaključak:
NAME AGE
set-log-and-pid 22h
Nakon što smo izradili ContainerRuntimeConfig, moramo modificirati jedan od MachineConfigPools kako bismo signalizirali Kubernetesu da želimo primijeniti ovu konfiguraciju na određenu grupu strojeva u klasteru. U ovom slučaju promijenit ćemo MachineConfigPool za glavne čvorove:
oc edit MachineConfigPool/master
Zaključak (radi jasnoće, glavna suština je ostavljena):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
U ovom trenutku MCO počinje stvarati novu crio.conf datoteku za klaster. U ovom slučaju, potpuno gotova konfiguracijska datoteka može se vidjeti pomoću Kubernetes API-ja. Zapamtite, ContainerRuntimeConfig samo je specijalizirana verzija MachineConfiga, tako da možemo vidjeti rezultat gledajući relevantne retke u MachineConfigs:
oc get MachineConfigs | grep rendered
Zaključak:
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
Imajte na umu da je rezultirajuća konfiguracijska datoteka za glavne čvorove bila novija verzija od originalnih konfiguracija. Da biste ga vidjeli, pokrenite sljedeću naredbu. Usput, napominjemo da je ovo možda jedan od najboljih one-linera u povijesti 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čak:
pids_limit = 2048
Sada provjerimo je li konfiguracija primijenjena na sve glavne čvorove. Prvo dobivamo popis čvorova u klasteru:
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
Sada pogledajmo instaliranu datoteku. Vidjet ćete da je datoteka ažurirana novim vrijednostima za direktive pid i debug koje smo naveli u resursu ContainerRuntimeConfig. Sama elegancija:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Zaključak:
...
pids_limit = 2048
...
log_level = "debug"
...
Sve ove promjene u klasteru napravljene su bez pokretanja SSH-a. Sav posao obavljen je pristupom glavnom čvoru Kuberentes. Odnosno, ti novi parametri konfigurirani su samo na glavnim čvorovima. Radnički čvorovi nisu se promijenili, što pokazuje prednosti Kubernetesove metodologije korištenja specificiranih i stvarnih stanja u odnosu na hostove spremnika i motore spremnika s izmjenjivim elementima.
Gornji primjer pokazuje mogućnost unošenja izmjena u mali klaster OpenShift Container Platform 4 s tri proizvodna čvora ili veliki proizvodni klaster s 3000 čvorova. U svakom slučaju, količina posla bit će ista - i vrlo mala - samo konfigurirajte datoteku ContainerRuntimeConfig i promijenite jednu oznaku u MachineConfigPoolu. A to možete učiniti s bilo kojom verzijom OpenShift Container Platform 4.X koja pokreće Kubernetes tijekom svog životnog ciklusa.
Često se tehnološke tvrtke razvijaju tako brzo da ne možemo objasniti zašto odabiremo određene tehnologije za temeljne komponente. Kontejnerski motori su kroz povijest bili komponenta s kojom korisnici izravno komuniciraju. Budući da je popularnost kontejnera prirodno počela s pojavom kontejnerskih motora, korisnici često pokazuju interes za njih. Ovo je još jedan razlog zašto je Red Hat odabrao CRI-O. Kontejneri se razvijaju s fokusom sada na orkestraciju, a otkrili smo da CRI-O pruža najbolje iskustvo pri radu s OpenShift 4.
Izvor: www.habr.com