Platforma yaradılmasını sadələşdirməyə imkan verir , o cümlədən bulud xidməti təminatçılarının infrastrukturunda, virtualizasiya platformalarında və ya çılpaq metal sistemlərdə. Həqiqətən bulud əsaslı platforma yaratmaq üçün istifadə olunan bütün elementlərə ciddi nəzarət etməli və beləliklə də mürəkkəb avtomatlaşdırma prosesinin etibarlılığını artırmalı olduq.
Aşkar həll yolu Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux-un bir variantı) və CRI-O-dan standart olaraq istifadə etmək idi və buna görə də...
Yelkən mövzusu Kubernetes və konteynerlərin işini izah edərkən bənzətmələr tapmaq üçün çox yaxşı mövzu olduğundan, bir misaldan istifadə edərək CoreOS və CRI-O-nun həll etdiyi biznes problemlərindən danışmağa çalışaq. . 1803-cü ildə Mark Brunelə artan İngilis donanmasının ehtiyacları üçün 100 dəzgah istehsal etmək tapşırığı verildi. Arma blok, yelkənlərə iplər bağlamaq üçün istifadə olunan bir armatur növüdür. 19-cu əsrin əvvəllərinə qədər bu bloklar əl ilə hazırlanırdı, lakin Brunel istehsalı avtomatlaşdırmağa müvəffəq oldu və dəzgahlardan istifadə edərək standartlaşdırılmış bloklar istehsal etməyə başladı. Bu prosesin avtomatlaşdırılması nəticədə yaranan blokların mahiyyətcə eyni olması, qırıldığı təqdirdə asanlıqla dəyişdirilə və böyük miqdarda istehsal oluna bilməsi demək idi.
İndi təsəvvür edin ki, Brunel 20 müxtəlif gəmi modeli (Kubernetes versiyaları) və tamamilə fərqli dəniz axınları və küləkləri olan beş fərqli planet (bulud provayderləri) üçün bu işi görməli idi. Bundan əlavə, kapitanların (klasterlərin işini idarə edən operatorların) nöqteyi-nəzərindən naviqasiyanın həyata keçirildiyi planetlərdən asılı olmayaraq, bütün gəmilərdən (OpenShift klasterlərindən) eyni davranması tələb olunurdu. Dəniz bənzətməsini davam etdirmək üçün gəmi kapitanları gəmilərində hansı armatur bloklarından (CRI-O) istifadə olunduğuna heç əhəmiyyət vermirlər - onlar üçün əsas odur ki, bu bloklar möhkəm və etibarlıdır.
OpenShift 4, bulud platforması olaraq, çox oxşar iş problemi ilə üzləşir. Yeni qovşaqlar klasterin yaradılması zamanı, qovşaqlardan birində nasazlıq olduqda və ya klasterin miqyası dəyişdirilərkən yaradılmalıdır. Yeni node yaradıldıqda və işə salındıqda, CRI-O daxil olmaqla, kritik host komponentləri müvafiq olaraq konfiqurasiya edilməlidir. Hər hansı digər istehsalatda olduğu kimi, ilkin mərhələdə “xammal” tədarük edilməlidir. Gəmilərdə xammal metal və ağacdır. Bununla belə, OpenShift 4 klasterində konteynerlərin yerləşdirilməsi üçün host yaratmaq vəziyyətində, giriş kimi konfiqurasiya fayllarına və API tərəfindən təmin edilmiş serverlərə sahib olmalısınız. OpenShift daha sonra bütün həyat dövrü ərzində tələb olunan avtomatlaşdırma səviyyəsini təmin edəcək, son istifadəçilərə lazımi məhsul dəstəyi təklif edəcək və bununla da platformaya qoyulan sərmayəni geri qaytaracaq.
OpenShift 4 bütün əsas bulud hesablama provayderləri, virtuallaşdırma platformaları və hətta çılpaq metal sistemlər üçün platformanın bütün həyat dövrü ərzində (4.X versiyaları üçün) sistemi rahat şəkildə yeniləmək imkanı verəcək şəkildə yaradılmışdır. Bunun üçün dəyişdirilə bilən elementlər əsasında qovşaqlar yaradılmalıdır. Klaster Kubernetes-in yeni versiyasını tələb etdikdə, CoreOS-da CRI-O-nun müvafiq versiyasını da alır. CRI-O versiyası birbaşa Kubernetes-ə bağlandığından, bu, sınaq, problemlərin aradan qaldırılması və ya dəstək məqsədləri üçün hər hansı dəyişdirməni xeyli asanlaşdırır. Bundan əlavə, bu yanaşma son istifadəçilər və Red Hat üçün xərcləri azaldır.
Bu, Kubernetes klasterləri haqqında tamamilə yeni düşüncə tərzidir və bəzi çox faydalı və cəlbedici yeni funksiyaların planlaşdırılması üçün təməl qoyur. CRI-O (Container Runtime Interface - Open Container Initiative, qısaldılmış CRI-OCI) OpenShift ilə işləmək üçün zəruri olan qovşaqların kütləvi yaradılması üçün ən uğurlu seçim oldu. CRI-O OpenShift istifadəçilərinə əvvəllər istifadə edilən Docker mühərrikini əvəz edəcək – bəli, düz eşitdiniz – xüsusi olaraq Kubernetes ilə işləmək üçün yaradılmış darıxdırıcı konteyner mühərriki.
Açıq konteynerlər dünyası
Dünya uzun müddətdir ki, açıq konteynerlərə doğru irəliləyir. İstər Kubernetesdə, istərsə də aşağı səviyyələrdə, hər səviyyədə innovasiya ekosistemi ilə nəticələnir.
Hər şey Açıq Konteynerlər Təşəbbüsünün yaradılması ilə başladı . İşin bu ilk mərhələsində konteyner spesifikasiyalar formalaşdırıldı и . Bu, alətlərin vahid standartdan istifadə edə bilməsini təmin etdi və onlarla işləmək üçün vahid format. Spesifikasiyalar sonradan əlavə edildi , istifadəçilərə asanlıqla paylaşmağa imkan verir .
Kubernetes icması daha sonra qoşula bilən interfeys üçün vahid standart hazırladı . Bunun sayəsində Kubernetes istifadəçiləri Docker-ə əlavə olaraq konteynerlərlə işləmək üçün müxtəlif mühərrikləri birləşdirə bildilər.
Red Hat və Google-dakı mühəndislər bazarda CRI protokolu üzərindən Kubelet sorğularını qəbul edə bilən konteyner mühərrikinə ehtiyac olduğunu gördülər və yuxarıda qeyd olunan OCI spesifikasiyasına uyğun konteynerlər təqdim etdilər. Belə ki . Bağışlayın, bu materialın CRI-O-ya həsr olunacağını demədikmi? Əslində bu, yalnız buraxılışla layihə CRI-O adlandırıldı.
Fig. 1.
CRI-O və CoreOS ilə innovasiya
OpenShift 4 platformasının istifadəyə verilməsi ilə o dəyişdirildi , platformada standart olaraq istifadə olunur və Docker, Kubernetes ilə paralel olaraq inkişaf edən bir konteyneri idarə etmək üçün sərfəli, sabit, sadə və darıxdırıcı bir mühit təklif edərək CRI-O ilə əvəz edildi. Bu, klaster dəstəyini və konfiqurasiyasını xeyli asanlaşdırır. Konteyner mühərrikinin və hostun konfiqurasiyası, eləcə də onların idarə edilməsi OpenShift 4-də avtomatlaşdırılır.
Gözləyin, bu necədir?
Düzdü, OpenShift 4-ün gəlişi ilə artıq fərdi hostlara qoşulmağa və konteyner mühərriki quraşdırmaq, yaddaşı konfiqurasiya etmək, axtarış serverlərini konfiqurasiya etmək və ya şəbəkəni konfiqurasiya etməyə ehtiyac qalmır. OpenShift 4 platforması istifadə etmək üçün tamamilə yenidən işlənib təkcə son istifadəçi proqramları baxımından deyil, həm də şəkillərin yerləşdirilməsi, sistemin konfiqurasiyası və ya yeniləmələrin quraşdırılması kimi əsas platforma səviyyəli əməliyyatlar baxımından.
Kubernetes həmişə istifadəçilərə istənilən vəziyyəti təyin etməklə və istifadə etməklə tətbiqləri idarə etməyə icazə verib , faktiki vəziyyətin hədəf vəziyyətə mümkün qədər yaxından uyğun olmasını təmin etmək. Bu həm inkişaf, həm də əməliyyatlar baxımından böyük imkanlar açır. Tərtibatçılar tələb olunan vəziyyəti müəyyən edə bilərlər operatora YAML və ya JSON faylı şəklində göndərir və sonra operator istehsal mühitində tələb olunan tətbiq nümunəsini yarada bilər və bu instansiyanın iş vəziyyəti göstərilənə tam uyğun olacaq.
Platformada Operatorlardan istifadə etməklə OpenShift 4 bu yeni paradiqmanı (dəst və faktiki vəziyyət anlayışından istifadə etməklə) RHEL CoreOS və CRI-O idarəetməsinə gətirir. Əməliyyat sisteminin və konteyner mühərrikinin versiyalarının konfiqurasiyası və idarə edilməsi vəzifələri sözdə istifadə edərək avtomatlaşdırılır. . MCO klaster inzibatçısının işini xeyli asanlaşdırır, mahiyyətcə quraşdırmanın son mərhələlərini, eləcə də quraşdırmadan sonrakı sonrakı əməliyyatları (ikinci gün əməliyyatları) avtomatlaşdırır. Bütün bunlar OpenShift 4-ü əsl bulud platformasına çevirir. Bu məsələyə bir az sonra girəcəyik.
İşləyən konteynerlər
İstifadəçilər CRI-O mühərrikindən OpenShift platformasında Tech Preview statusunda 3.7 versiyasından və Ümumi Mövcud statusunda 3.9 versiyasından (hazırda dəstəklənir) istifadə etmək imkanı əldə ediblər. Bundan əlavə, Red Hat kütləvi şəkildə istifadə edir 3.10 versiyasından bəri OpenShift Online-da. Bütün bunlar CRI-O üzərində işləyən komandaya böyük Kubernetes klasterlərində konteynerlərin kütləvi buraxılması üzrə geniş təcrübə qazanmağa imkan verdi. Kubernetesin CRI-O-dan necə istifadə etdiyinə dair əsas anlayışı əldə etmək üçün arxitekturanın necə işlədiyini göstərən aşağıdakı təsvirə baxaq.
düyü. 2. Konteynerlər Kubernetes klasterində necə işləyir
CRI-O, yeni qovşaqları işə salarkən və OpenShift platformasının yeni versiyalarını buraxarkən bütün üst səviyyəni sinxronlaşdırmaqla yeni konteyner hostlarının yaradılmasını asanlaşdırır. Bütün platformanın yenidən nəzərdən keçirilməsi əməliyyat yeniləmələrinə/geri dönmələrə imkan verir, həmçinin konteyner quyruğu nüvəsi, konteyner mühərriki, qovşaqlar (Kubelets) və Kubernetes Master qovşağı arasındakı asılılıqlarda kilidlərin qarşısını alır. Nəzarət və versiya ilə bütün platforma komponentlərini mərkəzləşdirilmiş şəkildə idarə etməklə, A vəziyyətindən B vəziyyətinə həmişə aydın bir yol var. Bu, yeniləmə prosesini asanlaşdırır, təhlükəsizliyi artırır, performans hesabatını yaxşılaşdırır və yeni versiyaların yeniləmələri və quraşdırılması xərclərini azaltmağa kömək edir. .
Əvəzedici elementlərin gücünü nümayiş etdirmək
Daha əvvəl qeyd edildiyi kimi, OpenShift 4-də konteyner hostunu və konteyner mühərrikini idarə etmək üçün Maşın Konfiqurasiya Operatorundan istifadə Kubernetes platformasında əvvəllər mümkün olmayan yeni avtomatlaşdırma səviyyəsini təmin edir. Yeni funksiyaları nümayiş etdirmək üçün crio.conf faylına necə dəyişiklik edə biləcəyinizi göstərəcəyik. Terminologiya ilə qarışmamaq üçün nəticələrə diqqət yetirməyə çalışın.
Əvvəlcə konteynerin işləmə vaxtı konfiqurasiyası adlanan şeyi yaradaq - Container Runtime Config. Bunu CRI-O üçün konfiqurasiyanı təmsil edən Kubernetes resursu kimi düşünün. Reallıqda bu, OpenShift klasterinin bir hissəsi kimi RHEL CoreOS maşınına yerləşdirilən istənilən konfiqurasiya olan MachineConfig adlı bir şeyin xüsusi versiyasıdır.
ContainerRuntimeConfig adlanan bu xüsusi resurs klaster inzibatçılarının CRI-O-nu konfiqurasiyasını asanlaşdırmaq üçün yaradılmışdır. Bu alət kifayət qədər güclüdür ki, MachineConfigPool parametrlərindən asılı olaraq yalnız müəyyən qovşaqlara tətbiq oluna bilər. Bunu eyni məqsədə xidmət edən maşınlar qrupu kimi düşünün.
/etc/crio/crio.conf faylında dəyişdirəcəyimiz son iki sətirə diqqət yetirin. Bu iki sətir crio.conf faylındakı xətlərə çox bənzəyir, bunlar:
vi ContainerRuntimeConfig.yaml
Nəticə:
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
İndi gəlin bu faylı Kubernetes klasterinə itələyək və onun həqiqətən yaradıldığını yoxlayaq. Nəzərə alın ki, əməliyyat hər hansı digər Kubernetes resursu ilə eynidir:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Nəticə:
NAME AGE
set-log-and-pid 22h
ContainerRuntimeConfig yaratdıqdan sonra, bu konfiqurasiyanı klasterdəki xüsusi maşınlar qrupuna tətbiq etmək istədiyimizi Kubernetes-ə bildirmək üçün MachineConfigPools-dan birini dəyişdirməliyik. Bu halda biz əsas qovşaqlar üçün MachineConfigPool-u dəyişəcəyik:
oc edit MachineConfigPool/master
Nəticə (aydınlıq üçün əsas mahiyyət qalıb):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Bu zaman MCO klaster üçün yeni crio.conf faylı yaratmağa başlayır. Bu halda, tamamilə hazır konfiqurasiya faylına Kubernetes API istifadə edərək baxmaq olar. Unutmayın, ContainerRuntimeConfig sadəcə MachineConfig-in ixtisaslaşmış versiyasıdır, ona görə də MachineConfigs-də müvafiq sətirlərə baxaraq nəticəni görə bilərik:
oc get MachineConfigs | grep rendered
Nəticə:
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
Nəzərə alın ki, əsas qovşaqlar üçün ortaya çıxan konfiqurasiya faylı orijinal konfiqurasiyalardan daha yeni versiya idi. Onu görmək üçün aşağıdakı əmri işlədin. Keçən zaman qeyd edirik ki, bu, bəlkə də Kubernetes tarixindəki ən yaxşı tək laynerlərdən biridir:
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
Nəticə:
pids_limit = 2048
İndi konfiqurasiyanın bütün əsas qovşaqlara tətbiq olunduğuna əmin olaq. Əvvəlcə klasterdəki qovşaqların siyahısını alırıq:
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
İndi quraşdırılmış fayla baxaq. Faylın ContainerRuntimeConfig resursunda qeyd etdiyimiz pid və debug direktivləri üçün yeni dəyərlərlə yeniləndiyini görəcəksiniz. Zərifliyin özü:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Nəticə:
...
pids_limit = 2048
...
log_level = "debug"
...
Klasterdəki bütün bu dəyişikliklər hətta SSH-ni işə salmadan edildi. Bütün işlər Kuberentes master node-a daxil olmaqla edildi. Yəni, bu yeni parametrlər yalnız əsas qovşaqlarda konfiqurasiya edilmişdir. İşçi qovşaqları dəyişməyib ki, bu da Kubernetes metodologiyasının konteyner hostları və dəyişdirilə bilən elementləri olan konteyner mühərrikləri ilə bağlı müəyyən edilmiş və faktiki vəziyyətlərdən istifadənin üstünlüklərini nümayiş etdirir.
Yuxarıdakı nümunə üç istehsal qovşağına malik kiçik OpenShift Konteyner Platforması 4 klasterinə və ya 3000 qovşaqdan ibarət nəhəng istehsal klasterinə dəyişiklik etmək qabiliyyətini göstərir. İstənilən halda, işin həcmi eyni olacaq və çox kiçik olacaq - sadəcə ContainerRuntimeConfig faylını konfiqurasiya edin və MachineConfigPool-da bir etiketi dəyişdirin. Və siz bunu bütün ömrü boyu Kubernetes ilə işləyən OpenShift Konteyner Platformasının 4.X istənilən versiyası ilə edə bilərsiniz.
Çox vaxt texnologiya şirkətləri o qədər sürətlə inkişaf edir ki, biz əsas komponentlər üçün nə üçün müəyyən texnologiyalar seçdiyimizi izah edə bilmirik. Konteyner mühərrikləri tarixən istifadəçilərin birbaşa əlaqə qurduğu komponent olub. Konteynerlərin populyarlığı təbii olaraq konteyner mühərriklərinin meydana çıxması ilə başladığı üçün istifadəçilər tez-tez onlara maraq göstərirlər. Red Hat-ın CRI-O-nu seçməsinin başqa səbəbi də budur. Konteynerlər indi orkestrləşməyə diqqət yetirərək inkişaf edir və biz aşkar etdik ki, CRI-O OpenShift 4 ilə işləyərkən ən yaxşı təcrübə təqdim edir.
Mənbə: www.habr.com