კონტეინერი კონვეიერამდე: CRI-O ახლა ნაგულისხმევია OpenShift Container Platform 4-ში

პლატფორმა Red Hat OpenShift კონტეინერების პლატფორმა 4 საშუალებას გაძლევთ გაამარტივოთ შექმნა მასპინძლები კონტეინერების განლაგებისთვის, მათ შორის ღრუბლოვანი სერვისის პროვაიდერების ინფრასტრუქტურაში, ვირტუალიზაციის პლატფორმებზე ან შიშველი ლითონის სისტემებში. ჭეშმარიტად ღრუბელზე დაფუძნებული პლატფორმის შესაქმნელად, ჩვენ უნდა აგვეღო მკაცრი კონტროლი გამოყენებული ყველა ელემენტზე და ამით გავზარდოთ კომპლექსური ავტომატიზაციის პროცესის საიმედოობა.

აშკარა გამოსავალი იყო Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux-ის ვარიანტი) და CRI-O სტანდარტად გამოყენება და აი რატომ...

იმის გამო, რომ ნაოსნობის თემა ძალიან კარგია კუბერნეტების და კონტეინერების მუშაობის ახსნისას ანალოგიების მოსაძებნად, შევეცადოთ ვისაუბროთ ბიზნეს პრობლემებზე, რომლებსაც CoreOS და CRI-O წყვეტენ მაგალითის გამოყენებით. ბრუნელის გამოგონებები გაყალბების ბლოკების წარმოებისთვის. 1803 წელს მარკ ბრუნელს დაევალა 100 გაყალბებული ბლოკის წარმოება მზარდი ბრიტანეთის საზღვაო ფლოტის საჭიროებისთვის. გაყალბების ბლოკი არის გაყალბების სახეობა, რომელიც გამოიყენება იალქნებზე თოკების დასამაგრებლად. მე-19 საუკუნის დასაწყისამდე ეს ბლოკები მზადდებოდა ხელით, მაგრამ ბრუნელმა მოახერხა წარმოების ავტომატიზაცია და დაიწყო სტანდარტიზებული ბლოკების წარმოება ჩარხების გამოყენებით. ამ პროცესის ავტომატიზაცია ნიშნავს, რომ შედეგად მიღებული ბლოკები არსებითად იდენტური იყო, ადვილად შეიცვლებოდა გატეხვის შემთხვევაში და შეიძლება დიდი რაოდენობით წარმოებულიყო.

ახლა წარმოიდგინეთ, თუ ბრუნელს ეს სამუშაო უნდა გაეკეთებინა 20 სხვადასხვა გემის მოდელისთვის (Kubernetes ვერსიები) და ხუთი განსხვავებული პლანეტისთვის სრულიად განსხვავებული ზღვის დინებითა და ქარით (ღრუბლების პროვაიდერები). გარდა ამისა, საჭირო იყო, რომ ყველა ხომალდი (OpenShift კლასტერები), მიუხედავად პლანეტებისა, რომლებზეც ნავიგაცია ხორციელდება, კაპიტნების (ოპერატორები, რომლებიც მართავენ მტევანთა მუშაობას) ერთნაირად მოქცეულიყვნენ. საზღვაო ანალოგიის გასაგრძელებლად, გემების კაპიტანებს საერთოდ არ აინტერესებთ, თუ როგორი გაყალბების ბლოკები (CRI-O) გამოიყენება მათ გემებზე - მათთვის მთავარია, რომ ეს ბლოკები იყოს ძლიერი და საიმედო.

OpenShift 4, როგორც ღრუბლოვანი პლატფორმა, ძალიან მსგავსი ბიზნეს გამოწვევის წინაშე დგას. ახალი კვანძები უნდა შეიქმნას კლასტერის შექმნის დროს, ერთ-ერთ კვანძში წარუმატებლობის შემთხვევაში ან კლასტერის მასშტაბირებისას. როდესაც ახალი კვანძი იქმნება და ინიციალიზდება, კრიტიკული ჰოსტის კომპონენტები, მათ შორის CRI-O, შესაბამისად უნდა იყოს კონფიგურირებული. როგორც ნებისმიერ სხვა წარმოებაში, „ნედლეულის“ მიწოდება თავიდანვე უნდა მოხდეს. გემების შემთხვევაში ნედლეული ლითონი და ხეა. თუმცა, OpenShift 4 კლასტერში კონტეინერების განლაგებისთვის ჰოსტის შექმნის შემთხვევაში, თქვენ უნდა გქონდეთ კონფიგურაციის ფაილები და API-ით მოწოდებული სერვერები, როგორც შეყვანის სახით. შემდეგ OpenShift უზრუნველყოფს ავტომატიზაციის საჭირო დონეს მთელი სასიცოცხლო ციკლის განმავლობაში, შესთავაზებს პროდუქტის აუცილებელ მხარდაჭერას საბოლოო მომხმარებლებს და ამით ანაზღაურებს ინვესტიციას პლატფორმაში.

OpenShift 4 შეიქმნა ისე, რომ უზრუნველყოს სისტემის მოხერხებულად განახლების შესაძლებლობა პლატფორმის მთელი სასიცოცხლო ციკლის განმავლობაში (4.X ვერსიებისთვის) ყველა ძირითადი ღრუბლოვანი გამოთვლითი პროვაიდერისთვის, ვირტუალიზაციის პლატფორმებისთვის და თუნდაც შიშველი ლითონის სისტემებისთვის. ამისათვის კვანძები უნდა შეიქმნას ურთიერთშემცვლელი ელემენტების საფუძველზე. როდესაც კლასტერს სჭირდება Kubernetes-ის ახალი ვერსია, ის ასევე იღებს CRI-O-ს შესაბამის ვერსიას CoreOS-ზე. ვინაიდან CRI-O ვერსია პირდაპირ არის მიბმული Kubernetes-თან, ეს მნიშვნელოვნად ამარტივებს ტესტირების, პრობლემების აღმოფხვრის ან მხარდაჭერის მიზნებისთვის ნებისმიერ ცვლილებას. გარდა ამისა, ეს მიდგომა ამცირებს ხარჯებს საბოლოო მომხმარებლებისა და Red Hat-ისთვის.

ეს არის ფუნდამენტურად ახალი აზროვნების გზა Kubernetes კლასტერების შესახებ და უყრის საფუძველს რამდენიმე ძალიან სასარგებლო და დამაჯერებელი ახალი ფუნქციების დაგეგმვისთვის. CRI-O (Container Runtime Interface - Open Container Initiative, შემოკლებით CRI-OCI) აღმოჩნდა ყველაზე წარმატებული არჩევანი კვანძების მასობრივი შექმნისთვის, რაც აუცილებელია OpenShift-თან მუშაობისთვის. CRI-O ჩაანაცვლებს ადრე გამოყენებულ Docker ძრავას, სთავაზობს OpenShift მომხმარებლებს ეკონომიური, სტაბილური, მარტივი და მოსაწყენი - დიახ, სწორად გსმენიათ - მოსაწყენი კონტეინერის ძრავა შექმნილია სპეციალურად Kubernetes-თან მუშაობისთვის.

ღია კონტეინერების სამყარო

მსოფლიო დიდი ხანია ღია კონტეინერებისკენ მიიწევს. კუბერნეტში თუ დაბალ დონეზე, კონტეინერის სტანდარტების შემუშავება იწვევს ინოვაციების ეკოსისტემას ყველა დონეზე.

ყველაფერი ღია კონტეინერების ინიციატივის შექმნით დაიწყო 2015 წლის ივნისში. მუშაობის ამ ადრეულ ეტაპზე ჩამოყალიბდა კონტეინერის სპეციფიკაციები გამოსახულება и გაშვების გარემო. ეს უზრუნველყოფდა, რომ ხელსაწყოებს შეეძლოთ ერთი სტანდარტის გამოყენება კონტეინერის სურათები და მათთან მუშაობის ერთიანი ფორმატი. სპეციფიკაციები მოგვიანებით დაემატა განაწილება, რაც მომხმარებლებს საშუალებას აძლევს ადვილად გააზიარონ კონტეინერის სურათები.

შემდეგ Kubernetes-ის საზოგადოებამ შეიმუშავა ერთი სტანდარტი ჩამრთველი ინტერფეისისთვის, ე.წ კონტეინერის გაშვების ინტერფეისი (CRI). ამის წყალობით Kubernetes-ის მომხმარებლებმა შეძლეს Docker-ის გარდა სხვადასხვა ძრავების დაკავშირება კონტეინერებთან მუშაობისთვის.

Red Hat-ისა და Google-ის ინჟინრებმა დაინახეს საბაზრო საჭიროება კონტეინერის ძრავისთვის, რომელსაც შეეძლო მიეღო Kubelet-ის მოთხოვნები CRI პროტოკოლით და წარმოადგინეს კონტეინერები, რომლებიც თავსებადი იყო OCI-ის ზემოთ აღნიშნულ სპეციფიკაციებთან. Ისე OCID გამოჩნდა. მაგრამ მაპატიეთ, არ ვთქვით, რომ ეს მასალა დაეთმობა CRI-O-ს? სინამდვილეში ასეა, მხოლოდ გამოშვებით ვერსია 1.0 პროექტს ეწოდა CRI-O.

Fig. 1.

ინოვაცია CRI-O და CoreOS-ით

OpenShift 4 პლატფორმის გაშვებით, ის შეიცვალა კონტეინერის ძრავა, ნაგულისხმევად გამოყენებული პლატფორმაში და Docker შეიცვალა CRI-O-ით, რომელიც გვთავაზობდა ეკონომიურ, სტაბილურ, მარტივ და მოსაწყენ გარემოს კონტეინერის გასაშვებად, რომელიც ვითარდება Kubernetes-ის პარალელურად. ეს მნიშვნელოვნად ამარტივებს კლასტერების მხარდაჭერას და კონფიგურაციას. კონტეინერის ძრავისა და ჰოსტის კონფიგურაცია, ისევე როგორც მათი მართვა, ხდება ავტომატიზირებული OpenShift 4-ში.

მოიცადე, როგორ არის ეს?

ეს ასეა, OpenShift 4-ის მოსვლასთან ერთად აღარ არის საჭირო ცალკეულ ჰოსტებთან დაკავშირება და კონტეინერის ძრავის დაყენება, შენახვის კონფიგურაცია, საძიებო სერვერების კონფიგურაცია ან ქსელის კონფიგურაცია. OpenShift 4 პლატფორმა მთლიანად გადაკეთებულია იმისათვის, რომ გამოიყენოთ იგი ოპერატორის ჩარჩო არა მხოლოდ საბოლოო მომხმარებლის აპლიკაციების თვალსაზრისით, არამედ პლატფორმის დონის ძირითადი ოპერაციების თვალსაზრისითაც, როგორიცაა სურათების დაყენება, სისტემის კონფიგურაცია ან განახლებების ინსტალაცია.

Kubernetes ყოველთვის საშუალებას აძლევს მომხმარებლებს მართონ აპლიკაციები სასურველი მდგომარეობის განსაზღვრით და გამოყენებით კონტროლერები, რათა უზრუნველყოს, რომ რეალური მდგომარეობა მაქსიმალურად ემთხვევა სამიზნე მდგომარეობას. ეს სამიზნე სახელმწიფო და ფაქტობრივი სახელმწიფო მიდგომა ხსნის დიდ შესაძლებლობებს როგორც განვითარების, ასევე ოპერაციების პერსპექტივიდან. დეველოპერებს შეუძლიათ განსაზღვრონ საჭირო მდგომარეობა გადაეცით ოპერატორს YAML ან JSON ფაილის სახით და შემდეგ ოპერატორს შეუძლია შექმნას აპლიკაციის საჭირო ინსტანცია საწარმოო გარემოში და ამ ინსტანციის ოპერაციული მდგომარეობა სრულად შეესაბამებოდეს მითითებულს.

პლატფორმაზე ოპერატორების გამოყენებით, OpenShift 4 შემოაქვს ამ ახალ პარადიგმას (სიმრავლის და ფაქტობრივი მდგომარეობის კონცეფციის გამოყენებით) RHEL CoreOS-ისა და CRI-O-ის მენეჯმენტში. ოპერაციული სისტემის და კონტეინერის ძრავის ვერსიების კონფიგურაციისა და მართვის ამოცანები ავტომატიზირებულია ე.წ. მანქანის კონფიგურაციის ოპერატორი (MCO). MCO მნიშვნელოვნად ამარტივებს კლასტერის ადმინისტრატორის მუშაობას, არსებითად ავტომატიზირებს ინსტალაციის ბოლო ეტაპებს, ისევე როგორც შემდგომ ინსტალაციის შემდგომ ოპერაციებს (ოპერაციები მეორე დღეს). ეს ყველაფერი OpenShift 4-ს ნამდვილ ღრუბლოვან პლატფორმად აქცევს. ამას ცოტა მოგვიანებით შევეხებით.

გაშვებული კონტეინერები

მომხმარებლებს საშუალება ჰქონდათ გამოეყენებინათ CRI-O ძრავა OpenShift პლატფორმაში 3.7 ვერსიიდან Tech Preview სტატუსში და 3.9 ვერსიიდან Generally Available სტატუსში (ამჟამად მხარდაჭერილი). გარდა ამისა, Red Hat მასიურად იყენებს CRI-O წარმოების დატვირთვისთვის OpenShift Online-ში 3.10 ვერსიიდან. ამ ყველაფერმა საშუალება მისცა CRI-O-ზე მომუშავე გუნდს მიეღო დიდი გამოცდილება კუბერნეტის დიდ კლასტერებზე კონტეინერების მასობრივი გაშვების საქმეში. იმისათვის, რომ გავიგოთ, თუ როგორ იყენებს Kubernetes CRI-O-ს, მოდით შევხედოთ შემდეგ ილუსტრაციას, რომელიც გვიჩვენებს, თუ როგორ მუშაობს არქიტექტურა.

ბრინჯი. 2. როგორ მუშაობს კონტეინერები კუბერნეტის კლასტერში

CRI-O ამარტივებს ახალი კონტეინერის ჰოსტების შექმნას მთელი ზედა დონის სინქრონიზაციის გზით ახალი კვანძების ინიციალიზაციისას და OpenShift პლატფორმის ახალი ვერსიების გამოშვებისას. მთელი პლატფორმის გადახედვა საშუალებას იძლევა ტრანზაქციის განახლებები/დაბრუნებები და ასევე თავიდან აიცილებს ჩიხებს კონტეინერის კუდის ბირთვს, კონტეინერის ძრავას, კვანძებს (Kubelets) და Kubernetes Master კვანძს შორის. პლატფორმის ყველა კომპონენტის ცენტრალიზებული მართვით, კონტროლით და ვერსიებით, ყოველთვის არის ნათელი გზა A მდგომარეობიდან B მდგომარეობამდე. ეს ამარტივებს განახლების პროცესს, აუმჯობესებს უსაფრთხოებას, აუმჯობესებს შესრულების მოხსენებას და ეხმარება შეამციროს განახლებებისა და ახალი ვერსიების ინსტალაციის ღირებულება. .

შემცვლელი ელემენტების სიმძლავრის დემონსტრირება

როგორც უკვე აღვნიშნეთ, Machine Config ოპერატორის გამოყენება კონტეინერის ჰოსტისა და კონტეინერის ძრავის სამართავად OpenShift 4-ში უზრუნველყოფს ავტომატიზაციის ახალ დონეს, რომელიც ადრე შეუძლებელი იყო Kubernetes-ის პლატფორმაზე. ახალი ფუნქციების საჩვენებლად, ჩვენ გაჩვენებთ, თუ როგორ შეგიძლიათ ცვლილებების შეტანა crio.conf ფაილში. ტერმინოლოგიით დაბნევის თავიდან ასაცილებლად, შეეცადეთ ყურადღება გაამახვილოთ შედეგებზე.

პირველი, მოდით შევქმნათ რასაც ეწოდება კონტეინერის გაშვების კონფიგურაცია - Container Runtime Config. იფიქრეთ მასზე, როგორც Kubernetes-ის რესურსზე, რომელიც წარმოადგენს CRI-O-ს კონფიგურაციას. სინამდვილეში, ეს არის MachineConfig-ის სპეციალიზებული ვერსია, რომელიც არის ნებისმიერი კონფიგურაცია, რომელიც განლაგებულია RHEL CoreOS აპარატზე, როგორც OpenShift კლასტერის ნაწილი.

ეს მორგებული რესურსი, სახელწოდებით 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, ჩვენ უნდა შევცვალოთ MachineConfigPool-ებიდან ერთ-ერთი, რათა მივცეთ სიგნალი Kubernetes-ს, რომ გვინდა გამოვიყენოთ ეს კონფიგურაცია კლასტერში მანქანების კონკრეტულ ჯგუფზე. ამ შემთხვევაში ჩვენ შევცვლით 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: ""
...

ამ ეტაპზე, MCO იწყებს ახალი 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

ახლა ვნახოთ დაინსტალირებული ფაილი. თქვენ ნახავთ, რომ ფაილი განახლდა ახალი მნიშვნელობებით pid და გამართვის დირექტივებისთვის, რომლებიც ჩვენ მითითებულია ContainerRuntimeConfig რესურსში. თავად ელეგანტურობა:

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 Master Node-ზე წვდომით. ანუ, ეს ახალი პარამეტრები კონფიგურირებული იყო მხოლოდ მთავარ კვანძებზე. მუშათა კვანძები არ შეცვლილა, რაც აჩვენებს Kubernetes-ის მეთოდოლოგიის სარგებელს კონტეინერების მასპინძლებთან და ურთიერთშემცვლელი ელემენტებით კონტეინერის ძრავებთან მიმართებაში მითითებული და ფაქტობრივი მდგომარეობის გამოყენებისას.

ზემოთ მოყვანილი მაგალითი გვიჩვენებს მცირე OpenShift Container Platform 4 კლასტერში ცვლილებების შეტანის შესაძლებლობას სამი წარმოების კვანძით ან უზარმაზარი წარმოების კლასტერში 3000 კვანძით. ნებისმიერ შემთხვევაში, სამუშაოს მოცულობა იგივე იქნება - და ძალიან მცირე - უბრალოდ დააკონფიგურირეთ ContainerRuntimeConfig ფაილი და შეცვალეთ ერთი ეტიკეტი MachineConfigPool-ში. და ამის გაკეთება შეგიძლიათ OpenShift Container Platform 4.X-ის ნებისმიერი ვერსიით, რომელიც მუშაობს Kubernetes-ის მთელი სიცოცხლის ციკლის განმავლობაში.

ხშირად ტექნოლოგიური კომპანიები ისე სწრაფად ვითარდებიან, რომ ჩვენ ვერ ავხსნით, რატომ ვირჩევთ გარკვეულ ტექნოლოგიებს ძირითადი კომპონენტებისთვის. კონტეინერის ძრავები ისტორიულად იყო ის კომპონენტი, რომელთანაც მომხმარებლები უშუალოდ ურთიერთობენ. მას შემდეგ, რაც კონტეინერების პოპულარობა ბუნებრივად დაიწყო კონტეინერის ძრავების გამოჩენით, მომხმარებლები ხშირად იჩენენ ინტერესს მათ მიმართ. ეს არის კიდევ ერთი მიზეზი, რის გამოც Red Hat აირჩია CRI-O. კონტეინერები ვითარდება ახლა ორკესტრირებაზე ორიენტირებული და ჩვენ აღმოვაჩინეთ, რომ CRI-O უზრუნველყოფს საუკეთესო გამოცდილებას OpenShift 4-თან მუშაობისას.

წყარო: www.habr.com