Emelvény lehetővé teszi az alkotás egyszerűsítését , beleértve a felhőszolgáltatók infrastruktúrájában, a virtualizációs platformokon vagy a bare-metal rendszerekben. Ahhoz, hogy egy valóban felhőalapú platformot hozzunk létre, szigorúan át kellett vennünk az összes használt elemet, és ezzel növelni kellett egy összetett automatizálási folyamat megbízhatóságát.
A kézenfekvő megoldás a Red Hat Enterprise Linux CoreOS (a Red Hat Enterprise Linux egyik változata) és a CRI-O használata volt szabványként, és itt van miért...
Mivel a vitorlázás témája nagyon alkalmas arra, hogy analógiákat találjunk a Kubernetes és a konténerek munkájának ismertetésekor, próbáljunk meg egy példán keresztül beszélni a CoreOS és a CRI-O által megoldott üzleti problémákról. . 1803-ban Marc Brunel azt a feladatot kapta, hogy készítsen 100 19 kötélzettömböt a növekvő brit haditengerészet igényeire. A kötélzetblokk egyfajta kötélzet, amelyet kötélek vitorlákhoz rögzítésére használnak. A XNUMX. század elejéig ezeket a blokkokat kézzel készítették, de Brunelnek sikerült automatizálnia a gyártást, és szerszámgépekkel elkezdett szabványos blokkokat gyártani. Ennek a folyamatnak az automatizálása azt jelentette, hogy a kapott blokkok gyakorlatilag azonosak voltak, könnyen cserélhetők, ha eltörnek, és nagy mennyiségben gyárthatók.
Most képzelje el, ha Brunelnek ezt a munkát 20 különböző hajómodellnél (Kubernetes-verziók) és öt különböző bolygón kellene elvégeznie, teljesen eltérő tengeráramlatokkal és széllel (felhőszolgáltatók). Ezen túlmenően megkövetelték, hogy minden hajó (OpenShift klaszter), függetlenül attól, hogy mely bolygókon történik a navigáció, a kapitányok (a klaszterek működését irányító üzemeltetők) szempontjából azonos magatartást tanúsítsanak. A tengeri analógia folytatásaként a hajóskapitányokat egyáltalán nem érdekli, hogy milyen kötélzetblokkokat (CRI-O) használnak hajóikon – számukra az a lényeg, hogy ezek a blokkok erősek és megbízhatóak legyenek.
Az OpenShift 4, mint felhőplatform, nagyon hasonló üzleti kihívással néz szembe. Új csomópontokat kell létrehozni a fürt létrehozásakor, az egyik csomópont meghibásodása esetén vagy a fürt méretezésekor. Új csomópont létrehozásakor és inicializálásakor a kritikus gazdagép-összetevőket, beleértve a CRI-O-t is, ennek megfelelően kell konfigurálni. Mint minden más gyártásnál, az „alapanyagot” az elején kell szállítani. Hajók esetében az alapanyag a fém és a fa. Ha azonban egy OpenShift 4-fürtben lévő tárolók üzembe helyezésére szolgáló gazdagépet hoz létre, bemenetként konfigurációs fájlokat és API által biztosított kiszolgálókat kell használnia. Az OpenShift ezután biztosítja a szükséges automatizálási szintet a teljes életciklus során, a szükséges terméktámogatást kínálva a végfelhasználóknak, és így megtérül a platformba fektetett befektetés.
Az OpenShift 4-et úgy hozták létre, hogy lehetővé tegye a rendszer kényelmes frissítését a platform teljes életciklusa során (a 4.X verzióhoz) az összes jelentős számítási felhő szolgáltató, virtualizációs platform és még fémes rendszerek számára is. Ehhez cserélhető elemek alapján csomópontokat kell létrehozni. Ha egy fürtnek a Kubernetes új verziójára van szüksége, a CRI-O megfelelő verzióját is megkapja a CoreOS rendszeren. Mivel a CRI-O verzió közvetlenül kapcsolódik a Kuberneteshez, ez nagyban leegyszerűsíti a tesztelési, hibaelhárítási vagy támogatási célú permutációkat. Ezenkívül ez a megközelítés csökkenti a végfelhasználók és a Red Hat költségeit.
Ez egy alapvetően új gondolkodásmód a Kubernetes-fürtökről, és lefekteti az alapot néhány nagyon hasznos és lenyűgöző új funkció tervezéséhez. A CRI-O (Container Runtime Interface – Open Container Initiative, rövidítve CRI-OCI) bizonyult a legsikeresebb választásnak a csomópontok tömeges létrehozásához, amely szükséges az OpenShift-tel való együttműködéshez. A CRI-O felváltja a korábban használt Docker motort, OpenShift felhasználókat kínálva – igen, jól hallottad – egy unalmas konténermotor, amelyet kifejezetten a Kubernetes-szel való együttműködéshez készítettek.
A nyitott konténerek világa
A világ már régóta a nyitott konténerek felé halad. Akár Kubernetesben, akár alacsonyabb szinten, innovációs ökoszisztémát eredményez minden szinten.
Az egész az Open Containers Initiative létrehozásával kezdődött . A munka e korai szakaszában kialakították a konténerspecifikációkat и . Ez biztosította, hogy az eszközök egyetlen szabványt alkalmazhassanak és a velük való munka egységes formátuma. A specifikációkat később kiegészítették , lehetővé téve a felhasználók számára a könnyű megosztást .
A Kubernetes közösség ezután egyetlen szabványt dolgozott ki a csatlakoztatható interfészhez, az úgynevezett . Ennek köszönhetően a Kubernetes-felhasználók a Docker mellett különféle motorokat is csatlakoztathattak konténerekkel való munkához.
A Red Hat és a Google mérnökei látták, hogy a piacon szükség van egy olyan konténermotorra, amely képes fogadni a Kubelet kéréseket a CRI protokollon keresztül, és olyan konténereket vezettek be, amelyek kompatibilisek a fent említett OCI specifikációkkal. Így . De elnézést, nem azt mondtuk, hogy ezt az anyagot a CRI-O-nak szentelik? Valójában az, csak a megjelenéssel a projektet átnevezték CRI-O-ra.
Fig. 1.
Innováció a CRI-O és CoreOS segítségével
Az OpenShift 4 platform elindításával ez megváltozott , amelyet alapértelmezés szerint használnak a platformon, a Dockert pedig a CRI-O váltotta fel, amely költséghatékony, stabil, egyszerű és unalmas környezetet kínál a Kubernetes-szel párhuzamosan fejlődő konténer futtatásához. Ez nagymértékben leegyszerűsíti a fürt támogatását és konfigurálását. A tárolómotor és a gazdagép konfigurálása, valamint azok kezelése automatizálódik az OpenShift 4-ben.
Várj, hogy van ez?
Így van, az OpenShift 4 megjelenésével többé nem kell csatlakozni az egyes gazdagépekhez és telepíteni egy konténermotort, konfigurálni a tárolást, konfigurálni a keresőkiszolgálókat vagy hálózatot. Az OpenShift 4 platformot teljesen újratervezték, hogy a nemcsak a végfelhasználói alkalmazások, hanem az alapvető platformszintű műveletek, például 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 is lehetővé tette a felhasználók számára az alkalmazások kezelését a kívánt állapot meghatározásával és használatával , hogy a tényleges állapot a lehető legjobban egyezzen a célállapottal. Ez fejlesztési és üzemeltetési szempontból egyaránt nagy lehetőségeket nyit meg. A fejlesztők meghatározhatják a kívánt állapotot az operátorhoz YAML vagy JSON fájl formájában, majd az operátor létrehozhatja a szükséges alkalmazáspéldányt az éles környezetben, és ennek a példánynak a működési állapota teljes mértékben megfelel a megadottnak.
A platformon az Operatorok használatával az OpenShift 4 ezt az új paradigmát (a halmaz és a tényleges állapot fogalmát használva) hozza az RHEL CoreOS és a CRI-O kezelésébe. Az operációs rendszer és a konténermotor verzióinak konfigurálásának és kezelésének feladatait az ún . Az MCO nagymértékben leegyszerűsíti a fürt adminisztrátorának munkáját, lényegében automatizálja a telepítés utolsó szakaszait, valamint az azt követő telepítés utáni műveleteket (második napi műveletek). Mindez valódi felhőplatformmá teszi az OpenShift 4-et. Kicsit később kitérünk erre.
Futó konténerek
A felhasználóknak lehetőségük volt a CRI-O motort az OpenShift platformon a 3.7-es verzió óta Tech Preview állapotban, a 3.9-es verziótól pedig Általánosan elérhető állapotban (jelenleg támogatott) használni. Ezenkívül a Red Hat tömegesen használja az OpenShift Online-ban a 3.10-es verzió óta. Mindez lehetővé tette a CRI-O-n dolgozó csapat számára, hogy széleskörű tapasztalatot szerezzen a nagy Kubernetes-klasztereken lévő konténerek tömeges indítása terén. A Kubernetes CRI-O használatának alapvető megértéséhez nézzük meg a következő ábrát, amely bemutatja az architektúra működését.
Rizs. 2. Hogyan működnek a tárolók egy Kubernetes-fürtben
A CRI-O leegyszerűsíti az új tárolóállomások létrehozását azáltal, hogy az új csomópontok inicializálásakor és az OpenShift platform új verzióinak kiadásakor a teljes felső szintet szinkronizálja. A teljes platform felülvizsgálata lehetővé teszi a tranzakciós frissítéseket/visszaállításokat, valamint megakadályozza a konténer farokmagja, a konténermotor, a csomópontok (Kubelets) és a Kubernetes Master csomópont közötti függőségek holtpontjait. Az összes platformösszetevő központi kezelésével, vezérléssel és verziószámítással, mindig egyértelmű az út az A állapotból a B állapotba. Ez leegyszerűsíti a frissítési folyamatot, javítja a biztonságot, javítja a teljesítményjelentéseket, és segít csökkenteni a frissítések és az új verziók telepítésének költségeit. .
A helyettesítő elemek erejének bemutatása
Ahogy korábban említettük, a Machine Config Operator használata a konténergazda- és tárolómotor kezeléséhez az OpenShift 4-ben az automatizálás új szintjét kínálja, amely korábban nem volt lehetséges a Kubernetes platformon. Az új funkciók bemutatásához megmutatjuk, hogyan módosíthatja a crio.conf fájlt. Annak elkerülése érdekében, hogy a terminológia összezavarja magát, próbáljon az eredményekre összpontosítani.
Először is hozzuk létre az úgynevezett tároló futásidejű konfigurációt – Container Runtime Config. Tekintsd úgy, mint egy Kubernetes-erőforrást, amely a CRI-O konfigurációját képviseli. Valójában ez a MachineConfig nevű valami speciális verziója, amely bármely olyan konfiguráció, amelyet egy OpenShift-fürt részeként telepítenek egy RHEL CoreOS-gépre.
Ezt a ContainerRuntimeConfig nevű egyéni erőforrást azért hozták létre, hogy megkönnyítse a fürtrendszergazdák számára a CRI-O konfigurálását. Ez az eszköz elég erős ahhoz, hogy a MachineConfigPool beállításaitól függően csak bizonyos csomópontokra alkalmazható. Tekintsd úgy, mint egy olyan gépcsoportot, amely ugyanazt a célt szolgálja.
Figyeljük meg az /etc/crio/crio.conf fájl utolsó két sorát, amelyet módosítani fogunk. Ez a két sor nagyon hasonlít a crio.conf fájl soraihoz, ezek a következők:
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 toljuk ezt a fájlt a Kubernetes-fürtbe, és ellenőrizzük, hogy valóban létrejött-e. Kérjük, vegye figyelembe, hogy a művelet pontosan ugyanaz, mint bármely más Kubernetes-erőforrásnál:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Következtetés:
NAME AGE
set-log-and-pid 22h
Miután létrehoztuk a ContainerRuntimeConfig-ot, módosítanunk kell az egyik MachineConfigPool-t, hogy jelezze a Kubernetes felé, hogy ezt a konfigurációt a fürtben lévő gépek egy adott csoportjára szeretnénk alkalmazni. Ebben az esetben megváltoztatjuk a fő csomópontok MachineConfigPool-ját:
oc edit MachineConfigPool/master
Következtetés (az egyértelműség kedvéért a fő lényeg maradt):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Ezen a ponton az MCO megkezdi egy új crio.conf fájl létrehozását a fürt számára. Ebben az esetben a teljesen kész konfigurációs fájl a Kubernetes API segítségével tekinthető meg. Ne feledje, a ContainerRuntimeConfig csak a MachineConfig speciális verziója, így láthatjuk az eredményt, ha megnézzük a MachineConfig megfelelő sorait:
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
Kérjük, vegye figyelembe, hogy a kapott konfigurációs fájl a fő csomópontokhoz egy újabb verzió volt, mint az eredeti konfigurációk. Megtekintéséhez futtassa a következő parancsot. Mellékesen megjegyezzük, hogy ez talán az egyik legjobb egysoros 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 az összes főcsomópontra alkalmazták. Először megkapjuk a fürt csomópontjainak listáját:
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
Most nézzük meg a telepített fájlt. Látni fogja, hogy a fájl frissítve lett a ContainerRuntimeConfig erőforrásban megadott pid és debug direktívák új értékeivel. 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 fürt módosításai az SSH futtatása nélkül történtek. Minden munka a Kuberentes főcsomópont elérésével történt. Vagyis ezek az új paraméterek csak a fő csomópontokon lettek konfigurálva. A munkavégző csomópontok nem változtak, ami bemutatja a Kubernetes módszertan előnyeit a megadott és tényleges állapotok használatában a cserélhető elemekkel rendelkező konténergazdagépek és konténermotorok vonatkozásában.
A fenti példa bemutatja a módosítások lehetőségét egy kis OpenShift Container Platform 4 fürtön három éles csomóponttal vagy egy hatalmas éles fürtön 3000 csomóponttal. Mindenesetre a munka mennyisége ugyanannyi lesz - és nagyon kicsi -, csak konfigurálja a ContainerRuntimeConfig fájlt, és módosítson egy címkét a MachineConfigPoolban. És ezt megteheti az OpenShift Container Platform 4.X bármely verziójával, amely a Kuberneteset futja teljes életciklusa során.
A technológiai vállalatok gyakran olyan gyorsan fejlődnek, hogy nem tudjuk megmagyarázni, miért választunk bizonyos technológiákat a mögöttes összetevőkhöz. A konténermotorok történelmileg azok az összetevők, amelyekkel a felhasználók közvetlenül érintkeznek. Mivel a konténerek népszerűsége természetesen a konténermotorok megjelenésével kezdődött, a felhasználók gyakran érdeklődnek irántuk. Ez egy másik oka annak, hogy a Red Hat a CRI-O-t választotta. A konténerek fejlesztése során a hangszerelésre helyezik a hangsúlyt, és azt találtuk, hogy a CRI-O nyújtja a legjobb élményt az OpenShift 4-gyel végzett munka során.
Forrás: will.com