Platformalar yaratishni tartibga solish imkonini beradi , shu jumladan bulutli xizmat ko'rsatuvchi provayderlar infratuzilmasida, virtualizatsiya platformalarida yoki yalang'och metall tizimlarda. Haqiqiy bulutga asoslangan platformani yaratish uchun biz foydalanilgan barcha elementlarni qattiq nazoratga olishimiz va shu tariqa murakkab avtomatlashtirish jarayonining ishonchliligini oshirishimiz kerak edi.
Aniq yechim standart sifatida Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux varianti) va CRI-O dan foydalanish edi va nima uchun...
Suzib yurish mavzusi Kubernetes va konteynerlarning ishini tushuntirishda o'xshashliklarni topish uchun juda yaxshi mavzu bo'lganligi sababli, keling, misol yordamida CoreOS va CRI-O hal qiladigan biznes muammolari haqida gapirishga harakat qilaylik. . 1803 yilda Mark Brunel o'sib borayotgan Britaniya dengiz floti ehtiyojlari uchun 100 19 dona armatura ishlab chiqarishni topshirdi. Arqonlarni yelkanlarga ulash uchun ishlatiladigan armatura turi. XNUMX-asrning boshlariga qadar bu bloklar qo'lda qilingan, ammo Brunel ishlab chiqarishni avtomatlashtirishga muvaffaq bo'ldi va dastgohlar yordamida standartlashtirilgan bloklarni ishlab chiqarishni boshladi. Ushbu jarayonni avtomatlashtirish natijasida hosil bo'lgan bloklar mohiyatan bir xil bo'lib, singan holda osongina almashtirilishi va ko'p miqdorda ishlab chiqarilishi mumkin edi.
Endi tasavvur qiling-a, Brunel bu ishni 20 xil kema modellari (Kubernetes versiyalari) va butunlay boshqa dengiz oqimlari va shamollari (bulut provayderlari) bilan besh xil sayyoralar uchun bajarishi kerak edi. Bundan tashqari, barcha kemalar (OpenShift klasterlari), navigatsiya qaysi sayyoralarda amalga oshirilayotganidan qat'i nazar, kapitanlar (klasterlar ishini boshqaradigan operatorlar) nuqtai nazaridan bir xil yo'l tutishlari kerak edi. Dengiz o'xshashligini davom ettirish uchun kema kapitanlari o'z kemalarida qanday armatura bloklari (CRI-O) ishlatilishiga umuman ahamiyat bermaydilar - ular uchun asosiysi bu bloklar kuchli va ishonchli.
OpenShift 4, bulutli platforma sifatida, juda o'xshash biznes muammosiga duch keladi. Yangi tugunlar klasterni yaratish vaqtida, tugunlardan birida ishlamay qolganda yoki klasterni masshtablashda yaratilishi kerak. Yangi tugun yaratilganda va ishga tushirilganda, muhim xost komponentlari, shu jumladan CRI-O mos ravishda sozlanishi kerak. Boshqa har qanday ishlab chiqarishda bo'lgani kabi, "xom ashyo" boshida etkazib berilishi kerak. Kemalarda xom ashyo metall va yog'ochdir. Biroq, OpenShift 4 klasterida konteynerlarni joylashtirish uchun xost yaratishda siz kiritish sifatida konfiguratsiya fayllari va API tomonidan taqdim etilgan serverlarga ega bo'lishingiz kerak. Keyin OpenShift butun hayot tsikli davomida kerakli darajadagi avtomatlashtirishni ta'minlaydi, oxirgi foydalanuvchilarga kerakli mahsulotni qo'llab-quvvatlashni taklif qiladi va shu bilan platformaga investitsiyalarni qoplaydi.
OpenShift 4 barcha yirik bulutli hisoblash provayderlari, virtualizatsiya platformalari va hatto yalang'och metall tizimlar uchun platformaning butun hayotiy tsikli davomida (4.X versiyalari uchun) tizimni qulay yangilash imkoniyatini beradigan tarzda yaratilgan. Buning uchun tugunlar almashtiriladigan elementlar asosida yaratilishi kerak. Klaster Kubernetesning yangi versiyasini talab qilganda, u CoreOS da tegishli CRI-O versiyasini ham oladi. CRI-O versiyasi to'g'ridan-to'g'ri Kubernetes bilan bog'langanligi sababli, bu sinov, muammolarni bartaraf etish yoki qo'llab-quvvatlash maqsadlari uchun har qanday almashtirishlarni sezilarli darajada soddalashtiradi. Bundan tashqari, bu yondashuv oxirgi foydalanuvchilar va Red Hat uchun xarajatlarni kamaytiradi.
Bu Kubernetes klasterlari haqida mutlaqo yangi fikrlash usuli bo'lib, juda foydali va jozibali yangi xususiyatlarni rejalashtirish uchun asos yaratadi. CRI-O (Container Runtime Interface - Open Container Initiative, qisqartirilgan CRI-OCI) OpenShift bilan ishlash uchun zarur bo'lgan tugunlarni ommaviy yaratish uchun eng muvaffaqiyatli tanlov bo'lib chiqdi. CRI-O OpenShift foydalanuvchilariga ilgari ishlatilgan Docker dvigatelini almashtiradi - Ha, siz to'g'ri eshitdingiz - Kubernetes bilan ishlash uchun maxsus yaratilgan zerikarli konteyner dvigateli.
Ochiq konteynerlar dunyosi
Dunyo uzoq vaqtdan beri ochiq konteynerlar tomon harakat qilmoqda. Kubernetesda bo'ladimi yoki pastroq darajada, har bir darajadagi innovatsiyalar ekotizimiga olib keladi.
Hammasi ochiq konteynerlar tashabbusini yaratish bilan boshlandi . Ishning ushbu dastlabki bosqichida konteyner spetsifikatsiyalari shakllantirildi и . Bu asboblarning yagona standartdan foydalanishini ta'minladi va ular bilan ishlashning yagona formati. Keyinchalik spetsifikatsiyalar qo'shildi , foydalanuvchilarga osongina almashish imkonini beradi .
Keyin Kubernetes hamjamiyati ulanishi mumkin bo'lgan interfeys uchun yagona standartni ishlab chiqdi . Buning yordamida Kubernetes foydalanuvchilari Docker-dan tashqari konteynerlar bilan ishlash uchun turli dvigatellarni ulashga muvaffaq bo'lishdi.
Red Hat va Google muhandislari bozorda CRI protokoli bo'yicha Kubelet so'rovlarini qabul qila oladigan konteyner dvigateliga ehtiyoj sezdi va yuqorida aytib o'tilgan OCI spetsifikatsiyalariga mos keladigan konteynerlarni taqdim etdi. Shunday qilib . Kechirasiz, biz ushbu material CRI-O ga bag'ishlanganligini aytmadikmi? Aslida, bu faqat reliz bilan loyiha CRI-O deb o'zgartirildi.
Fig. 1.
CRI-O va CoreOS bilan innovatsiyalar
OpenShift 4 platformasining ishga tushirilishi bilan u o'zgartirildi , platformada sukut boʻyicha foydalanilgan va Docker CRI-O bilan almashtirildi, bu esa Kubernetes bilan parallel ravishda rivojlanayotgan konteynerni ishlatish uchun tejamkor, barqaror, oddiy va zerikarli muhitni taklif qildi. Bu klasterni qo'llab-quvvatlash va konfiguratsiyani sezilarli darajada osonlashtiradi. Konteyner dvigateli va xost konfiguratsiyasi, shuningdek ularni boshqarish OpenShift 4 da avtomatlashtiriladi.
Kuting, bu qanday?
To'g'ri, OpenShift 4 paydo bo'lishi bilan endi alohida xostlarga ulanish va konteyner mexanizmini o'rnatish, saqlashni sozlash, qidiruv serverlarini sozlash yoki tarmoqni sozlash kerak emas. OpenShift 4 platformasi foydalanish uchun butunlay qayta ishlab chiqilgan nafaqat oxirgi foydalanuvchi ilovalari nuqtai nazaridan, balki tasvirlarni joylashtirish, tizimni sozlash yoki yangilanishlarni o'rnatish kabi asosiy platforma darajasidagi operatsiyalar nuqtai nazaridan ham.
Kubernetes har doim foydalanuvchilarga kerakli holatni aniqlash va foydalanish orqali ilovalarni boshqarishga ruxsat bergan , haqiqiy holat maqsadli holatga iloji boricha yaqinroq mos kelishini ta'minlash. Bu rivojlanish va operatsion nuqtai nazardan katta imkoniyatlar ochadi. Ishlab chiquvchilar kerakli holatni belgilashlari mumkin operatorga YAML yoki JSON fayli ko'rinishida, so'ngra operator ishlab chiqarish muhitida kerakli dastur namunasini yaratishi mumkin va bu instansiyaning ish holati ko'rsatilganiga to'liq mos keladi.
Platformada Operatorlardan foydalangan holda, OpenShift 4 RHEL CoreOS va CRI-O boshqaruviga ushbu yangi paradigmani (to'plam va haqiqiy holat tushunchasidan foydalangan holda) olib keladi. Operatsion tizim va konteyner dvigatelining versiyalarini sozlash va boshqarish vazifalari avtomatlashtirilgan. . MCO klaster ma'murining ishini sezilarli darajada soddalashtiradi, asosan o'rnatishning oxirgi bosqichlarini, shuningdek, keyingi o'rnatishdan keyingi operatsiyalarni (ikkinchi kun operatsiyalari) avtomatlashtiradi. Bularning barchasi OpenShift 4 ni haqiqiy bulutli platformaga aylantiradi. Bu haqda biroz keyinroq to‘xtalamiz.
Ishlaydigan konteynerlar
Foydalanuvchilar CRI-O dvigatelidan OpenShift platformasida Tech Preview holatidagi 3.7-versiyasidan boshlab va 3.9-versiyasidan “Umumiy mavjud” holatida (hozirda qo‘llab-quvvatlanadi) foydalanish imkoniyatiga ega bo‘ldilar. Bundan tashqari, Red Hat ommaviy ravishda foydalanadi 3.10 versiyasidan boshlab OpenShift Online-da. Bularning barchasi CRI-O ustida ishlayotgan jamoaga katta Kubernetes klasterlarida konteynerlarni ommaviy ishga tushirishda katta tajriba orttirish imkonini berdi. Kubernetes CRI-O dan qanday foydalanishi haqida asosiy tushunchaga ega bo'lish uchun arxitektura qanday ishlashini ko'rsatadigan quyidagi rasmni ko'rib chiqaylik.
Guruch. 2. Kubernetes klasterida konteynerlar qanday ishlaydi
CRI-O yangi tugunlarni ishga tushirishda va OpenShift platformasining yangi versiyalarini chiqarishda butun yuqori darajani sinxronlash orqali yangi konteyner xostlarini yaratishni soddalashtiradi. Butun platformani qayta ko'rib chiqish tranzaksiyalarni yangilash/qayta tiklash imkonini beradi, shuningdek, konteyner quyruq yadrosi, konteyner dvigateli, tugunlar (Kubelets) va Kubernetes Master tugunlari o'rtasidagi bog'liqliklarning oldini oladi. Platformaning barcha komponentlarini nazorat qilish va versiyalash bilan markazlashtirilgan holda boshqarish orqali har doim A holatidan B holatiga aniq yo‘l bor. Bu yangilash jarayonini soddalashtiradi, xavfsizlikni yaxshilaydi, ishlash hisobotini yaxshilaydi va yangi versiyalarni yangilash va o‘rnatish xarajatlarini kamaytirishga yordam beradi. .
O'zgartirish elementlarining kuchini ko'rsatish
Yuqorida aytib o'tilganidek, OpenShift 4-da konteyner xostini va konteyner dvigatelini boshqarish uchun Machine Config operatoridan foydalanish Kubernetes platformasida ilgari imkoni bo'lmagan avtomatlashtirishning yangi darajasini ta'minlaydi. Yangi xususiyatlarni namoyish qilish uchun crio.conf fayliga qanday o'zgartirishlar kiritishingiz mumkinligini ko'rsatamiz. Terminologiya bilan chalkashmaslik uchun natijalarga e'tibor qaratishga harakat qiling.
Birinchidan, konteynerning ishlash vaqti konfiguratsiyasi deb ataladigan narsani yarataylik - Container Runtime Config. Buni CRI-O konfiguratsiyasini ifodalovchi Kubernetes resursi sifatida tasavvur qiling. Aslida, bu OpenShift klasterining bir qismi sifatida RHEL CoreOS mashinasiga o'rnatiladigan har qanday konfiguratsiya bo'lgan MachineConfig deb nomlangan narsaning ixtisoslashtirilgan versiyasidir.
ContainerRuntimeConfig deb nomlangan ushbu maxsus resurs klaster ma'murlari uchun CRI-O ni sozlashni osonlashtirish uchun yaratilgan. Ushbu vosita etarlicha kuchli bo'lib, u MachineConfigPool sozlamalariga qarab faqat ma'lum tugunlarga qo'llanilishi mumkin. Buni bir xil maqsadga xizmat qiluvchi mashinalar guruhi sifatida tasavvur qiling.
Biz /etc/crio/crio.conf faylida o'zgartirmoqchi bo'lgan oxirgi ikki qatorga e'tibor bering. Bu ikki qator crio.conf faylidagi satrlarga juda o'xshaydi, ular:
vi ContainerRuntimeConfig.yaml
xulosa:
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
Keling, ushbu faylni Kubernetes klasteriga suramiz va u haqiqatda yaratilganligini tekshiramiz. E'tibor bering, operatsiya boshqa Kubernetes manbalari bilan bir xil:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
xulosa:
NAME AGE
set-log-and-pid 22h
ContainerRuntimeConfig-ni yaratganimizdan so'ng, Kubernetesga ushbu konfiguratsiyani klasterdagi ma'lum bir mashinalar guruhiga qo'llashni xohlayotganimizni bildirish uchun MachineConfigPools-dan birini o'zgartirishimiz kerak. Bunday holda biz asosiy tugunlar uchun MachineConfigPool-ni o'zgartiramiz:
oc edit MachineConfigPool/master
Xulosa (aniqlik uchun asosiy mohiyat qoldiriladi):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Bu vaqtda MCO klaster uchun yangi crio.conf faylini yaratishni boshlaydi. Bunday holda, to'liq tayyor konfiguratsiya faylini Kubernetes API yordamida ko'rish mumkin. Esingizda bo'lsin, ContainerRuntimeConfig - bu MachineConfig-ning ixtisoslashtirilgan versiyasi, shuning uchun biz MachineConfigs-dagi tegishli qatorlarga qarab natijani ko'rishimiz mumkin:
oc get MachineConfigs | grep rendered
xulosa:
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
E'tibor bering, asosiy tugunlar uchun olingan konfiguratsiya fayli asl konfiguratsiyalarga qaraganda yangiroq versiya edi. Uni ko'rish uchun quyidagi buyruqni bajaring. O'tmishda shuni ta'kidlaymizki, bu Kubernetes tarixidagi eng yaxshi laynerlardan biri:
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
xulosa:
pids_limit = 2048
Endi konfiguratsiya barcha asosiy tugunlarga qo'llanganligiga ishonch hosil qilaylik. Avval biz klasterdagi tugunlar ro'yxatini olamiz:
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
Endi o'rnatilgan faylni ko'rib chiqamiz. Fayl biz ContainerRuntimeConfig resursida ko'rsatgan pid va disk raskadrovka direktivalari uchun yangi qiymatlar bilan yangilanganligini ko'rasiz. Elegantning o'zi:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
xulosa:
...
pids_limit = 2048
...
log_level = "debug"
...
Klasterdagi barcha bu o'zgarishlar hatto SSH-ni ishga tushirmasdan ham amalga oshirildi. Barcha ishlar Kuberentes asosiy tuguniga kirish orqali amalga oshirildi. Ya'ni, bu yangi parametrlar faqat asosiy tugunlarda tuzilgan. Ishchi tugunlari o'zgarmadi, bu Kubernetes metodologiyasining konteyner xostlari va almashtiriladigan elementlarga ega konteyner dvigatellariga nisbatan belgilangan va haqiqiy holatlardan foydalanishning afzalliklarini ko'rsatadi.
Yuqoridagi misol uchta ishlab chiqarish tuguniga ega bo'lgan kichik OpenShift Konteyner Platformasi 4 klasteriga yoki 3000 ta tugunli ulkan ishlab chiqarish klasteriga o'zgartirish kiritish imkoniyatini ko'rsatadi. Har qanday holatda, ish hajmi bir xil bo'ladi - va juda kichik - faqat ContainerRuntimeConfig faylini sozlang va MachineConfigPool-da bitta yorliqni o'zgartiring. Siz buni butun umr davomida Kubernetes bilan ishlaydigan OpenShift Container Platform 4.X ning istalgan versiyasi bilan qilishingiz mumkin.
Ko'pincha texnologiya kompaniyalari shunchalik tez rivojlanadiki, biz nima uchun asosiy komponentlar uchun ma'lum texnologiyalarni tanlaganimizni tushuntira olmaymiz. Konteyner dvigatellari tarixan foydalanuvchilar bilan bevosita muloqot qiladigan komponent bo'lib kelgan. Konteynerlarning mashhurligi tabiiy ravishda konteyner dvigatellarining paydo bo'lishi bilan boshlanganligi sababli, foydalanuvchilar ko'pincha ularga qiziqish bildiradilar. Bu Red Hat CRI-O ni tanlashining yana bir sababidir. Konteynerlar orkestratsiyaga e'tibor qaratib rivojlanmoqda va biz CRI-O OpenShift 4 bilan ishlashda eng yaxshi tajribani taqdim etishini aniqladik.
Manba: www.habr.com