Платформ бүтээлийг оновчтой болгох боломжийг танд олгоно Үүлэн үйлчилгээ үзүүлэгчдийн дэд бүтцэд, виртуалчлалын платформ дээр эсвэл нүцгэн металл системд орно. Жинхэнэ үүлэн дээр суурилсан платформыг бий болгохын тулд бид ашигласан бүх элементүүдэд хатуу хяналт тавьж, улмаар нарийн төвөгтэй автоматжуулалтын үйл явцын найдвартай байдлыг нэмэгдүүлэх шаардлагатай болсон.
Очевидным решением стало использование в качестве стандарта Red Hat Enterprise Linux CoreOS (разновидности Red Hat Enterprise Linux) и CRI-O, и вот почему…
Дарвуулт завины сэдэв нь Кубернетес болон контейнерийн ажлыг тайлбарлахдаа аналоги олоход маш сайн сэдэв тул CoreOS болон CRI-O-ийн шийддэг бизнесийн асуудлын талаар жишээн дээр ярихыг хичээцгээе. . 1803 онд Марк Брунел өсөн нэмэгдэж буй Британийн тэнгисийн цэргийн хэрэгцээнд зориулж 100 армийн блок үйлдвэрлэх даалгавар авсан. Армийн блок гэдэг нь далбаат онгоцонд олс бэхлэх зориулалттай бэхэлгээний нэг төрөл юм. 19-р зууны эхэн үе хүртэл эдгээр блокуудыг гараар хийдэг байсан ч Брунел үйлдвэрлэлийг автоматжуулж, машин багаж ашиглан стандартчилагдсан блокуудыг үйлдвэрлэж эхлэв. Энэ процессыг автоматжуулснаар үүссэн блокууд нь бараг ижил, эвдэрсэн тохиолдолд амархан сольж, их хэмжээгээр үйлдвэрлэх боломжтой гэсэн үг юм.
Брунел энэ ажлыг 20 өөр хөлөг онгоцны загвар (Кубернетес хувилбарууд) болон огт өөр далайн урсгал, салхитай таван өөр гаригт (үүл үйлчилгээ үзүүлэгч) хийх ёстой байсан бол төсөөлөөд үз дээ. Нэмж дурдахад, бүх хөлөг онгоцууд (OpenShift кластерууд) ямар гариг дээр навигаци хийж байгаагаас үл хамааран ахмадуудын (кластеруудын ажиллагааг удирддаг операторуудын) үүднээс ижилхэн ажиллахыг шаарддаг. Далайн аналогийг үргэлжлүүлэхийн тулд хөлөг онгоцны ахмадууд хөлөг онгоцондоо ямар төрлийн бэхэлгээний блокуудыг (CRI-O) ашигладаг нь огт хамаагүй - тэдний хувьд хамгийн гол зүйл бол эдгээр блокууд нь бат бөх, найдвартай байх явдал юм.
OpenShift 4 нь үүлэн платформын хувьд бизнесийн маш төстэй сорилттой тулгардаг. Кластер үүсгэх үед, аль нэг зангилаанд алдаа гарсан тохиолдолд, эсвэл кластерыг масштаблах үед шинэ зангилаа үүсэх ёстой. Шинэ зангилаа үүсгэж, эхлүүлэх үед CRI-O зэрэг чухал хост бүрэлдэхүүн хэсгүүдийг зохих ёсоор тохируулах ёстой. Бусад үйлдвэрлэлийн нэгэн адил “түүхий эдийг” эхэнд нь нийлүүлэх ёстой. Усан онгоцны хувьд түүхий эд нь металл, мод юм. Гэсэн хэдий ч OpenShift 4 кластерт контейнер байршуулах хост үүсгэх тохиолдолд та тохиргооны файлууд болон API-аар хангагдсан серверүүдийг оруулах хэрэгтэй. OpenShift нь бүх амьдралын мөчлөгийн туршид шаардлагатай түвшний автоматжуулалтыг хангаж, эцсийн хэрэглэгчдэд шаардлагатай бүтээгдэхүүний дэмжлэгийг санал болгож, платформд оруулсан хөрөнгө оруулалтыг нөхөх болно.
OpenShift 4 нь үүлэн тооцооллын бүх томоохон үйлчилгээ үзүүлэгчид, виртуалчлалын платформууд, тэр ч байтугай нүцгэн металл системүүдэд зориулсан платформын амьдралын мөчлөгийн туршид (4.X хувилбаруудын хувьд) системийг хялбархан шинэчлэх боломжийг олгох үүднээс бүтээгдсэн. Үүнийг хийхийн тулд сольж болох элементүүдийн үндсэн дээр зангилаа үүсгэх ёстой. Кластерт Kubernetes-ийн шинэ хувилбар шаардлагатай үед CoreOS дээрх CRI-O-ийн холбогдох хувилбарыг хүлээн авдаг. CRI-O хувилбар нь шууд Kubernetes-тэй холбогддог тул энэ нь туршилт, алдааг олж засварлах эсвэл дэмжлэг үзүүлэх зорилгоор ямар ч өөрчлөлтийг ихээхэн хялбаршуулдаг. Үүнээс гадна энэ арга нь эцсийн хэрэглэгчид болон Red Hat-ийн зардлыг бууруулдаг.
Энэ нь Kubernetes кластеруудын талаар цоо шинэ сэтгэлгээний арга бөгөөд маш хэрэгтэй, сэтгэл хөдөлгөм шинэ боломжуудыг төлөвлөх үндэс суурийг тавьдаг. CRI-O (Container Runtime Interface - Open Container Initiative, товчилсон CRI-OCI) нь OpenShift-тэй ажиллахад шаардлагатай зангилаа үүсгэх хамгийн амжилттай сонголт болсон. CRI-O нь OpenShift хэрэглэгчдэд өмнө нь ашиглагдаж байсан Docker хөдөлгүүрийг солих болно – Тийм ээ, та зөв сонссон – Кубернетестэй ажиллахад зориулан бүтээсэн уйтгартай чингэлэг хөдөлгүүр.
Нээлттэй савны ертөнц
Дэлхий задгай чингэлэг рүү шилжих болсоор удаж байна. Кубернетес эсвэл доод түвшний аль нь ч бай, бүх түвшинд инновацийн экосистемийг бий болгодог.
Энэ бүхэн "Нээлттэй контейнер" санаачилгыг бий болгосноор эхэлсэн . Ажлын энэ эхний үе шатанд савны техникийн үзүүлэлтүүд бий болсон и . Энэ нь багаж хэрэгсэл нь нэг стандартыг ашиглах боломжтой болсон мөн тэдэнтэй ажиллах нэгдсэн хэлбэр. Тодорхойлолтыг дараа нь нэмсэн , хэрэглэгчдэд хялбар хуваалцах боломжийг олгодог .
Дараа нь Кубернетес нийгэмлэг нь залгах боломжтой интерфейсийн нэгдсэн стандартыг боловсруулсан . Үүний ачаар Kubernetes-ийн хэрэглэгчид Docker-ээс гадна контейнертэй ажиллах янз бүрийн хөдөлгүүрүүдийг холбох боломжтой болсон.
Red Hat болон Google-ийн инженерүүд CRI протоколоор Kubelet-ийн хүсэлтийг хүлээн авч чадах чингэлэг хөдөлгүүртэй болох зах зээлийн хэрэгцээг олж харж, дээр дурдсан OCI техникийн үзүүлэлтүүдтэй нийцсэн контейнеруудыг нэвтрүүлсэн. Тэгэхээр . Гэхдээ уучлаарай, бид энэ материалыг CRI-O-д зориулна гэж хэлээгүй гэж үү? Үнэн хэрэгтээ энэ нь зөвхөн хувилбарын дагуу юм төслийн нэрийг CRI-O гэж өөрчилсөн.
Зураг: арван тав.
CRI-O болон CoreOS бүхий инноваци
OpenShift 4 платформ гарч ирснээр энэ нь өөрчлөгдсөн , платформ дээр анхдагчаар ашиглагддаг бөгөөд Docker-ийг CRI-O-оор сольсон бөгөөд Кубернетестэй зэрэгцэн хөгжиж буй контейнер ажиллуулах зардал багатай, тогтвортой, энгийн бөгөөд уйтгартай орчинг санал болгож байна. Энэ нь кластерийн дэмжлэг болон тохиргоог ихээхэн хялбаршуулдаг. OpenShift 4-т чингэлэг хөдөлгүүр болон хостын тохиргоо, тэдгээрийн удирдлага автоматжуулсан болно.
Хүлээгээрэй, энэ яаж байна?
Зөв, OpenShift 4 гарч ирснээр бие даасан хостуудтай холбогдож, контейнер хөдөлгүүр суулгах, хадгалах санг тохируулах, хайлтын серверүүдийг тохируулах, сүлжээг тохируулах шаардлагагүй болсон. OpenShift 4 платформыг ашиглахын тулд бүрэн шинэчлэгдсэн Зөвхөн эцсийн хэрэглэгчийн хэрэглээний программуудын хувьд төдийгүй зураг байршуулах, системийг тохируулах, шинэчлэлт суулгах зэрэг платформын түвшний үндсэн үйлдлүүдийн хувьд.
Kubernetes нь хэрэглэгчдэд хүссэн төлөвийг тодорхойлж, ашиглах замаар програмуудыг удирдах боломжийг үргэлж олгодог , бодит төлөв нь зорилтот төлөвтэй аль болох ойр байхыг баталгаажуулах. Энэ хөгжил, үйл ажиллагааны аль алиных нь үүднээс асар их боломжийг нээж өгдөг. Хөгжүүлэгчид шаардлагатай төлөвийг тодорхойлох боломжтой YAML эсвэл JSON файл хэлбэрээр оператор руу илгээж, дараа нь оператор үйлдвэрлэлийн орчинд шаардлагатай програмын жишээг үүсгэж болох бөгөөд энэ инстанцийн үйл ажиллагааны төлөв нь заасантай бүрэн нийцэх болно.
Платформ дээр Операторуудыг ашигласнаар OpenShift 4 нь RHEL CoreOS болон CRI-O-ийн удирдлагад энэхүү шинэ парадигмыг (тогтоосон ба бодит төлөвийн ойлголтыг ашиглан) авчирдаг. Үйлдлийн систем ба контейнер хөдөлгүүрийн хувилбаруудыг тохируулах, удирдах ажлыг автоматжуулсан болно. . MCO нь кластерийн администраторын ажлыг ихээхэн хялбарчилж, үндсэндээ суулгацын сүүлийн үе шатууд, түүнчлэн суулгацын дараах дараагийн үйлдлүүдийг (хоёр дахь өдрийн ажиллагаа) автоматжуулдаг. Энэ бүхэн нь OpenShift 4-ийг жинхэнэ үүл платформ болгодог. Бид энэ талаар хэсэг хугацааны дараа ярих болно.
Ажиллаж байгаа савнууд
Хэрэглэгчид CRI-O хөдөлгүүрийг OpenShift платформ дээр 3.7 хувилбараас хойш Tech Preview төлөвт, 3.9 хувилбараас эхлэн General Available төлөвт (одоогоор дэмжигдэж байна) ашиглах боломжтой болсон. Нэмж дурдахад Red Hat-ийг их хэмжээгээр ашигладаг 3.10 хувилбараас хойш OpenShift Online дээр. Энэ бүхэн нь CRI-O дээр ажиллаж буй багт Кубернетесийн томоохон кластерууд дээр савыг бөөнөөр нь хөөргөх арвин туршлага хуримтлуулах боломжийг олгосон. Кубернетес CRI-O-г хэрхэн ашигладаг талаар үндсэн ойлголттой болохын тулд архитектур хэрхэн ажилладагийг харуулсан дараах зургийг харцгаая.
Цагаан будаа. 2. Кубернетес кластерт савнууд хэрхэн ажилладаг
CRI-O нь шинэ зангилаа эхлүүлэх болон OpenShift платформын шинэ хувилбаруудыг гаргах үед дээд түвшнийг бүхэлд нь синхрончлох замаар шинэ контейнер хост үүсгэх ажлыг хялбаршуулдаг. Платформыг бүхэлд нь шинэчлэх нь гүйлгээний шинэчлэлт/буцах боломжийг олгохоос гадна чингэлэгийн сүүлний цөм, чингэлэг хөдөлгүүр, зангилаа (Кубелец) болон Кубернетес Мастер зангилааны хоорондох хамаарал үүсэхээс сэргийлдэг. Бүх платформын бүрэлдэхүүн хэсгүүдийг хяналт, хувилбараар нь төвлөрсөн байдлаар удирдсанаар А төлөвөөс Б төлөв рүү үргэлж тодорхой зам байдаг. Энэ нь шинэчлэлтийн процессыг хялбарчилж, аюулгүй байдлыг сайжруулж, гүйцэтгэлийн тайланг сайжруулж, шинэ хувилбаруудыг шинэчлэх, суулгах зардлыг бууруулахад тусалдаг. .
Орлуулах элементүүдийн хүчийг харуулах
Өмнө дурьдсанчлан OpenShift 4 дээрх контейнерийн хост болон контейнерийн хөдөлгүүрийг удирдахын тулд Machine Config Operator-ийг ашиглах нь Kubernetes платформ дээр өмнө нь боломжгүй байсан автоматжуулалтын шинэ түвшний боломжийг олгодог. Шинэ боломжуудыг харуулахын тулд бид crio.conf файлд хэрхэн өөрчлөлт оруулахыг харуулах болно. Нэр томъёонд төөрөгдүүлэхгүйн тулд үр дүнд анхаарлаа төвлөрүүлэхийг хичээ.
Эхлээд контейнер ажиллах цагийн тохиргоо гэж нэрлэгддэг зүйлийг үүсгэцгээе - Container Runtime Config. Үүнийг CRI-O-ийн тохиргоог төлөөлдөг Kubernetes нөөц гэж бодоорой. Бодит байдал дээр энэ нь OpenShift кластерын нэг хэсэг болгон RHEL CoreOS машинд суулгасан аливаа тохиргоо болох MachineConfig нэртэй зүйлийн тусгай хувилбар юм.
ContainerRuntimeConfig гэж нэрлэгддэг энэхүү тусгай нөөцийг кластерын администраторуудад CRI-O-г тохируулахад хялбар болгох зорилгоор бүтээсэн. Энэ хэрэгсэл нь хангалттай хүчтэй тул зөвхөн MachineConfigPool тохиргооноос хамааран тодорхой цэгүүдэд ашиглах боломжтой. Үүнийг ижил зорилготой машинуудын бүлэг гэж төсөөлөөд үз дээ.
Сүүлийн хоёр мөрийг /etc/crio/crio.conf файлд өөрчлөх гэж буйг анхаарна уу. Эдгээр хоёр мөр нь crio.conf файл дахь мөрүүдтэй маш төстэй бөгөөд тэдгээр нь:
vi ContainerRuntimeConfig.yaml
Дүгнэлт:
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
Одоо энэ файлыг Kubernetes кластер руу түлхэж, үнэхээр үүсгэгдсэн эсэхийг шалгацгаая. Үйл ажиллагаа нь бусад Kubernetes нөөцтэй яг адилхан гэдгийг анхаарна уу:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Дүгнэлт:
NAME AGE
set-log-and-pid 22h
Бид ContainerRuntimeConfig-ийг үүсгэсний дараа бид энэ тохиргоог кластерын тодорхой бүлэг машинд хэрэглэхийг хүсэж байгаагаа Кубернетес рүү дохио өгөхийн тулд MachineConfigPools-ийн аль нэгийг өөрчлөх хэрэгтэй. Энэ тохиолдолд бид мастер зангилааны хувьд MachineConfigPool-г өөрчлөх болно:
oc edit MachineConfigPool/master
Дүгнэлт (тодорхой болгохын тулд гол мөн чанарыг нь үлдээсэн болно):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Энэ үед МСО нь кластерт зориулж шинэ crio.conf файл үүсгэж эхэлдэг. Энэ тохиолдолд бүрэн дууссан тохиргооны файлыг Kubernetes API ашиглан үзэх боломжтой. ContainerRuntimeConfig бол MachineConfig-ийн тусгай хувилбар учраас бид MachineConfigs-ийн холбогдох мөрүүдийг харснаар үр дүнг харах боломжтой гэдгийг санаарай.
oc get MachineConfigs | grep rendered
Дүгнэлт:
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
Мастер зангилааны тохиргооны файл нь анхны тохиргооноос шинэ хувилбар байсныг анхаарна уу. Үүнийг үзэхийн тулд дараах тушаалыг ажиллуулна уу. Энэ нь магадгүй Кубернетесийн түүхэн дэх хамгийн шилдэг нэг тоглогчдын нэг гэдгийг бид тэмдэглэж байна.
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
Дүгнэлт:
pids_limit = 2048
Одоо тохиргоог бүх мастер зангилаанд ашигласан эсэхийг шалгацгаая. Эхлээд бид кластер дахь зангилааны жагсаалтыг авна.
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
Одоо суулгасан файлыг харцгаая. ContainerRuntimeConfig нөөцөд бидний заасан pid болон дибаг хийх удирдамжийн шинэ утгуудаар файл шинэчлэгдсэнийг та харах болно. Дэгжин байдал өөрөө:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Дүгнэлт:
...
pids_limit = 2048
...
log_level = "debug"
...
Кластерт хийсэн эдгээр бүх өөрчлөлтийг SSH ажиллуулахгүйгээр хийсэн. Kuberentes мастер зангилаа руу нэвтрэх замаар бүх ажлыг хийсэн. Өөрөөр хэлбэл, эдгээр шинэ параметрүүдийг зөвхөн мастер зангилаанууд дээр тохируулсан болно. Ажилчны зангилаа өөрчлөгдөөгүй бөгөөд энэ нь сольж болох элементүүдтэй контейнерийн хостууд болон чингэлэг хөдөлгүүртэй холбоотой тодорхой болон бодит төлөвийг ашиглах Кубернетес аргачлалын ашиг тусыг харуулж байна.
Дээрх жишээ нь үйлдвэрлэлийн гурван зангилаа бүхий жижиг OpenShift Container Platform 4 кластер эсвэл 3000 зангилаа бүхий асар том үйлдвэрлэлийн кластерт өөрчлөлт хийх чадварыг харуулж байна. Ямар ч тохиолдолд ажлын хэмжээ ижил бөгөөд маш бага байх болно - ContainerRuntimeConfig файлыг тохируулаад MachineConfigPool доторх нэг шошгыг өөрчлөхөд л хангалттай. Та үүнийг амьдралынхаа туршид Kubernetes-ийг ажиллуулж буй OpenShift Container Platform 4.X-ийн аль ч хувилбараар хийж болно.
Технологийн компаниуд ихэвчлэн маш хурдан хөгжиж байгаа тул бид яагаад үндсэн бүрэлдэхүүн хэсгүүдийн зарим технологийг сонгохдоо тайлбарлаж чадахгүй. Чингэлэг хөдөлгүүрүүд нь түүхэндээ хэрэглэгчид шууд харьцдаг бүрэлдэхүүн хэсэг байсаар ирсэн. Савны алдар нэр нь чингэлэг хөдөлгүүр гарч ирснээр аяндаа эхэлсэн тул хэрэглэгчид үүнийг ихэвчлэн сонирхдог. Энэ нь Red Hat-ийг CRI-O-г сонгосон бас нэг шалтгаан юм. Контейнерууд одоо найрал хөгжимд анхаарлаа хандуулж хөгжиж байгаа бөгөөд CRI-O нь OpenShift 4-тэй ажиллахад хамгийн сайн туршлагыг өгдөг болохыг бид олж мэдсэн.
Эх сурвалж: www.habr.com
