Платформ
Үүний ойлгомжтой шийдэл бол Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux-ийн хувилбар) болон CRI-O-г стандарт болгон ашиглах явдал байсан бөгөөд эндээс...
Дарвуулт завины сэдэв нь Кубернетес болон контейнерийн ажлыг тайлбарлахдаа аналоги олоход маш сайн сэдэв тул CoreOS болон CRI-O-ийн шийддэг бизнесийн асуудлын талаар жишээн дээр ярихыг хичээцгээе.
Брунел энэ ажлыг 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 хөдөлгүүрийг солих болно
Нээлттэй савны ертөнц
Дэлхий задгай чингэлэг рүү шилжих болсоор удаж байна. Кубернетес эсвэл доод түвшний аль нь ч бай,
Энэ бүхэн "Нээлттэй контейнер" санаачилгыг бий болгосноор эхэлсэн
Дараа нь Кубернетес нийгэмлэг нь залгах боломжтой интерфейсийн нэгдсэн стандартыг боловсруулсан
Red Hat болон Google-ийн инженерүүд CRI протоколоор Kubelet-ийн хүсэлтийг хүлээн авч чадах чингэлэг хөдөлгүүртэй болох зах зээлийн хэрэгцээг олж харж, дээр дурдсан OCI техникийн үзүүлэлтүүдтэй нийцсэн контейнеруудыг нэвтрүүлсэн. Тэгэхээр
Зураг: арван тав.
CRI-O болон CoreOS бүхий инноваци
OpenShift 4 платформ гарч ирснээр энэ нь өөрчлөгдсөн
Хүлээгээрэй, энэ яаж байна?
Зөв, OpenShift 4 гарч ирснээр бие даасан хостуудтай холбогдож, контейнер хөдөлгүүр суулгах, хадгалах санг тохируулах, хайлтын серверүүдийг тохируулах, сүлжээг тохируулах шаардлагагүй болсон. OpenShift 4 платформыг ашиглахын тулд бүрэн шинэчлэгдсэн
Kubernetes нь хэрэглэгчдэд хүссэн төлөвийг тодорхойлж, ашиглах замаар програмуудыг удирдах боломжийг үргэлж олгодог
Платформ дээр Операторуудыг ашигласнаар OpenShift 4 нь RHEL CoreOS болон CRI-O-ийн удирдлагад энэхүү шинэ парадигмыг (тогтоосон ба бодит төлөвийн ойлголтыг ашиглан) авчирдаг. Үйлдлийн систем ба контейнер хөдөлгүүрийн хувилбаруудыг тохируулах, удирдах ажлыг автоматжуулсан болно.
Ажиллаж байгаа савнууд
Хэрэглэгчид CRI-O хөдөлгүүрийг OpenShift платформ дээр 3.7 хувилбараас хойш Tech Preview төлөвт, 3.9 хувилбараас эхлэн General Available төлөвт (одоогоор дэмжигдэж байна) ашиглах боломжтой болсон. Нэмж дурдахад Red Hat-ийг их хэмжээгээр ашигладаг
Цагаан будаа. 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