Plataforma sorkuntza arintzeko aukera ematen du , hodeiko zerbitzu hornitzaileen azpiegituretan, birtualizazio plataformetan edo bare-metal sistemetan barne. Benetan hodeian oinarritutako plataforma bat sortzeko, erabilitako elementu guztien kontrol zorrotza hartu behar izan dugu eta horrela automatizazio prozesu konplexu baten fidagarritasuna areagotu.
Konponbidea Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux-en aldaera bat) eta CRI-O estandar gisa erabiltzea zen, eta hona hemen zergatik...
Nabigazioaren gaia Kubernetesen eta edukiontzien lana azaltzerakoan analogiak aurkitzeko oso ona denez, saia gaitezen CoreOS eta CRI-Ok konpontzen dituzten negozio arazoei buruz hitz egiten, adibide bat erabiliz. . 1803an, Marc Brunel-ek 100 apareju-bloke ekoizteaz arduratu zen, gero eta handiagoa zen Britainia Handiko itsas armadaren beharretarako. Aparejo-blokea beletan sokak lotzeko erabiltzen den apareju mota bat da. mendearen hasierara arte, bloke hauek eskuz egiten ziren, baina Brunelek produkzioa automatizatzea lortu zuen eta makina-erreminta erabiliz bloke estandarizatuak ekoizten hasi zen. Prozesu honen automatizazioak esan nahi zuen ondoriozko blokeak funtsean berdinak zirela, hautsiz gero erraz ordezka zitezkeela eta kantitate handietan ekoiztu zitezkeela.
Orain imajinatu Brunelek lan hau egin beharko balu 20 itsasontzi modelo ezberdinetarako (Kubernetes bertsioak) eta itsas korronte eta haize guztiz desberdinak dituzten bost planeta ezberdinetarako (hodei hornitzaileak). Horrez gain, itsasontzi guztiek (OpenShift klusterrak), nabigazioa egiten den planeta edozein dela ere, kapitainen (klusterren funtzionamendua kudeatzen duten operadoreak) berdin jokatzea eskatzen zen. Itsasoko analogiarekin jarraitzeko, ontzi-kapitainei ez zaie batere axola zer nolako blokeak (CRI-O) erabiltzen diren beren ontzietan - haientzako gauza nagusia bloke hauek sendoak eta fidagarriak direla da.
OpenShift 4-k, hodeiko plataforma gisa, negozio-erronka oso antzeko bati aurre egiten dio. Nodo berriak sortu behar dira klusterren sorreran, nodoren batean hutsegiterik gertatuz gero, edo klusterra eskalatzean. Nodo berri bat sortu eta hasieratzen denean, ostalariaren osagai kritikoak, CRI-O barne, horren arabera konfiguratu behar dira. Beste edozein ekoizpenetan bezala, βlehengaiakβ hornitu behar dira hasieran. Itsasontzien kasuan, lehengaiak metala eta egurra dira. Hala ere, OpenShift 4 kluster batean edukiontziak zabaltzeko ostalari bat sortzeko kasuan, konfigurazio fitxategiak eta APIak emandako zerbitzariak izan behar dituzu sarrera gisa. Ondoren, OpenShift-ek beharrezko automatizazio-maila emango du bizitza-ziklo osoan zehar, azken erabiltzaileei beharrezko produktu-laguntza eskainiz eta, horrela, plataformako inbertsioa berreskuratuz.
OpenShift 4 plataformaren bizi-ziklo osoan (4.X bertsioetarako) sistema eroso eguneratzeko gaitasuna eskaintzeko moduan sortu zen hodeiko informatika-hornitzaile, birtualizazio-plataforma eta baita bare metal-sistemei ere. Horretarako, nodoak elementu trukagarrietan oinarrituta sortu behar dira. Kluster batek Kubernetes-en bertsio berri bat eskatzen duenean, CoreOS-en CRI-O-ren dagokion bertsioa ere jasotzen du. CRI-O bertsioa Kubernetes-ekin zuzenean lotuta dagoenez, horrek asko errazten du probak, arazoak konpontzeko edo laguntza-helburuetarako permutazioak. Gainera, ikuspegi honek azken erabiltzaileen eta Red Hat-en kostuak murrizten ditu.
Hau Kubernetes klusterrei buruz pentsatzeko modu berri bat da eta funtzio berri oso erabilgarriak eta erakargarriak planifikatzeko oinarriak ezartzen ditu. CRI-O (Container Runtime Interface - Open Container Initiative, CRI-OCI laburtua) OpenShift-ekin lan egiteko beharrezkoak diren nodoak sortzeko aukerarik arrakastatsuena izan da. CRI-Ok lehen erabilitako Docker motorra ordezkatuko du, OpenShift erabiltzaileei eskainiz β Bai, ondo entzun duzu β Kubernetesekin lan egiteko bereziki sortutako edukiontzi motor aspergarria.
Edukiontzi irekien mundua
Mundua edukiontzi irekietara mugitzen ari da aspalditik. Kubernetes-en, edo maila baxuagoetan, maila guztietan berrikuntza ekosistema bat sortzen du.
Dena, Open Containers Initiativeren sorrerarekin hasi zen . Lanaren hasierako fase honetan, edukiontzien zehaztapenak osatu ziren ΠΈ . Honek tresnak estandar bakarra erabil zezaketela ziurtatu zuen eta haiekin lan egiteko formatu bateratua. Geroago zehaztapenak gehitu ziren , erabiltzaileei erraz partekatzeko aukera emanez .
Orduan Kubernetes komunitateak estandar bakarra garatu zuen entxufagarrizko interfaze baterako, izenekoa . Horri esker, Kuberneteseko erabiltzaileek hainbat motor konektatu ahal izan zituzten Dockeraz gain edukiontziekin lan egiteko.
Red Hat eta Google-ko ingeniariek CRI protokoloaren bidez Kubelet eskaerak onar ditzakeen edukiontzi-motor baten beharra ikusi zuten eta goian aipatutako OCI zehaztapenekin bateragarriak ziren edukiontziak sartu zituzten. Beraz . Baina barkatu, ez al genuen esan material hau CRI-Ori eskainiko zitzaiola? Egia esan, kaleratzearekin besterik ez da proiektuari CRI-O izena jarri zioten.
Fig. 1.
Berrikuntza CRI-O eta CoreOSekin
OpenShift 4 plataforma abian jarrita, aldatu egin zen , plataforman lehenespenez erabiltzen dena, eta Docker CRI-O-k ordezkatu zuen, Kubernetesekin paraleloan garatzen den edukiontzi bat martxan jartzeko ingurune errentagarria, egonkorra, sinplea eta aspergarria eskainiz. Horrek asko errazten ditu klusterraren laguntza eta konfigurazioa. Edukiontzi-motorren eta ostalariaren konfigurazioa, baita haien kudeaketa ere, automatizatu egiten dira OpenShift 4-n.
Itxaron, nola da hau?
Hori bai, OpenShift 4-ren etorrerarekin, jada ez da beharrezkoa ostalari indibidualetara konektatu eta edukiontzi-motor bat instalatu, biltegiratzea konfiguratu, bilaketa-zerbitzariak konfiguratu edo sare bat konfiguratu beharrik. OpenShift 4 plataforma guztiz birmoldatu da erabiltzeko ez bakarrik azken erabiltzailearen aplikazioei dagokienez, baita plataforma-mailako oinarrizko eragiketei dagokienez ere, hala nola irudiak zabaltzea, sistema konfiguratzea edo eguneraketak instalatzea.
Kubernetesek beti eman die erabiltzaileei aplikazioak kudeatzeko, nahi den egoera definitu eta erabiliz , benetako egoera helburuko egoerarekin bat datorren ahalik eta hurbilen ziurtatzeko. Hau aukera handiak zabaltzen ditu garapenaren eta eragiketen ikuspegitik. Garatzaileek beharrezko egoera defini dezakete operadoreari YAML edo JSON fitxategi moduan, eta, ondoren, operadoreak beharrezko aplikazio-instantzia sor dezake ekoizpen-ingurunean, eta instantzia honen funtzionamendu-egoera zehaztutakoarekin bat etorriko da guztiz.
Plataforman Operadoreak erabiliz, OpenShift 4-k paradigma berri hau (multzoaren eta benetako egoeraren kontzeptua erabiliz) RHEL CoreOS eta CRI-O-ren kudeaketara ekartzen du. Sistema eragilearen eta edukiontzi-motorraren bertsioak konfiguratzeko eta kudeatzeko zereginak automatizatu egiten dira . MCOk asko errazten du klusterreko administratzailearen lana, funtsean, instalazioaren azken faseak automatizatuz, baita ondorengo instalazioaren ondorengo eragiketak ere (bigarren eguneko eragiketak). Horrek guztiak OpenShift 4 benetako hodeiko plataforma bihurtzen du. Honetan pixka bat geroago sartuko gara.
Ontziak martxan
Erabiltzaileek CRI-O motorra OpenShift plataforman erabiltzeko aukera izan dute 3.7 bertsioaz geroztik Tech Preview egoeran eta 3.9 bertsiotik Orokorrean eskuragarri egoeran (orain onartzen da). Horrez gain, Red Hat-ek masiboki erabiltzen du OpenShift Online-n 3.10 bertsiotik. Horri guztiari esker, CRI-On lanean ari den taldeari esperientzia zabala lortu zuen Kubernetes kluster handietan edukiontziak masa jaurtitzeko. Kubernetes-ek CRI-O nola erabiltzen duen jakiteko, ikus dezagun arkitektura nola funtzionatzen duen erakusten duen hurrengo ilustrazioa.
Arroza. 2. Nola funtzionatzen duten edukiontziak Kubernetes kluster batean
CRI-O-k edukiontzi-ostalari berriak sortzea errazten du goi-maila osoa sinkronizatuz nodo berriak hastean eta OpenShift plataformaren bertsio berriak askatzen dituenean. Plataforma osoaren berrikuspenak transakzio-eguneratzeak/itzultzeak ahalbidetzen ditu eta, gainera, edukiontziaren buztanaren nukleoaren, edukiontzien motorren, nodoen (Kubelets) eta Kubernetes Master nodoaren arteko menpekotasunen blokeoak saihesten ditu. Plataformaren osagai guztiak zentralki kudeatuz, kontrol eta bertsioekin, beti dago bide argia A egoeratik B egoerara. Horrek eguneratze-prozesua errazten du, segurtasuna hobetzen du, errendimendu-txostenak hobetzen ditu eta bertsio berrien eguneratzeen eta instalazioen kostua murrizten laguntzen du. .
Ordezko elementuen ahalmena erakustea
Lehen esan bezala, OpenShift 4-n edukiontzi-ostalari eta edukiontzi-motorra kudeatzeko Machine Config Operadorea erabiltzeak Kubernetes plataforman orain arte posible ez zen automatizazio maila berri bat eskaintzen du. Ezaugarri berriak erakusteko, crio.conf fitxategian aldaketak nola egin ditzakezun erakutsiko dizugu. Terminologiarekin nahastea saihesteko, saiatu emaitzetan zentratzen.
Lehenik eta behin, sor dezagun edukiontziaren exekuzio-denboraren konfigurazioa deritzona - Container Runtime Config. Pentsa ezazu CRI-Oren konfigurazioa adierazten duen Kubernetes baliabide gisa. Egia esan, MachineConfig izeneko zerbaiten bertsio espezializatua da, hau da, RHEL CoreOS makina batean OpenShift kluster baten zati gisa zabaltzen den edozein konfigurazio.
Baliabide pertsonalizatu hau, ContainerRuntimeConfig izenekoa, kluster-administratzaileei CRI-O konfiguratzea errazteko sortu zen. Tresna hau nahikoa indartsua da, MachineConfigPool-en ezarpenen arabera nodo jakin batzuei soilik aplikatzeko. Pentsa ezazu helburu bera duten makina talde bat bezala.
Kontuan izan /etc/crio/crio.conf fitxategian aldatuko ditugun azken bi lerroak. Bi lerro hauek crio.conf fitxategiko lerroen oso antzekoak dira, hauek dira:
vi ContainerRuntimeConfig.yaml
Ondorioa:
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
Orain bultza dezagun fitxategi hau Kubernetes klusterera eta egiazta dezagun benetan sortu dela. Kontuan izan eragiketa Kubernetes-eko beste edozein baliabideren berdina dela:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Ondorioa:
NAME AGE
set-log-and-pid 22h
ContainerRuntimeConfig sortu ondoren, MachineConfigPools bat aldatu behar dugu Kubernetes-i konfigurazio hau klusterreko makina talde zehatz bati aplikatu nahi diogula adierazteko. Kasu honetan MachineConfigPool aldatuko dugu nodo nagusietarako:
oc edit MachineConfigPool/master
Ondorioa (argitasuna lortzeko, esentzia nagusia geratzen da):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Une honetan, MCO klustererako crio.conf fitxategi berri bat sortzen hasten da. Kasu honetan, guztiz amaitutako konfigurazio fitxategia Kubernetes APIa erabiliz ikus daiteke. Gogoratu, ContainerRuntimeConfig MachineConfig-en bertsio espezializatu bat besterik ez da, beraz, emaitza ikusi ahal izango dugu MachineConfigs-en dagozkion lerroei begiratuta:
oc get MachineConfigs | grep rendered
Ondorioa:
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
Kontuan izan nodo nagusien ondoriozko konfigurazio-fitxategia jatorrizko konfigurazioak baino bertsio berriagoa zela. Ikusteko, exekutatu komando hau. Bide batez, nabarmentzen dugu hau agian Kubernetes-en historiako lerrorik onenetako bat dela:
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
Ondorioa:
pids_limit = 2048
Orain, ziurtatu konfigurazioa nodo nagusi guztietan aplikatu dela. Lehenik eta behin klusterreko nodoen zerrenda jasoko dugu:
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
Orain ikus dezagun instalatutako fitxategia. Fitxategia ContainerRuntimeConfig baliabidean zehaztu ditugun pid eta arazketa zuzentarauetarako balio berriekin eguneratu dela ikusiko duzu. Dotorezia bera:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal β cat /host/etc/crio/crio.conf | egrep 'debug||pidβ
Ondorioa:
...
pids_limit = 2048
...
log_level = "debug"
...
Klusterrean aldaketa hauek guztiak SSH exekutatu gabe egin ziren. Lan guztia Kuberentesen nodo nagusira sartuz egin zen. Hau da, parametro berri hauek nodo nagusietan bakarrik konfiguratu ziren. Langile-nodoak ez ziren aldatu, eta horrek erakusten du Kubernetes metodologiaren onurak egoera zehatzak eta errealak erabiltzearen edukiontzi-ostalari eta edukiontzi-motorrekiko elementu trukagarriekin.
Goiko adibidean hiru produkzio-nodo dituen OpenShift Container Platform 4 kluster txiki batean edo 3000 nodo dituen ekoizpen-kluster handi batean aldaketak egiteko gaitasuna erakusten du. Nolanahi ere, lan-kopurua berdina izango da -eta oso txikia-, ContainerRuntimeConfig fitxategia konfiguratu eta MachineConfigPool-en etiketa bat aldatu. Eta hori egin dezakezu Kubernetes exekutatzen duen OpenShift Container Platform 4.X edozein bertsiorekin bere bizi-ziklo osoan.
Askotan teknologia-enpresek hain azkar eboluzionatzen dute, non ezin baitugu azaldu zergatik aukeratzen ditugun teknologia batzuk azpiko osagaietarako. Edukiontzi motorrak izan dira historikoki erabiltzaileek zuzenean elkarreragiten duten osagaia. Edukiontzien ospea modu naturalean edukiontzien motorren etorrerarekin hasi zenez, erabiltzaileek maiz erakusten dute haiekiko interesa. Hau da Red Hat-ek CRI-O aukeratu izanaren beste arrazoi bat. Ontziak eboluzionatzen ari dira orain orkestrazioari begira, eta aurkitu dugu CRI-Ok esperientzia onena eskaintzen duela OpenShift 4-rekin lan egitean.
Iturria: www.habr.com