Platforma lehetővé teszi az automatizálás folyamatának megszervezését , beleértve a felhőszolgáltatók infrastruktúráját, virtualizációs platformokat vagy bare-metal rendszereket. Ahhoz, hogy egy igazán felhőalapú platformot hozzunk létre, szigorú ellenőrzés alá kellett vonnunk az összes felhasznált elemet, ezzel növelve a bonyolult automatizálási folyamat megbízhatóságát.
Nyilvánvaló megoldásnak bizonyult a Red Hat Enterprise Linux CoreOS (a Red Hat Enterprise Linux egyik változata) és a CRI-O használata, és itt van, miért…
Mivel a hajózás témája rendkívül jól illeszkedik a Kubernetes és a konténerek működésének magyarázatához, próbáljuk meg bemutatni azokat az üzleti problémákat, amelyeket a CoreOS és a CRI-O megoldanak, egy példán keresztül . 1803-ban Mark Brunel előtt az a feladat állt, hogy 100 ezer vitorlás blokkot készítsen az Egyesült Királyság növekvő tengeri flottájának igényeihez. A vitorlás blokk egy olyan kötélzet, amelyet a kötelek vitorlákhoz rögzítésére használnak. A 19. század elejéig ezeket a blokkokat kézzel állították elő, de Brunelnek sikerült automatizálnia a gyártást és elkezdte a szabványosított blokkok gyártását gépek segítségével. A folyamat automatizálása azt jelentette, hogy a blokkok gyakorlatilag azonosak lettek, könnyen cserélhetők voltak, ha meghibásodtak, és nagy mennyiségben állíthatók elő.
Most pedig képzelje el, hogy Brunelnek ezt a munkát 20 különböző hajótípus (Kubernetes verziók) számára kellene elvégeznie, öt különböző bolygón, teljesen eltérő tengeri áramlatokkal és szelek mellett (felhőszolgáltatók). Ezen kívül meg kellett volna oldania, hogy minden hajó (OpenShift klaszter), függetlenül a navigációs bolygótól, a kapitányok (a klaszterek működését irányító operátorok) szempontjából egyformán viselkedjen. Folytatva a tengeri analógiát, a hajók kapitányai számára teljesen mindegy, hogy milyen vitorlás blokkokat (CRI-O) használnak a hajóikon – számukra a fő szempont az, hogy ezek a blokkok tartósak és megbízhatóak legyenek.
Az OpenShift 4 előtt, mint felhőplatform, egy hasonló üzleti kihívás áll. Az új csomópontokat a klaszter létrehozásakor, egy csomópont hibája esetén, vagy a klaszter méretezésekor kell létrehozni. Új csomópont létrehozásakor és inicializálásakor a hoszt kritikus komponenseit is megfelelően konfigurálni kell, beleértve a CRI-O-t is. Mint bármilyen más gyártás során, először is „nyersanyagot” kell biztosítani. A hajók esetében a nyersanyagot a fém és a fa jelenti. Azonban amikor hosztot hozunk létre konténerek telepítéséhez az OpenShift 4 klaszterében, be kell szereznünk a konfigurációs fájlokat és a szolgáltatott API szervereket. Ezt követően az OpenShift biztosítja a szükséges automatizálási szintet az egész életciklus során, terméktámogatást nyújtva a végfelhasználóknak, így visszahozva a platformba fektetett befektetéseket.
Az OpenShift 4-et úgy alakították ki, hogy kényelmes frissítési lehetőséget biztosítson a platform életciklusa alatt (4.X verziók esetén) az összes fő felhőszolgáltató, virtualizációs platform és akár bare metal rendszerek számára is. Ehhez a csomópontokat helyettesíthető elemekre kell alapozni. Amikor a klaszternek új Kubernetes verzióra van szüksége, megkapja a megfelelő CRI-O verziót is a CoreOS-on. Mivel a CRI-O verzió közvetlenül kapcsolódik a Kuberneteshez, ez jelentősen megkönnyíti a bármilyen átrendezést a tesztelés, hibaelhárítás vagy támogatás céljából. Ezen kívül ez a megközelítés csökkenti a végfelhasználók és a Red Hat költségeit.
Ez egy radikálisan új megközelítés a Kubernetes klaszterekhez, amely új, rendkívül hasznos és vonzó funkciók tervezésének alapját képezi. A CRI-O (Container Runtime Interface - Open Container Initiative nyílt projekt, röviden CRI-OCI) a legjobbnak bizonyult választás a csomópontok tömeges létrehozásához, amely szükséges az OpenShift működéséhez. A CRI-O váltja fel a korábban használt Docker motort, és kínál használati lehetőségeket az OpenShift felhasználói számára. – igen, nem hallottad félre – unalmas konténermotor, amelyet kifejezetten Kubernetes használatára terveztek.
A nyílt konténerek világát
A világ régóta az open container-ek felé halad. Legyen szó Kubernetes-ről vagy alacsonyabb szintekről, új innovációs ökoszisztémák megjelenéséhez vezet minden szinten.
Minden az Open Containers Initiative kezdeményezés létrehozásával kezdődött Ezen a korai szakaszban a konténer és specifikációi alakultak ki. Ez lehetővé tette, hogy az eszközök egyetlen szabványt használjanak és egy egységes formátumot azok kezelésére. Később a specifikációi is hozzá lettek adva, ami lehetővé tette a felhasználók számára, hogy könnyedén megosszák .
Ezután a Kubernetes közössége kidolgozott egy egységes pluggable interface szabványt, amelyet néven ismernek. Ennek köszönhetően a Kubernetes felhasználói különböző motorokat csatlakoztathattak a konténerek kezelésére a Docker mellett.
A Red Hat és a Google mérnökei észrevették a piacon a szükségletet egy olyan konténermotorra, amely képes fogadni a Kubelet kérelmeit a CRI protokollon keresztül, és bemutatták az OCI említett specifikációinak megfelelő konténereket. Így De várjunk, hiszen azt mondtuk, hogy ez az anyag a CRI-O-ról szól? Valójában így van, csak a a projekt átnevezésre került CRI-O-ra.
Fig. 1.
Innovációk a CRI-O-val és a CoreOS-szal
Az OpenShift 4 platform bevezetésével megváltozott az Várj, miért?
Pontosan így, az OpenShift 4 megjelenésével már nincs szükség külön gazdákhoz csatlakozni és konténermotort telepíteni, tárolót konfigurálni, szervereket beállítani a kereséshez vagy hálózatot konfigurálni. Az OpenShift 4 platform teljes mértékben át lett alakítva a használathoz.
a. Nemcsak a végfelhasználói alkalmazások, hanem a platform szintű alapvető műveletek, mint a képek telepítése, a rendszer konfigurálása vagy a frissítések telepítése szempontjából is.
A Kubernetes mindig lehetővé tette a felhasználók számára, hogy az alkalmazásaikat a kívánt állapot meghatározásával és az , hogy biztosítsák, hogy a tényleges állapot maximálisan megfeleljen a megadott állapotnak. Ez a nagy lehetőségeket nyit meg mind a fejlesztés, mind a műveletek szempontjából. A fejlesztők meghatározhatják a szükséges állapotot, az operátornak YAML vagy JSON fájl formájában, majd az operátor létrehozhatja a szükséges alkalmazás példányt a működési környezetben, miközben ennek a példánynak a működési állapota teljesen megfelel a megadottnak.
Az OpenShift 4 a platform operátorainak használatával bevezeti ezt az új paradigmát (a megadott és a tényleges állapot fogalmával) az RHEL CoreOS és a CRI-O kezelésébe. A konfigurálási és verziókezelési feladatokat a úgynevezett . Az MCO jelentősen leegyszerűsíti a klaszter adminisztrátorának munkáját, lényegében automatizálva az utolsó telepítési lépéseket, valamint a telepítés utáni műveleteket (day two operations). Mindez teszi az OpenShift 4-et egy valódi felhőplatformmá. Ezt később részletesebben áttekintjük.
Konténerek indítása
A felhasználók a CRI-O motort használhatták az OpenShift platformon 3.7-es verziótól Tech Preview státuszban, és 3.9-es verziótól általánosan elérhető státuszban (jelenleg támogatott). Ezen kívül a Red Hat széles körben használja a az OpenShift Online-on 3.10-es verziótól. Mindez lehetővé tette a CRI-O csapat számára, hogy hatalmas tapasztalatot szerezzen nagy konténer klaszterek tömeges indításában a Kubernetes-en. Hogy alapvető képet kapjunk arról, hogyan használja a Kubernetes a CRI-O-t, nézzük meg a következő ábrát, amely bemutatja az architektúra működésének elvét.
7. ábra. Hogyan működnek a konténerek a Kubernetes klaszterben
A CRI-O egyszerűsíti az új konténergazdák létrehozását azáltal, hogy a legfelső szint összes szinkronizálásával biztosítja az új csomópontok inicializálását, valamint az OpenShift platform új verzióinak kiadását. Az egész platform revíziója lehetővé teszi a tranzakcionális frissítések / visszagörbítések végrehajtását, valamint megakadályozza a kölcsönös zárolásokat a konténergazda magja, a konténer motor, a csomópontok (Kubelets) és a Kubernetes Master között. Központosított irányítás mellett a platform összes komponensének verziókezelésével mindig nyomon követhetjük a világos utat az A állapotból a B állapotba. Ez leegyszerűsíti a frissítési folyamatot, növeli a biztonságot, javítja a teljesítményjelentést és segít csökkenteni a frissítési és új verziók telepítési költségeit.
A cserélhető elemek erejének bemutatása
Ahogy azt korábban említettük, a Machine Config Operator használata a konténergazda és a konténermotor kezelésére az OpenShift 4-ben új szintű automatizálást biztosít, amely korábban nem volt lehetséges a Kubernetes platformon. Az új lehetőségek bemutatása érdekében megmutatjuk, hogyan módosíthatná a crio.conf fájlt. Hogy ne zavarodjon össze a terminológiában, próbáljon a kimenetekre összpontosítani.
Először is hozzunk létre egy olyan konfigurációt, amelyet konténer futtatási konfigurációnak – Container Runtime Config – nevezünk. Tekintse ezt egy Kubernetes erőforrásnak, amely a CRI-O konfigurációját képviseli. Valójában ez egy specializált változata annak, amit MachineConfig-nak neveznek, és amely bármilyen konfigurációt képvisel, amelyet a RHEL CoreOS gépen telepítenek az OpenShift klaszter keretein belül.
Ez a ContainerRuntimeConfig néven ismert egyedi erőforrás a klaszteradminisztrátorok számára készült, hogy megkönnyítse a CRI-O beállítását. Elegendően erőteljes eszköz ahhoz, hogy csak bizonyos csomópontokra alkalmazzák a MachineConfigPool beállításaitól függően. Tekintse ezt egy olyan gépcsoportnak, amely ugyanazt a célt szolgálja.
Vegye észre az utolsó két sort, amelyet meg fogunk változtatni a /etc/crio/crio.conf fájlban. Ezek a sorok nagyon hasonlóak a crio.conf fájlban található sorokhoz, ezek:
vi ContainerRuntimeConfig.yaml
Következtetés:
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
Most ezután feltöltjük ezt a fájlt a Kubernetes klaszterre, és ellenőrizzük, hogy valóban létrejött-e. Vegye figyelembe, hogy a folyamat pontosan ugyanúgy zajlik, mint bármely más Kubernetes erőforrással.
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Következtetés:
NÉV ÉLETKOR
set-log-and-pid 22h
Miután létrehoztuk a ContainerRuntimeConfig-ot, módosítanunk kell az egyik MachineConfigPool-t, hogy tudassa a Kubernetes-szel, melyik gépcsoporton szeretnénk alkalmazni ezt a konfigurációt. Esetünkben a master gépek MachineConfigPool-ját fogjuk módosítani:
oc edit MachineConfigPool/master
Kimenet (az alapvető lényeg a világosság kedvéért megmaradt):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Ebben a pillanatban az MCO elkezdi létrehozni az új crio.conf fájlt a klaszter számára. Ekkor a Kubernetes API-n keresztül megtekinthető a teljesen elkészült konfigurációs fájl. Ne feledje, hogy a ContainerRuntimeConfig csak a MachineConfig egy speciális változata, ezért megtekinthetjük az eredményt, ha a szükséges sorokra nézünk a MachineConfigs-nál:
oc get MachineConfigs | grep rendered
Következtetés:
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
Vegye figyelembe, hogy a kapott konfigurációs fájl a master gépek számára újabb verzióval rendelkezik, mint az eredeti konfigurációk. Ezek megtekintéséhez futtassa a következő parancsot. Megjegyezzük, hogy ez talán az egyik legjobb egysoros szkript a Kubernetes történetében:
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
Következtetés:
pids_limit = 2048
Most győződjünk meg arról, hogy a konfigurációt alkalmazták az összes master gépen. Először megszerezzük a gépek listáját a klaszterben:
oc get node | grep master
Kimenet:
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
Most nézzük meg a telepített fájlt. Látni fogja, hogy a fájl frissült az új pid és debug direktívák értékeivel, amelyeket megadtunk a ContainerRuntimeConfig erőforrásban. Maga az elegancia:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Következtetés:
...
pids_limit = 2048
...
log_level = "debug"
...
Mindezek a változtatások a klaszterben SSH indítása nélkül is végrehajtásra kerültek. Az összes munka a Kubernetes master csomópontjára való hivatkozással történt. Ez azt jelenti, hogy ezek az új paraméterek csak a master csomópontokon voltak konfigurálva. A munkacsomópontok nem változtak, ami a Kubernetes metodológiájának előnyeit mutatja be az aktuális és megadott állapotok használatával a konténerhősök és a helyettesíthető elemekhez kapcsolódó konténermotorok tekintetében.
A fenti példa azt mutatja, hogy lehetőség van változtatások végrehajtására egy három munkacsomópontból álló kis OpenShift Container Platform 4 klaszterben vagy egy 3000 csomópontból álló hatalmas termelési klaszterben. Bármi is legyen, a munka terjedelme ugyanaz marad – és meglehetősen kicsi – elegendő csak a ContainerRuntimeConfig fájlt beállítani, és megváltoztatni egy címkét (label) a MachineConfigPool-ban. Ezt bármilyen verzióban elvégezheti, amely az OpenShift Container Platform 4.X Kubernetes platformot használja a teljes élettartama alatt.
Gyakran a technológiai vállalatok annyira gyorsan fejlődnek, hogy nem tudjuk megmagyarázni, miért választunk bizonyos technológiákat az alapvető komponensekhez. A konténermotorok történelmileg azok a komponensek voltak, amelyekkel a felhasználók közvetlenül foglalkoznak. Mivel a konténerek népszerűsége a konténermotorok megjelenésével indult, a felhasználók gyakran érdeklődnek irántuk. Ez egy újabb ok, amiért a Red Hat a CRI-O mellett döntött. A konténerek fejlődnek, és manapság a hangsúly az orchestration-en van, és arra a következtetésre jutottunk, hogy a CRI-O a legjobb élményt nyújtja az OpenShift 4 használata során.
Forrás: habr.com
