Kubernetes qruplaşdırılmış istehsal mühitində Docker konteynerlərini işə salmaq üçün əla vasitədir. Bununla belə, Kubernetesin həll edə bilmədiyi problemlər var. Tez-tez istehsal yerləşdirmələri üçün, prosesdə fasilələrin qarşısını almaq üçün tam avtomatlaşdırılmış Mavi/Yaşıl yerləşdirmə lazımdır ki, bu da xarici HTTP sorğularını idarə etməli və SSL yükləmələrini yerinə yetirməlidir. Bu, ha-proxy kimi yük balanslaşdırıcısı ilə inteqrasiya tələb edir. Digər bir problem, bulud mühitində işləyərkən Kubernetes klasterinin özünün yarı avtomatik miqyaslanmasıdır, məsələn, gecələr klasterin qismən kiçilməsi.
Kubernetes-də bu xüsusiyyətlər qutudan kənarda olmasa da, oxşar problemləri həll etmək üçün istifadə edə biləcəyiniz API təmin edir. Açıq mənbə əsasında yaradılmış Bulud RTI layihəsinin bir hissəsi kimi Kubernetes klasterinin avtomatlaşdırılmış Mavi/Yaşıl yerləşdirilməsi və miqyası üçün alətlər hazırlanmışdır.
Video transkript olan bu məqalə, istehsalda fasilələr olmadan git öhdəliyindən kodu qəbul edən istehsala hazır mühit yaratmaq üçün digər açıq mənbə komponentləri ilə birlikdə Kubernetes-i necə quracağınızı göstərir.
Beləliklə, xarici dünyadan tətbiqlərinizə giriş əldə etdikdən sonra siz avtomatlaşdırmanı tam qurmağa başlaya bilərsiniz, yəni onu git commitini yerinə yetirə biləcəyiniz mərhələyə gətirə və bu git commitinin istehsalda bitməsinə əmin ola bilərsiniz. Təbii ki, bu addımları həyata keçirərkən, yerləşdirməni həyata keçirərkən, dayanma vaxtı ilə qarşılaşmaq istəmirik. Beləliklə, Kubernetes-də istənilən avtomatlaşdırma API ilə başlayır.
Kubernetes qutudan kənarda məhsuldar istifadə edilə bilən bir vasitə deyil. Əlbəttə ki, siz bunu edə bilərsiniz, kubectl istifadə edin və sair, amma yenə də API bu platformada ən maraqlı və faydalı şeydir. API-dən funksiyalar dəsti kimi istifadə etməklə siz Kubernetes-də etmək istədiyiniz demək olar ki, hər şeyə daxil ola bilərsiniz. kubectl özü də REST API-dən istifadə edir.
Bu REST-dir, ona görə də siz bu API ilə işləmək üçün istənilən dil və ya alətdən istifadə edə bilərsiniz, lakin fərdi kitabxanalar sizin həyatınızı xeyli asanlaşdıracaq. Komandam 2 belə kitabxana yazdı: biri Java/OSGi üçün, biri isə Go üçün. İkincisi tez-tez istifadə edilmir, lakin hər halda bu faydalı şeylər sizin ixtiyarınızdadır. Onlar qismən lisenziyalı açıq mənbəli layihədir. Müxtəlif dillər üçün belə kitabxanalar çoxdur, ona görə də sizə ən uyğun olanı seçə bilərsiniz.
Beləliklə, yerləşdirmənizi avtomatlaşdırmağa başlamazdan əvvəl, prosesin heç bir fasiləyə məruz qalmadığından əmin olmalısınız. Məsələn, komandamız insanların tətbiqlərdən maksimum istifadə etdiyi günün ortasında istehsal yerləşdirmələri həyata keçirir, ona görə də bu prosesdə gecikmələrin qarşısını almaq vacibdir. Boş vaxtların qarşısını almaq üçün 2 üsuldan istifadə olunur: mavi/yaşıl yerləşdirmə və ya yuvarlanan yeniləmə. Sonuncu halda, əgər sizdə işləyən proqramın 5 replikası varsa, onlar ardıcıl olaraq bir-birinin ardınca yenilənir. Bu üsul əla işləyir, lakin yerləşdirmə prosesi zamanı eyni vaxtda işləyən tətbiqin müxtəlif versiyaları varsa, bu uyğun deyil. Bu halda, backend köhnə versiya ilə işləyərkən istifadəçi interfeysini yeniləyə bilərsiniz və proqram işləməyi dayandıracaq. Ona görə də proqramlaşdırma nöqteyi-nəzərindən belə şəraitdə işləmək kifayət qədər çətindir.
Bu, tətbiqlərimizin yerləşdirilməsini avtomatlaşdırmaq üçün mavi/yaşıl yerləşdirmədən istifadə etməyimizin səbəblərindən biridir. Bu üsulla, eyni anda tətbiqin yalnız bir versiyasının aktiv olmasını təmin etməlisiniz.
Mavi/yaşıl yerləşdirmə mexanizmi belə görünür. Biz tətbiqlərimiz üçün trafiki ha-proxy vasitəsilə alırıq ki, bu da onu eyni versiyanın tətbiqinin işləyən replikalarına yönləndirir.
Yeni yerləşdirmə həyata keçirildikdə, biz yeni komponentlər verilən və yeni versiyanı yerləşdirən Deployer istifadə edirik. Tətbiqin yeni versiyasının yerləşdirilməsi o deməkdir ki, yeni replika dəsti “qaldırılır”, bundan sonra yeni versiyanın bu replikaları ayrıca, yeni podda işə salınır. Bununla belə, ha-proxy onlar haqqında heç nə bilmir və hələ onlara heç bir iş yükü yönləndirmir.
Buna görə də, ilk növbədə, replikaların yükə xidmət göstərməyə hazır olmasını təmin etmək üçün sağlamlıq yoxlanışının yeni versiyalarının performans yoxlamasını həyata keçirmək lazımdır.
Bütün yerləşdirmə komponentləri sağlamlıq yoxlamasının bir formasını dəstəkləməlidir. Bu, 200 statuslu kod aldığınız zaman çox sadə HTTP zəng yoxlaması və ya replikaların verilənlər bazası və digər xidmətlərlə əlaqəsini, dinamik mühit əlaqələrinin sabitliyini yoxladığınız daha dərin yoxlama ola bilər. , və hər şeyin düzgün başlaması və işləməsi. Bu proses olduqca mürəkkəb ola bilər.
Sistem bütün yenilənmiş replikaların işlədiyini yoxladıqdan sonra Deployer konfiqurasiyanı yeniləyəcək və ha-proksini yenidən konfiqurasiya edəcək düzgün konfiqurasiyanı keçirəcək.
Yalnız bundan sonra trafik yeni versiyanın replikaları olan pod-a yönəldiləcək və köhnə pod yox olacaq.
Bu mexanizm Kubernetesin xüsusiyyəti deyil. Mavi/yaşıl yerləşdirmə konsepsiyası kifayət qədər uzun müddətdir mövcud olub və o, həmişə yük balanslaşdırıcısından istifadə edib. Əvvəlcə bütün trafiki tətbiqin köhnə versiyasına yönəldirsiniz və yeniləmədən sonra onu tamamilə yeni versiyaya köçürürsünüz. Bu prinsip təkcə Kubernetesdə istifadə edilmir.
İndi sizi yeni yerləşdirmə komponenti ilə tanış edəcəyəm - sağlamlıq yoxlamalarını həyata keçirən, proksiləri yenidən konfiqurasiya edən və s. Bu, xarici dünyaya aid olmayan və Kubernetes daxilində mövcud olan bir anlayışdır. Mən sizə açıq mənbə alətlərindən istifadə edərək öz Deployer konsepsiyanızı necə yarada biləcəyinizi göstərəcəyəm.
Beləliklə, Deployer-in etdiyi ilk şey Kubernetes API-dən istifadə edərək RC replikasiya nəzarətçisi yaratmaqdır. Bu API sonrakı yerləşdirmə üçün podlar və xidmətlər yaradır, yəni tətbiqlərimiz üçün tamamilə yeni klaster yaradır. RC replikaların işə salındığına əmin olan kimi, onların funksionallığı ilə bağlı sağlamlıq yoxlanışı həyata keçirəcək. Bunun üçün Deployer GET /health əmrindən istifadə edir. O, müvafiq skan komponentlərini işə salır və klasterin işini dəstəkləyən bütün elementləri yoxlayır.
Bütün podlar öz sağlamlıqlarını bildirdikdən sonra Deployer yeni konfiqurasiya elementi yaradır - etcd paylanmış yaddaş, Kubernetes tərəfindən daxili olaraq istifadə olunur, o cümlədən yük balanslaşdırıcı konfiqurasiyanın saxlanması. Biz məlumatları etcd-ə yazırıq və yeni məlumatlar üçün confd monitors etcd adlı kiçik alət.
İlkin konfiqurasiyada hər hansı dəyişiklik aşkar edərsə, o, yeni parametrlər faylı yaradır və onu ha-proxy-yə köçürür. Bu halda, ha-proxy heç bir əlaqəni itirmədən yenidən yüklənir və tətbiqlərimizin yeni versiyasının işləməsini təmin edən yükü yeni xidmətlərə ünvanlayır.
Gördüyünüz kimi, komponentlərin bolluğuna baxmayaraq, burada mürəkkəb bir şey yoxdur. Sadəcə API və s.-ə daha çox diqqət yetirməlisiniz. Mən sizə özümüzün istifadə etdiyimiz açıq mənbəli yerləşdirici haqqında danışmaq istəyirəm - Amdatu Kubernetes Deployer.
Bu, Kubernetes yerləşdirmələrini təşkil etmək üçün bir vasitədir və aşağıdakı xüsusiyyətlərə malikdir:
- Mavi/Yaşıl yerləşdirmə;
- xarici yük balanslaşdırıcısının qurulması;
- yerləşdirmə deskriptorunun idarə edilməsi;
- faktiki yerləşdirməni idarə etmək;
- yerləşdirmə zamanı Sağlamlıq yoxlamalarının funksionallığının yoxlanılması;
- mühit dəyişənlərinin podlara tətbiqi.
Bu Deployer Kubernetes API-nin üzərində qurulub və tutacaqları və yerləşdirmələri idarə etmək üçün REST API, həmçinin yerləşdirmə prosesi zamanı qeydlərin axın edilməsi üçün Websocket API təmin edir.
O, yük balanslaşdırıcı konfiqurasiya məlumatlarını etcd-ə qoyur, beləliklə, siz qutudan kənar dəstək ilə ha-proxy istifadə etməli deyilsiniz, lakin asanlıqla öz yük balanslaşdırıcı konfiqurasiya faylınızı istifadə edin. Amdatu Deployer, Kubernetesin özü kimi Go-da yazılmışdır və Apache tərəfindən lisenziyalaşdırılmışdır.
Mən yerləşdiricinin bu versiyasını istifadə etməyə başlamazdan əvvəl mənə lazım olan parametrləri təyin edən aşağıdakı yerləşdirmə deskriptorundan istifadə etdim.
Bu kodun vacib parametrlərindən biri “useHealthCheck” bayrağını aktivləşdirməkdir. Yerləşdirmə prosesi zamanı ağlı başında olma yoxlamasının aparılmalı olduğunu qeyd etməliyik. Yerləşdirmə təsdiqlənməsinə ehtiyac olmayan üçüncü tərəf konteynerlərindən istifadə etdikdə bu parametr deaktiv edilə bilər. Bu deskriptor həmçinin ha-proksinin ehtiyac duyduğu replikaların sayını və frontend URL-ni göstərir. Sonda port konfiqurasiyası, şəkil və s. haqqında məlumat üçün Kubernetes-i çağıran pod spesifikasiya bayrağı "podspec"dir. Bu kifayət qədər sadə JSON deskriptorudur.
Açıq mənbəli Amdatu layihəsinin bir hissəsi olan digər alət Deploymentctl-dir. O, yerləşdirmələri konfiqurasiya etmək üçün UI-yə malikdir, yerləşdirmə tarixçəsini saxlayır və üçüncü tərəf istifadəçiləri və tərtibatçılarından geri çağırışlar üçün veb-qancaları ehtiva edir. Siz UI-dən istifadə edə bilməzsiniz, çünki Amdatu Deployer özü REST API-dir, lakin bu interfeys heç bir API cəlb etmədən yerləşdirməni sizin üçün çox asanlaşdıra bilər. Deploymentctl Angular 2 istifadə edərək OSGi/Vertx-də yazılmışdır.
İndi yuxarıda göstərilənləri ekranda əvvəlcədən qeydə alınmış qeyddən istifadə edərək nümayiş etdirəcəyəm ki, siz gözləməyəsiniz. Biz sadə Go tətbiqini yerləşdirəcəyik. Əvvəllər Go-u sınamamısınızsa, narahat olmayın, bu, çox sadə proqramdır, ona görə də onu anlaya bilməlisiniz.
Burada biz yalnız /sağlamlığa cavab verən HTTP serveri yaradırıq, ona görə də bu proqram yalnız sağlamlıq yoxlamasını yoxlayır və başqa heç nə yoxlayır. Yoxlama keçərsə, aşağıda göstərilən JSON strukturu istifadə olunur. Bu proqramın yerləşdirici tərəfindən yerləşdiriləcək versiyasını, faylın yuxarısında gördüyünüz mesajı və boolean məlumat tipini ehtiva edir - tətbiqimizin işlək olub-olmamasından asılı olmayaraq.
Son sətirlə bir az aldatdım, çünki faylın yuxarı hissəsində sabit bir boolean dəyəri qoydum, bu gələcəkdə hətta "sağlam olmayan" bir tətbiqi yerləşdirməyə kömək edəcəkdir. Bununla sonra məşğul olacağıq.
Beləliklə, başlayaq. Əvvəlcə ~ kubectl get pods əmrindən istifadə edərək hər hansı işləyən podların olub-olmadığını yoxlayırıq və frontend URL-dən cavabın olmamasına əsaslanaraq, hazırda heç bir yerləşdirmənin aparılmadığına əmin oluruq.
Sonra ekranda qeyd etdiyim Deploymentctl interfeysini görürsünüz, burada yerləşdirmə parametrləri təyin olunur: ad sahəsi, proqram adı, yerləşdirmə versiyası, replikaların sayı, ön URL, konteyner adı, şəkil, resurs limitləri, sağlamlıq yoxlaması üçün port nömrəsi, və s. Resurs məhdudiyyətləri çox vacibdir, çünki onlar sizə mümkün olan maksimum miqdarda aparatdan istifadə etməyə imkan verir. Burada siz həmçinin Yerləşdirmə jurnalına baxa bilərsiniz.
İndi ~ kubectl get pods əmrini təkrarlasanız, sistemin 20 saniyə ərzində “donduğunu” görə bilərsiniz, bu müddət ərzində ha-proksi yenidən konfiqurasiya edilir. Bundan sonra pod işə başlayır və bizim replikamız yerləşdirmə jurnalında görünə bilər.
Videodan 20 saniyə gözləmə müddətini kəsdim və indi ekranda proqramın ilk versiyasının yerləşdirildiyini görə bilərsiniz. Bütün bunlar yalnız UI istifadə edərək edildi.
İndi ikinci versiyanı sınayaq. Bunun üçün tətbiqin mesajını "Salam, Kubernetes!" “Salam, Deployer!” mövzusunda sistem bu şəkli yaradır və onu Docker reyestrinə yerləşdirir, bundan sonra biz sadəcə Deploymentctl pəncərəsində yenidən “Yerləşdirmə” düyməsini sıxırıq. Bu halda, yerləşdirmə jurnalı proqramın ilk versiyasını yerləşdirərkən olduğu kimi avtomatik olaraq işə salınır.
~ kubectl get pods əmri hazırda tətbiqin 2 versiyasının işlədiyini göstərir, lakin ön hissə göstərir ki, biz hələ də 1-ci versiyanı işlədirik.
Yük balanslaşdırıcısı trafiki yeni versiyaya yönləndirməzdən əvvəl sağlamlıq yoxlamasının tamamlanmasını gözləyir. 20 saniyədən sonra biz curl-a keçirik və görürük ki, indi tətbiqin 2-ci versiyası yerləşdirilib və birincisi silinib.
Bu, "sağlam" tətbiqin tətbiqi idi. Gəlin görək tətbiqin yeni versiyası üçün Sağlam parametrini doğrudan yalana dəyişsəm, yəni sağlamlıq yoxlanışında uğursuz olan qeyri-sağlam tətbiqi yerləşdirməyə çalışsam nə olacaq. Bu, inkişaf mərhələsində tətbiqdə bəzi konfiqurasiya səhvlərinə yol verildiyi və bu formada istehsala göndərildiyi təqdirdə baş verə bilər.
Gördüyünüz kimi, yerləşdirmə yuxarıdakı bütün addımlardan keçir və ~kubectl get pods hər iki podun işlədiyini göstərir. Ancaq əvvəlki yerləşdirmədən fərqli olaraq, jurnal fasilə vəziyyətini göstərir. Yəni sağlamlıq yoxlaması uğursuz olduğu üçün tətbiqin yeni versiyası yerləşdirilə bilməz. Nəticədə, sistemin tətbiqin köhnə versiyasından istifadə etməyə qayıtdığını və yeni versiyanın sadəcə olaraq silindiyini görürsünüz.
Bunun yaxşı tərəfi odur ki, tətbiqə daxil olan çoxlu sayda eyni vaxtda sorğularınız olsa belə, yerləşdirmə prosedurunu həyata keçirərkən onlar fasilələri belə hiss etməyəcəklər. Bu tətbiqi mümkün qədər çox sorğu göndərən Gatling çərçivəsi ilə sınaqdan keçirsəniz, bu sorğuların heç biri ləğv edilməyəcək. Bu o deməkdir ki, istifadəçilərimiz real vaxtda versiya yeniləmələrini belə hiss etməyəcəklər. Əgər uğursuz olarsa, iş köhnə versiya üzərində davam edəcək, uğurlu olarsa, istifadəçilər yeni versiyaya keçəcəklər.
Uğursuz ola biləcək yalnız bir şey var - sağlamlıq yoxlaması uğurlu olarsa, lakin iş yükü ona tətbiq olunan kimi tətbiq uğursuz olarsa, yəni çökmə yalnız yerləşdirmə tamamlandıqdan sonra baş verəcəkdir. Bu halda, köhnə versiyaya əl ilə geri qayıtmalı olacaqsınız. Beləliklə, biz Kubernetes-dən onun üçün hazırlanmış açıq mənbə alətləri ilə necə istifadə edəcəyimizə baxdıq. Bu alətləri Quraşdırma/Yerləşdirmə boru kəmərlərində qursanız, yerləşdirmə prosesi daha asan olacaq. Eyni zamanda, yerləşdirməyə başlamaq üçün siz ya istifadəçi interfeysindən istifadə edə bilərsiniz, ya da, məsələn, master üçün öhdəlik götürməklə bu prosesi tam avtomatlaşdıra bilərsiniz.
Quraşdırma Serverimiz Docker təsviri yaradacaq, onu Docker Hub-a və ya istifadə etdiyiniz hər hansı reyestrə köçürür. Docker Hub webhook-u dəstəkləyir, ona görə də yuxarıda göstərilən şəkildə Deployer vasitəsilə uzaqdan yerləşdirməni işə sala bilərik. Bu yolla siz tətbiqinizin potensial istehsala yerləşdirilməsini tam avtomatlaşdıra bilərsiniz.
Gəlin növbəti mövzuya - Kubernetes klasterinin miqyasına keçək. Qeyd edək ki, kubectl əmri miqyaslama əmridir. Daha çox yardımla, mövcud klasterimizdəki replikaların sayını asanlıqla artıra bilərik. Bununla belə, praktikada biz adətən podlardan çox qovşaqların sayını artırmaq istəyirik.
Eyni zamanda, iş saatları ərzində Amazon xidmətlərinin qiymətini artırmaq, gecələr isə, işləyən tətbiq nümunələrinin sayını azaltmaq lazım ola bilər. Bu o demək deyil ki, yalnız podların sayını miqyaslaşdırmaq kifayət edəcək, çünki qovşaqlardan biri boş olsa belə, bunun üçün hələ də Amazon-a pul ödəməli olacaqsınız. Yəni, podların miqyasını artırmaqla yanaşı, istifadə olunan maşınların sayını da ölçməli olacaqsınız.
Bu çətin ola bilər, çünki Amazon və ya başqa bulud xidmətindən istifadə etməyimizdən asılı olmayaraq, Kubernetes istifadə olunan maşınların sayı haqqında heç nə bilmir. Sistemi qovşaq səviyyəsində genişləndirməyə imkan verən bir vasitə yoxdur.
Beləliklə, həm düyünlərə, həm də podlara qulluq etməli olacağıq. Kubernetes işçi qovşaqlarının sayını konfiqurasiya etmək üçün AWS API və Scaling qrup maşınlarından istifadə edərək yeni qovşaqların işə salınmasını asanlıqla miqyaslaya bilərik. Siz həmçinin Kubernetes klasterində qovşaqları qeyd etmək üçün cloud-init və ya oxşar skriptdən istifadə edə bilərsiniz.
Yeni maşın Scaling qrupunda başlayır, özünü qovşaq kimi işə salır, master reyestrində qeydiyyatdan keçir və işə başlayır. Bundan sonra, yaranan qovşaqlarda istifadə üçün replikaların sayını artıra bilərsiniz. Ölçəyi azaltmaq daha çox səy tələb edir, çünki belə bir addımın "lazımsız" maşınları söndürdükdən sonra artıq işləyən proqramların məhvinə səbəb olmadığına əmin olmalısınız. Belə bir ssenarinin qarşısını almaq üçün qovşaqları "planlaşdırılmayan" vəziyyətə gətirməlisiniz. Bu o deməkdir ki, DaemonSet podlarını planlaşdırarkən defolt planlaşdırıcı bu qovşaqlara məhəl qoymayacaq. Planlayıcı bu serverlərdən heç nə silməyəcək, həm də orada yeni konteynerləri işə salmayacaq. Növbəti addım drenaj düyününü çıxarmaqdır, yəni işləyən podları ondan başqa bir maşına və ya bunun üçün kifayət qədər tutumu olan digər qovşaqlara köçürməkdir. Bu qovşaqlarda artıq konteynerlərin olmadığına əmin olduqdan sonra onları Kubernetes-dən silə bilərsiniz. Bundan sonra onlar sadəcə Kubernetes üçün mövcud olmağı dayandıracaqlar. Sonra, lazımsız qovşaqları və ya maşınları söndürmək üçün AWS API istifadə etməlisiniz.
AWS API-yə bənzər başqa bir açıq mənbəli miqyaslandırma vasitəsi olan Amdatu Scalerd-dən istifadə edə bilərsiniz. Bir çoxluqda qovşaqları əlavə etmək və ya silmək üçün CLI təmin edir. Onun maraqlı xüsusiyyəti aşağıdakı json faylından istifadə edərək planlaşdırıcını konfiqurasiya etmək imkanıdır.
Göstərilən kod gecə vaxtı klaster tutumunu yarıya endirir. O, həm mövcud replikaların sayını, həm də Amazon klasterinin istənilən tutumunu konfiqurasiya edir. Bu planlaşdırıcıdan istifadə avtomatik olaraq gecə qovşaqlarının sayını azaldacaq və səhər onları artıracaq, Amazon kimi bulud xidmətinin qovşaqlarından istifadə xərclərinə qənaət edəcək. Bu xüsusiyyət Kubernetes-də qurulmayıb, lakin Scalerd-dən istifadə bu platformanı istədiyiniz kimi miqyaslandırmağa imkan verəcək.
Qeyd etmək istərdim ki, bir çox insan mənə deyir: “Hər şey yaxşıdır, bəs mənim verilənlər bazam, adətən statikdir?” Kubernetes kimi dinamik bir mühitdə belə bir şeyi necə işlədə bilərsiniz? Məncə, bunu etməməlisən, Kubernetesdə məlumat anbarı işlətməyə çalışmamalısan. Bu, texniki cəhətdən mümkündür və İnternetdə bu mövzuda dərsliklər var, lakin bu, həyatınızı ciddi şəkildə çətinləşdirəcək.
Bəli, Kubernetes-də davamlı mağazalar anlayışı var və siz Mongo və ya MySQL kimi məlumat mağazalarını işə salmağa cəhd edə bilərsiniz, lakin bu, kifayət qədər əmək tələb edən bir işdir. Bu, məlumat anbarlarının dinamik mühitlə qarşılıqlı əlaqəni tam dəstəkləməməsi ilə bağlıdır. Əksər verilənlər bazası əhəmiyyətli konfiqurasiya tələb edir, o cümlədən klasterin əl ilə konfiqurasiyası, avtomatik ölçmə və digər oxşar şeyləri sevmir.
Buna görə də, Kubernetes-də məlumat anbarı işlətməyə çalışaraq həyatınızı çətinləşdirməməlisiniz. Tanış xidmətlərdən istifadə edərək işlərini ənənəvi şəkildə təşkil edin və sadəcə olaraq Kubernetes-ə onlardan istifadə etmək imkanı verin.
Mövzunu yekunlaşdırmaq üçün sizi komandamın üzərində işlədiyi Kubernetes əsasında Cloud RTI platforması ilə tanış etmək istərdim. O, mərkəzləşdirilmiş giriş, tətbiq və klaster monitorinqi və lazımlı olacaq bir çox digər faydalı xüsusiyyətləri təmin edir. Monitorinqi göstərmək üçün Grafana kimi müxtəlif açıq mənbə alətlərindən istifadə edir.
Ha-proksi yük balanslaşdırıcısını Kubernetes ilə niyə istifadə etməyinizlə bağlı bir sual var idi. Yaxşı sual, çünki hazırda yük balansının 2 səviyyəsi var. Kubernetes xidmətləri hələ də virtual IP ünvanlarında yaşayır. Onları xarici host maşınlarında portlar üçün istifadə edə bilməzsiniz, çünki Amazon bulud hostunu həddən artıq yükləsə, ünvan dəyişəcək. Buna görə də biz ha-proxy-ni xidmətlərin qarşısında yerləşdiririk - trafikin Kubernetes ilə problemsiz əlaqə saxlaması üçün daha statik bir quruluş yaratmaq.
Başqa bir yaxşı sual, mavi/yaşıl yerləşdirmə edərkən verilənlər bazası sxemindəki dəyişikliklərə necə diqqət yetirə bilərsiniz? Fakt budur ki, Kubernetes-in istifadəsindən asılı olmayaraq, verilənlər bazası sxemini dəyişdirmək çətin bir işdir. Köhnə və yeni sxemin uyğun olduğundan əmin olmalısınız, bundan sonra verilənlər bazasını yeniləyə və sonra proqramların özlərini yeniləyə bilərsiniz. Siz verilənlər bazasını isti dəyişdirə və sonra proqramları yeniləyə bilərsiniz. Mən tamamilə yeni verilənlər bazası klasterini yeni sxemlə işə salmış insanları tanıyıram, Mongo kimi sxemsiz verilənlər bazanız varsa, bu seçimdir, lakin hər halda asan məsələ deyil. Əlavə sualınız yoxdursa, diqqətinizə görə təşəkkür edirik!
Bəzi reklamlar 🙂
Bizimlə qaldığınız üçün təşəkkür edirik. Məqalələrimiz xoşunuza gəlirmi? Daha maraqlı məzmun görmək istəyirsiniz? Sifariş verməklə və ya dostlarınıza tövsiyə etməklə bizə dəstək olun, , Sizin üçün bizim tərəfimizdən icad edilmiş giriş səviyyəli serverlərin unikal analoqu: (RAID1 və RAID10, 24 nüvəyə qədər və 40 GB DDR4 ilə mövcuddur).
Dell R730xd Amsterdamdakı Equinix Tier IV məlumat mərkəzində 2 dəfə ucuzdur? Yalnız burada Hollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! haqqında oxuyun
Mənbə: www.habr.com