Kubernetes-in resursları yeniləmək üçün bir neçə variantı var: tətbiq edin, redaktə edin, yamaqlayın və dəyişdirin. Hər birinin nə etdiyi və nə vaxt istifadə ediləcəyi ilə bağlı qarışıqlıq var. Gəlin bunu anlayaq.
Əgər "kubernetes tətbiq et vs dəyişdir" ifadəsi yer alır , bu düzgün deyil. "kubernetes tətbiq vs yamaq" ilk keçid üçün sənədlərdir kubectl patch, buna müqayisə daxil deyil apply и patch. Bu məqalə müxtəlif variantlara, eləcə də hər birinin düzgün istifadəsinə baxacaq.
Kubernetes resursunun (xidmət, yerləşdirmə, giriş və s.) həyat dövrü ərzində bəzən bu resursun bəzi xüsusiyyətlərini dəyişməli, əlavə etməli və ya silməlisən. Məsələn, qeyd əlavə edin, replikaların sayını artırın və ya azaldın.
Kubernetes CLI
Əgər siz artıq CLI vasitəsilə Kubernetes klasterləri ilə işləyirsinizsə, siz artıq bunlarla tanışsınız. apply и edit. Komanda apply fayldan resurs spesifikasiyasını oxuyur və Kubernetes klasterinə "yuxarı" edir, yəni. resurs mövcud deyilsə onu yaradır və varsa onu yeniləyir. Komanda edit API vasitəsilə resursu oxuyur, sonra resursun spesifikasiyasını yerli fayla yazır və mətn redaktorunda açılır. Faylı redaktə edib saxladıqdan sonra, kubectl API vasitəsilə edilən dəyişiklikləri geri göndərəcək və bu dəyişiklikləri ehtiyatla resursa tətbiq edəcək.
Hər kəs əmrləri bilmir patch и replace. Komanda patch əmr satırında yalnız dəyişdirilmiş hissəni təmin etməklə, resursun spesifikasiyasının bir hissəsini dəyişdirməyə imkan verir. Komanda replace kimi işləyir edit, lakin hər şeyi əl ilə etmək lazımdır: resurs spesifikasiyasının cari versiyasını yükləməlisiniz, məsələn, istifadə edərək kubectl get -o yaml, redaktə edin, sonra istifadə edin replace dəyişdirilmiş spesifikasiyaya uyğun olaraq resursu yeniləmək. Komanda replace resursun oxunması və dəyişdirilməsi arasında hər hansı dəyişiklik baş verərsə işləməyəcək.
Kubernetes API
Yəqin ki, üsullarla tanışsınız CoreV1().Pods().Update(), replaceNamespacedService və ya patch_namespaced_deployment, vasitəsilə klasterlərlə işləyirsinizsə bəzi proqramlaşdırma dilindən istifadə etməklə. Kitabxana bu metodları metodlardan istifadə edərək HTTP sorğuları vasitəsilə idarə edir PUT и PATCH. Bununla update и replace istifadə edin PUTVə patch, nə qədər əhəmiyyətsiz olsa da, istifadə edir PATCH.
Qeyd edək ki, kubectl həmçinin API vasitəsilə klasterlərlə işləyir. Başqa sözlə, kubectlstandart API imkanlarına əlavə olaraq, əsasən daha yığcam və oxunaqlı formada alt əmrləri təmin etmək imkanı verən Go dili üçün müştəri kitabxanasının üstündəki sarğıdır. Məsələn, artıq qeyd etdiyiniz kimi, üsul apply əvvəlki bənddə yuxarıda qeyd edilməmişdir. Hal-hazırda (May 2020, təqribən. tərcüməçi) bütün məntiq kubectl apply, yəni. mövcud olmayan resursların yaradılması və mövcud olanların yenilənməsi, tamamilə kod tərəfində işləyir kubectl. Səylər edilir apply API tərəfinə, lakin hələ də beta mərhələsindədir. Aşağıda daha ətraflı yazacam.
Defolt olaraq yamaq
Ən yaxşı istifadə olunur patch, resursu yeniləmək istəyirsinizsə. Hər iki müştəri kitabxanası Kubernetes API üzərində necə işləyir və kubectl (təəccüblü deyil, çünki bu, müştəri kitabxanası üçün sarğıdır, təqribən. tərcüməçi).
Strateji işləyin
Bütün komandalar kubectl apply, edit и patch üsulundan istifadə edin PATCH mövcud resursu yeniləmək üçün HTTP sorğularında. Əmrlərin həyata keçirilməsini daha ətraflı araşdırsanız, onların hamısı yanaşmadan istifadə edir əmri olsa da resursları yeniləmək patch digər yanaşmalardan istifadə edə bilər (aşağıda bu barədə daha ətraflı). Strateji birləşdirmə yamaq yanaşması, təqdim edilmiş spesifikasiyanı mövcud spesifikasiya ilə birləşdirərək "düzgün əldə etməyə" çalışır. Daha dəqiq desək, o, həm obyektləri, həm də massivləri birləşdirməyə çalışır, yəni dəyişikliklər əlavə xarakter daşıyır. Məsələn, əmri işə salmaq patch pod konteyner spesifikasiyasında yeni mühit dəyişəni ilə həmin mühit dəyişəninin onların üzərinə yazmaq əvəzinə mövcud mühit dəyişənlərinə əlavə edilməsinə səbəb olur. Bu yanaşmadan istifadə edərək silmək üçün təqdim edilmiş spesifikasiyada parametr dəyərini null etməyə məcbur etməlisiniz. Hansı komandalardan kubectl Yeniləmə üçün istifadə etmək daha yaxşıdır?
Resurslarınızı istifadə edərək yaradıb idarə edirsinizsə kubectl apply, yeniləyərkən həmişə istifadə etmək daha yaxşıdır kubectl applyÜzrə kubectl konfiqurasiyanı idarə edə və tətbiqdən tətbiqə tələb olunan dəyişiklikləri düzgün izləyə bilər. Üstünlük həmişə istifadə edin apply odur ki, o, əvvəllər tətbiq edilmiş spesifikasiyanı izləyir, ona spesifikasiya xassələrinin və massiv elementlərinin nə vaxt açıq şəkildə silindiyini bilməyə imkan verir. Bu istifadə etməyə imkan verir apply xassələri və massiv elementlərini silmək üçün normal bir strateji birləşmə işləməyəcək. Komandalar edit и patch ki, qeydləri yeniləməyin kubectl apply dəyişikliklərini izləmək üçün istifadə edir, beləliklə Kubernetes API vasitəsilə izlənilən və edilən, lakin əmrlər vasitəsilə edilən hər hansı dəyişikliklər edit и patch, sonrakı əmrlərə görünməz applyKi, apply üçün giriş spesifikasiyasında görünməsələr belə, onları silmir apply (Sənədlərdə belə deyilir edit и patch istifadə edilən qeydlərə yeniliklər etmək apply, lakin praktikada - yox).
Əgər əmrdən istifadə etmirsinizsə apply, kimi istifadə edilə bilər editVə patch, edilən dəyişikliyə ən uyğun olan əmri seçmək. BOM xassələrini əlavə edərkən və dəyişdirərkən hər iki yanaşma təxminən eynidir. Spesifikasiya xüsusiyyətlərini və ya massiv elementlərini silərkən edit birdəfəlik buraxılış kimi davranır apply, o cümlədən spesifikasiyanın redaktə edilməzdən əvvəl və sonra necə olduğunu izləmək, beləliklə, siz resursdan xassələri və massiv elementlərini açıq şəkildə silə bilərsiniz. Siz spesifikasiyada xassə dəyərini açıq şəkildə null olaraq təyin etməlisiniz patchresursdan silmək üçün. Strateji birləşmə yamaqlarından istifadə edərək massiv elementinin çıxarılması daha mürəkkəbdir, çünki birləşmə direktivlərinin istifadəsini tələb edir. Daha əlverişli alternativlər üçün aşağıdakı təkmilləşdirmə yanaşmalarına baxın.
Yuxarıdakı əmrlərə oxşar davranan müştəri kitabxanasında yeniləmə metodlarını tətbiq etmək kubectl, sorğularda təyin edilməlidir content-type в application/strategic-merge-patch+json. Bir spesifikasiyada xassələri silmək istəyirsinizsə, oxşar şəkildə onların dəyərlərini açıq şəkildə sıfıra təyin etməlisiniz. kubectl patch. Massiv elementlərini silmək lazımdırsa, yeniləmə spesifikasiyasına birləşmə direktivlərini daxil etməli və ya yeniləmələrə fərqli yanaşmadan istifadə etməlisiniz.
Yeniləmələrə digər yanaşmalar
Kubernetes digər iki yeniləmə yanaşmasını dəstəkləyir: и . JSON birləşmə patch yanaşması giriş kimi qismən Kubernetes spesifikasiyasını qəbul edir və strateji birləşmə yamaq yanaşmasına bənzər birləşmə obyektlərini dəstəkləyir. İkisi arasındakı fərq, pod spesifikasiyasındakı konteyner massivi də daxil olmaqla, yalnız massiv dəyişdirilməsini dəstəkləməsidir. Bu o deməkdir ki, JSON birləşmə yamasından istifadə edərkən, hər hansı bir konteynerin hər hansı bir xüsusiyyəti dəyişdiyi halda, bütün konteynerlər üçün tam spesifikasiyalar təqdim etməlisiniz. Beləliklə, bu yanaşma BOM-da massivdən elementləri silmək üçün faydalıdır. Komanda xəttində istifadə edərək JSON birləşmə yamasını seçə bilərsiniz kubectl patch --type=merge. Kubernetes API ilə işləyərkən sorğu metodundan istifadə etməlisiniz PATCH və quraşdırma content-type в application/merge-patch+json.
JSON patch yanaşması, resursun qismən spesifikasiyasını təmin etmək əvəzinə, massiv kimi resursda etmək istədiyiniz dəyişiklikləri təmin etməkdən istifadə edir, burada massivin hər bir elementi resursda edilən dəyişikliyin təsvirini təmsil edir. Bu yanaşma edilən dəyişiklikləri ifadə etmək üçün daha çevik və güclü bir yoldur, lakin edilən dəyişiklikləri qismən resurs spesifikasiyası göndərmək əvəzinə, ayrıca, Kubernetes formatında olmayan formatda sadalamaq bahasına başa gəlir. IN kubectl istifadə edərək JSON patch seçə bilərsiniz kubectl patch --type=json. Kubernetes API istifadə edərkən bu yanaşma sorğu metodundan istifadə etməklə işləyir PATCH və quraşdırma content-type в application/json-patch+json.
Bizə güvən lazımdır - əvəzdən istifadə edin
Bəzi hallarda, mənbənin oxunduğu vaxtla onun yenilənməsi arasında resursda heç bir dəyişiklik edilmədiyinə əmin olmalısınız. Başqa sözlə, bütün dəyişikliklərin olacağına əmin olmalısınız atom. Bu halda, resursları yeniləmək üçün istifadə etməlisiniz replace. Məsələn, bir neçə mənbə tərəfindən yenilənən sayğaclı ConfigMapiniz varsa, əmin olmalısınız ki, iki mənbə eyni vaxtda sayğacı yeniləməyib, yeniləmənin itirilməsinə səbəb olur. Nümayiş etmək üçün yanaşmadan istifadə edərək hadisələrin ardıcıllığını təsəvvür edin patch:
- A və B API-dən resursun cari vəziyyətini alır
- Hər biri sayğacı bir dəfə artırmaqla və həmçinin "yenilənmiş" qeydinə müvafiq olaraq "A" və ya "B" əlavə etməklə spesifikasiyanı yerli olaraq yeniləyir.
- Və resursu bir az daha sürətli yeniləyir
- B resursu yeniləyir
Nəticədə A yeniləməsi itirilir. Son əməliyyat patch qalib gəlir, sayğac iki əvəzinə bir artır və "yeniləndi" qeydinin dəyəri "B" ilə bitir və "A" yoxdur. Yuxarıdakıları yanaşmadan istifadə edərək yeniləmələr edildikdə baş verənlərlə müqayisə edək replace:
- A və B API-dən resursun cari vəziyyətini alır
- Hər biri sayğacı bir dəfə artırmaqla və həmçinin "yenilənmiş" qeydinə müvafiq olaraq "A" və ya "B" əlavə etməklə spesifikasiyanı yerli olaraq yeniləyir.
- Və resursu bir az daha sürətli yeniləyir
- B resursu yeniləməyə çalışır, lakin resurs versiyası spesifikasiyada olduğu üçün yeniləmə API tərəfindən rədd edilir
replaceKubernetesdəki resursun cari versiyasına uyğun gəlmir, çünki resursun versiyası A-nın dəyişdirmə əməliyyatı ilə artırılıb.
Yuxarıdakı halda, B resursu yenidən götürməli, yeni vəziyyətə dəyişiklik etməli və yenidən cəhd etməli olacaq replace. Bu, sayğacın iki dəfə artmasına və "yenilənilən" qeydinin sonunda "AB" hərfinin daxil olmasına səbəb olacaq.
Yuxarıdakı nümunə icra edərkən bunu nəzərdə tutur replace Bütün resurs tamamilə dəyişdirilir. Üçün istifadə olunan spesifikasiya replace, kimi qismən və ya hissələrlə olmamalıdır apply, lakin əlavə daxil olmaqla tam resourceVersion spesifikasiya metadatasına daxil edin. Əgər aktiv etməmisinizsə resourceVersion və ya təqdim etdiyiniz versiya cari deyilsə, əvəzetmə rədd ediləcək. Beləliklə, istifadə etmək üçün ən yaxşı yanaşmadır replace – resursu oxuyun, yeniləyin və dərhal dəyişdirin. İstifadə kubectl, bu belə görünə bilər:
$ kubectl get deployment my-deployment -o json
| jq '.spec.template.spec.containers[0].env[1].value = "new value"'
| kubectl replace -f -Qeyd etmək lazımdır ki, ardıcıl olaraq yerinə yetirilən aşağıdakı iki əmr uğurla yerinə yetiriləcəkdir, çünki deployment.yaml əmlak ehtiva etmir .metadata.resourceVersion
$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yamlBu, yuxarıda deyilənlərə zidd görünür, yəni. "əlavə edir resourceVersion spesifikasiya metadatasına daxil edin." Bunu demək səhvdir? Xeyr, belə deyil, çünki əgər kubectl qeyd etmədiyiniz bildirişlər resourceVersion, onu resursdan oxuyacaq və qeyd etdiyiniz spesifikasiyaya əlavə edəcək və yalnız bundan sonra icra edəcək replace. Əgər atomikliyə güvənsəniz, bu potensial təhlükəli olduğundan, sehr tamamilə yan tərəfdə işləyir kubectl, API ilə işləyən müştəri kitabxanalarından istifadə edərkən ona etibar etməməlisiniz. Bu halda siz cari resurs spesifikasiyasını oxumalı, onu yeniləməli və sonra icra etməli olacaqsınız PUT xahiş.
Siz yamaq edə bilməzsiniz - biz əvəz edirik
Bəzən API tərəfindən idarə edilə bilməyən bəzi dəyişikliklər etməlisiniz. Bu hallarda, resursu silib yenidən yaratmaqla onu dəyişdirməyə məcbur edə bilərsiniz. Bu istifadə edilir kubectl replace --force. Komandanın icrası dərhal resursları silir və sonra onları təchiz edilmiş spesifikasiyadan yenidən yaradır. API-də "məcburi dəyişdirmə" idarəedicisi yoxdur və bunu API vasitəsilə etmək üçün siz iki əməliyyat yerinə yetirməlisiniz. Əvvəlcə onu təyin edərək resursu silməlisiniz gracePeriodSeconds sıfıra (0) və propagationPolicy "Arxa planda" seçin və sonra bu resursu istədiyiniz spesifikasiya ilə yenidən yaradın.
Xəbərdarlıq: Bu yanaşma potensial təhlükəlidir və qeyri-müəyyən vəziyyətə gətirib çıxara bilər.
Server tərəfində müraciət edin
Yuxarıda qeyd edildiyi kimi, Kubernetes tərtibatçıları məntiqi həyata keçirmək üzərində işləyirlər apply haqqında kubectl Kubernetes API-də. Məntiqlər apply vasitəsilə Kubernetes 1.18-də mövcuddur kubectl apply --server-side və ya metoddan istifadə edərək API vasitəsilə PATCH с content-type application/apply-patch+YAML.
Qeyd: JSON da etibarlı YAML-dir, ona görə də spesifikasiyanı JSON kimi göndərə bilərsiniz
content-typeiradəapplication/apply-patch+yaml.
Bu məntiqdən başqa kubectl API vasitəsilə hər kəs üçün əlçatan olur, apply server tərəfində spesifikasiyadakı sahələrə kimin cavabdeh olduğunu izləyir və beləliklə, onun münaqişəsiz redaktəsinə təhlükəsiz çoxsaylı giriş imkanı verir. Başqa sözlə, əgər apply server tərəfində daha geniş yayılacaq, müxtəlif müştərilər, məsələn, kubectl, Pulumi və ya Terraform, GitOps, həmçinin müştəri kitabxanalarından istifadə edərək öz-özünə yazılmış skriptlər üçün universal təhlükəsiz resurs idarəetmə interfeysi görünəcək.
Nəticələri
Ümid edirəm ki, klasterlərdə resursları yeniləməyin müxtəlif yollarına dair bu qısa icmal sizin üçün faydalı oldu. Bunun sadəcə tətbiq etmək əvəzinə əvəz etmək olmadığını bilmək yaxşıdır; tətbiq etmək, redaktə etmək, yamaq və ya əvəz etməkdən istifadə edərək resursu yeniləmək mümkündür. Axı, prinsipcə, hər bir yanaşmanın öz tətbiq sahəsi var. Atom dəyişiklikləri üçün əvəz etmək daha məqsədəuyğundur; əks halda, tətbiq vasitəsilə strateji birləşmə yamasından istifadə etməlisiniz. Ən azı, "kubernetes tətbiq və dəyişdirmə" üçün axtarış edərkən Google və ya StackOerflow-a etibar edə bilməyəcəyinizi başa düşməyinizi gözləyirəm. Ən azı bu məqalə hazırkı cavabı əvəz edənə qədər.
Mənbə: www.habr.com