panggung ngidinan Anjeun pikeun streamline kreasi , kaasup dina infrastruktur panyadia ladenan awan, dina platform virtualisasi atawa dina sistem bare-logam. Pikeun nyiptakeun platform anu leres-leres dumasar kana awan, urang kedah ngawasaan sadaya unsur anu dianggo sahingga ningkatkeun réliabilitas prosés automation anu kompleks.
Solusi anu jelas nyaéta ngagunakeun Red Hat Enterprise Linux CoreOS (varian Red Hat Enterprise Linux) sareng CRI-O salaku standar, sareng ieu sababna ...
Kusabab topik pelayaran mangrupikeun anu saé pikeun milarian analogi nalika ngajelaskeun karya Kubernetes sareng wadahna, hayu urang cobian ngobrolkeun masalah bisnis anu direngsekeun ku CoreOS sareng CRI-O, nganggo conto. . Dina 1803, Marc Brunel ditugaskeun pikeun ngahasilkeun 100 blok rigging pikeun kaperluan angkatan laut Inggris tumuwuh. Blok rigging mangrupikeun jinis rigging anu dianggo pikeun ngagantelkeun tali kana layar. Nepi ka awal abad ka-19, blok ieu dijieun ku leungeun, tapi Brunel junun ngajadikeun otomatis produksi sarta mimiti ngahasilkeun blok standar ngagunakeun parabot mesin. Automation tina prosés ieu dimaksudkan yén blok dihasilkeun éta dasarna idéntik, bisa gampang diganti lamun pegat, sarta bisa dihasilkeun dina jumlah badag.
Ayeuna bayangkeun lamun Brunel kudu ngalakukeun pagawean ieu 20 model kapal béda (versi Kubernetes) jeung lima planét béda jeung arus laut lengkep beda jeung angin (panyadia awan). Sajaba ti éta, éta diperlukeun yén sakabéh kapal (OpenShift klaster), paduli planét on nu napigasi dilumangsungkeun, ti sudut pandang kaptén (operator anu ngatur operasi tina klaster) kalakuanana sarua. Pikeun neraskeun analogi maritim, kaptén kapal henteu paduli naon jinis blok rigging (CRI-O) anu dianggo dina kapalna - hal utama pikeun aranjeunna nyaéta blok ieu kuat sareng dipercaya.
OpenShift 4, salaku platform awan, nyanghareupan tantangan bisnis anu sami. Titik anyar kedah didamel nalika nyiptakeun klaster, upami aya kagagalan dina salah sahiji titik, atanapi nalika skala klaster. Nalika hiji titik anyar dijieun tur initialized, komponén host kritis, kaasup CRI-O, kudu ngonpigurasi sasuai. Sapertos dina produksi anu sanés, "bahan baku" kedah disayogikeun di awal. Dina kasus kapal, bahan baku anu logam jeung kai. Nanging, dina kasus nyiptakeun host pikeun nyebarkeun wadah dina klaster OpenShift 4, anjeun kedah gaduh file konfigurasi sareng server anu disayogikeun API salaku input. OpenShift teras bakal nyayogikeun tingkat otomatisasi anu diperyogikeun sapanjang sadaya siklus kahirupan, nawiskeun pangrojong produk anu dipikabutuh pikeun pangguna akhir sahingga ngarobih deui investasi dina platform éta.
OpenShift 4 dijieun dina cara sapertos nyadiakeun kamampuhan pikeun merenah ngamutahirkeun sistem sapanjang sakabéh siklus kahirupan platform (pikeun versi 4.X) pikeun sakabéh panyadia komputasi awan utama, platform virtualization komo sistem logam bulistir. Jang ngalampahkeun ieu, titik kudu dijieun dina dasar elemen ditukeurkeun. Nalika klaster merlukeun versi anyar tina Kubernetes, éta ogé narima versi pakait tina CRI-O on CoreOS. Kusabab versi CRI-O disambungkeun langsung ka Kubernetes, ieu pisan nyederhanakeun sagala permutasi pikeun nguji, ngungkulan, atawa kaperluan rojongan. Salaku tambahan, pendekatan ieu ngirangan biaya pikeun pangguna akhir sareng Red Hat.
Ieu mangrupikeun cara pamikiran anu dasarna énggal ngeunaan klaster Kubernetes sareng nempatkeun dasar pikeun ngarencanakeun sababaraha fitur énggal anu mangpaat sareng pikaresepeun. CRI-O (Container Runtime Interface - Open Container Initiative, disingget CRI-OCI) tétéla janten pilihan anu paling suksés pikeun nyiptakeun masal titik anu kedah dianggo sareng OpenShift. CRI-O bakal ngagentos mesin Docker anu kantos dianggo, nawiskeun pangguna OpenShift - nuhun, anjeun uninga katuhu - mesin wadah boring dijieun husus pikeun gawé bareng Kubernetes.
Dunya wadah kabuka
Dunya parantos lami nuju ka wadah terbuka. Naha di Kubernetes, atanapi di tingkat handap, ngahasilkeun ékosistem inovasi dina unggal tingkatan.
Éta sadayana dimimitian ku nyiptakeun Inisiatif Wadah Terbuka . Dina tahap awal karya ieu, spésifikasi wadahna dibentuk и . Ieu mastikeun yén alat tiasa nganggo standar tunggal sarta format ngahijikeun Tatar pikeun gawé bareng aranjeunna. Spésifikasi engké ditambahkeun , ngamungkinkeun pamaké pikeun gampang babagi .
Komunitas Kubernetes lajeng ngembangkeun hiji standar tunggal pikeun panganteur pluggable, disebutna . Hatur nuhun kana ieu, pangguna Kubernetes tiasa nyambungkeun sababaraha mesin pikeun dianggo sareng wadah salian ti Docker.
Insinyur di Red Hat sareng Google ningali kabutuhan pasar pikeun mesin wadah anu tiasa nampi pamundut Kubelet dina protokol CRI sareng ngenalkeun wadah anu cocog sareng spésifikasi OCI anu disebatkeun di luhur. Janten . Tapi hapunten, naha urang henteu nyarios yén bahan ieu bakal dikhususkeun pikeun CRI-O? Sabenerna éta, ngan jeung release proyék ieu diganti CRI-O.
Gbr. 1.
Inovasi sareng CRI-O sareng CoreOS
Kalayan peluncuran platform OpenShift 4, éta dirobih , Dipaké sacara standar dina platform, sarta Docker diganti ku CRI-O, nawarkeun hiji ongkos-éféktif, stabil, lingkungan basajan tur boring pikeun ngajalankeun hiji wadah anu tumuwuh dina paralel kalawan Kubernetes. Ieu greatly simplifies rojongan klaster jeung konfigurasi. Konfigurasi mesin wadah sareng host, ogé manajeménna, janten otomatis dina OpenShift 4.
Antosan, kumaha ieu?
Éta leres, kalayan munculna OpenShift 4, teu aya deui anu peryogi pikeun nyambung ka host individu sareng masang mesin wadahna, ngonpigurasikeun panyimpenan, ngonpigurasikeun server milarian atanapi ngonpigurasikeun jaringan. Platform OpenShift 4 parantos dirarancang deui pikeun ngagunakeun éta teu ngan dina watesan aplikasi tungtung-pamaké, tapi ogé dina watesan operasi platform-tingkat dasar kayaning deploying gambar, ngonpigurasikeun sistem, atawa masang apdet.
Kubernetes salawasna ngidinan pamaké pikeun ngatur aplikasi ku nangtukeun kaayaan nu dipikahoyong tur ngagunakeun , pikeun mastikeun yén kaayaan sabenerna cocog kaayaan target sacaket mungkin. Ieu muka kasempetan anu saé tina sudut pandang pamekaran sareng operasi. Pamekar bisa nangtukeun kaayaan diperlukeun ku ka operator dina bentuk file YAML atanapi JSON, teras operator tiasa nyiptakeun conto aplikasi anu diperyogikeun di lingkungan produksi, sareng kaayaan operasi tina conto ieu bakal saluyu sareng anu ditangtukeun.
Ku ngagunakeun Operator dina platform, OpenShift 4 nyangking paradigma anyar ieu (ngagunakeun konsép set sareng kaayaan aktual) pikeun manajemén RHEL CoreOS sareng CRI-O. Tugas ngonpigurasikeun sareng ngatur versi sistem operasi sareng mesin wadahna otomatis nganggo anu disebut. . MCO greatly simplifies karya administrator klaster, dasarna automating tahap panungtungan instalasi, kitu ogé operasi pos-instalasi saterusna (dinten dua operasi). Sadaya ieu ngajadikeun OpenShift 4 platform awan anu leres. Urang bakal lebet kana ieu sakedik engké.
Ngajalankeun peti
Pamaké ngagaduhan kasempetan ngagunakeun mesin CRI-O dina platform OpenShift saprak versi 3.7 dina status Tech Preview sareng tina versi 3.9 dina status Umumna Sadia (ayeuna didukung). Sajaba ti éta, Red Hat massively ngagunakeun dina OpenShift Online saprak versi 3.10. Sadaya ieu ngamungkinkeun tim anu damel dina CRI-O mangtaun pangalaman éksténsif dina wadah peluncuran massal dina klaster Kubernetes ageung. Pikeun ngartos dasar kumaha Kubernetes ngagunakeun CRI-O, hayu urang tingali ilustrasi di handap ieu, anu nunjukkeun kumaha arsitéktur jalan.
Sangu. 2. Kumaha wadahna dianggo dina klaster Kubernetes
CRI-O nyederhanakeun kreasi host wadah anyar ku nyinkronkeun sakabéh tingkat luhur nalika ngamimitian titik anyar, sareng nalika ngaleupaskeun versi anyar tina platform OpenShift. Révisi sakabéh platform ngamungkinkeun pikeun apdet transactional / rollbacks, sarta ogé nyegah deadlocks dina kagumantungan antara inti buntut wadahna, mesin wadahna, titik (Kubelets) jeung titik Master Kubernetes. Ku centrally ngatur sakabéh komponén platform, kalawan kontrol jeung versioning, aya salawasna jalur jelas ti kaayaan A ka kaayaan B. Ieu simplifies prosés update, ngaronjatkeun kaamanan, ngaronjatkeun ngalaporkeun kinerja, tur mantuan ngurangan biaya apdet sarta pamasangan versi anyar. .
Mendemonstrasikan kakuatan elemen ngagantian
Sakumaha anu disebatkeun sateuacana, ngagunakeun Mesin Config Operator pikeun ngatur host wadahna sareng mesin wadahna di OpenShift 4 nyayogikeun tingkat otomatisasi énggal anu saacanna henteu mungkin dina platform Kubernetes. Pikeun nunjukkeun fitur anyar, kami bakal nunjukkeun kumaha anjeun tiasa ngarobih file crio.conf. Pikeun ngahindarkeun kabingungan ku terminologi, coba difokuskeun hasil.
Mimiti, hayu urang nyiptakeun naon anu disebut konfigurasi runtime wadah - Container Runtime Config. Pikirkeun éta salaku sumber daya Kubernetes anu ngagambarkeun konfigurasi pikeun CRI-O. Kanyataanna, éta mangrupikeun versi khusus tina hal anu disebut MachineConfig, nyaéta konfigurasi naon waé anu disebarkeun ka mesin RHEL CoreOS salaku bagian tina klaster OpenShift.
Ieu sumberdaya custom, disebut ContainerRuntimeConfig, dijieun pikeun leuwih gampang pikeun administrator klaster ngonpigurasikeun CRI-O. Alat ieu cukup kuat sahingga ngan tiasa diterapkeun ka titik-titik anu tangtu gumantung kana setélan MachineConfigPool. Pikirkeun éta salaku sakumpulan mesin anu nyayogikeun tujuan anu sami.
Perhatikeun dua garis panungtungan nu urang bade ngarobah dina /etc/crio/crio.conf file. Dua garis ieu mirip pisan sareng garis dina file crio.conf, nyaéta:
vi ContainerRuntimeConfig.yaml
kacindekan:
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
Ayeuna hayu urang nyorong file ieu kana klaster Kubernetes sareng pariksa yén éta leres-leres diciptakeun. Punten dicatet yén operasina sami sareng sumber daya Kubernetes anu sanés:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
kacindekan:
NAME AGE
set-log-and-pid 22h
Sakali kami geus dijieun ContainerRuntimeConfig, urang kudu ngaropea salah sahiji MachineConfigPools pikeun sinyal ka Kubernetes yén urang rék nerapkeun konfigurasi ieu grup husus mesin dina klaster. Dina hal ieu urang bakal ngarobah MachineConfigPool pikeun titik master:
oc edit MachineConfigPool/master
Kacindekan (pikeun kajelasan, hakekat utama ditinggalkeun):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Dina titik ieu, MCO mimiti nyieun file crio.conf anyar pikeun klaster. Dina hal ieu, file konfigurasi lengkep tiasa ditingali nganggo API Kubernetes. Émut, ContainerRuntimeConfig mangrupikeun versi khusus tina MachineConfig, ku kituna urang tiasa ningali hasilna ku ningali garis anu relevan dina MachineConfigs:
oc get MachineConfigs | grep rendered
kacindekan:
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
Punten dicatet yén file konfigurasi anu dihasilkeun pikeun master node mangrupikeun versi anu langkung énggal tibatan konfigurasi asli. Pikeun ningali éta, jalankeun paréntah di handap ieu. Saliwatan, urang dicatet yén ieu meureun salah sahiji pangalusna hiji-liners dina sajarah Kubernetes:
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
kacindekan:
pids_limit = 2048
Ayeuna hayu urang pastikeun yén konfigurasi geus dilarapkeun ka sadaya titik master. Mimiti urang kéngingkeun daptar titik dina kluster:
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
Ayeuna hayu urang tingali file anu dipasang. Anjeun bakal ningali yén file parantos diénggalan ku nilai-nilai énggal pikeun arahan pid sareng debug anu kami jelaskeun dina sumber ContainerRuntimeConfig. Elegance sorangan:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
kacindekan:
...
pids_limit = 2048
...
log_level = "debug"
...
Sadaya parobihan kana klaster ieu dilakukeun tanpa ngajalankeun SSH. Sadaya padamelan dilakukeun ku ngaksés titik master Kuberentes. Hartina, parameter anyar ieu dikonpigurasi ngan dina titik master. Titik worker henteu robih, anu nunjukkeun kauntungan tina metodologi Kubernetes ngagunakeun kaayaan anu khusus sareng aktual dina hubungan host wadah sareng mesin wadahna sareng unsur anu tiasa ditukeurkeun.
Conto di luhur nunjukkeun kamampuan ngadamel parobihan kana klaster OpenShift Container Platform 4 leutik sareng tilu titik produksi atanapi klaster produksi ageung kalayan 3000 titik. Dina sagala hal, jumlah gawé bakal sarua - sarta pohara leutik - ngan ngonpigurasikeun file ContainerRuntimeConfig, sarta ngarobah hiji labél dina MachineConfigPool. Sareng anjeun tiasa ngalakukeun ieu sareng versi naon waé tina OpenShift Container Platform 4.X ngajalankeun Kubernetes sapanjang siklus hirupna.
Seringna perusahaan téknologi mekar gancang sahingga urang henteu tiasa ngajelaskeun naha urang milih téknologi anu tangtu pikeun komponén dasar. Mesin wadahna baheulana mangrupikeun komponén anu berinteraksi langsung ku pangguna. Kusabab popularitas wadahna sacara alami dimimitian ku munculna mesin wadahna, pangguna sering nunjukkeun minat aranjeunna. Ieu alesan sejen naha Red Hat milih CRI-O. Wadahna ngembang kalayan fokus ayeuna kana orkestrasi, sareng kami mendakan yén CRI-O nyayogikeun pangalaman pangsaéna nalika damel sareng OpenShift 4.
sumber: www.habr.com