Qeyd. tərcümə.: bu material təhsil layihəsindəndir - Kubernetes əsasında infrastruktur layihələndirərkən məşhur sualın cavabı. Ümid edirik ki, variantların hər birinin müsbət və mənfi tərəflərinin kifayət qədər ətraflı təsviri layihəniz üçün ən yaxşı seçimi etməyə kömək edəcəkdir.
TL; DR: eyni iş yükləri dəsti bir neçə böyük klasterdə (hər klasterdə çoxlu sayda iş yükü olacaq) və ya bir çox kiçik klasterdə (hər klasterdə az sayda iş yükü ilə) idarə oluna bilər.
Aşağıda hər bir yanaşmanın müsbət və mənfi tərəflərini qiymətləndirən bir cədvəl var:
Kubernetes-dən tətbiqləri işə salmaq üçün platforma kimi istifadə edərkən, çox vaxt klasterlərin konfiqurasiyasının incəlikləri ilə bağlı bir neçə əsas sual yaranır:
- Neçə klasterdən istifadə etmək lazımdır?
- Onları nə qədər böyük etməlisiniz?
- Hər bir klasterə nə daxil edilməlidir?
Bu yazıda hər bir yanaşmanın müsbət və mənfi tərəflərini təhlil edərək bütün bu suallara cavab verməyə çalışacağam.
Bir sualın ifadəsi
Bir proqram tərtibatçısı olaraq, çox güman ki, paralel olaraq bir çox tətbiqi inkişaf etdirəcək və işlədə bilərsiniz.
Bundan əlavə, bu proqramların bir çox nümunələri müxtəlif mühitlərdə işləyə bilər - məsələn, bunlar ola bilər dev, sınaq и prod.
Nəticə tətbiqlərin və mühitlərin tam matrisidir:
Tətbiqlər və mühitlər
Yuxarıdakı misalda 3 proqram və 3 mühit var, nəticədə cəmi 9 mümkün variant var.
Hər bir tətbiq nümunəsi digərlərindən asılı olmayaraq işləyə biləcəyiniz müstəqil yerləşdirmə vahididir.
Qeyd edin ki, tətbiq nümunəsi çoxlarından ibarət ola bilər komponentləriməsələn, frontend, backend, verilənlər bazası və s. Mikroservis tətbiqi vəziyyətində nümunə bütün mikroxidmətləri əhatə edəcək.
Nəticədə Kubernetes istifadəçilərinin bir neçə sualı var:
- Bütün tətbiq nümunələri eyni klasterdə yerləşdirilməlidirmi?
- Hər bir tətbiq nümunəsi üçün ayrıca klaster yaratmağa dəyərmi?
- Və ya bəlkə yuxarıda göstərilən yanaşmaların kombinasiyası istifadə edilməlidir?
Kubernetes istifadəçinin seçimlərini məhdudlaşdırmayan çevik sistem olduğundan bu seçimlərin hamısı etibarlıdır.
Mümkün yollardan bəziləri bunlardır:
- bir böyük ümumi klaster;
- çoxlu kiçik yüksək ixtisaslaşmış klasterlər;
- hər tətbiq üçün bir klaster;
- hər mühitə bir klaster.
Aşağıda göstərildiyi kimi, ilk iki yanaşma seçimlər miqyasının əks tərəfindədir:
Bir neçə böyük qrupdan (solda) bir çox kiçik qrupa (sağda)
Ümumiyyətlə, bir klasterin qovşaqların və qovşaqların cəmindən çox olduğu halda digərindən "böyük" olduğu hesab edilir. Məsələn, 10 qovşaq və 100 qovşaq olan klaster, 1 qovşaq və 10 qovşaqlı çoxluqdan daha böyükdür.
Yaxşı, başlayaq!
1. Bir böyük paylaşılan klaster
Birinci seçim bütün iş yüklərini bir klasterə yerləşdirməkdir:
Bir böyük klaster
Bu yanaşma çərçivəsində klaster universal kimi istifadə olunur infrastruktur platforması - sadəcə olaraq sizə lazım olan hər şeyi mövcud Kubernetes klasterində yerləşdirirsiniz.
Kubernetes sizə klasterin hissələrini məntiqi olaraq bir-birindən ayırmağa imkan verir ki, hər bir tətbiq nümunəsi öz ad məkanından istifadə edə bilsin.
Bu yanaşmanın müsbət və mənfi tərəflərinə baxaq.
+ Resurslardan səmərəli istifadə
Tək klaster vəziyyətində, Kubernetes klasterini işə salmaq və idarə etmək üçün lazım olan bütün resursların yalnız bir nüsxəsi tələb olunacaq.
Məsələn, bu master qovşaqlar üçün doğrudur. Tipik olaraq, hər Kubernetes klasterində 3 əsas qovşaq var, buna görə də bir klaster üçün onların sayı belə qalacaq (müqayisə üçün 10 klasterə 30 əsas qovşaq lazımdır).
Yuxarıdakı incəlik yük balanslaşdırıcıları, Giriş nəzarətçiləri, autentifikasiya, giriş və monitorinq sistemləri kimi bütün klasterdə işləyən digər xidmətlərə də aiddir.
Vahid klasterdə bütün bu xidmətlər birdən bütün iş yükləri üçün istifadə oluna bilər (çoxlu klasterlərdə olduğu kimi onların surətlərini yaratmağa ehtiyac yoxdur).
+ ucuz
Yuxarıda göstərilənlərin nəticəsi olaraq, daha az klaster adətən daha ucuz olur, çünki artıq resurslar üçün heç bir xərc yoxdur.
Bu, xüsusilə yerli və ya buludda yerləşdirilməsindən asılı olmayaraq əhəmiyyətli miqdarda pula başa gələ bilən masternodlar üçün doğrudur.
Kimi bəzi idarə olunan Kubernetes xidmətləri və ya , nəzarət qatını pulsuz təmin edin. Bu halda xərclər məsələsi daha az kəskin olur.
Hər bir Kubernetes klasterinin işləməsi üçün sabit ödəniş tələb edən idarə olunan xidmətlər də var (məsələn, ).
+ Səmərəli idarəetmə
Bir çoxluğu idarə etmək bir neçə qrupdan daha asandır.
İdarəetmə aşağıdakı vəzifələri əhatə edə bilər:
- Kubernetes versiyasının yenilənməsi;
- CI/CD boru kəmərinin konfiqurasiyası;
- CNI plagininin quraşdırılması;
- istifadəçinin autentifikasiya sisteminin qurulması;
- qəbul nəzarətçisinin quraşdırılması;
və bir çox başqaları...
Tək bir çoxluq vəziyyətində, bütün bunları yalnız bir dəfə etməli olacaqsınız.
Bir çox klasterlər üçün əməliyyatlar dəfələrlə təkrarlanmalı olacaq ki, bu da yəqin ki, sistemli və vahid prosesi təmin etmək üçün proseslərin və vasitələrin müəyyən qədər avtomatlaşdırılmasını tələb edəcək.
İndi mənfi cəhətləri haqqında bir neçə kəlmə.
- Bir uğursuzluq nöqtəsi
İmtina edildiyi halda yalnız klasterlər dərhal fəaliyyətini dayandıracaq bütün iş yükü!
Bir şeyin səhv getməsi üçün bir çox variant var:
- Kubernetes yeniləməsi gözlənilməz yan təsirlərə səbəb olur
- klaster miqyaslı komponent (məsələn, CNI plagini) gözlənildiyi kimi işə başlamır;
- klaster komponentlərindən biri səhv konfiqurasiya edilmişdir;
- əsas infrastrukturda uğursuzluq.
Belə hadisələrdən biri ümumi qrupda yerləşdirilən bütün iş yüklərinə ciddi ziyan vura bilər.
− Sərt izolyasiyanın olmaması
Paylaşılan klasterdə işləmək o deməkdir ki, proqramlar klaster qovşaqlarında aparat, şəbəkə imkanları və əməliyyat sistemini paylaşır.
Müəyyən mənada, eyni hostda işləyən iki fərqli tətbiqi olan iki konteyner eyni OS nüvəsi ilə işləyən eyni maşında işləyən iki proses kimidir.
Linux konteynerləri bir növ izolyasiya təmin edir, lakin o, virtual maşınların təmin etdiyi qədər güclü deyil. Əslində, konteynerdəki proses ana əməliyyat sistemində işləyən eyni prosesdir.
Bu təhlükəsizlik problemi ola bilər: bu təşkilat nəzəri olaraq əlaqəsi olmayan proqramların bir-biri ilə əlaqə saxlamasına imkan verir (qəsdən və ya təsadüfən).
Bundan əlavə, Kubernetes klasterindəki bütün iş yükləri bəzi klaster miqyaslı xidmətləri paylaşır, məsələn - bu, proqramlara klasterdəki digər proqramların Xidmətlərini tapmağa imkan verir.
Yuxarıdakı məqamların hamısı tətbiqin təhlükəsizlik tələblərindən asılı olaraq müxtəlif mənalara malik ola bilər.
Kubernetes kimi təhlükəsizlik problemlərinin qarşısını almaq üçün müxtəlif vasitələr təqdim edir и . Bununla belə, düzgün konfiqurasiya etmək üçün müəyyən təcrübə tələb olunur və onlar tamamilə bütün təhlükəsizlik boşluqlarını bağlaya bilmirlər.
Kubernetesin əvvəlcə bunun üçün nəzərdə tutulduğunu həmişə xatırlamaq vacibdir paylaşma, üçün deyil izolyasiya və təhlükəsizlik.
− Sərt çoxlu kirayəçiliyin olmaması
Kubernetes klasterində paylaşılan resursların çoxluğunu nəzərə alsaq, müxtəlif tətbiqlərin bir-birinin ayaq barmaqlarına basa biləcəyi bir çox yol var.
Məsələn, proqram paylaşılan resursu (məsələn, prosessor və ya yaddaş) monopoliya altına ala və eyni hostda işləyən digər proqramların ona girişini rədd edə bilər.
Kubernetes bu davranışı idarə etmək üçün müxtəlif mexanizmlər təqdim edir, məsələn (həmçinin məqaləyə baxın ""- təqribən. tərcümə.), и . Bununla belə, təhlükəsizlik vəziyyətində olduğu kimi, onların konfiqurasiyası olduqca qeyri-ciddidir və onlar tamamilə gözlənilməz yan təsirlərin qarşısını ala bilmirlər.
− Çox sayda istifadəçi
Tək bir çoxluq vəziyyətində, bir çox insan üçün ona girişi açmalısınız. Onların sayı nə qədər çox olsa, nəyisə “sındırmaq” riski bir o qədər yüksəkdir.
Klaster daxilində kimin nə edə biləcəyini idarə edə bilərsiniz ("məqaləsinə baxın""- təqribən. tərcümə.). Bununla belə, bu, istifadəçilərin məsuliyyət dairələri daxilində nəyisə “sındırmasına” mane olmayacaq.
− Klasterlər sonsuza qədər böyüyə bilməz
Bütün iş yükləri üçün istifadə edilən klaster, çox güman ki, olduqca böyükdür (qovşaqların və podların sayı baxımından).
Ancaq burada başqa bir problem yaranır: Kubernetesdəki klasterlər sonsuza qədər böyüyə bilməz.
Klaster ölçüsündə nəzəri məhdudiyyət var. Kubernetesdə təxminən belədir .
Ancaq real həyatda problemlər daha erkən başlaya bilər - məsələn, yalnız nə vaxt .
Məsələ burasındadır ki, böyük klasterlər Kubernetes idarəetmə qatına yüksək yük verir. Başqa sözlə, klasterin işlək vəziyyətdə qalması və səmərəli işləməsi üçün diqqətli tənzimləmə tələb olunur.
Bu məsələ orijinal bloqda " başlıqlı əlaqəli məqalədə araşdırılır..
Ancaq əks yanaşmanı nəzərdən keçirək: çoxlu kiçik klasterlər.
2. Çoxlu kiçik, ixtisaslaşmış klasterlər
Bu yanaşma ilə siz yerləşdirdiyiniz hər bir element üçün ayrıca klasterdən istifadə edirsiniz:
Çoxlu kiçik qruplar
Bu maddənin məqsədləri üçün yerləşdirilə bilən element tətbiqin nümunəsi kimi başa düşülür - məsələn, ayrıca proqramın dev versiyası.
Bu strategiyada Kubernetes ixtisaslaşmış kimi istifadə olunur icra müddəti fərdi tətbiq halları üçün.
Bu yanaşmanın müsbət və mənfi tərəflərinə baxaq.
+ Məhdud "partlayış radiusu"
Klaster "sındırıldığında" mənfi nəticələr yalnız bu klasterdə yerləşdirilmiş iş yükləri ilə məhdudlaşır. Bütün digər iş yükləri toxunulmaz qalır.
+ İzolyasiya
Fərdi klasterlərdə yerləşdirilən iş yükləri prosessor, yaddaş, əməliyyat sistemi, şəbəkə və ya digər xidmətlər kimi ümumi resursları paylaşmır.
Nəticədə, əlaqəsi olmayan proqramlar arasında güclü izolyasiya əldə edirik ki, bu da onların təhlükəsizliyi üçün faydalı ola bilər.
+ Az sayda istifadəçi
Nəzərə alsaq ki, hər bir klaster yalnız məhdud sayda iş yükünü ehtiva edir, ona girişi olan istifadəçilərin sayı azalır.
Klasterə çıxışı olan insanlar nə qədər az olsa, nəyinsə “qırılması” riski bir o qədər az olar.
Mənfi cəhətlərə baxaq.
− Resurslardan səmərəsiz istifadə
Daha əvvəl qeyd edildiyi kimi, hər bir Kubernetes klasteri müəyyən idarəetmə resursları dəsti tələb edir: əsas qovşaqlar, nəzarət qatının komponentləri, monitorinq və giriş həlləri.
Çoxlu sayda kiçik klasterlər olduqda, resursların daha böyük payı idarəetməyə ayrılmalıdır.
− Bahalı
Resurslardan səmərəsiz istifadə avtomatik olaraq yüksək xərclərə səbəb olur.
Məsələn, eyni hesablama gücünə malik üç əvəzinə 30 masternodun saxlanması mütləq xərclərə təsir edəcəkdir.
− İdarəetmədə çətinliklər
Birdən çox Kubernetes klasterini idarə etmək birini idarə etməkdən qat-qat çətindir.
Məsələn, hər bir klaster üçün autentifikasiya və avtorizasiyanı konfiqurasiya etməli olacaqsınız. Kubernetes versiyasını təkmilləşdirmək də bir neçə dəfə aparılmalı olacaq.
Çox güman ki, bütün bu vəzifələrin səmərəliliyini artırmaq üçün avtomatlaşdırma tətbiq etməlisiniz.
İndi daha az ekstremal ssenariləri nəzərdən keçirin.
3. Hər tətbiq üçün bir klaster
Bu yanaşma ilə siz müəyyən bir tətbiqin bütün nümunələri üçün ayrıca klaster yaradırsınız:
Tətbiq başına klaster
Bu yolu prinsipin ümumiləşdirilməsi hesab etmək olar”komanda başına ayrı klaster” çünki adətən mühəndislər qrupu bir və ya bir neçə tətbiqin hazırlanmasında iştirak edir.
Bu yanaşmanın müsbət və mənfi tərəflərinə baxaq.
+ Klaster proqrama uyğunlaşdırıla bilər
Tətbiqin xüsusi ehtiyacları varsa, onlar digər klasterlərə təsir etmədən klasterdə həyata keçirilə bilər.
Belə ehtiyaclara GPU işçiləri, müəyyən CNI plaginləri, xidmət şəbəkəsi və ya digər xidmətlər daxil ola bilər.
Hər bir klaster yalnız lazım olanı ehtiva etmək üçün üzərində işləyən proqrama uyğunlaşdırıla bilər.
− Bir klasterdə müxtəlif mühitlər
Bu yanaşmanın dezavantajı müxtəlif mühitlərdən olan tətbiq nümunələrinin eyni klasterdə birgə mövcud olmasıdır.
Məsələn, proqramın məhsul versiyası dev versiyası ilə eyni klasterdə işləyir. Bu həm də o deməkdir ki, tərtibatçılar proqramın istehsal versiyası ilə eyni klasterdə işləyirlər.
Əgər klaster tərtibatçıların hərəkətləri və ya dev versiyadakı nasazlıqlar səbəbindən uğursuz olarsa, o zaman məhsul versiyası potensial olaraq zərər çəkə bilər - bu yanaşmanın böyük çatışmazlığı.
Və nəhayət, siyahımızda olan son ssenari.
4. Hər mühit üçün bir klaster
Bu ssenari hər bir mühit üçün ayrıca klasterin ayrılmasını təmin edir:
Hər mühit üçün bir klaster
Məsələn, klasterləriniz ola bilər dev, sınaq и prod, burada müəyyən bir mühit üçün nəzərdə tutulmuş tətbiqin bütün nümunələrini işlədəcəksiniz.
Bu yanaşmanın müsbət və mənfi tərəfləri bunlardır.
+ Məhsul mühitinin izolyasiyası
Bu yanaşma çərçivəsində bütün mühitlər bir-birindən təcrid olunur. Bununla belə, praktikada bu, istehsal mühiti üçün xüsusilə vacibdir.
Tətbiqin istehsal versiyaları indi digər klasterlərdə və mühitlərdə baş verənlərdən müstəqildir.
Beləliklə, inkişaf klasterində birdən problem yaranarsa, proqramların istehsal versiyaları heç nə olmamış kimi işləməyə davam edəcək.
+ Çoxluq ətraf mühitə uyğunlaşdırıla bilər
Hər bir klaster öz mühitinə uyğunlaşdırıla bilər. Məsələn, edə bilərsiniz:
- dev klasterində inkişaf və sazlama üçün alətlər quraşdırmaq;
- klasterdə test çərçivələri və alətləri quraşdırın sınaq;
- klasterdə daha güclü aparat və şəbəkə bağlantılarından istifadə edin prod.
Bu, həm proqram inkişafının, həm də əməliyyatın səmərəliliyini artırır.
+ İstehsal klasterinə girişin məhdudlaşdırılması
Bir məhsul klasteri ilə birbaşa işləmək ehtiyacı tez-tez yaranmır, buna görə də ona çıxışı olan insanların dairəsini əhəmiyyətli dərəcədə məhdudlaşdıra bilərsiniz.
Siz daha da irəli gedə və insanları bu klasterə girişdən tamamilə məhrum edə və avtomatlaşdırılmış CI / CD alətindən istifadə edərək bütün yerləşdirmələri edə bilərsiniz. Bu cür yanaşma insan səhvləri riskini ən uyğun olduğu yerdə minimuma endirəcəkdir.
İndi mənfi cəhətləri haqqında bir neçə kəlmə.
− Tətbiqlər arasında izolyasiyanın olmaması
Bu yanaşmanın əsas çatışmazlığı proqramlar arasında aparat və resurs izolyasiyasının olmamasıdır.
Əlaqəsi olmayan proqramlar klaster resurslarını paylaşır: sistem nüvəsi, prosessor, yaddaş və bəzi digər xidmətlər.
Artıq qeyd edildiyi kimi, bu potensial təhlükəli ola bilər.
− Tətbiqdən asılılıqların lokallaşdırıla bilməməsi
Tətbiqin xüsusi tələbləri varsa, onlar bütün qruplarda təmin edilməlidir.
Məsələn, tətbiqin GPU-ya ehtiyacı varsa, hər bir klasterdə GPU-lu ən azı bir işçi olmalıdır (yalnız bu proqram tərəfindən istifadə olunsa belə).
Nəticədə biz daha yüksək xərclər və resurslardan səmərəsiz istifadə riski ilə üzləşirik.
Nəticə
Müəyyən bir proqram dəsti varsa, onlar bir neçə böyük qrupa və ya bir çox kiçik qruplara yerləşdirilə bilər.
Məqalədə bir qlobal klasterdən tutmuş bir neçə kiçik və yüksək ixtisaslaşdırılmış yanaşmalara qədər müxtəlif yanaşmaların müsbət və mənfi cəhətləri müzakirə olunur:
- bir böyük ümumi klaster;
- çoxlu kiçik yüksək ixtisaslaşmış klasterlər;
- hər tətbiq üçün bir klaster;
- hər mühitə bir klaster.
Beləliklə, hansı yanaşmanı seçməlisiniz?
Həmişə olduğu kimi, cavab istifadə vəziyyətindən asılıdır: müxtəlif yanaşmaların müsbət və mənfi cəhətlərini ölçməli və ən yaxşı variantı seçməlisiniz.
Bununla belə, seçim yuxarıda göstərilən nümunələrlə məhdudlaşmır - onların hər hansı bir birləşməsindən istifadə edə bilərsiniz!
Məsələn, hər komanda üçün bir cüt klaster təşkil edə bilərsiniz: inkişaf üçün klaster (mühitləri olacaq) dev и sınaq) və üçün klaster istehsal (istehsal mühitinin harada olacağı).
Bu məqalədəki məlumatlara əsaslanaraq, müəyyən bir ssenari üçün müsbət və mənfi cəhətləri optimallaşdıra biləcəksiniz. Uğurlar!
PS
Bloqumuzda da oxuyun:
- «";
- «";
- «";
- «.
Mənbə: www.habr.com