Platforma destûrê dide te ku hûn afirandêriyê xweş bikin , di nav binesaziya pêşkêşkerên karûbarê ewr de, li ser platformên virtualkirinê an di pergalên tazî-metal de. Ji bo afirandina platformek bi rastî ewr-based, me neçar ma ku kontrola hişk a hemî hêmanên ku têne bikar anîn bigirin û bi vî rengî pêbaweriya pêvajoyek xweseriya tevlihev zêde bikin.
Çareseriya eşkere ev bû ku Red Hat Enterprise Linux CoreOS (guhertoyek Red Hat Enterprise Linux) û CRI-O wekî standard bikar bîne, û li vir çima ...
Ji ber ku mijara keştiyê ji bo dîtina analogiyan gava ravekirina xebata Kubernetes û konteyneran pir baş e, em hewl bidin ku li ser pirsgirêkên karsaziyê yên ku CoreOS û CRI-O çareser dikin biaxivin, mînakek bikar bînin. . Di sala 1803-an de, Marc Brunel ji bo hewcedariyên mezinbûna deryayî ya Brîtanî, ji bo hilberîna 100 blokên hilberandinê hate peywirdarkirin. Rîgging blokek celebek lêdanê ye ku ji bo girêdana keştiyan bi keştiyan tê bikar anîn. Heya destpêka sedsala 19-an, ev blokan bi destan dihatin çêkirin, lê Brunel karî hilberandinê otomatîk bike û bi karanîna amûrên makîneyê dest bi hilberîna blokên standardkirî kir. Otomatîzekirina vê pêvajoyê tê vê wateyê ku blokên encam di bingeh de wekî hev in, heke bişkestin bi hêsanî werin guheztin, û dikarin di mîqdarên mezin de werin hilberandin.
Naha bifikire ku Brunel neçar ma ku vî karî ji bo 20 modelên cihê yên keştiyê (guhertoyên Kubernetes) û ji bo pênc gerstêrkên cihêreng ên bi herik û bayên deryayê yên bi tevahî cûda (pêşkêşkerên ewran) bike. Wekî din, pêdivî bû ku hemî keştî (komên OpenShift), bêyî ku gerstêrkên ku li ser wan navîgasyon têne kirin, ji nihêrîna kaptanan (operatorên ku xebata koman birêve dibin) bi heman rengî tevbigerin. Ji bo domandina analojiya deryayî, kaptanên keştiyê qet guh nadin ka çi celeb blokên gemarî (CRI-O) li ser keştiyên wan têne bikar anîn - ya sereke ji bo wan ev e ku ev blokên bihêz û pêbawer in.
OpenShift 4, wekî platformek ewr, bi dijwariyek karsaziyek pir bi heman rengî re rû bi rû dimîne. Pêdivî ye ku di dema çêkirina komê de, di bûyera têkçûnek yek ji girêkan de, an dema ku komê pîvandin de girêkên nû werin afirandin. Dema ku girêkek nû tê afirandin û dest pê kirin, divê pêkhateyên mêvandar ên krîtîk, tevî CRI-O, li gorî wê werin mîheng kirin. Wekî di her hilberînek din de, divê di destpêkê de "materyalên xav" were peyda kirin. Di mijara keştiyan de madeyên xav metal û dar in. Lêbelê, di mijara afirandina mêvandarek ji bo danîna konteynir di komek OpenShift 4 de, hûn hewce ne ku pelên vesazkirinê û pêşkêşkerên API-ê wekî têketinê hebin. Wê hingê OpenShift dê di tevahiya çerxa jiyanê de asta xweseriya hewce peyda bike, ji bikarhênerên dawîn re piştgiriya hilbera pêwîst pêşkêşî dike û bi vî rengî veberhênana li platformê vegere.
OpenShift 4 bi vî rengî hate afirandin ku jêhatîbûna nûvekirina pergalê li seranserê tevahiya çerxa jiyanê ya platformê (ji bo guhertoyên 4.X) ji bo hemî pêşkêşkerên sereke yên hesabkirina ewr, platformên virtualkirinê û tewra pergalên metal ên tazî peyda bike. Ji bo vê yekê, pêdivî ye ku nod li ser bingeha hêmanên guhezbar werin afirandin. Gava ku komek guhertoyek nû ya Kubernetes hewce dike, ew guhertoya têkildar a CRI-O li ser CoreOS jî distîne. Ji ber ku guhertoya CRI-O rasterast bi Kubernetes ve girêdayî ye, ev yek ji bo ceribandin, çareserkirin, an mebestên piştgiriyê her veguheztinê pir hêsan dike. Wekî din, ev nêzîkatî lêçûnên ji bo bikarhênerên dawîn û Red Hat kêm dike.
Ev rêgezek bingehîn a nû ye ku di derbarê komikên Kubernetes de fikirîn e û bingehê plansazkirina hin taybetmendiyên nû yên pir bikêr û berbiçav datîne. CRI-O (Container Runtime Interface - Open Container Initiative, bi kurtî CRI-OCI) derket holê ku ji bo afirandina girseyî ya nodên ku ji bo xebatê bi OpenShift re pêdivî ye, bijareya herî serketî ye. CRI-O dê li şûna motora Dockerê ya berê hatî bikar anîn, bikarhênerên OpenShift pêşkêşî bike - erê, we rast bihîst - motorek konteynerek bêzar ku bi taybetî ji bo xebata bi Kubernetes re hatî afirandin.
Cîhana konteynerên vekirî
Cîhan ji mêj ve ber bi konteynerên vekirî ve diçe. Çi li Kubernetes, çi di astên jêrîn de, di her astê de ekosîstemek nûbûnê encam dide.
Hemî bi avakirina Înîsiyatîfa Konteynirên Vekirî dest pê kir . Di vê qonaxa destpêkê ya xebatê de, taybetmendiyên konteynerê hatin çêkirin и . Vê yekê piştrast kir ku amûr dikarin standardek yekane bikar bînin û formek yekgirtî ji bo xebata bi wan re. Specifications paşê hatin zêdekirin , dihêle bikarhêneran bi hêsanî parve bikin .
Dûv re civata Kubernetes standardek yekane ji bo pêvekek pêvekirî, ku jê re tê gotin, pêş xist . Bi saya vê yekê, bikarhênerên Kubernetes karîbûn motorên cihêreng girêdin da ku ji bilî Docker bi konteyneran re bixebitin.
Endezyarên li Red Hat û Google hewcedariya bazarê ji motorek konteynerê dît ku bikaribe daxwazên Kubelet li ser protokola CRI qebûl bike û konteynerên ku bi taybetmendiyên OCI yên ku li jor hatine destnîşan kirin re hevaheng in destnîşan kirin. Wiha . Lê min bibore, ma me negot ku ev materyal dê ji CRI-O re were veqetandin? Bi rastî ew e, tenê bi berdanê navê projeyê CRI-O bû.
Keman. 1
Nûbûn bi CRI-O û CoreOS
Bi destpêkirina platforma OpenShift 4 re, ew hate guheztin , ku ji hêla xwerû di platformê de tê bikar anîn, û Docker ji hêla CRI-O ve hate guheztin, ji bo meşandina konteynerek ku bi Kubernetes re paralel pêşve diçe, hawîrdorek biha-bandor, aram, sade û bêzar pêşkêşî dike. Ev piştgirî û veavakirina komê pir hêsan dike. Veavakirina motora konteynerê û mêvandarê, û her weha rêveberiya wan, di OpenShift 4 de otomatîk dibe.
Bisekine, ev çawa ye?
Rast e, bi hatina OpenShift 4-ê re, êdî ne hewce ye ku meriv bi hosteyên kesane ve were girêdan û motorek konteynerê saz bike, hilanînê mîheng bike, serverên lêgerînê mîheng bike an torê mîheng bike. Platforma OpenShift 4 bi tevahî ji nû ve hatî sêwirandin ku bikar bîne ne tenê di warê serîlêdanên bikarhênerê dawî de, lê di heman demê de di warê operasyonên bingehîn ên asta platformê de jî wekî bicihkirina wêneyan, veavakirina pergalê, an sazkirina nûvekirinan.
Kubernetes her gav destûr daye bikarhêneran ku bi diyarkirina rewşa xwestinê û karanîna serîlêdanan birêve bibin , da ku bicîh bikin ku dewleta rastîn bi qasî ku gengaz dibe bi dewleta armanc re li hev dike. Ev hem ji perspektîfa pêşkeftinê û hem jî ji hêla operasyonê ve fersendên mezin vedike. Pêşdebir dikarin ji hêla dewleta pêwîst ve diyar bikin ji operatorê re di forma pelek YAML an JSON de, û dûv re operator dikare mînaka serîlêdana pêwîst di hawîrdora hilberînê de biafirîne, û rewşa xebitandinê ya vê nimûneyê dê bi tevahî bi ya diyarkirî re têkildar be.
Bi karanîna Operatoran di platformê de, OpenShift 4 vê paradîgmaya nû (bikaranîna têgeha set û rewşa rastîn) tîne rêveberiya RHEL CoreOS û CRI-O. Karên mîhengkirin û birêvebirina guhertoyên pergala xebitandinê û motora konteynerê bi karanîna bi navê xwerû têne otomatîk kirin. . MCO karê rêvebirê komê pir hêsan dike, bi bingehîn qonaxên paşîn ên sazkirinê, û her weha operasyonên paşîn ên piştî sazkirinê (roja duduyan) otomatîk dike. Hemî ev OpenShift 4 dike platformek ewr a rastîn. Em ê piçekî paşê têkevin vê mijarê.
Konteyner diherikin
Bikarhêner ji guhertoya 3.7-ê ve di statûya Pêşdîtina Teknîkî de û ji guhertoya 3.9-ê di statûya Bi gelemperî Berdest de (niha piştgirî tê piştgirî kirin) şansê karanîna motora CRI-O di platforma OpenShift de heye. Wekî din, Red Hat bi girseyî bikar tîne di OpenShift Online de ji guhertoya 3.10. Hemî vê yekê hişt ku tîmê ku li ser CRI-O dixebite ezmûnek berfireh di avêtina konteynerên girseyî de li ser komên mezin ên Kubernetes bi dest bixe. Ji bo ku hûn têgihîştina bingehîn a ka Kubernetes çawa CRI-O bikar tîne, em li nîgara jêrîn binêrin, ku nîşan dide ka mîmarî çawa dixebite.
Birinc. 2. Konteynir di komek Kubernetes de çawa dixebitin
CRI-O dema destpêkirina girêkên nû, û dema berdana guhertoyên nû yên platforma OpenShift-ê, çêkirina mêvandarên konteynerê yên nû bi hevdengkirina tevahiya asta jorîn hêsan dike. Guhertoya tevaya platformê rê dide nûvekirin/vegerandina danûstendinê, û di heman demê de rê li ber girtina girêdanên di navbera bingeha dûvikê konteynerê, motora konteynerê, girêkan (Kubelets) û girêka Kubernetes Master digire. Bi rêvebirina navendî ya hemî pêkhateyên platformê, bi kontrol û versiyonê, her gav rêyek zelal ji dewleta A berbi dewleta B ve heye. Ev pêvajoya nûvekirinê hêsan dike, ewlehiyê çêtir dike, raporkirina performansê çêtir dike, û dibe alîkar ku lêçûna nûvekirin û sazkirinên guhertoyên nû kêm bike. .
Nîşandana hêza hêmanên veguherînê
Wekî ku berê hate behs kirin, karanîna Operatorê Vesazkirina Makîneyê ji bo birêvebirina mêvandarê konteynerê û motora konteynerê di OpenShift 4 de astek nû ya xweseriyê peyda dike ku berê li ser platforma Kubernetes ne gengaz bû. Ji bo nîşandana taybetmendiyên nû, em ê nîşan bidin ka hûn çawa dikarin di pelê crio.conf de guhertinan bikin. Ji bo ku hûn ji hêla termînolojiyê ve tevlihev bibin, hewl bidin ku li ser encaman bisekinin.
Pêşîn, bila em tiştê ku jê re veavakirina dema xebitandinê ya konteyner tê gotin biafirînin - Container Runtime Config. Wê wekî çavkaniyek Kubernetes-ê ku veavakirina CRI-O-yê temsîl dike bifikire. Di rastiyê de, ew guhertoyek pispor a tiştek bi navê MachineConfig e, ku her veavakirinek e ku li makîneyek RHEL CoreOS wekî beşek ji komek OpenShift tête bicîh kirin.
Vê çavkaniya xwerû, bi navê ContainerRuntimeConfig, hate afirandin ku ji bo rêvebirên komê hêsantir bike ku CRI-O mîheng bikin. Ev amûr têra xwe bi hêz e ku ew tenê dikare li ser hin girêkan li gorî mîhengên MachineConfigPool were sepandin. Wê wekî komek makîneyên ku ji heman armancê re xizmetê dikin bifikirin.
Bala xwe bidin du rêzên paşîn ên ku em ê di pelê /etc/crio/crio.conf de biguherînin. Van her du rêzan pir dişibin rêzikên pelê crio.conf, ew in:
vi ContainerRuntimeConfig.yaml
Encam:
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
Naha em vê pelê bixin koma Kubernetes û kontrol bikin ku ew bi rastî hatî afirandin. Ji kerema xwe not bikin ku operasyon bi tevahî wekî çavkaniyên din ên Kubernetes re heman e:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Encam:
NAME AGE
set-log-and-pid 22h
Dema ku me ContainerRuntimeConfig çêkir, pêdivî ye ku em yek ji MachineConfigPools biguhezînin da ku ji Kubernetes re nîşan bide ku em dixwazin vê veavakirinê li komek taybetî ya makîneyên di komê de bicîh bikin. Di vê rewşê de em ê MachineConfigPool-ê ji bo girêkên sereke biguhezînin:
oc edit MachineConfigPool/master
Encam (ji bo zelaliyê, cewhera sereke hiştin):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Di vê nuqteyê de, MCO dest pê dike ku pelek nû ya crio.conf ji bo komê biafirîne. Di vê rewşê de, pelê mîhengê bi tevahî qediyayî dikare bi karanîna Kubernetes API-ê were dîtin. Bînin bîra xwe, ContainerRuntimeConfig tenê guhertoyek pispor a MachineConfig e, ji ber vê yekê em dikarin bi lênihêrîna rêzikên têkildar di MachineConfigs de encamê bibînin:
oc get MachineConfigs | grep rendered
Encam:
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
Ji kerema xwe not bikin ku pela veavakirinê ya encam ji bo girêkên sereke guhertoyek nûtir bû ji mîhengên orîjînal. Ji bo dîtina wê, emrê jêrîn bicîh bikin. Di derbazbûnê de, em bala xwe didinê ku ev belkî di dîroka Kubernetes de yek ji baştirîn yek-hêl e:
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
Encam:
pids_limit = 2048
Naha em pê ewle bin ku veavakirin li hemî girêkên masterê hatine sepandin. Pêşî em navnîşek girêkên di komê de digirin:
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
Naha em li pelê sazkirî binêrin. Hûn ê bibînin ku pel bi nirxên nû yên ji bo rêwerzên pid û debug-ê yên ku me di çavkaniya ContainerRuntimeConfig-ê de destnîşan kirine ve hatî nûve kirin. Elegance bixwe:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Encam:
...
pids_limit = 2048
...
log_level = "debug"
...
Hemî van guheztinên komê bêyî ku SSH-ê jî were xebitandin hatine çêkirin. Hemî kar bi gihîştina girêka masterê Kuberentes hate kirin. Ango, van pîvanên nû tenê li ser girêkên sereke hatine mîheng kirin. Girêkên karker neguherî, ku ev feydeyên metodolojiya Kubernetes ya karanîna dewletên diyarkirî û rastîn ên têkildarî mêvandarên konteynerê û motorên konteynerê yên bi hêmanên guhezbar nîşan dide.
Mînaka li jor şiyana guheztina guheztinek piçûk a OpenShift Container Platform 4 bi sê girêkên hilberînê an komek hilberîna mezin a bi 3000 girêkan nîşan dide. Di her rewşê de, hêjeya xebatê dê heman be - û pir piçûk - tenê pelê ContainerRuntimeConfig mîheng bike, û yek etîketê li MachineConfigPool biguhezîne. Û hûn dikarin vê yekê bi her guhertoya OpenShift Container Platform 4.X ku Kubernetes di seranserê jiyana xwe de dixebitînin bikin.
Bi gelemperî pargîdaniyên teknolojiyê ew qas zû pêşve diçin ku em nikanin rave bikin ka çima em hin teknolojiyên ji bo pêkhateyên bingehîn hilbijêrin. Motorên konteyner di dîrokê de pêkhateya ku bikarhêner rasterast pê re têkildar in. Ji ber ku populerbûna konteyneran bi xwezayî bi hatina motorên konteyneran re dest pê kir, bikarhêner bi gelemperî eleqe nîşanî wan didin. Ev sedemek din e ku Red Hat CRI-O hilbijart. Konteyner bi baldarî naha li ser orkestrasyonê pêşve diçin, û me dît ku CRI-O dema ku bi OpenShift 4 re dixebite ezmûna çêtirîn peyda dike.
Source: www.habr.com