Kubernetes üçün ən populyar paket meneceri haqqında hekayənin mahiyyəti bir emoji istifadə edərək təsvir edilə bilər:
- qutu Helm (son Emoji buraxılışına ən yaxın olan şeydir);
- kilid - təhlükəsizlik;
- kiçik adam problemin həllidir.
Əslində, hər şey bir az daha mürəkkəb olacaq və hekayə texniki detallarla doludur Helmi necə təhlükəsiz etmək olar.
- Bilmədiyiniz və ya unutmusunuzsa, Helmin nə olduğunu qısaca izah edin. Hansı problemləri həll edir və ekosistemdə harada yerləşir.
- Gəlin Helm memarlığına baxaq. Komponentin arxitekturasını başa düşmədən təhlükəsizlik və alət və ya həlli necə daha təhlükəsiz etmək barədə heç bir söhbət tamamlanmır.
- Gəlin Helm komponentlərini müzakirə edək.
- Ən çox yanan sual gələcək - Helm 3-ün yeni versiyasıdır.
Bu məqalədəki hər şey Helm 2-yə aiddir. Bu versiya hazırda istehsaldadır və çox güman ki, hazırda istifadə etdiyiniz versiyadır və təhlükəsizlik risklərini ehtiva edən versiyadır.
Spiker haqqında: Aleksandr Xayorov () 10 ildir inkişaf edir, məzmunun təkmilləşdirilməsinə kömək edir və komitəyə daxil oldu . İndi o, Chainstack-də inkişaf rəhbəri kimi işləyir - bu, inkişaf meneceri ilə son buraxılışların çatdırılmasına cavabdeh olan şəxs arasında hibriddir. Yəni, o, döyüş meydanında yerləşir, burada məhsulun yaradılmasından tutmuş onun istismarına qədər hər şey baş verir.
Chainstack kiçik, fəal inkişaf edən startapdır, onun missiyası müştərilərə mərkəzləşdirilməmiş tətbiqlərin istismarının infrastrukturu və mürəkkəbliklərini unutmağa imkan verməkdir; inkişaf qrupu Sinqapurda yerləşir. Chainstack-dən kriptovalyuta satmağı və ya almağı xahiş etməyin, lakin müəssisə blokçeyn çərçivələri haqqında danışmağı təklif edin və onlar sizə məmnuniyyətlə cavab verəcəklər.
sükan
Bu, Kubernetes üçün paket (diaqram) meneceridir. Tətbiqləri Kubernetes klasterinə gətirməyin ən intuitiv və universal yolu.
Biz, əlbəttə ki, öz YAML manifestlərinizi yaratmaqdan və kiçik kommunal proqramlar yazmaqdan daha çox struktur və sənaye yanaşmasından danışırıq.
Helm hazırda mövcud və populyar olan ən yaxşısıdır.
Niyə Helm? İlk növbədə CNCF tərəfindən dəstəkləndiyi üçün. Cloud Native böyük bir təşkilatdır və Kubernetes, etcd, Fluentd və digər layihələr üçün əsas şirkətdir.
Digər mühüm fakt isə Helm-in çox məşhur layihə olmasıdır. 2019-cu ilin yanvarında Helm-i necə təhlükəsiz etmək barədə danışmağa başlayanda layihənin GitHub-da min ulduzu var idi. May ayına qədər onların sayı 12 min idi.
Bir çox insan Helm ilə maraqlanır, buna görə də hələ istifadə etməsəniz belə, onun təhlükəsizliyi haqqında bilməkdən faydalanacaqsınız. Təhlükəsizlik vacibdir.
Əsas Helm komandası Microsoft Azure tərəfindən dəstəklənir və buna görə də bir çox başqalarından fərqli olaraq kifayət qədər sabit layihədir. İyulun ortalarında Helm 3 Alpha 2-nin buraxılması onu göstərir ki, layihə üzərində çalışan kifayət qədər çox insan var və onların Helm-i inkişaf etdirmək və təkmilləşdirmək arzusu və enerjisi var.
Helm, Kubernetes-də tətbiqlərin idarə edilməsinin bir neçə əsas problemini həll edir.
- Tətbiq qablaşdırması. Hətta WordPress-də “Salam, Dünya” kimi bir proqram artıq bir neçə xidmətdən ibarətdir və siz onları bir yerə yığmaq istəyirsiniz.
- Bu proqramların idarə edilməsi ilə gələn mürəkkəbliyin idarə edilməsi.
- Tətbiq quraşdırıldıqdan və ya yerləşdirildikdən sonra bitməyən həyat dövrü. Yaşamağa davam edir, onu yeniləmək lazımdır və Helm buna kömək edir və bunun üçün düzgün tədbirlər və siyasətlər gətirməyə çalışır.
Torbalama aydın şəkildə təşkil edilmişdir: Linux, Windows və ya MacOS üçün müntəzəm paket menecerinin işinə tam uyğun metadata var. Yəni, depo, müxtəlif paketlərdən asılılıqlar, tətbiqlər üçün meta-məlumat, parametrlər, konfiqurasiya xüsusiyyətləri, məlumatların indeksləşdirilməsi və s. Helm bütün bunları proqramlar üçün əldə etməyə və istifadə etməyə imkan verir.
Mürəkkəbliyin İdarə Edilməsi. Eyni tipli bir çox tətbiqiniz varsa, parametrləşdirmə tələb olunur. Şablonlar buradan yaranır, lakin şablon yaratmaq üçün öz yolunuzu tapmaq məcburiyyətində qalmamaq üçün Helm-in qutudan kənarda təklif etdiyi şeylərdən istifadə edə bilərsiniz.
Tətbiq Həyat Dövrünün İdarə Edilməsi - məncə, bu, ən maraqlı və həll olunmamış sualdır. Elə buna görə də o gün yenə Helmə gəldim. Tətbiqin həyat dövrünə diqqət yetirməli idik və CI/CD və tətbiq dövrlərimizi bu paradiqmaya köçürmək istədik.
Helm sizə imkan verir:
- yerləşdirmələri idarə edir, konfiqurasiya və təftiş konsepsiyasını təqdim edir;
- geri qaytarmağı uğurla həyata keçirmək;
- müxtəlif tədbirlər üçün qarmaqlardan istifadə edin;
- əlavə tətbiq yoxlamaları əlavə edin və onların nəticələrinə cavab verin.
Üstəlik Sükanda "batareyalar" var - həyatınızı asanlaşdıran plaginlər şəklində daxil edilə bilən çox sayda dadlı şeylər. Pluginlər müstəqil şəkildə yazıla bilər, onlar kifayət qədər təcrid olunublar və harmonik arxitektura tələb etmirlər. Əgər nəyisə həyata keçirmək istəyirsinizsə, mən bunu plagin kimi etməyi və sonra onu yuxarı axınına daxil etməyi məsləhət görürəm.
Helm üç əsas konsepsiyaya əsaslanır:
- Diaqram Repo — manifestiniz üçün mümkün parametrləşdirmələrin təsviri və massivi.
- Config — yəni tətbiq olunacaq dəyərlər (mətn, ədədi dəyərlər və s.).
- Buraxın iki yuxarı komponenti toplayır və onlar birlikdə Release-ə çevrilirlər. Buraxılışlar versiyalaşdırıla bilər və bununla da mütəşəkkil bir həyat dövrünə nail olmaq olar: quraşdırma zamanı kiçik və təkmilləşdirmə, endirmə və ya geri qaytarma zamanı böyük.
Sükan memarlığı
Diaqram konseptual olaraq Helmin yüksək səviyyəli arxitekturasını təsvir edir.
Nəzərinizə çatdırım ki, Helm Kubernetes ilə əlaqəli bir şeydir. Buna görə də Kubernetes klasteri (düzbucaqlı) olmadan edə bilmərik. Kube-apiserver komponenti master üzərində yerləşir. Helm olmadan bizdə Kubeconfig var. Helm kiçik bir binar gətirir, əgər belə adlandıra bilsəniz, kompüterdə, noutbukda, meynfreymdə - hər hansı bir yerdə quraşdırılmış Helm CLI yardım proqramı.
Lakin bu kifayət deyil. Helm-də Tiller adlı server komponenti var. O, klaster daxilində Helm-in maraqlarını təmsil edir; digərləri kimi, Kubernetes klasterindəki proqramdır.
Chart Repo-nun növbəti komponenti diaqramları olan bir depodur. Rəsmi depo var, şirkətin və ya layihənin özəl deposu da ola bilər.
Qarşılıqlı əlaqə
Helm-dən istifadə edərək proqram quraşdırmaq istədiyimiz zaman arxitektura komponentlərinin qarşılıqlı əlaqəsinə baxaq.
- Danışırıq
Helm install, depoya daxil olun (Chart Repo) və Helm chart əldə edin.
- Helm yardım proqramı (Helm CLI) hansı klasterlə əlaqə saxlayacağını anlamaq üçün Kubeconfig ilə qarşılıqlı əlaqə qurur.
- Bu məlumatı əldə edərək, yardım proqramı bizim klasterimizdə yerləşən Tiller-ə müraciət edir.
- Tiller Kubernetes-də hərəkətləri yerinə yetirmək, bəzi obyektlər (xidmətlər, podlar, replikalar, sirlər və s.) yaratmaq üçün Kube-apiserverə zəng edir.
Sonra, bütün Helm arxitekturasının bütövlükdə məruz qala biləcəyi hücum vektorunu görmək üçün diaqramı çətinləşdirəcəyik. Və sonra onu qorumağa çalışacağıq.
Hücum vektoru
İlk potensial zəif nöqtədir imtiyazlı API-istifadəçi. Sxemin bir hissəsi olaraq, bu Helm CLI-yə admin girişi əldə etmiş bir hakerdir.
İmtiyazsız API istifadəçisi yaxınlıqda olarsa da təhlükə yarada bilər. Belə bir istifadəçinin fərqli konteksti olacaq, məsələn, o, Kubeconfig parametrlərində bir klaster ad məkanında düzəldilə bilər.
Ən maraqlı hücum vektoru Tiller yaxınlığında bir klaster daxilində yerləşən və ona daxil ola bilən proses ola bilər. Bu, klasterin şəbəkə mühitini görən veb server və ya mikroservis ola bilər.
Ekzotik, lakin getdikcə populyarlaşan hücum variantına Chart Repo daxildir. Vicdansız müəllif tərəfindən yaradılmış qrafikdə təhlükəli mənbələr ola bilər və siz onu imanla tamamlayacaqsınız. Və ya o, rəsmi depodan endirdiyiniz diaqramı əvəz edə və məsələn, siyasətlər şəklində resurs yarada və onun girişini artıra bilər.
Gəlin bütün bu dörd tərəfdən hücumları dəf etməyə çalışaq və Helm arxitekturasında problemlərin harada olduğunu və harada, bəlkə də, heç olmadığını anlayaq.
Diaqramı genişləndirək, daha çox element əlavə edək, lakin bütün əsas komponentləri saxlayaq.
Helm CLI Chart Repo ilə əlaqə qurur, Kubeconfig ilə qarşılıqlı əlaqə qurur və iş klasterə Tiller komponentinə ötürülür.
Tiller iki obyektlə təmsil olunur:
- Müəyyən bir xidməti ifşa edən tiller-deploy svc;
- Bütün yükün işlədiyi, klasterə daxil olan tiller-deploy pod (bir replikada bir nüsxədə diaqramda).
Qarşılıqlı əlaqə üçün müxtəlif protokollar və sxemlər istifadə olunur. Təhlükəsizlik baxımından bizi ən çox maraqlandıran:
- Helm CLI-nin qrafik repo-ya daxil olduğu mexanizm: hansı protokol, autentifikasiya var və onunla nə etmək olar.
- Helm CLI-nin kubectl istifadə edərək Tiller ilə əlaqə saxladığı protokol. Bu, klaster daxilində quraşdırılmış RPC serveridir.
- Tiller özü klasterdə yerləşən və Kube-apiserver ilə qarşılıqlı əlaqədə olan mikroservislər üçün əlçatandır.
Gəlin bütün bu sahələri ardıcıllıqla müzakirə edək.
RBAC
RBAC aktivləşdirilmədikcə Helm və ya klaster daxilində hər hansı digər xidmət üçün hər hansı təhlükəsizlik haqqında danışmağın mənası yoxdur.
Görünür, bu, ən son tövsiyə deyil, amma əminəm ki, bir çox insanlar hələ də istehsalda RBAC-ı aktivləşdirməyiblər, çünki bu, çox təlaşdır və çox şey konfiqurasiya edilməlidir. Bununla belə, mən sizi bunu etməyə təşviq edirəm.
— RBAC üçün veb sayt hüquqşünası. Bu, RBAC qurmağınıza kömək edəcək, nə üçün yaxşı olduğunu və istehsalda onunla necə yaşamaq lazım olduğunu göstərməyə kömək edəcək çox sayda maraqlı material ehtiva edir.
Tiller və RBAC-ın necə işlədiyini izah etməyə çalışacağam. Tiller müəyyən bir xidmət hesabı altında klaster daxilində işləyir. Tipik olaraq, əgər RBAC konfiqurasiya edilməyibsə, bu, super istifadəçi olacaq. Əsas konfiqurasiyada Tiller admin olacaq. Buna görə də tez-tez deyilir ki, Tiller çoxluq üçün bir SSH tunelidir. Əslində, bu doğrudur, ona görə də yuxarıdakı diaqramda Defolt Xidmət Hesabı əvəzinə ayrıca xüsusi xidmət hesabından istifadə edə bilərsiniz.
Helm-i işə saldıqda və onu ilk dəfə serverə quraşdırdıqda, istifadə edərək xidmət hesabını təyin edə bilərsiniz --service-account. Bu, minimum tələb olunan hüquqlar dəsti ilə istifadəçidən istifadə etməyə imkan verəcəkdir. Düzdür, belə bir "çələng" yaratmalı olacaqsınız: Rol və Rol Bağlama.
Təəssüf ki, Helm bunu sizin üçün etməyəcək. Siz və ya Kubernetes klaster administratorunuz Helm-dən keçmək üçün əvvəlcədən xidmət hesabı üçün Rollar və Rol Bağlamaları dəsti hazırlamalısınız.
Sual yaranır - Rol və ClusterRole arasındakı fərq nədir? Fərq ondadır ki, ClusterRole yalnız xüsusi ad sahəsi üçün işləyən adi Rollar və RoleBindings-dən fərqli olaraq bütün ad məkanları üçün işləyir. Siz bütün klaster və bütün ad məkanları üçün siyasətləri konfiqurasiya edə və ya hər bir ad sahəsi üçün fərdiləşdirə bilərsiniz.
Qeyd etmək lazımdır ki, RBAC daha bir böyük problemi həll edir. Bir çox insanlar Helm-in təəssüf ki, multitenancy olmadığından şikayətlənir (çox icarədarlığı dəstəkləmir). Bir neçə komanda klasterdən istifadə edirsə və Helm-dən istifadə edirsə, bu klaster daxilində siyasət qurmaq və onların girişini məhdudlaşdırmaq, əsasən mümkün deyil, çünki Helm-in işlədiyi müəyyən bir xidmət hesabı var və o, klasterdəki bütün resursları onun altından yaradır. , bu bəzən çox əlverişsizdir. Bu doğrudur - ikili faylın özü kimi, proses kimi, Helm Tiller çox kirayəlik anlayışına malik deyil.
Bununla belə, bir çoxluqda Tiller-i bir neçə dəfə işə salmağa imkan verən əla bir yol var. Bununla bağlı heç bir problem yoxdur, Tiller hər ad məkanında işə salına bilər. Beləliklə, siz RBAC, Kubeconfig-dən kontekst kimi istifadə edə və xüsusi Helm-ə girişi məhdudlaşdıra bilərsiniz.
Bu belə görünəcək.
Məsələn, müxtəlif komandalar üçün konteksti olan iki Kubeconfig var (iki ad sahəsi): inkişaf qrupu üçün X Komandası və admin klasteri. İdarəetmə klasterinin müvafiq olaraq təkmil xidmət hesabı olan Kube-sistem ad məkanında yerləşən geniş Tiller var. Və inkişaf komandası üçün ayrıca ad sahəsi, onlar xidmətlərini xüsusi ad sahəsinə yerləşdirə biləcəklər.
Bu işlək bir yanaşmadır, Tiller o qədər də gücə ehtiyacı yoxdur ki, büdcənizə böyük təsir göstərəcək. Bu, sürətli həllərdən biridir.
Tilleri ayrıca konfiqurasiya etməkdən çekinmeyin və Kubeconfig-i komanda, müəyyən bir tərtibatçı və ya ətraf mühit üçün kontekstlə təmin edin: Dev, Səhnələşdirmə, İstehsal (hər şeyin eyni klasterdə olacağı şübhəlidir, lakin bunu etmək olar).
Hekayəmizə davam edərək, RBAC-dan keçək və ConfigMaps haqqında danışaq.
ConfigMaps
Helm məlumat anbarı kimi ConfigMaps-dən istifadə edir. Biz memarlıq haqqında danışarkən heç bir yerdə buraxılışlar, konfiqurasiyalar, geri çəkilmələr və s. haqqında məlumatları saxlayan verilənlər bazası yox idi. Bunun üçün ConfigMaps istifadə olunur.
ConfigMaps ilə bağlı əsas problem məlumdur - onlar prinsipcə təhlükəlidirlər; həssas məlumatları saxlamaq mümkün deyil. Xidmətdən kənara çıxmamalı olan hər şeydən, məsələn, parollardan danışırıq. Hal-hazırda Helm üçün ən doğma yol ConfigMaps istifadəsindən sirrlərə keçməkdir.
Bu çox sadə edilir. Tiller parametrini ləğv edin və saxlama yerinin sirr olacağını təyin edin. Sonra hər yerləşdirmə üçün siz ConfigMap deyil, sirr alacaqsınız.
Siz mübahisə edə bilərsiniz ki, sirlər qəribə bir anlayışdır və çox da təhlükəsiz deyil. Bununla belə, Kubernetes tərtibatçılarının özləri bunu etdiyini başa düşməyə dəyər. 1.10 versiyasından başlayaraq, yəni. Artıq bir müddətdir ki, heç olmasa ictimai buludlarda sirləri saxlamaq üçün düzgün anbarı birləşdirmək mümkün olmuşdur. Komanda indi sirrlərə, fərdi podlara və ya digər qurumlara girişi daha yaxşı yaymaq yolları üzərində işləyir.
Storage Helm-i sirrlərə köçürmək daha yaxşıdır və onlar da öz növbəsində mərkəzləşdirilmiş şəkildə qorunur.
Təbii ki, qalacaq məlumat saxlama həddi 1 MB. Helm burada ConfigMaps üçün paylanmış yaddaş kimi etcd istifadə edir. Və orada hesab etdilər ki, bu, replikasiya üçün uyğun bir məlumat parçasıdır və s. Reddit-də bununla bağlı maraqlı müzakirə var, mən həftə sonu üçün bu məzəli oxumağı tapmağı və ya çıxarışı oxumağı məsləhət görürəm. .
Diaqram Reposları
Diaqramlar sosial cəhətdən ən həssasdır və xüsusən də fond həllindən istifadə etsəniz, “Ortadakı adam” mənbəyinə çevrilə bilər. İlk növbədə, HTTP vasitəsilə məruz qalan depolardan danışırıq.
Siz mütləq Helm Repo-nu HTTPS üzərindən ifşa etməlisiniz - bu ən yaxşı seçimdir və ucuzdur.
Qeyd diaqram imza mexanizmi. Texnologiya cəhənnəm qədər sadədir. Bu, ümumi və şəxsi açarları olan adi PGP maşını olan GitHub-da istifadə etdiyiniz eyni şeydir. Quraşdırın və lazımi açarlara sahib olduğunuzdan və hər şeyi imzalayaraq əmin olun ki, bu həqiqətən sizin qrafikinizdir.
Bundan əlavə, Helm müştəri TLS-ni dəstəkləyir (server tərəfi HTTP mənasında deyil, qarşılıqlı TLS). Ünsiyyət qurmaq üçün server və müştəri açarlarından istifadə edə bilərsiniz. Düzünü desəm, mən qarşılıqlı sertifikatları sevmədiyim üçün belə mexanizmdən istifadə etmirəm. Əsasən, - Helm 2 üçün Helm Repo qurmaq üçün əsas alət - həmçinin əsas authanı dəstəkləyir. Daha rahat və səssizdirsə, əsas auth istifadə edə bilərsiniz.
Bir plagin də var , bu, Google Bulud Yaddaşında Diaqram Reposlarını yerləşdirməyə imkan verir. Bu olduqca rahatdır, əla işləyir və olduqca təhlükəsizdir, çünki təsvir olunan bütün mexanizmlər təkrar emal olunur.
Əgər HTTPS və ya TLS-i aktiv etsəniz, mTLS-dən istifadə etsəniz və riskləri daha da azaltmaq üçün əsas audentifikasiyanı aktivləşdirsəniz, Helm CLI və Chart Repo ilə təhlükəsiz rabitə kanalı əldə edəcəksiniz.
gRPC API
Növbəti addım çox vacibdir - klasterdə yerləşən və bir tərəfdən server olan Tiller-in təhlükəsizliyini təmin etmək, digər tərəfdən o, özü digər komponentlərə daxil olur və özünü kimsə kimi göstərməyə çalışır.
Artıq dediyim kimi, Tiller gRPC-ni ifşa edən bir xidmətdir, Helm müştəri ona gRPC vasitəsilə gəlir. Varsayılan olaraq, əlbəttə ki, TLS qeyri-aktivdir. Bunun niyə edildiyi mübahisəli bir sualdır, mənə elə gəlir ki, başlanğıcda quraşdırmanı sadələşdirmək lazımdır.
İstehsal və hətta səhnələşdirmə üçün gRPC-də TLS-ni aktivləşdirməyi tövsiyə edirəm.
Fikrimcə, diaqramlar üçün mTLS-dən fərqli olaraq, bu, burada uyğundur və çox sadə şəkildə edilir - PQI infrastrukturu yaradın, sertifikat yaradın, Tiller-i işə salın, başlanğıc zamanı sertifikatı köçürün. Bundan sonra, yaradılan sertifikat və şəxsi açarla özünüzü təqdim edərək, bütün Helm əmrlərini yerinə yetirə bilərsiniz.
Beləliklə, siz özünüzü klasterdən kənardan Tillerə edilən bütün sorğulardan qoruyacaqsınız.
Beləliklə, biz Tiller ilə əlaqə kanalını təmin etdik, biz artıq RBAC-ı müzakirə etdik və Kubernetes apiserverinin hüquqlarını tənzimlədik, onun qarşılıqlı əlaqə qura biləcəyi domeni azalddıq.
Qorunan Sükan
Son diaqrama baxaq. Eyni oxlarla eyni memarlıqdır.
İndi bütün əlaqələr təhlükəsiz şəkildə yaşıl rənglə çəkilə bilər:
- Chart Repo üçün TLS və ya mTLS və əsas auth istifadə edirik;
- Tiller üçün mTLS və TLS ilə gRPC xidməti kimi təqdim olunur, biz sertifikatlardan istifadə edirik;
- klaster Role və RoleBinding ilə xüsusi xidmət hesabından istifadə edir.
Biz klasteri əhəmiyyətli dərəcədə təmin etdik, lakin ağıllı biri dedi:
"Yalnız bir tamamilə təhlükəsiz həll ola bilər - beton qutuda yerləşən və əsgərlər tərəfindən qorunan söndürülmüş kompüter."
Məlumatları manipulyasiya etməyin və yeni hücum vektorlarını tapmağın müxtəlif yolları var. Bununla belə, mən əminəm ki, bu tövsiyələr təhlükəsizlik üçün əsas sənaye standartına nail olacaq.
Mükafat
Bu hissə təhlükəsizliklə birbaşa əlaqəli deyil, həm də faydalı olacaq. Mən sizə az adamın bildiyi bəzi maraqlı şeyləri göstərəcəyəm. Məsələn, qrafikləri necə axtarmaq olar - rəsmi və qeyri-rəsmi.
Anbarda İndi 300-ə yaxın qrafik və iki axın var: stabil və inkubator. Töhfə verən hər kəs inkubatordan tövləyə keçməyin nə qədər çətin olduğunu və tövlədən uçmağın nə qədər asan olduğunu mükəmməl bilir. Bununla belə, bu, Prometheus və istədiyiniz başqa hər şey üçün qrafikləri axtarmaq üçün ən yaxşı vasitə deyil, sadə bir səbəbə görə - bu, paketləri rahatlıqla axtara biləcəyiniz portal deyil.
Ancaq bir xidmət var , bu da diaqramları tapmağı daha rahat edir. Ən əsası, daha çox xarici depolar və demək olar ki, 800 yaraşıq mövcuddur. Üstəlik, nədənsə qrafiklərinizi stabilə göndərmək istəmirsinizsə, anbarınızı birləşdirə bilərsiniz.
hub.helm.sh-i sınayın və gəlin onu birlikdə inkişaf etdirək. Bu xidmət Helm layihəsi çərçivəsindədir və siz hətta qabaqcıl inkişaf etdiricisinizsə və sadəcə görünüşü yaxşılaşdırmaq istəyirsinizsə, onun UI-yə töhfə verə bilərsiniz.
Mən də diqqətinizi çəkmək istərdim Open Service Broker API inteqrasiyası. Bu, çətin və anlaşılmaz səslənir, lakin hər kəsin qarşılaşdığı problemləri həll edir. Sadə bir misalla izah edim.
Klassik bir tətbiqi - WordPress-i işə salmaq istədiyimiz Kubernetes klasteri var. Ümumiyyətlə, tam funksionallıq üçün verilənlər bazası lazımdır. Çox müxtəlif həllər var, məsələn, siz öz dövlət xidmətinizi işə sala bilərsiniz. Bu çox rahat deyil, amma çoxları bunu edir.
Digərləri, Chainstack-də bizim kimi, serverləri üçün MySQL və ya PostgreSQL kimi idarə olunan verilənlər bazalarından istifadə edirlər. Buna görə də məlumat bazalarımız buludda bir yerdə yerləşir.
Ancaq bir problem yaranır: xidmətimizi verilənlər bazası ilə əlaqələndirməliyik, verilənlər bazası ləzzəti yaratmalı, etimadnaməni köçürməli və birtəhər idarə etməliyik. Bütün bunlar adətən sistem administratoru və ya tərtibatçı tərəfindən əl ilə edilir. Və ərizələr az olanda heç bir problem yoxdur. Onlar çox olduqda, bir kombayn lazımdır. Belə bir kombayn var - bu Service Brokerdir. O, ictimai bulud klasteri üçün xüsusi plaqindən istifadə etməyə və sanki API kimi Broker vasitəsilə provayderdən resurslar sifariş etməyə imkan verir. Bunun üçün yerli Kubernetes alətlərindən istifadə edə bilərsiniz.
Çox sadədir. Siz, məsələn, Azure-da idarə olunan MySQL-i əsas səviyyə ilə sorğulaya bilərsiniz (bu, konfiqurasiya edilə bilər). Azure API istifadə edərək verilənlər bazası yaradılacaq və istifadəyə hazırlanacaq. Buna müdaxilə etmək lazım deyil, plagin buna cavabdehdir. Məsələn, OSBA (Azure plagini) etimadnaməni xidmətə qaytaracaq və onu Helm-ə ötürəcək. Siz WordPress-i bulud MySQL ilə istifadə edə biləcəksiniz, idarə olunan verilənlər bazası ilə ümumiyyətlə məşğul olmayacaqsınız və içəridəki tam xidmətlərdən narahat olmayacaqsınız.
Deyə bilərik ki, Helm bir tərəfdən xidmətləri yerləşdirməyə imkan verən, digər tərəfdən isə bulud provayderlərinin resurslarını istehlak edən yapışqan rolunu oynayır.
Öz plagininizi yaza və bütün bu hekayəni yerində istifadə edə bilərsiniz. Onda sadəcə olaraq korporativ Bulud provayderi üçün öz plagininiz olacaq. Bu yanaşmanı sınamağı məsləhət görürəm, xüsusən də geniş miqyaslısınızsa və bir xüsusiyyət üçün inkişaf, səhnələşdirmə və ya bütün infrastrukturu tez bir zamanda yerləşdirmək istəyirsinizsə. Bu, əməliyyatlarınız və ya DevOps üçün həyatı asanlaşdıracaq.
Artıq qeyd etdiyim başqa bir tapıntıdır helm-gcs plagini, bu sizə Helm diaqramlarını saxlamaq üçün Google-buckets (obyekt saxlama) istifadə etməyə imkan verir.
Onu istifadə etməyə başlamaq üçün sizə yalnız dörd əmr lazımdır:
- plagini quraşdırın;
- başlamaq;
- gcp-də olan çömçəyə gedən yolu təyin edin;
- qrafikləri standart şəkildə dərc edin.
Gözəllik ondadır ki, avtorizasiya üçün yerli gcp metodundan istifadə olunacaq. İstədiyiniz hər hansı bir xidmət hesabından, inkişaf etdirici hesabından istifadə edə bilərsiniz. Çox rahatdır və işləmək üçün heç bir xərc tələb etmir. Əgər siz də mənim kimi opsless fəlsəfəni təbliğ etsəniz, bu, xüsusilə kiçik komandalar üçün çox rahat olacaq.
Alternativlər
Helm yeganə xidmət idarəetmə həlli deyil. Bununla bağlı çoxlu suallar var, yəqin ki, üçüncü versiyanın belə tez ortaya çıxmasının səbəbi budur. Təbii ki, alternativlər var.
Bunlar xüsusi həllər ola bilər, məsələn, Ksonnet və ya Metaparticle. Siz klassik infrastruktur idarəetmə alətlərinizdən (Ansible, Terraform, Chef və s.) haqqında danışdığım eyni məqsədlər üçün istifadə edə bilərsiniz.
Nəhayət, bir həll var , kimin populyarlığı artır.
Operator Framework nəzərə alınmalı olan ən yaxşı Helm alternatividir.
CNCF və Kubernetes üçün daha çox doğmadır, lakin giriş maneəsi daha yüksəkdir, daha çox proqramlaşdırmalı və manifestləri daha az təsvir etməlisiniz.
Draft, Scaffold kimi müxtəlif əlavələr var. Onlar həyatı çox asanlaşdırır, məsələn, test mühitini yerləşdirmək üçün tərtibatçılar üçün Helm göndərmə və işə salma dövrünü sadələşdirirlər. Mən onlara güc verənlər deyərdim.
Budur, hər şeyin harada olduğunu göstərən vizual diaqram.
X oxunda baş verənlərə şəxsi nəzarətinizin səviyyəsi, y oxunda Kubernetesin doğmalıq səviyyəsidir. Helm versiyası 2 ortada bir yerə düşür. 3-cü versiyada çox deyil, həm nəzarət, həm də doğmalıq səviyyəsi yaxşılaşdırıldı. Ksonnet səviyyəsində həllər hələ də Helm 2-dən aşağıdır. Bununla belə, bu dünyada başqa nələrin olduğunu bilmək üçün onlara baxmağa dəyər. Əlbəttə ki, konfiqurasiya meneceriniz nəzarətinizdə olacaq, lakin o, tamamilə Kubernetes üçün doğma deyil.
Operator Çərçivəsi tamamilə Kubernetes üçün doğmadır və onu daha zərif və diqqətlə idarə etməyə imkan verir (lakin giriş səviyyəsini xatırlayın). Əksinə, bu, Helm-dən istifadə edərək çox sayda tətbiqin qablaşdırılması üçün kütləvi kombayn deyil, ixtisaslaşmış tətbiq və onun üçün idarəetmənin yaradılması üçün uyğundur.
Genişləndiricilər sadəcə nəzarəti bir az təkmilləşdirir, iş prosesini tamamlayır və ya CI/CD boru kəmərlərində küncləri kəsir.
Helmin gələcəyi
Yaxşı xəbər odur ki, Helm 3 gəlir. Helm 3.0.0-alpha.2-nin alfa versiyası artıq buraxılıb, onu sınaqdan keçirə bilərsiniz. Bu olduqca sabitdir, lakin funksionallıq hələ də məhduddur.
Niyə sizə Helm 3 lazımdır? Əvvəla, bu, haqqında bir hekayədir Tillerin yoxa çıxması, komponent kimi. Bu, artıq başa düşdüyünüz kimi, irəliyə doğru böyük bir addımdır, çünki memarlığın təhlükəsizliyi baxımından hər şey sadələşdirilmişdir.
Kubernetes 2 və ya daha əvvəlki dövrlərdə olan Helm 1.8 yaradılanda bir çox anlayışlar yetişməmişdi. Məsələn, CRD konsepsiyası indi fəal şəkildə həyata keçirilir və Helm də həyata keçirəcək CRD istifadə edinstrukturları saxlamaq üçün. Yalnız müştəridən istifadə etmək mümkün olacaq və server hissəsini saxlamaq mümkün olacaq. Müvafiq olaraq, strukturlar və resurslarla işləmək üçün doğma Kubernetes əmrlərindən istifadə edin. Bu, irəliyə doğru böyük bir addımdır.
Görünəcək yerli OCI depolarına dəstək (Açıq Konteyner Təşəbbüsü). Bu, böyük bir təşəbbüsdür və Helm ilk növbədə öz qrafiklərini yerləşdirməklə maraqlanır. Məsələn, Docker Hub bir çox OCI standartlarını dəstəkləyir. Mən təxmin etmirəm, amma bəlkə də klassik Docker repozitoriya provayderləri sizə Helm diaqramlarınızı yerləşdirmək imkanı verməyə başlayacaqlar.
Mənim üçün mübahisəli hekayədir Lua dəstəyi, skriptlərin yazılması üçün şablon mühərriki kimi. Mən Luanın böyük bir pərəstişkarı deyiləm, lakin bu, tamamilə isteğe bağlı bir xüsusiyyət olardı. Mən bunu 3 dəfə yoxladım - Lua istifadə etmək lazım olmayacaq. Buna görə də, Lua-dan istifadə etmək istəyənlər, Go-nu sevənlər bizim böyük düşərgəmizə qoşulun və bunun üçün go-tmpl-dən istifadə edin.
Nəhayət, qətiyyən əskik olduğum şey idi sxemin yaranması və məlumat növünün yoxlanılması. Artıq int və ya sətirlə bağlı problem olmayacaq, sıfırı ikiqat dırnaq işarəsinə yığmağa ehtiyac yoxdur. Bunu dəyərlər üçün açıq şəkildə təsvir etməyə imkan verəcək JSONS sxemi görünəcək.
Ciddi şəkildə yenidən işlənəcək hadisəyə əsaslanan model. Artıq konseptual olaraq təsvir edilmişdir. Helm 3 filialına baxın və siz nə qədər hadisə, qarmaq və başqa şeylərin əlavə olunduğunu görəcəksiniz, bu, çox sadələşdirəcək və digər tərəfdən, yerləşdirmə prosesləri və onlara reaksiyalar üzərində nəzarət əlavə edəcək.
Helm 3, Helm 2-ni bəyənmədiyimizə görə deyil, Kubernetes daha təkmilləşdiyinə görə daha sadə, təhlükəsiz və daha əyləncəli olacaq. Müvafiq olaraq, Helm Kubernetes-in inkişaflarından istifadə edə və onun üzərində Kubernetes üçün əla menecerlər yarada bilər.
Başqa bir yaxşı xəbər də budur Aleksandr Xayorov sizə deyəcək: Nəzərinizə çatdıraq ki, inkişaf, sınaq və istismar proseslərinin inteqrasiyası üzrə konfrans Moskvada keçiriləcək 30 sentyabr və 1 oktyabr. Siz hələ avqustun 20-nə kimi edə bilərsiniz və həll təcrübəniz haqqında bizə məlumat verin DevOps yanaşmasının vəzifələri.
Konfrans keçid məntəqələrini və xəbərləri burada izləyin и .
Mənbə: www.habr.com