Platform ngijini sampeyan kanggo streamline nggawe , kalebu ing infrastruktur panyedhiya layanan maya, ing platform virtualisasi utawa ing sistem bare-metal. Kanggo nggawe platform basis awan sing sejatine, kita kudu ngontrol kabeh unsur sing digunakake lan kanthi mangkono nambah linuwih proses otomatisasi sing rumit.
Solusi sing jelas yaiku nggunakake Red Hat Enterprise Linux CoreOS (varian saka Red Hat Enterprise Linux) lan CRI-O minangka standar, lan iki sebabe ...
Wiwit topik pelayaran iku apik banget kanggo nemokake analogi nalika nerangake karya Kubernetes lan kontaner, ayo nyoba ngobrol babagan masalah bisnis sing diatasi CoreOS lan CRI-O, nggunakake conto. . Ing taun 1803, Marc Brunel ditugasi ngasilake 100 blok rigging kanggo kabutuhan angkatan laut Inggris sing saya tambah akeh. Blok rigging minangka jinis rigging sing digunakake kanggo nempelake tali ing layar. Nganti awal abad kaping 19, pamblokiran kasebut digawe kanthi tangan, nanging Brunel bisa ngotomatisasi produksi lan wiwit ngasilake blok standar nggunakake alat mesin. Otomasi proses iki tegese blok sing diasilake pancen padha, bisa gampang diganti yen rusak, lan bisa diprodhuksi kanthi jumlah akeh.
Saiki bayangake yen Brunel kudu nindakake pakaryan iki kanggo 20 model kapal sing beda-beda (versi Kubernetes) lan kanggo limang planet sing beda-beda kanthi arus laut lan angin sing beda banget (panyedhiya awan). Kajaba iku, dibutuhake kabeh kapal (klompok OpenShift), preduli saka planet sing navigasi ditindakake, saka sudut pandang kapten (operator sing ngatur operasi klompok) tumindak padha. Kanggo nerusake analogi maritim, kapten kapal ora peduli apa jenis blok rigging (CRI-O) sing digunakake ing kapal - sing utama yaiku blok kasebut kuwat lan dipercaya.
OpenShift 4, minangka platform maya, ngadhepi tantangan bisnis sing padha. Node anyar kudu digawe nalika nggawe kluster, yen ana kegagalan ing salah sawijining simpul, utawa nalika nggawe skala kluster. Nalika simpul anyar digawe lan diinisialisasi, komponen inang kritis, kalebu CRI-O, kudu dikonfigurasi. Kaya ing produksi liyane, "bahan mentah" kudu diwenehake ing wiwitan. Ing kasus kapal, bahan mentah yaiku logam lan kayu. Nanging, nalika nggawe host kanggo nyebarake wadhah ing kluster OpenShift 4, sampeyan kudu duwe file konfigurasi lan server sing disedhiyakake API minangka input. OpenShift banjur bakal nyedhiyakake tingkat otomatisasi sing dibutuhake sajrone kabeh siklus urip, nawakake dhukungan produk sing dibutuhake kanggo pangguna pungkasan lan kanthi mangkono mbalekake investasi ing platform kasebut.
OpenShift 4 digawe kanthi cara kanggo nyedhiyakake kemampuan kanggo nganyari sistem kanthi gampang ing kabeh siklus urip platform (kanggo versi 4.X) kanggo kabeh panyedhiya komputasi awan utama, platform virtualisasi lan malah sistem logam kosong. Kanggo nindakake iki, simpul kudu digawe adhedhasar unsur sing bisa diganti. Nalika kluster mbutuhake versi anyar Kubernetes, uga nampa versi CRI-O sing cocog ing CoreOS. Wiwit versi CRI-O disambungake langsung menyang Kubernetes, iki bakal nyederhanakake permutasi kanggo testing, ngatasi masalah, utawa tujuan dhukungan. Kajaba iku, pendekatan iki nyuda biaya kanggo pangguna pungkasan lan Red Hat.
Iki minangka cara dhasar anyar kanggo mikir babagan klompok Kubernetes lan nggawe dhasar kanggo ngrancang sawetara fitur anyar sing migunani lan menarik. CRI-O (Container Runtime Interface - Open Container Initiative, disingkat CRI-OCI) dadi pilihan sing paling sukses kanggo nggawe simpul massa sing perlu kanggo nggarap OpenShift. CRI-O bakal ngganti mesin Docker sing sadurunge digunakake, nawakake pangguna OpenShift - ya, sampeyan krungu bener - mesin wadhah sing mboseni digawe khusus kanggo nggarap Kubernetes.
Donya wadhah mbukak
Donya wis suwe maju menyang wadah sing mbukak. Apa ing Kubernetes, utawa ing tingkat sing luwih murah, ngasilake ekosistem inovasi ing saben tingkat.
Iku kabeh diwiwiti kanthi nggawe Open Containers Initiative . Ing tahap awal karya iki, spesifikasi wadhah dibentuk ΠΈ . Iki mesthekake yen alat bisa nggunakake standar siji lan format manunggal kanggo nggarap wong-wong mau. Spesifikasi banjur ditambahake , ngidini pangguna bisa enggo bareng kanthi gampang .
Komunitas Kubernetes banjur ngembangake standar siji kanggo antarmuka pluggable, disebut . Thanks kanggo iki, pangguna Kubernetes bisa nyambung macem-macem mesin kanggo nggarap wadhah saliyane Docker.
Insinyur ing Red Hat lan Google weruh kabutuhan pasar kanggo mesin wadah sing bisa nampa panjalukan Kubelet liwat protokol CRI lan ngenalake wadhah sing kompatibel karo spesifikasi OCI sing kasebut ing ndhuwur. Dadi . Nanging nyuwun pangapunten, apa kita ora ujar manawa materi iki bakal dikhususake kanggo CRI-O? Bener iku, mung karo release project iki diganti jeneng CRI-O.
Gambar: limalas
Inovasi karo CRI-O lan CoreOS
Kanthi peluncuran platform OpenShift 4, iku diganti , digunakake minangka standar ing platform, lan Docker diganti dening CRI-O, nawakake lingkungan biaya-efektif, stabil, prasaja lan mboseni kanggo mbukak wadhah sing develops ing podo karo karo Kubernetes. Iki banget nyederhanakake dhukungan lan konfigurasi kluster. Konfigurasi mesin wadhah lan host, uga manajemen, dadi otomatis ing OpenShift 4.
Ngenteni, piye iki?
Bener, kanthi tekane OpenShift 4, ora perlu nyambung menyang host individu lan nginstal mesin kontainer, ngatur panyimpenan, ngatur server telusuran utawa ngatur jaringan. Platform OpenShift 4 wis didesain ulang kanggo nggunakake ora mung babagan aplikasi pangguna pungkasan, nanging uga babagan operasi tingkat platform dhasar kayata nyebarake gambar, ngatur sistem, utawa nginstal nganyari.
Kubernetes tansah ngidini pangguna kanggo ngatur aplikasi kanthi nemtokake status sing dikarepake lan nggunakake , kanggo mesthekake yen negara nyata cocog karo negara target sabisa. Iki mbukak kesempatan gedhe saka loro perspektif pembangunan lan operasi. Pangembang bisa nemtokake negara sing dibutuhake kanthi menyang operator ing bentuk file YAML utawa JSON, banjur operator bisa nggawe conto aplikasi sing dibutuhake ing lingkungan produksi, lan kahanan operasi saka conto iki bakal cocog karo sing wis ditemtokake.
Kanthi nggunakake Operator ing platform, OpenShift 4 nggawa paradigma anyar iki (nggunakake konsep set lan kahanan nyata) kanggo manajemen RHEL CoreOS lan CRI-O. Tugas kanggo ngatur lan ngatur versi sistem operasi lan mesin kontainer kanthi otomatis nggunakake apa sing diarani . MCO nemen nyederhanakake karya administrator kluster, ateges ngotomatisasi tahap pungkasan instalasi, uga operasi pasca instalasi sakteruse (operasi rong dina). Kabeh iki ndadekake OpenShift 4 dadi platform maya sing sejati. Kita bakal ngrembug babagan iki mengko.
Mlaku wadhah
Pangguna duwe kesempatan kanggo nggunakake mesin CRI-O ing platform OpenShift wiwit versi 3.7 ing status Tech Preview lan saka versi 3.9 ing status Umum sing kasedhiya (saiki didhukung). Kajaba iku, Red Hat massively nggunakake ing OpenShift Online wiwit versi 3.10. Kabeh iki ngidini tim sing nggarap CRI-O entuk pengalaman ekstensif ing wadah peluncuran massal ing kluster Kubernetes gedhe. Kanggo entuk pangerten dhasar babagan carane Kubernetes nggunakake CRI-O, ayo deleng ilustrasi ing ngisor iki, sing nuduhake cara kerja arsitektur.
Gabah. 2. Carane kontaner bisa ing kluster Kubernetes
CRI-O nyederhanakake nggawe host wadhah anyar kanthi nyinkronake kabeh level ndhuwur nalika miwiti simpul anyar, lan nalika ngeculake versi anyar saka platform OpenShift. Revisi kabeh platform ngidini kanggo nganyari transaksional / rollbacks, lan uga nyegah deadlocks ing dependensi antarane inti buntut wadhah, mesin wadhah, kelenjar (Kubelets) lan simpul Master Kubernetes. Kanthi ngatur kabeh komponen platform kanthi pusat, kanthi kontrol lan versi, mesthi ana dalan sing jelas saka negara A menyang negara B. Iki nyederhanakake proses nganyari, nambah keamanan, nambah laporan kinerja, lan mbantu nyuda biaya nganyari lan instalasi versi anyar. .
Nuduhake kekuwatan unsur panggantos
Kaya sing wis kasebut sadurunge, nggunakake Operator Konfigurasi Mesin kanggo ngatur host wadah lan mesin wadah ing OpenShift 4 nyedhiyakake tingkat otomatisasi anyar sing sadurunge ora bisa ditindakake ing platform Kubernetes. Kanggo nduduhake fitur-fitur anyar, kita bakal nuduhake carane sampeyan bisa ngganti file crio.conf. Supaya ora bingung karo terminologi, coba fokus ing asil.
Pisanan, ayo nggawe apa sing diarani konfigurasi runtime container - Container Runtime Config. Mikir minangka sumber Kubernetes sing makili konfigurasi kanggo CRI-O. Ing kasunyatan, iki minangka versi khusus sing diarani MachineConfig, yaiku konfigurasi apa wae sing dipasang ing mesin RHEL CoreOS minangka bagΓ©an saka kluster OpenShift.
Sumber daya khusus iki, sing diarani ContainerRuntimeConfig, digawe kanggo nggampangake pangurus kluster ngatur CRI-O. Alat iki cukup kuat sing mung bisa ditrapake ing kelenjar tartamtu gumantung saka setelan MachineConfigPool. Tjubo minangka klompok mesin sing duwe tujuan sing padha.
Wigati rong baris pungkasan sing bakal kita ganti ing file /etc/crio/crio.conf. Loro baris iki meh padha karo garis ing file crio.conf, yaiku:
vi ContainerRuntimeConfig.yaml
Kesimpulan:
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
Saiki ayo push file iki menyang cluster Kubernetes lan priksa manawa file kasebut bener-bener digawe. Wigati dimangerteni manawa operasi kasebut padha karo sumber daya Kubernetes liyane:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Kesimpulan:
NAME AGE
set-log-and-pid 22h
Sawise kita wis digawe ContainerRuntimeConfig, kita kudu ngowahi siji saka MachineConfigPools kanggo sinyal kanggo Kubernetes sing kita arep kanggo aplikasi konfigurasi iki kanggo klompok tartamtu saka mesin ing kluster. Ing kasus iki, kita bakal ngganti MachineConfigPool kanggo simpul master:
oc edit MachineConfigPool/master
Kesimpulan (kanggo kajelasan, inti utama ditinggalake):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Ing wektu iki, MCO wiwit nggawe file crio.conf anyar kanggo kluster. Ing kasus iki, file konfigurasi rampung bisa dideleng nggunakake API Kubernetes. Elinga, ContainerRuntimeConfig mung versi khusus saka MachineConfig, supaya kita bisa ndeleng asil kanthi ndeleng garis sing cocog ing MachineConfigs:
oc get MachineConfigs | grep rendered
Kesimpulan:
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
Wigati dimangerteni manawa file konfigurasi sing diasilake kanggo simpul master yaiku versi sing luwih anyar tinimbang konfigurasi asli. Kanggo ndeleng, jalanake printah ing ngisor iki. Sawise kabeh, kita nyathet manawa iki bisa uga salah sawijining baris paling apik ing sejarah 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
Kesimpulan:
pids_limit = 2048
Saiki ayo priksa manawa konfigurasi wis ditrapake kanggo kabeh simpul master. Pisanan kita entuk dhaptar simpul ing 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
Saiki ayo goleki file sing wis diinstal. Sampeyan bakal weruh manawa file kasebut wis dianyari karo nilai anyar kanggo arahan pid lan debug sing wis ditemtokake ing sumber ContainerRuntimeConfig. Elegance dhewe:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal β cat /host/etc/crio/crio.conf | egrep 'debug||pidβ
Kesimpulan:
...
pids_limit = 2048
...
log_level = "debug"
...
Kabeh owah-owahan ing kluster kasebut digawe tanpa nganggo SSH. Kabeh karya ditindakake kanthi ngakses simpul master Kuberentes. Yaiku, paramèter anyar iki dikonfigurasi mung ing simpul master. Node buruh ora owah, sing nuduhake keuntungan saka metodologi Kubernetes nggunakake negara sing ditemtokake lan nyata ing hubungane karo host kontainer lan mesin kontainer kanthi unsur sing bisa diganti.
Conto ing ndhuwur nuduhake kemampuan kanggo nggawe owah-owahan menyang kluster OpenShift Container Platform 4 cilik kanthi telung kelenjar produksi utawa kluster produksi gedhe kanthi 3000 simpul. Ing kasus apa wae, jumlah karya bakal padha - lan cilik banget - mung ngatur file ContainerRuntimeConfig, lan ngganti siji label ing MachineConfigPool. Lan sampeyan bisa nindakake iki karo versi OpenShift Container Platform 4.X sing nganggo Kubernetes sajrone siklus urip.
Asring perusahaan teknologi berkembang kanthi cepet nganti kita ora bisa nerangake kenapa kita milih teknologi tartamtu kanggo komponen dhasar. Mesin kontainer kanthi historis minangka komponen sing sesambungan karo pangguna langsung. Wiwit popularitas wadhah kanthi alami diwiwiti kanthi munculΓ© mesin kontainer, pangguna asring nuduhake minat kasebut. Iki minangka alesan liyane kenapa Red Hat milih CRI-O. Kontainer berkembang kanthi fokus ing orkestrasi, lan kita nemokake manawa CRI-O nyedhiyakake pengalaman paling apik nalika nggarap OpenShift 4.
Source: www.habr.com