Plattform erlaabt Iech d'Schafung ze streamline , och an der Infrastruktur vun de Cloud Service Provider, op Virtualiséierungsplattformen oder a Bare-Metal Systemer. Fir eng wierklech Cloud-baséiert Plattform ze kreéieren, hu mir strikt Kontroll iwwer all déi benotzt Elementer missen huelen an domat d'Zouverlässegkeet vun engem komplexe Automatisatiounsprozess erhéijen.
Déi offensichtlech Léisung war Red Hat Enterprise Linux CoreOS (eng Variant vu Red Hat Enterprise Linux) an CRI-O als Standard ze benotzen, an hei ass firwat ...
Well d'Thema Segelen e ganz gutt ass fir Analogien ze fannen wann Dir d'Aarbecht vu Kubernetes a Container erkläert, loosst eis probéieren iwwer d'Geschäftsproblemer ze schwätzen déi CoreOS an CRI-O léisen, mat engem Beispill . Am Joer 1803 krut de Marc Brunel d'Aufgab fir 100 Rigging-Blöcke fir d'Bedierfnesser vun der wuessender britescher Marine ze produzéieren. E Rigging Block ass eng Aart vu Rigging déi benotzt gëtt fir Seeler op Seegelen ze befestigen. Bis zum Ufank vum 19. Joerhonnert goufen dës Blöcke vun der Hand gemaach, awer de Brunel huet et fäerdeg bruecht d'Produktioun ze automatiséieren an ugefaang standardiséierte Blöden mat Maschinnen ze produzéieren. Automatisatioun vun dësem Prozess huet bedeit datt déi resultéierend Blöcke wesentlech identesch waren, einfach ersat kënne ginn wann se gebrach sinn, a konnten a grousse Quantitéite produzéiert ginn.
Stellt Iech elo vir, wann de Brunel dës Aarbecht fir 20 verschidde Schëffsmodeller muss maachen (Kubernetes Versiounen) a fir fënnef verschidde Planéiten mat komplett verschiddene Mieresstroum a Wand (Wollekprovider). Ausserdeem war et erfuerderlech datt all Schëffer (OpenShift Cluster), onofhängeg vun de Planéiten, op deenen d'Navigatioun duerchgefouert gëtt, aus der Siicht vun de Kapitänen (Operateuren, déi d'Operatioun vun de Cluster verwalten) d'selwecht behuelen. Fir d'maritime Analogie weiderzeféieren, sinn d'Schëffer Kapitänen guer net egal wéi eng Zort vu Rigging Blocks (CRI-O) op hire Schëffer benotzt ginn - den Haapt Saach fir si ass datt dës Blocks staark an zouverlässeg sinn.
OpenShift 4, als Cloud Plattform, steet virun enger ganz ähnlecher Geschäftsfuerderung. Nei Wirbelen mussen am Moment vun der Clusterkreatioun erstallt ginn, am Fall vun engem Ausfall an engem vun de Wirbelen oder beim Skaléieren vum Cluster. Wann en neien Node erstallt an initialiséiert gëtt, musse kritesch Hostkomponenten, dorënner CRI-O, deementspriechend konfiguréiert ginn. Wéi an all aner Produktioun mussen "Rohmaterial" am Ufank geliwwert ginn. Am Fall vu Schëffer sinn d'Rohmaterial Metall an Holz. Wéi och ëmmer, am Fall vun der Schafung vun engem Host fir Container an engem OpenShift 4 Cluster z'installéieren, musst Dir Konfiguratiounsdateien an API geliwwert Serveren als Input hunn. OpenShift wäert dann den erfuerderlechen Niveau vun der Automatisatioun am ganze Liewenszyklus ubidden, déi néideg Produktsupport fir Endbenotzer ubidden an domat d'Investitioun an der Plattform zréckzéien.
OpenShift 4 gouf sou erstallt fir d'Fäegkeet ze bidden fir de System bequem iwwer de ganze Liewenszyklus vun der Plattform ze aktualiséieren (fir Versioune 4.X) fir all gréisser Cloud Computing Ubidder, Virtualiséierungsplattformen a souguer Bare Metal Systemer. Fir dëst ze maachen, musse Wirbelen op Basis vun austauschbaren Elementer erstallt ginn. Wann e Cluster eng nei Versioun vu Kubernetes erfuerdert, kritt en och déi entspriechend Versioun vum CRI-O op CoreOS. Zënter datt d'CRI-O Versioun direkt un Kubernetes gebonnen ass, vereinfacht dëst immens all Permutatiounen fir Testen, Problembehandlung oder Ënnerstëtzungszwecker. Zousätzlech reduzéiert dës Approche d'Käschte fir Endbenotzer a Red Hat.
Dëst ass e grondsätzlech neie Wee fir iwwer Kubernetes Cluster ze denken a leet de Grondlag fir e puer ganz nëtzlech an zwéngend nei Features ze plangen. CRI-O (Container Runtime Interface - Open Container Initiative, ofgekierzt CRI-OCI) huet sech als déi erfollegräichst Wiel fir d'Masskreatioun vun Noden erausgestallt, déi néideg ass fir mat OpenShift ze schaffen. CRI-O ersetzt de virdru benotzte Docker-Motor, bitt OpenShift Benotzer - jo, Dir hutt richteg héieren - e langweilege Containermotor deen speziell erstallt gouf fir mat Kubernetes ze schaffen.
D'Welt vun oppene Container
D'Welt beweegt sech scho laang a Richtung oppe Container. Ob zu Kubernetes, oder op méi nidderegen Niveauen, Resultater an engem Ökosystem vun Innovatioun op all Niveau.
Et huet alles ugefaang mat der Schafung vun der Open Containers Initiative . An dësem fréie Stadium vun der Aarbecht goufen Container Spezifikatioune geformt и . Dëst huet gesuergt datt d'Tools een eenzege Standard benotze kënnen an e vereenegt Format fir mat hinnen ze schaffen. Spezifikatioune goufen spéider dobäi , erlaabt Benotzer einfach ze deelen .
D'Kubernetes Gemeinschaft huet dann en eenzege Standard fir eng pluggbar Interface entwéckelt, genannt . Dank dësem konnten d'Kubernetes Benotzer verschidde Motore verbannen fir mat Container zousätzlech zu Docker ze schaffen.
D'Ingenieuren vu Red Hat a Google hunn e Maartbedierfnes fir e Containermotor gesinn, deen Kubelet Ufroe iwwer de CRI Protokoll akzeptéiere konnt an Container agefouert hunn, déi kompatibel sinn mat den uewen ernimmten OCI Spezifikatioune. Also . Awer entschëllegt, hu mir net gesot datt dëst Material dem CRI-O gewidmet wier? Eigentlech ass et, just mat der Verëffentlechung de Projet gouf ëmbenannt CRI-O.
Fig. 1.
Innovatioun mat CRI-O a CoreOS
Mam Start vun der OpenShift 4 Plattform gouf et geännert , Standard benotzt an der Plattform, an Docker gouf duerch CRI-O ersat, bitt e kosteneffizienten, stabilen, einfachen a langweilegen Ëmfeld fir e Container ze lafen deen parallel mat Kubernetes entwéckelt. Dëst vereinfacht immens Cluster Ënnerstëtzung a Konfiguratioun. D'Konfiguratioun vum Containermotor an dem Host, souwéi hir Gestioun, gëtt automatiséiert bannent OpenShift 4.
Waart, wéi ass dat?
Dat ass richteg, mam Advent vun OpenShift 4 ass et net méi e Besoin fir eenzel Hosten ze verbannen an e Containermotor z'installéieren, d'Späichere konfiguréieren, d'Sichserver ze konfiguréieren oder en Netzwierk ze konfiguréieren. D'OpenShift 4 Plattform gouf komplett nei designt fir den net nëmmen am Sënn vun Enn-Benotzer Uwendungen, mä och am Sënn vun Basis Plattform-Niveau Operatiounen wéi Biller z'installéieren, de System konfiguréieren, oder Aktualiséierungen installéiert.
Kubernetes huet ëmmer Benotzer erlaabt Uwendungen ze verwalten andeems de gewënschten Zoustand definéiert a benotzt , fir sécherzestellen, datt den aktuellen Zoustand dem Zilstaat sou no wéi méiglech entsprécht. Dëst mécht grouss Méiglechkeeten souwuel aus Entwécklungs- an Operatiounsperspektiv op. Entwéckler kënnen déi néideg Staat definéieren duerch dem Bedreiwer a Form vun enger YAML- oder JSON-Datei, an dann kann de Bedreiwer déi erfuerderlech Uwendungsinstanz an der Produktiounsëmfeld erstellen, an de Betribszoustand vun dëser Instanz wäert voll mat der spezifizéierter entspriechen.
Andeems Dir Operatoren an der Plattform benotzt, bréngt OpenShift 4 dësen neie Paradigma (mat dem Konzept vu Set an aktuellen Zoustand) fir d'Gestioun vu RHEL CoreOS a CRI-O. D'Aufgaben vun der Konfiguratioun a Verwalte Versioune vum Betribssystem a Containermotor ginn automatiséiert mat der sougenannter . MCO vereinfacht immens d'Aarbecht vum Cluster Administrateur, am Wesentlechen automatiséiert déi lescht Etappe vun der Installatioun, souwéi spéider Post-Installatioun Operatiounen (Dag zwee Operatiounen). All dëst mécht OpenShift 4 eng richteg Cloud Plattform. Mir kommen e bësse méi spéit op dat.
Lafen Container
D'Benotzer hunn d'Méiglechkeet de CRI-O-Motor an der OpenShift Plattform zanter Versioun 3.7 am Tech Preview Status ze benotzen a vun der Versioun 3.9 am Allgemeng verfügbare Status (aktuell ënnerstëtzt). Zousätzlech benotzt Red Hat massiv an OpenShift Online zënter Versioun 3.10. All dëst huet d'Team, déi um CRI-O schafft, erlaabt eng extensiv Erfarung an der Massestart vu Container op grousse Kubernetes Cluster ze kréien. Fir e Basisverständnis ze kréien wéi Kubernetes CRI-O benotzt, kucke mer déi folgend Illustratioun, déi weist wéi d'Architektur funktionnéiert.
Reis. 2. Wéi Behälter Aarbecht an engem Kubernetes Stärekoup
CRI-O vereinfacht d'Schafung vun neie Containerhosten andeems de ganzen Topniveau synchroniséiert gëtt wann Dir nei Noden initialiséiert, a wann Dir nei Versioune vun der OpenShift Plattform verëffentlecht. D'Revisioun vun der ganzer Plattform erlaabt Transaktiounsupdates / Rollbacks, a verhënnert och Deadlocks an Ofhängegkeeten tëscht dem Container Schwanzkär, Containermotor, Noden (Kubelets) an dem Kubernetes Master Node. Andeems Dir all Plattformkomponenten zentral geréiert, mat Kontroll a Versionéierung, gëtt et ëmmer e kloere Wee vum Staat A op Staat B. Dëst vereinfacht den Updateprozess, verbessert d'Sécherheet, verbessert d'Leeschtungsberichterstattung an hëlleft d'Käschte vun Updates an Installatiounen vun neie Versiounen ze reduzéieren .
Demonstréieren d'Kraaft vun Ersatzelementer
Wéi virdru scho gesot, benotzt de Machine Config Operator fir de Containerhost a Containermotor an OpenShift 4 ze verwalten stellt en neien Niveau vun der Automatisatioun, déi net virdru méiglech war op der Kubernetes Plattform. Fir déi nei Fonctiounen ze demonstréieren, wäerte mir weisen wéi Dir Ännerungen an der crio.conf Datei maache kënnt. Fir ze vermeiden duerch Terminologie duercherneen ze kommen, probéiert op d'Resultater ze fokusséieren.
Als éischt, loosst eis erstellen wat eng Container Runtime Konfiguratioun genannt gëtt - Container Runtime Config. Denkt un et als Kubernetes Ressource déi d'Konfiguratioun fir CRI-O duerstellt. A Wierklechkeet ass et eng spezialiséiert Versioun vun eppes genannt MachineConfig, dat ass all Konfiguratioun déi op eng RHEL CoreOS Maschinn als Deel vun engem OpenShift Cluster ofgebaut gëtt.
Dës personaliséiert Ressource, genannt ContainerRuntimeConfig, gouf erstallt fir et méi einfach ze maachen fir CRI-O Administrateuren ze konfiguréieren. Dëst Tool ass mächteg genuch datt et nëmmen op bestëmmte Wirbelen applizéiert ka ginn ofhängeg vun den MachineConfigPool Astellungen. Denkt un et als eng Grupp vu Maschinnen déi deeselwechten Zweck déngen.
Notéiert déi lescht zwou Zeilen déi mir an der /etc/crio/crio.conf Datei änneren. Dës zwou Linnen si ganz ähnlech wéi d'Linnen an der crio.conf Datei, si sinn:
vi ContainerRuntimeConfig.yaml
Fazit:
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
Loosst eis dës Datei an de Kubernetes-Cluster drécken a kucken ob et tatsächlech erstallt gouf. Maacht weg datt d'Operatioun genau d'selwecht ass wéi mat all aner Kubernetes Ressource:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Fazit:
NAME AGE
set-log-and-pid 22h
Wann mir de ContainerRuntimeConfig erstallt hunn, musse mir ee vun de MachineConfigPools änneren fir Kubernetes ze signaliséieren datt mir dës Konfiguratioun op eng spezifesch Grupp vu Maschinnen am Cluster applizéiere wëllen. An dësem Fall wäerte mir den MachineConfigPool fir d'Masternoden änneren:
oc edit MachineConfigPool/master
Conclusioun (fir Kloerheet ass d'Haaptessens lénks):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Zu dësem Zäitpunkt fänkt MCO un eng nei crio.conf Datei fir de Cluster ze kreéieren. An dësem Fall kann déi komplett fäerdeg Konfiguratiounsdatei mat der Kubernetes API gekuckt ginn. Denkt drun, ContainerRuntimeConfig ass just eng spezialiséiert Versioun vu MachineConfig, also kënne mir d'Resultat gesinn andeems Dir déi entspriechend Linnen an MachineConfigs kuckt:
oc get MachineConfigs | grep rendered
Fazit:
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
Notéiert w.e.g. datt déi resultéierend Konfiguratiounsdatei fir d'Masternoden eng méi nei Versioun war wéi déi ursprénglech Konfiguratiounen. Fir et ze gesinn, fuert de folgende Kommando. Am laanschtgoungen bemierken mir datt dëst vläicht ee vun de beschten One-Liner an der Geschicht vu Kubernetes ass:
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
Fazit:
pids_limit = 2048
Loosst eis elo sécherstellen datt d'Konfiguratioun op all Masterknäppchen applizéiert gouf. Als éischt kréie mir eng Lëscht vun Noden am Cluster:
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
Loosst eis elo déi installéiert Datei kucken. Dir gesitt datt d'Datei mat den neie Wäerter fir d'Pid- an Debug-Direktiven aktualiséiert gouf, déi mir an der ContainerRuntimeConfig Ressource spezifizéiert hunn. Eleganz selwer:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Fazit:
...
pids_limit = 2048
...
log_level = "debug"
...
All dës Ännerungen am Stärekoup goufen gemaach ouni souguer SSH ze lafen. All Aarbecht gouf gemaach duerch Zougang zum Kuberentes Master Node. Dat ass, dës nei Parameteren goufen nëmmen op Master Wirbelen konfiguréiert. D'Aarbechterknäppchen hunn net geännert, wat d'Virdeeler vun der Kubernetes-Methodologie weist fir spezifizéiert an aktuell Staaten a Relatioun mat Containerhost a Containermotoren mat austauschbaren Elementer ze benotzen.
D'Beispill hei uewen weist d'Fäegkeet Ännerungen an engem klenge OpenShift Container Plattform 4 Cluster mat dräi Produktiounsknäppchen oder e risege Produktiounscluster mat 3000 Wirbelen ze maachen. Op alle Fall wäert d'Quantitéit vun der Aarbecht déiselwecht sinn - a ganz kleng - just d'ContainerRuntimeConfig Datei konfiguréieren, an e Label am MachineConfigPool änneren. An Dir kënnt dat mat all Versioun vun der OpenShift Container Plattform 4.X maachen, déi Kubernetes uechter säi Liewenszyklus leeft.
Dacks entwéckelen Technologiefirmen sou séier datt mir net fäeg sinn z'erklären firwat mir verschidden Technologien fir déi ënnerierdesch Komponenten wielen. Containermotoren sinn historesch de Komponente mat deem d'Benotzer direkt interagéieren. Zënter datt d'Popularitéit vu Behälter natierlech ugefaang huet mat der Advent vu Containermotoren, weisen d'Benotzer dacks Interesse an hinnen. Dëst ass en anere Grond firwat Red Hat CRI-O gewielt huet. Container evoluéiere mam Fokus elo op Orchestratioun, a mir hu festgestallt datt CRI-O déi bescht Erfahrung bitt wann Dir mat OpenShift 4 schafft.
Source: will.com