Uzun müddətdir gözlədiyimiz (tək bizdə deyil) baş verdi: , tətbiqlər yaratmaq və onları Kubernetes-ə çatdırmaq üçün Açıq Mənbə yardım proqramımız indi 3-yollu birləşmə yamaqlarından istifadə edərək dəyişikliklərin tətbiqini dəstəkləyir! Bundan əlavə, bu resursları yenidən qurmadan mövcud K8 resurslarını Helm buraxılışlarına qəbul etmək mümkündür.
Çox qısadırsa, qoyuruq WERF_THREE_WAY_MERGE=enabled — bizdə olduğu kimi yerləşdirmə əldə edirik kubectl apply", mövcud Helm 2 qurğularına və hətta bir az daha çoxuna uyğun gəlir.
Ancaq gəlin nəzəriyyədən başlayaq: 3 yollu birləşmə yamaqları tam olaraq nədir, insanlar onları yaratmaq üçün necə bir yanaşma tapdılar və Kubernetes əsaslı infrastruktur ilə CI/CD proseslərində nə üçün vacibdirlər? Bundan sonra gəlin görək werf-də 3 yollu birləşmə nədir, standart olaraq hansı rejimlər istifadə olunur və onu necə idarə etmək olar.
3 yollu birləşmə yaması nədir?
Beləliklə, YAML manifestlərində təsvir olunan resursları Kubernetes-ə yaymaq vəzifəsindən başlayaq.
Resurslarla işləmək üçün Kubernetes API aşağıdakı əsas əməliyyatları təklif edir: yaratmaq, yamaqlamaq, dəyişdirmək və silmək. Güman edilir ki, onların köməyi ilə klasterə resursların rahat davamlı yayılmasını qurmaq lazımdır. Necə?
kubectl imperativ əmrləri
Kubernetes-də obyektləri idarə etmək üçün ilk yanaşma bu obyektləri yaratmaq, dəyişdirmək və silmək üçün kubectl imperativ əmrlərindən istifadə etməkdir. Sadəcə qoymaq:
- komanda
kubectl runYerləşdirmə və ya İşi işə sala bilərsiniz:kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE - komanda
kubectl scale- replikaların sayını dəyişdirin:kubectl scale --replicas=3 deployment/mysql - və s.
Bu yanaşma ilk baxışdan əlverişli görünə bilər. Ancaq problemlər var:
- Çətindir avtomatlaşdırmaq.
- Kimi konfiqurasiyanı əks etdirir Git-də? Klasterdə baş verən dəyişiklikləri necə nəzərdən keçirmək olar?
- Necə təmin etmək reproduktivlik yenidən başladıqda konfiqurasiyalar?
- ...
Aydındır ki, bu yanaşma proqram və infrastrukturun kod (IaC; və ya hətta) kimi saxlanmasına uyğun gəlmir. daha müasir bir seçim olaraq, Kubernetes ekosistemində populyarlıq qazanır). Buna görə də, bu əmrlər kubectl-də əlavə inkişaf almadı.
Əməliyyatları yaradın, alın, dəyişdirin və silin
Əsas ilə yaradılması sadədir: əməliyyata manifest göndərin create kube api və resurs yaradıldı. Manifestin YAML təqdimatı Git-də saxlanıla və əmrdən istifadə edərək yaradıla bilər kubectl create -f manifest.yaml.
С çıxarır həm də sadə: eynisini əvəz edin manifest.yaml Gitdən komandaya kubectl delete -f manifest.yaml.
Əməliyyat replace resursu yenidən yaratmadan resurs konfiqurasiyasını tamamilə yenisi ilə əvəz etməyə imkan verir. Bu o deməkdir ki, resursda dəyişiklik etməzdən əvvəl əməliyyatla cari versiyanı sorğulamaq məntiqlidir get, dəyişdirin və əməliyyatla yeniləyin replace. kube apiserver quraşdırılmışdır və əgər əməliyyatdan sonra get obyekt dəyişdi, sonra əməliyyat replace işləməyəcək.
Konfiqurasiyanı Git-də saxlamaq və dəyişdirməklə yeniləmək üçün əməliyyatı yerinə yetirməlisiniz get, Git-dən konfiqurasiyanı qəbul etdiyimizlə birləşdirin və icra edin replace. Varsayılan olaraq kubectl yalnız əmrdən istifadə etməyə imkan verir kubectl replace -f manifest.yamlHara manifest.yaml — quraşdırılmalı olan artıq tam hazırlanmış (bizim vəziyyətimizdə birləşdirilmiş) manifest. Belə çıxır ki, istifadəçi birləşmə manifestlərini həyata keçirməlidir və bu, əhəmiyyətsiz məsələ deyil...
Baxmayaraq ki, onu da qeyd etmək lazımdır manifest.yaml və Git-də saxlanılır, obyekt yaratmaq və ya onu yeniləmək lazım olub-olmadığını əvvəlcədən bilə bilmərik - bu, istifadəçi proqramı tərəfindən edilməlidir.
Ümumi: biz davamlı yayım qura bilərik yalnız yaratmaq, dəyişdirmək və silməkdən istifadə edərək, infrastruktur konfiqurasiyasının kod və rahat CI/CD ilə birlikdə Git-də saxlanmasını təmin etmək?
Prinsipcə, biz edə bilərik... Bunun üçün birləşmə əməliyyatını həyata keçirməli olacaqsınız manifestlər və bir növ məcburiyyət:
- klasterdə bir obyektin mövcudluğunu yoxlayır,
- ilkin resurs yaradılmasını həyata keçirir,
- onu yeniləyir və ya silir.
Yeniləyərkən qeyd edin ki, resurs dəyişmiş ola bilər sonuncudan get və optimist kilidləmə işini avtomatik idarə edin - təkrar yeniləmə cəhdləri edin.
Bununla belə, kube-apiserver resursları yeniləmək üçün başqa bir yol təklif edərkən niyə təkəri yenidən kəşf edin: əməliyyat patch, hansı istifadəçini təsvir edilən bəzi problemlərdən azad edir?
yamaq
İndi yamaqlara keçirik.
Yamalar Kubernetes-də mövcud obyektlərə dəyişikliklərin tətbiqi üçün əsas üsuldur. Əməliyyat patch belə işləyir:
- kube-apiserver istifadəçisi JSON formasında yamaq göndərməli və obyekti göstərməlidir,
- və apiserver özü obyektin cari vəziyyəti ilə məşğul olacaq və onu lazımi formaya gətirəcək.
Bu halda optimist kilidləmə tələb olunmur. Bu əməliyyat dəyişdirməkdən daha bəyanedicidir, baxmayaraq ki, əvvəlcə əksinə görünə bilər.
Beləliklə:
- əməliyyatdan istifadə etməklə
createGit-dən manifestə uyğun olaraq bir obyekt yaradırıq, - köməyi ilə
delete— obyektə artıq ehtiyac yoxdursa, silin; - köməyi ilə
patch— obyekti Git-də təsvir olunan formaya gətirərək dəyişdiririk.
Ancaq bunu etmək üçün yaratmaq lazımdır düzgün yamaq!
Helm 2-də yamalar necə işləyir: 2 yollu birləşmə
Buraxılışı ilk dəfə quraşdırdığınız zaman Helm əməliyyatı yerinə yetirir create qrafik resursları üçün.
Hər resurs üçün Helm buraxılışını yeniləyərkən:
- əvvəlki diaqramdakı resurs versiyası ilə cari diaqram versiyası arasındakı yamağı nəzərdən keçirir,
- bu yamağı tətbiq edir.
Biz bu yamağı çağıracağıq 2 yollu birləşmə yaması, çünki onun yaradılmasında 2 manifest iştirak edir:
- əvvəlki buraxılışdan resurs manifestosu,
- cari mənbədən resurs manifestidir.
Əməliyyatı aradan qaldırarkən delete kube apiserver əvvəlki buraxılışda elan edilmiş, lakin indiki versiyada elan olunmayan resurslar üçün çağırılır.
2 yollu birləşmə yamağı yanaşmasında problem var: bu, gətirib çıxarır klasterdəki resursun real vəziyyəti və Git-dəki manifest ilə sinxronizasiya olunmur.
Məsələnin nümunə ilə təsviri
- Git-də diaqram sahənin olduğu bir manifest saxlayır
imageYerləşdirmə məsələləriubuntu:18.04. - İstifadəçi vasitəsilə
kubectl editbu sahənin dəyərini dəyişdiubuntu:19.04. - Helm diaqramını yenidən yerləşdirərkən yamaq yaratmır, çünki sahə
imageburaxılışın əvvəlki versiyasında və cari diaqramda eynidir. - Yenidən yerləşdirmədən sonra
imageqalıqlarıubuntu:19.04, baxmayaraq ki, qrafik deyirubuntu:18.04.
Biz desinxronizasiya əldə etdik və deklarativliyi itirdik.
Sinxronlaşdırılmış resurs nədir?
Ümumiyyətlə, tamamlandı Çalışan klasterdəki resurs manifesti ilə Git-dən manifest arasında uyğunluq əldə etmək mümkün deyil. Çünki real manifestdə bəzi kontrollerlər tərəfindən dinamik olaraq resursdan əlavə edilən və silinən xidmət annotasiyaları/etiketləri, əlavə konteynerlər və digər məlumatlar ola bilər. Biz bu məlumatları Git-də saxlaya bilmərik və istəmirik. Bununla belə, Git-də açıq şəkildə göstərdiyimiz sahələrin işə salındıqdan sonra müvafiq dəyərləri almasını istəyirik.
Çox ümumi çıxır sinxronlaşdırılmış resurs qaydası: resursu yayarkən siz yalnız Git-dən manifestdə açıq şəkildə göstərilən sahələri dəyişdirə və ya silə bilərsiniz (və ya əvvəlki versiyada göstərilib və indi silinib).
3 yollu birləşmə yaması
mərkəzi ideyası : çalışan klasterdən manifestin cari versiyasını nəzərə alaraq Git-dən manifestin son tətbiq edilmiş versiyası ilə Git-dən manifestin hədəf versiyası arasında yamaq yaradırıq. Nəticə yamaq sinxronlaşdırılmış resurs qaydasına uyğun olmalıdır:
- hədəf versiyaya əlavə edilmiş yeni sahələr yamaqdan istifadə etməklə əlavə edilir;
- son tətbiq edilmiş versiyada əvvəllər mövcud olan və hədəf versiyada mövcud olmayan sahələr yamaqdan istifadə edərək sıfırlanır;
- obyektin cari versiyasında manifestin hədəf versiyasından fərqli olan sahələr yamaqdan istifadə etməklə yenilənir.
Məhz bu prinsip əsasında yamaqlar yaradır kubectl apply:
- manifestin son tətbiq edilmiş versiyası obyektin özünün annotasiyasında saxlanılır,
- hədəf - göstərilən YAML faylından götürülmüşdür,
- cari bir çalışan klasterdəndir.
Nəzəriyyəni sıraladığımızdan sonra sizə werf-də nə etdiyimizi söyləməyin vaxtı gəldi.
Dəyişikliklərin werf-ə tətbiqi
Əvvəllər werf, Helm 2 kimi, 2 yollu birləşmə yamaqlarından istifadə edirdi.
Təmir yamağı
Yeni bir yamaq növünə - 3 yollu birləşməyə keçmək üçün ilk addım olaraq sözdə olanı təqdim etdik. təmir yamaları.
Yerləşdirmə zamanı standart 2 yollu birləşmə patchindən istifadə olunur, lakin werf əlavə olaraq resursun real vəziyyətini Git-də yazılanlarla sinxronlaşdıracaq yamaq yaradır (belə yamaq yuxarıda təsvir edilən eyni sinxronlaşdırılmış resurs qaydasından istifadə etməklə yaradılır) .
Sinxronizasiya baş verərsə, yerləşdirmənin sonunda istifadəçi resursu sinxronlaşdırılmış forma gətirmək üçün tətbiq edilməli olan müvafiq mesaj və yamaq ilə XƏBƏRDARLIQ alır. Bu yamaq da xüsusi annotasiyada qeyd olunur werf.io/repair-patch. İstifadəçinin əlləri olduğu güman edilir сам bu yamağı tətbiq edəcək: werf onu heç tətbiq etməyəcək.
Təmir yamaqlarının yaradılması 3 yollu birləşmə prinsipi əsasında yamaqların yaradılmasını həqiqətən sınaqdan keçirməyə imkan verən müvəqqəti tədbirdir, lakin bu yamaqları avtomatik tətbiq etmir. Hazırda bu iş rejimi standart olaraq aktivdir.
Yalnız yeni buraxılışlar üçün 3 yollu birləşmə yaması
1 dekabr 2019-cu il tarixindən etibarən werf-in beta və alfa versiyaları başlayır default olaraq Dəyişiklikləri yalnız werf vasitəsilə yayılmış yeni Helm buraxılışlarına tətbiq etmək üçün tam hüquqlu 3 yollu birləşmə yamaqlarından istifadə edin. Mövcud buraxılışlar 2 yollu birləşmə + təmir yamaqları yanaşmasından istifadə etməyə davam edəcək.
Bu iş rejimi təyin etməklə açıq şəkildə aktivləşdirilə bilər WERF_THREE_WAY_MERGE_MODE=onlyNewReleases İndi.
Qeyd: xüsusiyyət werf-də bir neçə buraxılışda ortaya çıxdı: alfa kanalında versiya ilə hazır oldu , və beta kanalında - ilə .
Bütün buraxılışlar üçün 3 yollu birləşmə yaması
15 dekabr 2019-cu il tarixindən etibarən werf-in beta və alfa versiyaları bütün buraxılışlara dəyişiklikləri tətbiq etmək üçün defolt olaraq tam 3 yollu birləşmə yamaqlarından istifadə etməyə başlayır.
Bu iş rejimi təyin etməklə açıq şəkildə aktivləşdirilə bilər WERF_THREE_WAY_MERGE_MODE=enabled İndi.
Resursun avtomatik miqyası ilə nə etməli?
Kubernetes-də 2 növ avtomatik ölçmə var: HPA (üfüqi) və VPA (şaquli).
Horizontal avtomatik olaraq replikaların sayını, şaquli - resursların sayını seçir. Həm replikaların sayı, həm də resurs tələbləri resurs manifestində göstərilmişdir (bax Resurs Manifestinə). spec.replicas və ya spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и ).
Problem: əgər istifadəçi qrafikdə resursu elə konfiqurasiya edirsə ki, o, resurslar üçün müəyyən dəyərləri təyin etsin və ya bu resurs üçün replikalar və avtomiqyaslayıcılar işə salınıbsa, onda hər yerləşdirmə zamanı werf bu dəyərləri diaqram manifestində yazılanlara sıfırlayacaq. .
Problemin iki həlli var. Başlamaq üçün, diaqram manifestində avtomatik miqyaslı dəyərləri açıq şəkildə göstərməkdən çəkinmək yaxşıdır. Əgər bu seçim nədənsə uyğun deyilsə (məsələn, ilkin resurs limitlərini və diaqramdakı replikaların sayını təyin etmək rahat olduğu üçün), onda werf aşağıdakı qeydləri təklif edir:
-
werf.io/set-replicas-only-on-creation=true -
werf.io/set-resources-only-on-creation=true
Əgər belə annotasiya varsa, werf hər yerləşdirmədə müvafiq dəyərləri sıfırlamayacaq, ancaq resurs ilkin yaradılan zaman onları təyin edəcək.
Ətraflı məlumat üçün layihə sənədlərinə baxın и .
3 yollu birləşmə yamasının istifadəsini qadağan edin
İstifadəçi hazırda mühit dəyişənindən istifadə edərək werf-də yeni yamaqların istifadəsini qadağan edə bilər WERF_THREE_WAY_MERGE_MODE=disabled. Bununla belə, başlayaraq 1-ci il martın 2020-dən etibarən bu qadağa artıq tətbiq edilməyəcək. və yalnız 3 yollu birləşmə yamaqlarından istifadə etmək mümkün olacaq.
Werf-də resursların qəbulu
3 yollu birləşmə yamaları ilə dəyişikliklərin tətbiqi metodunu mənimsəmək bizə klasterdə mövcud olan resursları Helm buraxılışına qəbul etmək kimi bir xüsusiyyəti dərhal tətbiq etməyə imkan verdi.
Helm 2-də problem var: siz bu resursu sıfırdan yaratmadan klasterdə artıq mövcud olan diaqram manifestlərinə mənbə əlavə edə bilməzsiniz (bax. , ). Biz werf-ə mövcud resursları buraxılış üçün qəbul etməyi öyrətdik. Bunu etmək üçün, çalışan klasterdən resursun cari versiyasına annotasiya quraşdırmalısınız (məsələn, istifadə edərək kubectl edit):
"werf.io/allow-adoption-by-release": RELEASE_NAMEİndi resurs diaqramda təsvir edilməlidir və növbəti dəfə werf müvafiq adla buraxılışı yerləşdirdikdə, mövcud resurs bu buraxılışa qəbul ediləcək və onun nəzarəti altında qalacaq. Üstəlik, buraxılış üçün resursun qəbulu prosesində werf eyni 3 yollu birləşmə yamaqlarından və sinxronlaşdırılmış resurs qaydasından istifadə edərək, işləyən klasterdən resursun cari vəziyyətini qrafikdə təsvir olunan vəziyyətə gətirəcək.
Qeyd: qəbulu WERF_THREE_WAY_MERGE_MODE resursların qəbuluna təsir göstərmir - övladlığa götürmə halında həmişə 3 yollu birləşmə yaması istifadə olunur.
Təfərrüatlar - daxil .
Nəticələr və gələcək planlar
Ümid edirəm ki, bu məqalədən sonra 3 yollu birləşmə yamaqlarının nə olduğu və niyə onlara gəldiyi daha aydın oldu. Werf layihəsinin inkişafının praktiki nöqteyi-nəzərindən onların həyata keçirilməsi Helm-ə bənzər yerləşdirmənin təkmilləşdirilməsi istiqamətində növbəti addım idi. İndi Helm 2-dən istifadə edərkən tez-tez yaranan konfiqurasiya sinxronizasiyası ilə bağlı problemləri unuda bilərsiniz. Eyni zamanda, Helm buraxılışına artıq yüklənmiş Kubernetes resurslarının qəbul edilməsinin yeni faydalı xüsusiyyəti əlavə edildi.
Helm-ə bənzər yerləşdirmələrlə bağlı hələ də bəzi problemlər və problemlər var, məsələn Go şablonlarının istifadəsi, biz onları həll etməyə davam edəcəyik.
Resurs yeniləmə üsulları və qəbulu haqqında məlumatı da burada tapa bilərsiniz .
Sükan 3
Xüsusi qeyd etməyə dəyər yalnız ötən gün Helm-in yeni əsas versiyası - v3 - bu da 3-yollu birləşmə yamaqlarından istifadə edir və Tiller-dən xilas olur. Helm-in yeni versiyası tələb olunur onları yeni buraxılış saxlama formatına çevirmək üçün mövcud qurğular.
Werf, öz növbəsində, hazırda Tiller-dən istifadə etməkdən xilas oldu, 3 yollu birləşməyə keçdi və əlavə etdi , mövcud Helm 2 quraşdırmaları ilə uyğun qalmaqla (heç bir miqrasiya skriptinin icrasına ehtiyac yoxdur). Buna görə də, werf Helm 3-ə keçənə qədər, werf istifadəçiləri Helm 3-ün Helm 2-dən əsas üstünlüklərini itirmirlər (werf də onlara malikdir).
Bununla belə, werf-in Helm 3 kod bazasına keçidi qaçılmazdır və yaxın gələcəkdə baş verəcək. Ehtimal ki, bu werf 1.1 və ya werf 1.2 olacaq (hazırda werf-in əsas versiyası 1.0-dır; werf versiyasını tərtib edən cihaz haqqında ətraflı məlumat üçün bax. ). Bu müddət ərzində Helm 3 sabitləşməyə vaxt tapacaq.
PS
Bloqumuzda da oxuyun:
- werf-də yeniliklər haqqında bir sıra qeydlər:
- «";
- «";
- «.
- «";
- «";
- «.
Mənbə: www.habr.com