Platforma omogućava vam da pojednostavite kreiranje , uključujući infrastrukturu provajdera usluga u oblaku, na platformama za virtuelizaciju ili u golim sistemima. Da bismo kreirali zaista platformu zasnovanu na oblaku, morali smo da preuzmemo strogu kontrolu nad svim elementima koji se koriste i na taj način povećamo pouzdanost složenog procesa automatizacije.
Očigledno rješenje je bilo korištenje Red Hat Enterprise Linux CoreOS-a (varijanta Red Hat Enterprise Linuxa) i CRI-O kao standarda, a evo zašto...
Budući da je tema jedrenja vrlo dobra za pronalaženje analogija pri objašnjavanju rada Kubernetesa i kontejnera, pokušajmo razgovarati o poslovnim problemima koje rješavaju CoreOS i CRI-O, koristeći primjer . Godine 1803. Marc Brunel je dobio zadatak da proizvede 100 blokova za opremanje za potrebe rastuće britanske mornarice. Blok za opremi je vrsta opreme koja se koristi za pričvršćivanje užadi na jedra. Sve do samog početka 19. stoljeća ovi blokovi su se izrađivali ručno, ali je Brunel uspio automatizirati proizvodnju i počeo proizvoditi standardizirane blokove pomoću alatnih mašina. Automatizacija ovog procesa značila je da su rezultujući blokovi u suštini identični, da su se mogli lako zamijeniti ako se pokvare i da su se mogli proizvoditi u velikim količinama.
Zamislite sada kada bi Brunel morao obaviti ovaj posao za 20 različitih modela brodova (verzije Kubernetes) i za pet različitih planeta s potpuno različitim morskim strujama i vjetrovima (provajderi oblaka). Osim toga, zahtijevalo se da se svi brodovi (OpenShift klasteri), bez obzira na planete na kojima se vrši navigacija, sa stanovišta kapetana (operatora koji upravljaju radom klastera) ponašaju isto. Da nastavimo pomorsku analogiju, kapetane brodova uopće nije briga kakvi se blokovi za namještanje (CRI-O) koriste na njihovim brodovima - glavno im je da su ti blokovi čvrsti i pouzdani.
OpenShift 4, kao platforma u oblaku, suočava se sa vrlo sličnim poslovnim izazovom. Novi čvorovi se moraju kreirati u trenutku kreiranja klastera, u slučaju kvara na jednom od čvorova ili prilikom skaliranja klastera. Kada je novi čvor kreiran i inicijaliziran, kritične komponente hosta, uključujući CRI-O, moraju biti konfigurirane u skladu s tim. Kao iu svakoj drugoj proizvodnji, "sirovine" se moraju nabaviti na početku. U slučaju brodova, sirovine su metal i drvo. Međutim, u slučaju kreiranja hosta za postavljanje kontejnera u OpenShift 4 klasteru, morate imati konfiguracijske datoteke i servere koje pruža API kao ulaz. OpenShift će tada osigurati potreban nivo automatizacije kroz cijeli životni ciklus, nudeći potrebnu podršku za proizvod krajnjim korisnicima i na taj način nadoknaditi ulaganje u platformu.
OpenShift 4 je kreiran na takav način da pruža mogućnost praktičnog ažuriranja sistema tokom čitavog životnog ciklusa platforme (za verzije 4.X) za sve glavne provajdere računarstva u oblaku, platforme za virtuelizaciju, pa čak i gole metalne sisteme. Da biste to učinili, čvorovi moraju biti kreirani na osnovu izmjenjivih elemenata. Kada klaster zahteva novu verziju Kubernetesa, on takođe dobija odgovarajuću verziju CRI-O na CoreOS-u. Budući da je CRI-O verzija direktno vezana za Kubernetes, 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 fundamentalno nov način razmišljanja o Kubernetes klasterima i postavlja temelj za planiranje nekih vrlo korisnih i uvjerljivih novih funkcija. CRI-O (Container Runtime Interface - Open Container Initiative, skraćeno CRI-OCI) se pokazao kao najuspješniji izbor za masovno kreiranje čvorova koji su neophodni za rad sa OpenShift-om. CRI-O će zamijeniti prethodno korišteni Docker engine, nudeći OpenShift korisnicima – da, dobro ste čuli – dosadni kontejnerski motor kreiran posebno za rad sa Kubernetesom.
Svijet otvorenih kontejnera
Svijet se već dugo kreće ka otvorenim kontejnerima. Bilo u Kubernetesu, ili na nižim nivoima, rezultira ekosistemom inovacija na svakom nivou.
Sve je počelo stvaranjem Inicijative za otvorene kontejnere . U ovoj ranoj fazi rada formirane su specifikacije kontejnera и . To je osiguralo da alati mogu koristiti jedan standard i jedinstveni format za rad s njima. Kasnije su dodane specifikacije , omogućavajući korisnicima da lako dijele .
Zajednica Kubernetes je tada razvila jedan standard za priključni interfejs, tzv . Zahvaljujući tome, korisnici Kubernetesa su uz Docker mogli da povežu različite mašine za rad sa kontejnerima.
Inženjeri u Red Hat-u i Google-u uočili su potrebu tržišta za kontejner motorom koji bi mogao prihvatiti Kubelet zahtjeve preko CRI protokola i predstavili kontejnere koji su kompatibilni sa gore navedenim OCI specifikacijama. Dakle . Ali izvinite, zar nismo rekli da će ovaj materijal biti posvećen CRI-O? Zapravo jeste, samo sa izdanjem projekat je preimenovan u CRI-O.
Fig. 1
Inovacija sa CRI-O i CoreOS
Sa lansiranjem OpenShift 4 platforme, to je promijenjeno , koji se podrazumevano koristi u platformi, a Docker je zamenjen CRI-O, nudeći isplativo, stabilno, jednostavno i dosadno okruženje za pokretanje kontejnera koji se razvija paralelno sa Kubernetesom. Ovo uvelike pojednostavljuje podršku i konfiguraciju klastera. Konfiguracija motora kontejnera i hosta, kao i njihovo upravljanje, postaje automatizirana unutar OpenShift 4.
Čekaj, kako je ovo?
Tako je, sa pojavom OpenShift 4, više nema potrebe da se povežete na pojedinačne hostove i instalirate kontejnerski mehanizam, konfigurišete skladište, konfigurišete servere za pretragu ili konfigurišete mrežu. OpenShift 4 platforma je potpuno redizajnirana za korištenje ne samo u smislu aplikacija za krajnje korisnike, već iu smislu osnovnih operacija na nivou platforme, kao što su postavljanje slika, konfiguracija sistema ili instaliranje ažuriranja.
Kubernetes je oduvijek dozvoljavao korisnicima da upravljaju aplikacijama definiranjem željenog stanja i korištenjem , kako bi se osiguralo da stvarno stanje odgovara ciljnom stanju što je bliže moguće. Ovo otvara velike mogućnosti kako iz perspektive razvoja tako i iz operativne perspektive. Programeri mogu definirati traženo stanje po operatoru u obliku YAML ili JSON datoteke, a zatim operater može kreirati potrebnu instancu aplikacije u proizvodnom okruženju, a radno stanje ove instance će u potpunosti odgovarati navedenom.
Koristeći Operatore u platformi, OpenShift 4 donosi ovu novu paradigmu (koristeći koncept skupa i stvarnog stanja) u upravljanje RHEL CoreOS-om i CRI-O. Zadaci konfigurisanja i upravljanja verzijama operativnog sistema i kontejner motora automatizovani su pomoću tzv. . MCO uvelike pojednostavljuje rad administratora klastera, u suštini automatizujući posljednje faze instalacije, kao i naknadne operacije nakon instalacije (drugi dan operacije). Sve ovo čini OpenShift 4 istinskom cloud platformom. Ući ćemo u ovo malo kasnije.
Radni kontejneri
Korisnici su imali priliku da koriste CRI-O engine u OpenShift platformi od verzije 3.7 u statusu Tech Preview i od verzije 3.9 u statusu Generalno dostupno (trenutno podržano). Pored 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 lansiranju kontejnera na velikim Kubernetes klasterima. Da bismo stekli osnovno razumijevanje o tome kako Kubernetes koristi CRI-O, pogledajmo sljedeću ilustraciju, koja pokazuje kako funkcionira arhitektura.
Rice. 2. Kako kontejneri rade u Kubernetes klasteru
CRI-O pojednostavljuje kreiranje novih host hostova tako što sinhronizuje čitav gornji nivo prilikom inicijalizacije novih čvorova i prilikom objavljivanja novih verzija platforme OpenShift. Revizija čitave platforme omogućava transakcijska ažuriranja/povrata, a takođe sprečava zastoje u zavisnostima između repnog jezgra kontejnera, motora kontejnera, čvorova (Kubelets) i Kubernetes Master čvora. Centralnim upravljanjem svim komponentama platforme, uz kontrolu i upravljanje verzijama, uvijek postoji jasan put od stanja A do stanja B. Ovo pojednostavljuje proces ažuriranja, poboljšava sigurnost, poboljšava izvještavanje o performansama i pomaže u smanjenju troškova ažuriranja i instalacije novih verzija .
Demonstracija snage zamjenskih elemenata
Kao što je ranije spomenuto, korištenje Machine Config Operatora za upravljanje hostom kontejnera i motorom kontejnera u OpenShift 4 pruža novi nivo automatizacije koji ranije nije bio moguć na Kubernetes platformi. Da bismo demonstrirali nove funkcije, pokazat ćemo kako možete napraviti promjene u datoteci crio.conf. Da ne budete zbunjeni terminologijom, pokušajte se fokusirati na rezultate.
Prvo, kreirajmo ono što se zove konfiguracija vremena izvođenja kontejnera - Container Runtime Config. Zamislite to kao Kubernetes resurs koji predstavlja konfiguraciju za CRI-O. U stvarnosti, to je specijalizovana verzija nečega što se zove MachineConfig, što je bilo koja konfiguracija koja se postavlja na RHEL CoreOS mašinu kao deo OpenShift klastera.
Ovaj prilagođeni resurs, nazvan ContainerRuntimeConfig, kreiran je da olakša administratorima klastera da konfigurišu CRI-O. Ovaj alat je dovoljno moćan da se može primijeniti samo na određene čvorove ovisno o postavkama MachineConfigPool-a. Zamislite to kao grupu mašina koje služe istoj svrsi.
Obratite pažnju na posljednja dva reda koje ćemo promijeniti u datoteci /etc/crio/crio.conf. Ove dvije linije su vrlo slične linijama u datoteci crio.conf, 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 da li je stvarno kreirana. Imajte na umu da je operacija potpuno ista kao i sa 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 kreirali ContainerRuntimeConfig, moramo modifikovati jedan od MachineConfigPools-a da signaliziramo Kubernetesu da želimo da primenimo ovu konfiguraciju na određenu grupu mašina u klasteru. U ovom slučaju ćemo promijeniti 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 kreirati 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 je samo specijalizirana verzija MachineConfig, tako da možemo vidjeti rezultat gledajući relevantne linije 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 pogledali, pokrenite sljedeću naredbu. Usput, napominjemo da je ovo možda jedan od najboljih jednostrukih tekstova u istoriji 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 se uvjerimo da je konfiguracija primijenjena na sve glavne čvorove. Prvo dobijamo listu č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 pid i debug direktive 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 su napravljene čak i bez pokretanja SSH-a. Sav posao je obavljen pristupom Kuberentes master čvoru. Odnosno, ovi novi parametri su konfigurisani samo na glavnim čvorovima. Radnički čvorovi se nisu mijenjali, što pokazuje prednosti Kubernetes metodologije korištenja specificiranih i stvarnih stanja u odnosu na hostove kontejnera i kontejnerske mašine sa zamjenjivim elementima.
Gornji primjer pokazuje mogućnost izmjena u malom OpenShift Container Platform 4 klasteru sa tri proizvodna čvora ili velikom proizvodnom klasteru sa 3000 čvorova. U svakom slučaju, količina posla će biti ista – i vrlo mala – samo konfigurišite datoteku ContainerRuntimeConfig i promijenite jednu oznaku u MachineConfigPool-u. A to možete učiniti sa bilo kojom verzijom OpenShift Container Platform 4.X koja pokreće Kubernetes tokom svog životnog ciklusa.
Često se tehnološke kompanije razvijaju tako brzo da nismo u mogućnosti objasniti zašto biramo određene tehnologije za osnovne komponente. Kontejnerski motori su kroz istoriju bili komponenta sa kojom korisnici direktno komuniciraju. Budući da je popularnost kontejnera prirodno počela pojavom kontejnerskih motora, korisnici često pokazuju interes za njih. Ovo je još jedan razlog zašto je Red Hat izabrao CRI-O. Kontejneri se sada razvijaju sa fokusom na orkestraciju i otkrili smo da CRI-O pruža najbolje iskustvo kada radite sa OpenShift 4.
izvor: www.habr.com