Bu gün mən ərizələrin necə yazılacağı və Kubernetes-də yaxşı işləməsi üçün tətbiqiniz üçün hansı tələblərin olması barədə danışmağı planlaşdırıram. Tətbiqdə baş ağrısı olmasın ki, onun ətrafında hər hansı bir "cızıq" icad edib qurmaq lazım deyil - və hər şey Kubernetesin özünün nəzərdə tutduğu kimi işləyir.
Bu mühazirə "" Axşam Məktəbinin açıq nəzəri mühazirələrinə baxa bilərsiniz . Videodan çox mətnə üstünlük verənlər üçün bu yazını hazırladıq.
Mənim adım Pavel Selivanov, hazırda Mail.ru Cloud Solutions şirkətində aparıcı DevOps mühəndisiyəm, biz buludlar edirik, idarəetmə kubernetləri edirik və s. İndi mənim vəzifələrimə inkişafda kömək etmək, bu buludları yaymaq, yazdığımız proqramları yaymaq və istifadəçilərimiz üçün təmin etdiyimiz alətləri birbaşa inkişaf etdirmək daxildir.
Mən DevOps ilə məşğul oluram, düşünürəm ki, son, yəqin ki, üç ildir. Ancaq prinsipcə, mən DevOps-un təxminən beş ildir ki, nə etdiyini edirəm. Ondan əvvəl mən daha çox adminlərlə məşğul olurdum. Mən Kubernetes ilə çoxdan işləməyə başladım - onunla işləməyə başladığımdan yəqin ki, dörd il keçib.
Ümumiyyətlə, mən Kubernetes 1.3 versiyası olanda, ehtimal ki, və bəlkə də 1.2 - hələ körpəlikdə olanda başladım. İndi o, artıq körpəlik mərhələsində deyil - və açıq-aydın görünür ki, bazarda Kubernetes edə bilmək istəyən mühəndislərə böyük tələbat var. Və şirkətlərin belə insanlara tələbatı çox yüksəkdir. Ona görə də əslində bu mühazirə meydana çıxdı.
Haqqında danışacağım plana uyğun danışsaq, belə görünür, mötərizədə (TL;DR) yazılır - “çox uzun; oxuma". Bugünkü təqdimatım sonsuz siyahılardan ibarət olacaq.
Əslində, mənim özüm belə təqdimatların edildiyi zaman xoşuma gəlmir, amma bu elə bir mövzudur ki, bu təqdimatı hazırlayarkən, sadəcə olaraq, bu məlumatı fərqli şəkildə necə təşkil edəcəyimi başa düşmədim.
Çünki, ümumiyyətlə, bu məlumat “ctrl+c, ctrl+v”, digər şeylərlə yanaşı, DevOps bölməsindəki Wiki-mizdir, burada tərtibatçılar üçün tələblər yazmışıq: “Uşaqlar, tətbiqinizi işə salmaq üçün Kubernetes, bu belə olmalıdır."
Buna görə təqdimat belə böyük bir siyahıya çevrildi. Bağışlayın. Mümkün qədər çox danışmağa çalışacam ki, imkan daxilində darıxdırıcı olmasın.
İndi nələrə baxacağıq:
- bunlar, birincisi, jurnallar (tətbiq jurnalları?), Kubernetesdə onlarla nə etməli, onlarla nə etməli, nə olmalıdır;
- Kubernetes-də konfiqurasiyalarla nə etməli, Kubernetes üçün tətbiqi konfiqurasiya etməyin ən yaxşı və ən pis yolları hansılardır;
- Ümumilikdə əlçatanlıq yoxlamalarının nə olduğunu, necə görünməli olduğunu danışaq;
- zərif bağlanmanın nə olduğunu danışaq;
- yenə də resurslardan danışaq;
- Məlumatların saxlanması mövzusuna bir daha toxunaq;
- və sonunda mən sizə bu sirli bulud tətbiqinin termininin nə olduğunu söyləyəcəyəm. Buludluluq, bu terminin sifəti kimi.
Qeydlər
Mən loglardan başlamağı təklif edirəm - bu logların Kubernetes-də itələməli olduğu yerdən. İndi Kubernetes-də bir tətbiq işə saldınız. Klassiklərə görə, əvvəllər proqramlar həmişə faylın bir yerində loglar yazırdı. Səhv proqramlar proqramı işə salan tərtibatçının ev kataloqunda olan fayla qeydlər yazdı. Yaxşı proqramlar haradasa bir fayla loglar yazdı /var/log.
Müvafiq olaraq, bundan əlavə, yaxşı idarəçilər öz infrastrukturlarında bu logların dönə biləcəyi bəzi şeyləri konfiqurasiya etdilər - eyni rsyslog, bu qeydlərə baxır və onlara bir şey olduqda, onların çoxu var, ehtiyat nüsxələri yaradır , logları ora qoyur , köhnə faylları silir, bir həftədən çox, altı ay və daha çox. Teorik olaraq, elə müddəalarımız olmalıdır ki, proqram sadəcə qeydləri yazdığı üçün istehsal serverlərində (döyüş serverlərində?) yer tükənməsin. Və müvafiq olaraq, loglar səbəbindən bütün istehsal dayanmadı.
Kubernetes dünyasına köçdükdə və orada eyni şeyi işlətdikdə, diqqət edə biləcəyiniz ilk şey, insanların bir faylda qeydlər yazdıqları zaman onları yazmağa davam etmələridir.
Belə çıxır ki, Kubernetes haqqında danışsaq, logları doker konteynerindən hardasa yazmaq üçün düzgün yer sadəcə onları proqramdan Stdout/Stderr adlanan proqrama, yəni əməliyyat sisteminin standart çıxış axınlarına yazmaqdır. standart səhv çıxışı. Bu, Docker-də və xüsusilə Kubernetis-də logları prinsipcə yerləşdirməyin ən düzgün, ən sadə və ən məntiqli yoludur. Çünki tətbiqiniz Stdout/Stderr-ə loglar yazırsa, bu qeydlərlə nə edəcəyinizə qərar vermək Docker və Kubernetes əlavəsindən asılıdır. Docker standart olaraq xüsusi fayllarını JSON formatında quracaq.
Burada sual yaranır, bu loglarla bundan sonra nə edəcəksiniz? Ən asan yol bəllidir, etmək qabiliyyətimiz var kubectl logs və bu "podların" bu qeydlərinə baxın. Ancaq yəqin ki, bu çox yaxşı bir seçim deyil - loglarla başqa bir şey etmək lazımdır.
Hələlik, eyni zamanda, loglar mövzusuna toxunduğumuz üçün logların görünməsi lazım olan bir şey haqqında danışaq. Yəni bu, birbaşa Kubernetesə aid deyil, amma loglarla nə edəcəyimizi düşünməyə başlayanda bu haqda da düşünsək yaxşı olar.
Bizə dostcasına bir vasitə lazımdır ki, dockerimizin fayllarına qoyduğu bu qeydləri götürüb harasa göndərsin. Ümumiyyətlə, biz adətən Kubernetes daxilində bir növ agenti DaemonSet şəklində işə salırıq - jurnal kollektoru, ona sadəcə Dockerin topladığı qeydlərin harada yerləşdiyi bildirilir. Və bu toplayıcı agent onları sadəcə olaraq götürür, bəlkə də yol boyu birtəhər təhlil edir, bəlkə də bəzi əlavə meta-məlumatlarla zənginləşdirir və nəhayət, onları harasa saxlamağa göndərir. Orada artıq variasiyalar mümkündür. Ən çox yayılmışı, yəqin ki, Elasticsearch-dir, burada qeydləri saxlaya bilərsiniz və onları oradan rahatlıqla əldə edə bilərsiniz. Sonra, sorğudan istifadə edərək, Kibana istifadə edərək, məsələn, onlara əsaslanan qrafiklər qurun, onlara əsasən xəbərdarlıqlar qurun və s.
Ən vacib fikir, bir daha təkrarlamaq istəyirəm ki, Docker daxilində, xüsusən Kubernetes daxilində loglarınızı faylda saxlamaq çox pis fikirdir.
Çünki birincisi, konteynerin içindəki logları faylda əldə etmək çətindir. Əvvəlcə konteynerə daxil olmalı, orada exec etməli və sonra jurnallara baxmalısınız. Növbəti məqam budur ki, bir faylda qeydləriniz varsa, konteynerlər adətən minimalist bir mühitə malikdir və adətən loglarla normal işləmək üçün lazım olan heç bir kommunal proqram yoxdur. Onları basdırın, onlara baxın, mətn redaktorunda açın. Növbəti an, konteynerin içərisində bir faylda loglarımız olduqda, bu konteyner silinirsə, başa düşürsən, loglar onunla birlikdə ölür. Müvafiq olaraq, konteynerin hər hansı yenidən işə salınması daha çox jurnalın olmaması deməkdir. Yenə pis seçimdir.
Və son məqam ondan ibarətdir ki, konteynerlərin içərisində adətən sizin ərizəniz var və bu, adətən işləyən yeganə prosesdir. Günlüklərinizlə faylları döndərəcək hər hansı bir proses haqqında heç bir söhbət yoxdur. Qeydlər fayla yazılmağa başlayan kimi, bu o deməkdir ki, bağışlayın, biz istehsal serverini itirməyə başlayacağıq. Çünki, birincisi, onları tapmaq çətindir, heç kim onları izləmir, üstəlik heç kim onlara nəzarət etmir - müvafiq olaraq, serverdəki yer bitənə qədər fayl sonsuz böyüyür. Buna görə bir daha deyirəm ki, Docker-də, xüsusən Kubernetes-də fayla daxil olmaq pis fikirdir.
Növbəti məqam, burada bir daha bu barədə danışmaq istəyirəm - loglar mövzusuna toxunduğumuz üçün, onlarla işləməyi rahat etmək üçün logların necə görünməsi barədə danışmaq yaxşı olardı. Dediyim kimi, mövzu birbaşa Kubernetes ilə əlaqəli deyil, lakin DevOps mövzusu ilə çox yaxşı əlaqəlidir. Hər kəsin rahat olması üçün bu iki fərqli şöbə - Dev və Ops arasındakı inkişaf mədəniyyəti və dostluq mövzusunda.
Bu o deməkdir ki, ideal olaraq bu gün jurnallar JSON formatında yazılmalıdır. Bir növ çap və ya buna bənzər bir şey daxil etdiyiniz üçün logları anlaşılmaz formatlarda yazan özünüzə aid anlaşılmaz bir tətbiqiniz varsa, normal girişi həyata keçirməyə imkan verən bir növ çərçivə, bir növ sarğı google-da axtarmağın vaxtı gəldi; orada JSON-da giriş parametrlərini aktivləşdirin, çünki JSON sadə formatdır, onu təhlil etmək sadədir.
Əgər JSON-unuz bəzi meyarlara uyğun işləmirsə, heç kim nəyi bilmir, onda heç olmasa təhlil edilə bilən formatda loglar yazın. Burada, daha doğrusu, düşünməyə dəyər ki, məsələn, bir dəstə konteyner işlədirsinizsə və ya sadəcə nginx ilə işləyirsinizsə və hər birinin öz giriş parametrləri varsa, o zaman çox güman ki, sizin üçün çox əlverişsiz olacaq. onları təhlil edin. Çünki hər yeni nginx nümunəsi üçün öz analizatorunuzu yazmalısınız, çünki onlar logları fərqli şəkildə yazırlar. Yenə də, yəqin ki, bütün bu nginx nümunələrinin eyni giriş konfiqurasiyasına malik olduğundan və bütün qeydlərini tamamilə eyni şəkildə yazdığından əmin olmaq barədə düşünməyə dəyərdi. Eyni şey tamamilə bütün tətbiqlərə aiddir.
Sonda mən də atəşə yanacaq əlavə etmək istəyirəm ki, ideal olaraq çox sətirli formatlı jurnallardan qaçınmaq lazımdır. Məsələ burasındadır ki, əgər siz nə vaxtsa log toplayıcılarla işləmisinizsə, o zaman çox güman ki, onların sizə vəd etdiklərini, çox sətirli jurnallarla işləyə biləcəyini, onları necə yığacağını və s. Əslində, mənim fikrimcə, bu gün heç bir kollektor çox sətirli jurnalları normal, tam və səhvsiz toplaya bilməz. İnsani şəkildə, rahat və səhvsiz olması üçün.
Ancaq yığın izi həmişə çox sətirli loglardır və onlardan necə qaçınmaq olar. Burada sual ondan ibarətdir ki, log bir hadisənin qeydidir və stactrace əslində jurnal deyil. Əgər logları toplayıb Elasticsearch-də harasa yerləşdirsək və sonra onlardan qrafiklər çəksək, saytınızda istifadəçi fəaliyyəti haqqında bəzi hesabatlar qursaq, o zaman stek izi əldə etdikdə, bu o deməkdir ki, gözlənilməz bir şey baş verir. tətbiqinizdə idarə olunmayan vəziyyət. Və onları izləyə bilən bir sistemə bir yığın izini avtomatik yükləməyin mənası var.
Bu, xüsusi olaraq yığın izi ilə işləmək üçün hazırlanmış proqramdır (eyni Sentry). O, dərhal avtomatlaşdırılmış tapşırıqlar yarada, onları kiməsə təyin edə, stacttraces baş verdikdə xəbərdar edə, bu stacttraceləri bir növ üzrə qruplaşdıra və s. Prinsipcə, loglar haqqında danışarkən statraslar haqqında danışmağın mənası yoxdur, çünki bunlar, hər şeydən əvvəl, müxtəlif məqsədləri olan müxtəlif şeylərdir.
Konfiqurasiya
Sonra Kubernetes-də konfiqurasiya haqqında danışırıq: onunla nə etməli və Kubernetes daxilindəki tətbiqləri necə konfiqurasiya etmək lazımdır. Ümumiyyətlə, mən adətən deyirəm ki, Docker konteynerlərə aid deyil. Hamı bilir ki, Docker konteynerlər haqqındadır, hətta Docker ilə çox işləməmişlər də. Təkrar edirəm, Docker konteynerlərə aid deyil.
Docker, mənim fikrimcə, standartlara aiddir. Və praktiki olaraq hər şey üçün standartlar var: tətbiqinizi qurmaq üçün standartlar, tətbiqinizi quraşdırmaq üçün standartlar.
Və bu şey - biz bundan əvvəl istifadə edirdik, yalnız konteynerlərin meydana gəlməsi ilə xüsusilə populyarlaşdı - bu şey ENV (mühit) dəyişənləri adlanır, yəni əməliyyat sisteminizdə olan mühit dəyişənləri. Bu, ümumiyyətlə, tətbiqinizi konfiqurasiya etmək üçün ideal bir yoldur, çünki JAVA, Python, Go, Perl, Allah qorusun proqramlarınız varsa və onların hamısı verilənlər bazası hostunu, verilənlər bazası istifadəçisini, verilənlər bazası parol dəyişənlərini oxuya bilirsə, bu, idealdır. Verilənlər bazası planında eyni şəkildə konfiqurasiya edilmiş dörd fərqli dildə tətbiqləriniz var. Daha fərqli konfiqurasiyalar yoxdur.
Hər şey ENV dəyişənlərindən istifadə edərək konfiqurasiya edilə bilər. Kubernetes haqqında danışarkən, ENV dəyişənlərini birbaşa Deployment daxilində elan etmək üçün əla bir yol var. Müvafiq olaraq, əgər söhbət məxfi məlumatlardan gedirsə, onda biz dərhal ENV dəyişənlərindən (verilənlər bazasına parollar və s.) məxfi məlumatları gizli şəkildə itələyə, gizli klaster yarada və Deployment-də ENV təsvirində birbaşa bəyan etmədiyimizi göstərə bilərik. bu dəyişənin dəyəri və bu verilənlər bazası parol dəyişəninin dəyəri sirrdən oxunacaq. Bu standart Kubernetes davranışıdır. Və bu, tətbiqlərinizi konfiqurasiya etmək üçün ən ideal seçimdir. Sadəcə kod səviyyəsində, bu yenidən tərtibatçılara aiddir. Əgər siz DevOpssınızsa, soruşa bilərsiniz: “Uşaqlar, lütfən, tətbiqinizə mühit dəyişənlərini oxumağı öyrədin. Və hamımız xoşbəxt olacağıq”.
Əgər şirkətdəki hər kəs eyni adlandırılmış mühit dəyişənlərini oxuyursa, bu, əladır. Belə olmasın ki, bəziləri postgres verilənlər bazasını, bəziləri verilənlər bazasının adını, digərləri başqa bir şey, digərləri isə hansısa bir dbn gözləyirlər ki, müvafiq olaraq vahidlik var.
Problem o qədər çox mühit dəyişəninə sahib olduğunuz zaman yaranır ki, siz sadəcə Yerləşdirməni açırsınız - və ətraf mühit dəyişənlərinin beş yüz xətti var. Bu halda, sadəcə olaraq, ətraf mühit dəyişənlərini aşmısınız - və artıq özünüzə işgəncə vermək lazım deyil. Bu halda, konfiqurasiyalardan istifadə etməyə başlamağın mənası var. Yəni tətbiqinizi konfiqurasiyalardan istifadə etmək üçün öyrədin.
Yeganə sual odur ki, konfiqurasiya sizin düşündüyünüz kimi deyil. Config.pi istifadəsi rahat olan konfiqurasiya deyil. Və ya öz formatınızdakı bəzi konfiqurasiya, alternativ olaraq istedadlı - bu da demək istədiyim konfiqurasiya deyil.
Mənim danışdığım məqbul formatlarda konfiqurasiyadır, yəni indiyə qədər ən populyar standart .yaml standartıdır. Onu necə oxumaq aydındır, insan oxuyur, tətbiqdən necə oxumaq aydındır.
Müvafiq olaraq, YAML-ə əlavə olaraq, məsələn, JSON-dan da istifadə edə bilərsiniz, təhlili proqram konfiqurasiyasını oradan oxumaq baxımından təxminən YAML qədər rahatdır. İnsanların oxuması nəzərəçarpacaq dərəcədə əlverişsizdir. Siz format cəhd edə bilərsiniz, a la ini. İnsan nöqteyi-nəzərindən oxumaq olduqca rahatdır, lakin onu avtomatik emal etmək əlverişsiz ola bilər, o mənada ki, nə vaxtsa öz konfiqurasiyalarınızı yaratmaq istəsəniz, ini formatını yaratmaq artıq əlverişsiz ola bilər.
Ancaq hər halda, hansı formatı seçdiyinizdən asılı olmayaraq, məsələ Kubernetes baxımından çox rahatdır. Bütün konfiqurasiyanızı ConfigMap-də Kubernetes daxilində yerləşdirə bilərsiniz. Və sonra bu konfiqurasiyanı götürün və onun podunuza hansısa xüsusi kataloqda quraşdırılmasını xahiş edin, burada tətbiqiniz bu konfiqurasiyadan konfiqurasiyanı sadəcə bir fayl kimi oxuyacaq. Tətbiqinizdə çoxlu konfiqurasiya seçimləri olduqda bunu etmək yaxşıdır. Və ya sadəcə bir növ mürəkkəb quruluşdur, yuva var.
Əgər konfiqurasiya xəritəniz varsa, o zaman tətbiqinizi çox yaxşı öyrədə bilərsiniz, məsələn, konfiqurasiyanın quraşdırıldığı faylda dəyişiklikləri avtomatik izləməyi, həmçinin konfiqurasiyalar dəyişdikdə tətbiqinizi avtomatik yenidən yükləməyi öyrədə bilərsiniz. Bu, ümumiyyətlə, ideal bir seçim olardı.
Yenə də bu barədə artıq danışdım - məxfi məlumat konfiqurasiyada deyil, gizli məlumatlar dəyişənlərdə deyil, gizli məlumatlar sirlərdə deyil. Oradan bu gizli məlumatı diplomatiyaya bağlayın. Adətən biz Kubernetes obyektlərinin, yerləşdirmələrin, konfiqurasiya xəritələrinin, xidmətlərinin bütün təsvirlərini git-də saxlayırıq. Müvafiq olaraq, şirkət daxilində olan gitiniz olsa belə, git-də verilənlər bazasına parol qoymaq pis fikirdir. Çünki, ən azı, git hər şeyi xatırlayır və sadəcə oradan parolları silmək o qədər də asan deyil.
Sağlamlıq müayinəsi
Növbəti nöqtə Sağlamlıq yoxlaması deyilən şeydir. Ümumiyyətlə, Sağlamlıq yoxlaması sadəcə olaraq tətbiqinizin işlədiyini yoxlamaqdır. Eyni zamanda, biz ən çox müəyyən veb tətbiqləri haqqında danışırıq, bunun üçün, müvafiq olaraq, sağlamlıq yoxlanışı nöqteyi-nəzərindən (burada və daha sonra tərcümə etməmək daha yaxşıdır) bu, bəzi xüsusi URL-lər olacaq, onlar kimi işləyəcəklər. standartdır, adətən edirlər /health.
Bu URL-ə daxil olduqda, müvafiq olaraq, tətbiqimiz ya “bəli, tamam, məndə hər şey yaxşıdır, 200” və ya “xeyr, məndə hər şey yaxşı deyil, təxminən 500” deyir. Müvafiq olaraq, əgər tətbiqimiz http deyilsə, veb proqram deyilsə, indi bir növ demondan danışırıq, sağlamlıq yoxlamalarını necə edəcəyimizi anlaya bilərik. Yəni, lazım deyil, əgər proqram http deyilsə, onda hər şey sağlamlıq yoxlaması olmadan işləyir və bu heç bir şəkildə edilə bilməz. Fayldakı bəzi məlumatları vaxtaşırı yeniləyə bilərsiniz, demonunuz üçün bəzi xüsusi əmrlər tapa bilərsiniz, məsələn: daemon status, "bəli, hər şey qaydasındadır, demon işləyir, canlıdır" deyəcək.
Bu nə üçündür? İlk və ən aydın olan şey, ehtimal ki, niyə sağlamlıq yoxlamasına ehtiyac duyulduğudur - tətbiqin işlədiyini başa düşmək üçün. Demək istədiyim odur ki, bu, sadəcə axmaqlıqdır, indi işə düşəndə, işləyir kimi görünür, ona görə də onun işlədiyinə əmin ola bilərsiniz. Və belə çıxır ki, proqram işləyir, konteyner işləyir, instansiya işləyir, hər şey qaydasındadır - və sonra istifadəçilər artıq bütün telefon nömrələrini texniki dəstəkdən kəsib “sən nəsən..., sən” deyirlər. yuxuya getdim, heç nə işləmir”.
Sağlamlıq yoxlaması istifadəçinin nöqteyi-nəzərindən onun işlədiyini görmək üçün məhz belə bir yoldur. Metodlardan biri. Gəlin bunu belə qoyaq. Kubernetes nöqteyi-nəzərindən bu həm də tətbiqin nə vaxt başladığını başa düşməyin bir yoludur, çünki anlayırıq ki, konteynerin nə vaxt işə salınması, yaradıldığı və işə salınması ilə tətbiqin birbaşa bu konteynerdə işə salınması arasında fərq var. Çünki orta hesabla bir java proqramı götürsək və onu dokda işə salmağa çalışsaq, qırx saniyə, hətta bir dəqiqə, hətta on saniyə ərzində o, yaxşı başlaya bilər. Bu vəziyyətdə, ən azı onun limanlarını döyə bilərsiniz, orada cavab verməyəcək, yəni trafik qəbul etməyə hələ hazır deyil.
Yenə bir sağlamlıq yoxlamasının köməyi ilə və bura dönməyimizin köməyi ilə Kubernetesdə başa düşə bilərik ki, tətbiqdə nəinki konteyner yüksəldi, həm də tətbiqin özü başladı, o, artıq cavab verir. sağlamlıq yoxlaması, yəni biz ora trafik göndərə bilərik.
İndi danışdığım şey Kubernetes daxilində Hazırlıq/Canlılıq testləri adlanır; müvafiq olaraq, bizim hazırlıq testlərimiz balanslaşdırmada tətbiqin mövcudluğuna cavabdehdir. Yəni proqramda hazırlıq testləri aparılırsa, hər şey qaydasındadır, müştəri trafiki tətbiqə gedir. Hazırlıq testləri aparılmırsa, proqram sadəcə iştirak etmir, bu xüsusi nümunə balanslaşdırmada iştirak etmir, balanslaşdırmadan çıxarılır, müştəri trafiki axmır. Müvafiq olaraq, Kubernetes daxilində Canlılıq testləri lazımdır ki, tətbiq ilişib qalarsa, onu yenidən işə salmaq mümkün olsun. Canlılıq testi Kubernetes-də elan edilmiş tətbiq üçün işləmirsə, o zaman tətbiq yalnız balanslaşdırmadan çıxarılmır, yenidən işə salınır.
Və burada qeyd etmək istədiyim vacib bir məqam var: praktiki nöqteyi-nəzərdən hazırlıq testi adətən canlılıq testindən daha tez-tez istifadə olunur və daha çox tələb olunur. Yəni, sadəcə düşünmədən həm hazırlıq, həm də canlılıq testlərini elan etmək, çünki Kubernetes bunu edə bilər və onun edə biləcəyi hər şeyi istifadə edək, çox yaxşı fikir deyil. Səbəbini izah edəcəyəm. Çünki testin ikinci nöqtəsi sağlamlıq yoxlamalarınızda əsas xidməti yoxlamaq yaxşı bir fikirdir. Bu o deməkdir ki, əgər sizin bəzi məlumat verən veb proqramınız varsa, bu da öz növbəsində təbii olaraq haradansa götürməlidir. Məsələn, verilənlər bazasında. Yaxşı, bu REST API-yə daxil olan məlumatları eyni verilənlər bazasında saxlayır. Sonra, müvafiq olaraq, sağlamlıq yoxlamanız sadəcə olaraq əlaqə saxladığınız slashhealth kimi cavab verirsə, proqram "200, tamam, hər şey yaxşıdır" deyir və eyni zamanda tətbiqinizin məlumat bazası əlçatmazdır və Healthcheck tətbiqi "200, tamam, hər şey yaxşıdır" deyir. ” - Bu, pis sağlamlıq yoxlamasıdır. Bu necə işləməli deyil.
Yəni ərizəniz, ona sorğu gələndə /health, o, sadəcə olaraq “200, ok” cavabını vermir, o, əvvəlcə, məsələn, verilənlər bazasına gedir, ona qoşulmağa çalışır, orada çox sadə bir şey edir, məsələn birini seçin, sadəcə olaraq, məlumat bazasında əlaqənin olub-olmadığını yoxlayır. verilənlər bazası və verilənlər bazasını sorğulaya bilərsiniz. Bütün bunlar uğurlu olarsa, cavab “200, tamam” olacaq. Uğurlu deyilsə, xəta olduğunu, verilənlər bazası əlçatmaz olduğunu bildirir.
Buna görə də, bu baxımdan, yenidən Hazırlıq/Canlılıq testlərinə qayıdıram - nə üçün çox güman ki, hazırlıq testinə ehtiyacınız var, amma canlılıq testi sual altındadır. Çünki sağlamlıq yoxlamalarını tam dediyim kimi təsvir etsəniz, o zaman onun instansiya hissəsində mövcud olmadığı ortaya çıxacaq.в или со всех instanceməsələn, verilənlər bazasında. Hazırlıq testini elan etdiyiniz zaman sağlamlıq yoxlamalarımız uğursuzluğa düçar oldu və buna görə də verilənlər bazasına daxil olmayan bütün proqramlar sadəcə balansdan çıxarılır və əslində sadəcə baxımsız vəziyyətdə "asılır" və verilənlər bazalarının işləməsini gözləyirlər. iş.
Canlılıq testi elan etmişiksə, onda təsəvvür edin ki, verilənlər bazamız pozuldu və Kubernetesinizdə canlılıq testi uğursuz olduğu üçün hər şeyin yarısı yenidən başlamağa başlayır. Bu o deməkdir ki, yenidən başlamalısınız. İstədiyiniz heç də bu deyil, hətta praktikada şəxsi təcrübəm də olub. Bizim JS-də yazılmış və Mongo verilənlər bazasına daxil edilmiş söhbət proqramımız var idi. Problem onda idi ki, Kubernetes ilə işimin əvvəlində biz Kubernetesin bunu edə biləcəyi prinsipi ilə sınaqların hazırlığını, canlılığını təsvir etdik, ona görə də ondan istifadə edəcəyik. Müvafiq olaraq, bir nöqtədə Mongo bir az "küt" oldu və nümunə uğursuz olmağa başladı. Müvafiq olaraq, yağış testinə görə, qabıqlar "ölməyə" başladı.
Anladığınız kimi, onlar "öldürüldükdə" bu söhbətdir, yəni müştərilərdən çoxlu əlaqələr var. Onlar da "öldürülür" - yox, müştərilər deyil, yalnız əlaqələr - hamısı eyni anda deyil və eyni anda öldürülmədiklərinə görə, bəziləri əvvəllər, bəziləri sonra, eyni vaxtda başlamırlar. vaxt. Üstəlik standart təsadüfi, biz hər dəfə tətbiqin başlama vaxtını millisaniyəlik dəqiqliklə proqnozlaşdıra bilmirik, ona görə də onlar bunu hər dəfə bir nüsxə edirlər. Bir infospot qalxır, balansa əlavə olunur, bütün müştərilər ora gəlir, belə yükə tab gətirə bilmir, çünki təkdir, kobud desək, orada onlarla işləyir, düşür. Növbəti qalxır, bütün yük onun üzərindədir, o da düşür. Yaxşı, bu şəlalələr şəlaləni davam etdirir. Nəhayət, bunun necə həll edildiyi - sadəcə olaraq, bu tətbiqə istifadəçi trafikini ciddi şəkildə dayandırmalı, bütün instansiyaların yüksəlməsinə icazə verməli və sonra bütün istifadəçi trafikini bir anda başlatmalı olduq ki, o, artıq on instansiya arasında paylansın.
Əgər hər şeyi yenidən başlamağa məcbur edəcək bu canlılıq testinin elan edilməsi olmasaydı, proqram bunu çox yaxşı idarə edərdi. Lakin balanslaşdırmadan tutmuş hər şey bizim üçün əlildir, çünki verilənlər bazası əlçatmazdır və bütün istifadəçilər “yıxılıb”. Sonra, bu verilənlər bazası mövcud olduqda, hər şey balanslaşdırmaya daxil edilir, lakin tətbiqlərin yenidən başlamasına ehtiyac yoxdur və buna vaxt və resurslar sərf etməyə ehtiyac yoxdur. Onların hamısı artıq buradadırlar, trafikə hazırdırlar, ona görə də trafik sadəcə açılır, hər şey qaydasındadır - proqram yerindədir, hər şey işləməyə davam edir.
Buna görə hazırlıq və canlılıq testləri fərqlidir, üstəlik nəzəri olaraq müxtəlif sağlamlıq yoxlamaları, bir növ radius, bir növ liv, məsələn, müxtəlif şeyləri yoxlaya bilərsiniz. Hazırlıq testləri zamanı arxa tərəflərinizi yoxlayın. Və canlılıq testində, məsələn, canlılıq testinin ümumiyyətlə cavab verə bilən bir tətbiq olduğunu yoxlamırsınız.
Çünki canlılıq testi, ümumiyyətlə, "ilişdiyimiz" zamandır. Sonsuz bir döngə və ya başqa bir şey başladı - və daha çox sorğu emal edilmir. Buna görə də, hətta onları ayırmaq və onlarda fərqli məntiq tətbiq etmək məntiqlidir.
Sınaqdan keçəndə, sağlamlığınızı yoxlayanda nə cavab verməli olduğunuza gəlincə. Sadəcə həqiqətən ağrıdır. Bununla tanış olanlar yəqin ki, güləcəklər - amma ciddi şəkildə, həyatımda 200% hallarda "XNUMX" cavab verən xidmətlər görmüşəm. Yəni kim uğur qazanır. Amma eyni zamanda cavabın mətnində “filan səhv” yazırlar.
Yəni cavab statusu sizə gəlir - hər şey uğurludur. Ancaq eyni zamanda bədəni təhlil etməlisiniz, çünki bədən "bağışlayın, sorğu səhvlə başa çatdı" deyir və bu, sadəcə reallıqdır. Bunu real həyatda gördüm.
Bəzi insanlar bunu gülməli, bəziləri isə çox ağrılı hesab etməməsi üçün yenə də sadə bir qaydaya riayət etməyə dəyər. Sağlamlıq yoxlamalarında və prinsipcə veb proqramları ilə işləyərkən.
Hər şey qaydasındadırsa, onda iki yüzüncü cavabla cavab verin. Prinsipcə, hər iki yüzdə bir cavab sizə uyğun olacaq. Əgər ragsy-i çox yaxşı oxuyursunuzsa və bəzi cavab statuslarının digərlərindən fərqli olduğunu bilirsinizsə, uyğun olanlarla cavab verin: 204, 5, 10, 15, nə olursa olsun. Çox yaxşı deyilsə, sadəcə "iki sıfır sıfır". Hər şey pis gedirsə və sağlamlıq yoxlaması cavab vermirsə, istənilən beş yüzüncü ilə cavab verin. Yenə də, necə cavab verəcəyinizi başa düşsəniz, fərqli cavab statusları bir-birindən necə fərqlənir. Əgər başa düşmürsünüzsə, 502 bir şey səhv olarsa, sağlamlıq yoxlamalarına cavab vermək seçiminizdir.
Bu başqa bir məqamdır, mən əsas xidmətləri yoxlamaq haqqında bir az qayıtmaq istəyirəm. Məsələn, tətbiqinizin arxasında duran bütün əsas xidmətləri yoxlamağa başlasanız - ümumiyyətlə hər şey. Mikroservis arxitekturası nöqteyi-nəzərindən əldə etdiyimiz şey, bizdə "aşağı birləşmə" kimi bir anlayış var - yəni xidmətləriniz bir-birindən minimal asılı olduqda. Onlardan biri uğursuz olarsa, bu funksionallığı olmayan bütün digərləri sadəcə işləməyə davam edəcəklər. Bəzi funksiyalar sadəcə işləmir. Müvafiq olaraq, bütün sağlamlıq yoxlamalarını bir-birinə bağlasanız, o zaman infrastrukturda bir şeyin düşməsi ilə nəticələnəcəksiniz və bu, yıxıldığı üçün bütün xidmətlərin bütün sağlamlıq yoxlamaları da uğursuzluğa düçar olacaq - və ümumiyyətlə, daha çox infrastruktur var. bütün mikroservis arxitekturası No. Orada hər şey qaraldı.
Buna görə də bunu bir daha təkrarlamaq istəyirəm ki, əsas xidmətləri yoxlamaq lazımdır, onsuz da yüz faiz hallarda müraciətiniz öz işini görə bilməz. Yəni, məntiqlidir ki, istifadəçinin verilənlər bazasında saxladığı və ya verilənlər bazasından çıxardığı REST API-niz varsa, verilənlər bazası olmadıqda, istifadəçilərinizlə işləməyə zəmanət verə bilməzsiniz.
Lakin istifadəçiləriniz onları verilənlər bazasından çıxardığınız zaman əlavə olaraq frontend-ə cavab göndərməzdən əvvəl daxil etdiyiniz digər backend-dən bəzi digər metadata ilə zənginləşdirilirsə və bu backend mövcud deyilsə, bu o deməkdir ki, siz metadatanın heç bir hissəsi olmadan cavab verin.
Bundan sonra, tətbiqləri işə salarkən ağrılı məsələlərdən biri də var.
Əslində, bu, təkcə Kubernetes-ə aid deyil, elə oldu ki, bir növ kütləvi inkişaf mədəniyyəti və xüsusən də DevOps Kubernetes ilə eyni vaxtda yayılmağa başladı. Buna görə də, ümumiyyətlə, Kubernetes olmadan tətbiqinizi zərif şəkildə bağlamalı olduğunuz ortaya çıxdı. Kubernetesdən əvvəl də insanlar bunu edirdilər, lakin Kubernetesin gəlişi ilə biz bu barədə kütləvi şəkildə danışmağa başladıq.
Zərif Kapatma
Ümumiyyətlə, Graceful Shutdown nədir və nə üçün lazımdır? Bu, tətbiqinizin nədənsə qəzaya uğraması ilə əlaqədardır, bunu etməlisiniz app stop - və ya məsələn, əməliyyat sistemindən bir siqnal alırsınız, tətbiqiniz bunu başa düşməli və bununla bağlı nəsə etməlidir. Ən pis vəziyyət ssenarisi, əlbəttə ki, ərizənizin SIGTERM alması və “SIGTERM, gəlin dayanaq, işləyək, heç nə etmə” kimi olmasıdır. Bu tamamilə pis seçimdir.
Demək olar ki, eyni dərəcədə pis seçim, ərizəniz SIGTERM aldıqda və “segterm dedilər, bu o deməkdir ki, biz sona çatırıq, mən görməmişəm, heç bir istifadəçi sorğusunu bilmirəm, nə cür olduğunu bilmirəm. hal-hazırda üzərində işlədiyim istəklər, dedilər SIGTERM, bu o deməkdir ki, biz sona çatırıq " Bu da pis seçimdir.
Hansı variant yaxşıdır? Birinci məqam əməliyyatların tamamlanmasını nəzərə almaqdır. Yaxşı bir seçimdir ki, serveriniz SIGTERM aldıqda onun nə etdiyini hələ də nəzərə alsın.
SIGTERM yumşaq bağlanmadır, xüsusi olaraq hazırlanmışdır, kod səviyyəsində tutula bilər, emal oluna bilər, deyin ki, indi gözləyin, əvvəl əlimizdə olan işi bitirəcəyik, sonra çıxacağıq.
Kubernetes nöqteyi-nəzərindən bu, belə görünür. Kubernetes klasterində işləyən poda “zəhmət olmasa dayan, get” dedikdə və ya biz yenidən işə salınırıq və ya Kubernetes podları yenidən yaratdıqda yeniləmə baş verir, Kubernetes poda eyni SIGTERM mesajını göndərir, gözləyir. bir müddət və , bu onun gözlədiyi vaxtdır, o da konfiqurasiya olunur, diplomlarda belə bir xüsusi parametr var və bu Graceful ShutdownTimeout adlanır. Anladığınız kimi, bu, boş yerə deyilmir və indi bu barədə danışdığımız da boş yerə deyil.
Orada xüsusi olaraq deyə bilərik ki, SIGTERM-i tətbiqə göndərdiyimiz vaxtla tətbiqin nəyəsə görə dəli olduğunu və ya "ilişib" qaldığını və bitməyəcəyini başa düşən zaman arasında nə qədər gözləməli olacağıq - və biz bunu etməliyik. ona SIGKILL göndərin, yəni işini çətin tamamlayın. Yəni, müvafiq olaraq, bizdə işləyən bir növ demon var, əməliyyatları emal edir. Biz başa düşürük ki, demonun işlədiyi əməliyyatlarımız orta hesabla bir dəfəyə 30 saniyədən çox davam etmir. Müvafiq olaraq, SIGTERM gələndə anlayırıq ki, demonumuz SIGTERM-dən ən çoxu 30 saniyə sonra bitirə bilər. Biz bunu məsələn 45 saniyə yazırıq hər ehtimala qarşı və SIGTERM deyirik. Bundan sonra 45 saniyə gözləyirik. Nəzəri olaraq, bu müddət ərzində iblis öz işini başa vurmalı və özünü bitirməli idi. Ancaq birdən bunu edə bilmədisə, bu, çox güman ki, ilişib qalıb - o, artıq sorğularımızı normal şəkildə işləmir. Və 45 saniyə ərzində siz təhlükəsiz şəkildə, əslində, onu yerə yıxa bilərsiniz.
Və burada, əslində, hətta 2 aspekt nəzərə alına bilər. Birincisi, anlayın ki, bir sorğu almısınızsa, onunla birtəhər işləməyə başladınız və istifadəçiyə cavab vermədiniz, lakin məsələn, SIGTERM aldınız. Onu təkmilləşdirmək və istifadəçiyə cavab vermək məntiqlidir. Bu baxımdan bir nömrəli məqamdır. Burada XNUMX nömrəli məqam ondan ibarətdir ki, əgər siz öz ərizənizi yazsanız, ümumiyyətlə arxitekturanı elə qurun ki, ərizəniz üçün sorğu alacaqsınız, sonra bir az işə başlayasınız, haradansa faylları yükləməyə, verilənlər bazasını endirməyə və başqa şeylərə başlayırsınız. Bu. Ümumiyyətlə, istifadəçiniz, sorğunuz yarım saat dayanır və ona cavab verməyinizi gözləyir - o zaman, çox güman ki, arxitektura üzərində işləmək lazımdır. Yəni, hətta sağlam düşüncəni də nəzərə alın ki, əməliyyatlarınız qısadırsa, SIGTERM-ə məhəl qoymamaq və onu dəyişdirməyin mənası var. Əgər əməliyyatlarınız uzundursa, bu halda SIGTERM-ə məhəl qoymağın mənası yoxdur. Belə uzun əməliyyatların qarşısını almaq üçün arxitekturanın yenidən dizayn edilməsi məntiqlidir. Beləliklə, istifadəçilər sadəcə oturub gözləməsinlər. Bilmirəm, orada bir növ veb-soket düzəldin, serverinizin artıq müştəriyə göndərəcəyi tərs qarmaqlar düzəldin, başqa bir şey edin, ancaq istifadəçini yarım saat asmağa məcbur etməyin və yalnız bir seans gözləyin. ona cavab ver. Çünki onun harada qırılacağı gözlənilməzdir.
Tətbiqiniz başa çatdıqda, bəzi müvafiq çıxış kodunu təqdim etməlisiniz. Yəni, ərizənizi bağlamaq, dayandırmaq istənilibsə və o, özünü normal şəkildə dayandıra bilibsə, o zaman bir növ çıxış kodunu 1,5,255 və s. qaytarmağa ehtiyac yoxdur. Sıfır kodu olmayan hər şey, ən azı Linux sistemlərində, buna əminəm, uğursuz hesab olunur. Yəni hesab olunur ki, sizin bu halda müraciətiniz xəta ilə başa çatıb. Buna görə dostcasına, müraciətiniz səhvsiz tamamlandısa, çıxışda 0 deyirsiniz. Tətbiqiniz hər hansı səbəbdən uğursuz olarsa, çıxışda qeyri-0 deyirsiniz. Və bu məlumatla işləyə bilərsiniz.
Və son seçim. İstifadəçinizin sorğu göndərməsi və siz onu emal edərkən yarım saat dayanması pisdir. Ancaq ümumiyyətlə, müştəri tərəfindən ümumiyyətlə nəyin dəyərli olduğunu da söyləmək istərdim. Fərq etməz ki, mobil proqram, front-end və s. Nəzərə almaq lazımdır ki, ümumiyyətlə istifadəçinin sessiyası dayandırıla bilər, hər şey ola bilər. Sorğu göndərilə bilər, məsələn, az işlənmiş və heç bir cavab qaytarılmamışdır. Sizin frontend və ya mobil tətbiqiniz - ümumiyyətlə hər hansı bir frontend, gəlin belə deyək - bunu nəzərə almalıdır. Əgər websockets ilə işləyirsinizsə, bu, ümumiyyətlə, indiyə qədər keçirdiyim ən pis ağrıdır.
Bəzi müntəzəm söhbətlərin tərtibatçıları bunu bilmədikdə, veb-rozetin qıra biləcəyi məlum olur. Onlar üçün, proxy-də bir şey baş verəndə, biz sadəcə konfiqurasiyanı dəyişirik və o, yenidən yüklənir. Təbii ki, bütün uzunömürlü seanslar bu halda yırtılır. Tərtibatçılar bizə qaçaraq deyirlər: "Uşaqlar, nə edirsiniz, bütün müştərilərimiz üçün söhbət pozuldu!" Biz onlara deyirik: “Nə edirsən? Müştəriləriniz yenidən qoşula bilmir? Deyirlər: “Xeyr, seansların cırılmaması lazımdır”. Bir sözlə, bu, əslində cəfəngiyyatdır. Müştəri tərəfi nəzərə alınmalıdır. Xüsusilə, dediyim kimi, websockets kimi uzun ömürlü seanslarla o, poza bilər və istifadəçinin fərqinə varmadan belə seansları yenidən quraşdıra bilməlisən. Və sonra hər şey mükəmməldir.
Resurslar
Əslində, burada sizə düz bir hekayə danışacağam. Yenə real həyatdan. Resurslar haqqında eşitdiyim ən pis şey.
Bu vəziyyətdə mənbələr, Kubernetes klasterlərinizdə podlara qoya biləcəyiniz bir növ sorğuları, məhdudiyyətləri nəzərdə tuturam. Bir tərtibatçıdan eşitdiyim ən gülməli şey... Əvvəlki iş yerində işləyən həmkarlarımdan biri bir dəfə dedi: “Mənim tətbiqim klasterdə başlamayacaq.” Baxdım ki, başlamadı, amma ya resurslara uyğun gəlmir, ya da çox kiçik məhdudiyyətlər qoyublar. Bir sözlə, proqram resurslara görə başlaya bilmir. Mən deyirəm: "Resurslara görə başlamayacaq, nə qədər ehtiyacınız olduğuna qərar verəcəksiniz və adekvat dəyər təyin edəcəksiniz." Deyir: “Nə cür resurslar?” Mən ona izah etməyə başladım ki, Kubernetes, istəklərə məhdudiyyətlər və blah, blah, blah müəyyən edilməlidir. Adam beş dəqiqə qulaq asdı, başını tərpətdi və dedi: “Mən bura tərtibatçı kimi işləməyə gəlmişəm, heç bir resurs haqqında heç nə bilmək istəmirəm. Mən bura kod yazmağa gəlmişəm və budur.” Bu kədərlidir. Bu, tərtibatçı baxımından çox kədərli bir anlayışdır. Xüsusilə müasir dünyada, belə demək mümkünsə, mütərəqqi devops.
Niyə ümumiyyətlə resurslara ehtiyac var? Kubernetes-də 2 növ resurs var. Bəziləri sorğular, digərləri isə limitlər adlanır. Resurslara əsasən başa düşəcəyik ki, əsasən həmişə yalnız iki əsas məhdudiyyət var. Yəni, Kubernetes-də işləyən konteyner üçün CPU vaxt məhdudiyyətləri və RAM məhdudiyyətləri.
Limit resursun tətbiqinizdə necə istifadə olunacağına yuxarı hədd qoyur. Yəni buna uyğun olaraq limitlərdə 1GB RAM desəniz, o zaman tətbiqiniz 1GB-dan çox RAM istifadə edə bilməyəcək. Və birdən istəsə və bunu etməyə çalışsa, o zaman oom killer adlanan, yaddaşdan çıxmış, yəni tətbiqinizi öldürəcək bir proses gələcək - yəni sadəcə olaraq yenidən başlayacaq. Proqramlar CPU əsasında yenidən başlamayacaq. CPU baxımından, əgər proqram məhdudiyyətlərdə göstəriləndən çox istifadə etməyə çalışırsa, CPU sadəcə olaraq ciddi şəkildə seçiləcək. Bu, yenidən başlamağa səbəb olmur. Bu hədddir - bu, yuxarı hədddir.
Və bir xahiş var. Sorğu, Kubernetes-in Kubernetes klasterinizdəki qovşaqların tətbiqlərlə necə doldurulduğunu necə başa düşməsidir. Yəni, sorğu ərizənizin bir növ öhdəliyidir. İstifadə etmək istədiyim şey yazır: "İstərdim ki, mənim üçün bu qədər CPU və bu qədər yaddaş rezerv edəsiniz." Belə sadə bir bənzətmə. Ümumilikdə 8 CPU olan, bilmirəm, bir qovşağımız varsa nə etməli? Və ora bir pod gəlir, onun sorğularında 1 CPU deyir, yəni qovşaqda 7 CPU qalıb. Yəni, müvafiq olaraq, hər birinin sorğularında 8 CPU olan 1 pod bu node çatan kimi, qovşaq, sanki Kubernetes nöqteyi-nəzərindən, CPU-nu bitirdi və sorğu ilə daha çox pods ola bilməz. bu qovşaqda işə salındı. Əgər bütün qovşaqlarda CPU bitərsə, onda Kubernetes deməyə başlayacaq ki, klasterdə podlarınızı işə salmaq üçün uyğun qovşaqlar yoxdur, çünki CPU bitib.
Niyə sorğulara ehtiyac var və niyə sorğular olmadan, məncə Kubernetes-də heç nə işə salmağa ehtiyac yoxdur? Gəlin hipotetik bir vəziyyəti təsəvvür edək. Tətbiqinizi sorğu olmadan işə salırsınız, Kubernetes nə qədər şeyə sahib olduğunuzu, onu hansı qovşaqlara itələyə biləcəyinizi bilmir. Yaxşı, düyünlərə itələyir, itələyir, itələyir. Bir nöqtədə, tətbiqinizə trafik almağa başlayacaqsınız. Tətbiqlərdən biri isə birdən-birə resursları limitlərə uyğun olaraq malik olduğu limitlərə qədər istifadə etməyə başlayır. Məlum oldu ki, yaxınlıqda başqa bir proqram var və onun da resurslara ehtiyacı var. Düyün əslində fiziki olaraq resursları tükənməyə başlayır, məsələn, OP. Düyün əslində fiziki olaraq resursların tükənməsinə başlayır, məsələn, təsadüfi giriş yaddaşı (RAM). Bir node gücü tükəndikdə, ilk növbədə docker cavab verməyi dayandıracaq, sonra kubelet, sonra ƏS. Onlar sadəcə huşunu itirəcəklər və HƏR ŞEY mütləq sizin üçün işləməyini dayandıracaq. Yəni bu, nodeunuzun ilişməsinə səbəb olacaq və onu yenidən başlatmalısınız. Bir sözlə, vəziyyət çox da yaxşı deyil.
İstəkləriniz olduqda, məhdudiyyətlər çox fərqli deyil, ən azı məhdudiyyətlərdən və ya sorğulardan dəfələrlə çox deyil, o zaman Kubernetes klasterlərinin qovşaqları arasında tətbiqlərin belə normal, rasional doldurulmasına sahib ola bilərsiniz. Eyni zamanda, Kubernetes nəyin nə qədər hara qoyulduğundan, nə qədərinin harada istifadə olunduğundan təxminən xəbərdardır. Yəni, bu elə bir məqamdır. Bunu başa düşmək vacibdir. Və bunun göstərilməsinə nəzarət etmək vacibdir.
Məlumat saxlama
Növbəti məqamımız məlumatların saxlanması ilə bağlıdır. Onlarla nə etməli və ümumiyyətlə, Kubernetesdə əzmkarlıqla nə etməli?
Düşünürəm ki, yenə bizim daxilində , Kubernetesdə verilənlər bazası haqqında bir mövzu var idi. Mənə elə gəlir ki, mən hətta həmkarlarınızın sizə soruşduqda dediklərini təxminən bilirəm: "Kubernetesdə verilənlər bazası idarə etmək mümkündürmü?" Nədənsə, mənə elə gəlir ki, həmkarlarınız sizə deməliydilər ki, əgər siz Kubernetes-də verilənlər bazası işlətməyin mümkün olub-olmadığı sualını verirsinizsə, bu, mümkün deyil.
Burada məntiq sadədir. Hər halda, bir daha izah edəcəyəm, əgər siz paylanmış şəbəkə yaddaşının kifayət qədər nasazlığa dözümlü sistemi qura bilən bir insansınızsa, bu halda verilənlər bazasını necə yerləşdirməyi, konteynerlərdə yerli buludun necə işləməli olduğunu anlayın. ümumiyyətlə verilənlər bazasında. Çox güman ki, onu necə işlətmək barədə heç bir sualınız yoxdur. Əgər belə bir sualınız varsa və siz əmin olmaq istəyirsiniz ki, hər şey istehsalda açılıb ölümcül dayanır və heç vaxt düşmür, onda bu baş vermir. Bu yanaşma ilə özünüzü ayağınıza vuracağınıza zəmanət verilir. Buna görə etməmək daha yaxşıdır.
Tətbiqimizin saxlamaq istədiyi məlumatlarla, istifadəçilərin yüklədiyi bəzi şəkillərlə, məsələn, işə salınarkən tətbiqimizin işlədiyi müddətdə yaratdığı bəzi şeylərlə nə etməliyik? Kubernetesdə onlarla nə etmək lazımdır?
Ümumiyyətlə, ideal olaraq, bəli, əlbəttə ki, Kubernetes çox yaxşı dizayn edilmişdir və ümumiyyətlə vətəndaşlığı olmayan tətbiqlər üçün nəzərdə tutulmuşdur. Yəni, ümumiyyətlə məlumat saxlamayan proqramlar üçün. Bu idealdır.
Ancaq təbii ki, ideal seçim həmişə mövcud deyil. Nə olsun? Birinci və ən sadə məqam, bir növ S3-ü götürməkdir, sadəcə evdə hazırlanmış deyil, necə işlədiyi də aydın deyil, ancaq bəzi provayderdən. Yaxşı, normal provayder - və tətbiqinizə S3-dən istifadə etməyi öyrədin. Yəni istifadəçiniz fayl yükləmək istəyəndə “burada, lütfən, onu S3-ə yükləyin” deyin. Onu almaq istədikdə deyin: "Budur, S3-ə bir keçid var və onu buradan götürün." Bu idealdır.
Birdən nədənsə bu ideal seçim uyğun gəlmirsə, sizin yazmadığınız, inkişaf etdirmədiyiniz bir proqramınız varsa və ya bu, bir növ dəhşətli mirasdırsa, S3 protokolundan istifadə edə bilməz, ancaq yerli kataloqlarla işləməlidir. yerli qovluqlar. Daha çox və ya daha az sadə bir şey götürün, Kubernetes yerləşdirin. Yəni, Cef-i bəzi minimal tapşırıqlar üçün dərhal qılıncoynatmaq, mənə elə gəlir ki, pis fikirdir. Çünki Ceph, əlbəttə ki, yaxşı və dəblidir. Ancaq həqiqətən nə etdiyinizi başa düşmürsünüzsə, Cef-ə bir şey qoysanız, onu çox asanlıqla və sadəcə olaraq bir daha oradan çıxara bilməzsiniz. Çünki bildiyiniz kimi, Ceph öz klasterində məlumatları sadə fayllar şəklində deyil, binar formada saxlayır. Buna görə də, birdən Ceph klasteri pozulursa, məlumatlarınızı bir daha oradan ala bilməyəcəyiniz tam və yüksək ehtimal var.
Ceph haqqında kursumuz olacaq, edə bilərsiniz .
Buna görə də, NFS serveri kimi sadə bir şey etmək daha yaxşıdır. Kubernetes onlarla işləyə bilər, siz NFS serveri altında kataloq quraşdıra bilərsiniz - tətbiqiniz yerli kataloq kimidir. Eyni zamanda, təbii olaraq, başa düşmək lazımdır ki, yenə də NFS ilə nəsə etmək lazımdır, bəzən onun əlçatmaz ola biləcəyini başa düşmək və bu halda nə edəcəyiniz sualını nəzərdən keçirmək lazımdır. Bəlkə də ayrı bir maşında bir yerdə ehtiyat nüsxəsini çıxarmaq lazımdır.
Haqqında danışdığım növbəti məqam, əgər tətbiqiniz əməliyyat zamanı bəzi faylları yaradırsa, nə etmək lazımdır. Məsələn, işə başlayanda o, tətbiqin yalnız işə salınma anında aldığı bəzi məlumatlara əsaslanan bəzi statik fayl yaradır. Nə an. Əgər belə məlumatlar çox deyilsə, o zaman heç narahat olmaq lazım deyil, sadəcə özünüz üçün bu proqramı quraşdırın və işləyin. Burada yeganə sual nədir, baxın. Çox vaxt WordPress və s. kimi hər cür köhnə sistemlər, xüsusən dəyişdirilmiş bir növ ağıllı plaginlər, ağıllı PHP tərtibatçıları ilə onlar tez-tez özləri üçün bir növ fayl yaratmaq üçün bunu necə etməyi bilirlər. Müvafiq olaraq, biri bir fayl yaradır, ikincisi ikinci fayl yaradır. Onlar fərqlidirlər. Müştərilərin Kubernetes klasterində balanslaşdırma təsadüfən baş verir. Müvafiq olaraq, belə çıxır ki, onlar məsələn, necə birlikdə işləyəcəklərini bilmirlər. Biri bir məlumat verir, digəri istifadəçiyə başqa məlumat verir. Bu, qaçınmalı olduğunuz bir şeydir. Yəni, Kubernetes-də işə saldığınız hər şeyin bir çox hallarda işləyə biləcəyinə zəmanət verilir. Çünki Kubernetes hərəkət edən bir şeydir. Buna görə də heç kimdən soruşmadan istədiyi zaman hər şeyi hərəkət etdirə bilər. Buna görə də, buna güvənmək lazımdır. Bir instansiyada işə salınan hər şey gec-tez uğursuz olacaq. Nə qədər çox rezervasiya etsəniz, bir o qədər yaxşıdır. Amma yenə deyirəm, əgər sizin bir neçə belə faylınız varsa, onları düz altına qoya bilərsiniz, onlar az miqdarda çəkirlər. Əgər onlardan bir az daha çox olarsa, yəqin ki, onları konteynerin içərisinə itələməməlisiniz.
Məsləhət görərdim ki, Kubernetesdə belə gözəl bir şey var, həcmdən istifadə edə bilərsiniz. Xüsusilə boş dir tipli bir həcm var. Yəni, Kubernetes avtomatik olaraq başladığınız serverdəki xidmət qovluqlarında bir kataloq yaradacaq. Və onu sənə verəcək ki, ondan istifadə edə biləsən. Yalnız bir vacib məqam var. Yəni məlumatlarınız konteynerin içərisində deyil, işlədiyiniz hostda saxlanılacaq. Üstəlik, Kubernetes normal konfiqurasiyada belə boş dirsləri idarə edə bilir və onların maksimum ölçüsünü idarə edə bilir və onun aşılmasına imkan vermir. Yeganə məqam odur ki, boş dirəkdə yazdıqlarınız podun yenidən başlaması zamanı itirilmir. Yəni podunuz səhvən düşüb yenidən qalxsa, boş dirdəki məlumat heç yerə getməyəcək. Yeni bir başlanğıcda yenidən istifadə edə bilər - və bu yaxşıdır. Podunuz bir yerə getsə, təbii ki, məlumatsız gedəcək. Yəni boş dir ilə işə salındığı qovşaqdan olan pod itən kimi boş dir silinir.
Boş rejissordan başqa nə yaxşıdır? Məsələn, bir önbellek kimi istifadə edilə bilər. Təsəvvür edək ki, tətbiqimiz anında nəsə yaradır, istifadəçilərə verir və uzun müddət bunu edir. Buna görə də, tətbiq, məsələn, yaradır və istifadəçilərə verir və eyni zamanda onu bir yerdə saxlayır ki, növbəti dəfə istifadəçi eyni şey üçün gələndə onu dərhal yaradılan vermək daha sürətli olacaq. Yaddaşda yaratmaq üçün Kubernetesdən boş dirijor tələb oluna bilər. Beləliklə, keşləriniz ümumiyyətlə ildırım sürətində işləyə bilər - diskə giriş sürəti baxımından. Yəni yaddaşınızda boş dir var, ƏS-də o yaddaşda saxlanılır, ancaq sizin üçün pod daxilindəki istifadəçi üçün o, sadəcə lokal kataloq kimi görünür. Xüsusi olaraq hər hansı bir sehr öyrətmək üçün proqrama ehtiyacınız yoxdur. Siz sadəcə olaraq faylınızı birbaşa götürüb qovluğa yerləşdirirsiniz, əslində isə OS yaddaşına. Bu da Kubernetes baxımından çox əlverişli xüsusiyyətdir.
Minionun hansı problemləri var? Minio ilə bağlı əsas problem odur ki, bu şeyin işləməsi üçün onun haradasa işləməsi lazımdır və bir növ fayl sistemi, yəni yaddaş olmalıdır. Və burada Cephin yaşadığı eyni problemlərlə qarşılaşırıq. Yəni Minio fayllarını hardasa saxlamalıdır. Bu, sadəcə olaraq fayllarınız üçün HTTP interfeysidir. Üstəlik, funksionallıq Amazon S3-dən daha zəifdir. Əvvəllər o, istifadəçiyə lazımi icazə verə bilmirdi. İndi, bildiyim qədər, o, artıq müxtəlif icazələrə malik vedrələr yarada bilər, amma yenə də mənə elə gəlir ki, əsas problem, belə desək, minimum saxlama sistemidir.
Yaddaşdakı Empty dir limitlərə necə təsir edir? Heç bir şəkildə məhdudiyyətlərə təsir göstərmir. Bu, konteynerinizin yaddaşında deyil, ev sahibinin yaddaşındadır. Yəni, konteyneriniz yaddaşdakı boş direktoru işğal olunmuş yaddaşının bir hissəsi kimi görmür. Ev sahibi bunu görür. Buna görə bəli, kubernetlər nöqteyi-nəzərindən, bundan istifadə etməyə başlayanda yaddaşınızın bir hissəsini boş dirəyə həsr etdiyinizi başa düşmək yaxşı olardı. Və buna uyğun olaraq anlayın ki, yaddaş təkcə proqramlara görə deyil, həm də kimsə bu boş dirslərə yazdığından tükənə bilər.
Buludluluq
Və son alt mövzu Cloudnative nədir. Niyə lazımdır? Buludluluq və s.
Yəni müasir bulud infrastrukturunda işləmək üçün bacarıqlı və yazılmış proqramlar. Ancaq əslində Cloudnative-in başqa bir belə cəhəti var. Bu, təkcə müasir bulud infrastrukturunun bütün tələblərini nəzərə alan proqram deyil, həm də bu müasir bulud infrastrukturu ilə işləməyi, onun bu buludlarda işləməsinin üstünlüklərindən və mənfi cəhətlərindən yararlanmağı bilir. Yalnız həddi aşıb buludlarda işləməyin, buludda işləməyin üstünlüklərindən yararlanın.
Məsələn, Kubernetesi götürək. Tətbiqiniz Kubernetesdə işləyir. Tətbiqiniz həmişə, daha doğrusu tətbiqinizin adminləri hər zaman xidmət hesabı yarada bilər. Yəni, serverində Kubernetes-in özündə avtorizasiya üçün hesab. Orada bizə lazım olan bəzi hüquqları əlavə edin. Siz tətbiqinizdən Kubernetes-ə daxil ola bilərsiniz. Bu şəkildə nə edə bilərsən? Məsələn, tətbiqdən digər tətbiqlərinizin, digər oxşar instansiyalarınızın harada yerləşdiyi barədə məlumat alın və belə bir ehtiyac varsa, birlikdə bir şəkildə Kubernetes-in üstündə klaster edin.
Yenə də bu yaxınlarda sözün əsl mənasında bir işimiz oldu. Növbəyə nəzarət edən bir nəzarətçimiz var. Və bu növbədə bəzi yeni tapşırıqlar görünəndə o, Kubernetesə gedir və Kubernetes daxilində yeni pod yaradır. Bu pod bir neçə yeni tapşırıq verir və bu pod çərçivəsində pod tapşırığı yerinə yetirir, nəzarətçinin özünə cavab göndərir və nəzarətçi daha sonra bu məlumatla nəsə edir. Məsələn, verilənlər bazası əlavə edir. Yəni, yenə də bu, tətbiqimizin Kubernetes-də işləməsinin üstünlüyüdür. Tətbiqimizin funksionallığını bir növ genişləndirmək və daha rahat etmək üçün daxili Kubernetes funksionallığından istifadə edə bilərik. Yəni, bir tətbiqin necə işə salınacağı, işçinin necə işə salınacağı ilə bağlı bir növ sehr gizlətməyin. Kubernetes-də proqram Python-da yazılıbsa, sadəcə proqramda sorğu göndərirsiniz.
Kubernetesdən kənara çıxsaq, eyni şey tətbiq olunur. Kubernetlərimiz bir yerdə işləyir - bir növ buludda olsa yaxşıdır. Yenə də biz işlədiyimiz yerdə buludun imkanlarından istifadə edə bilərik və hətta istifadə etməliyik. Buludun bizə verdiyi elementar şeylərdən. Balanslaşdırma, yəni bulud balanslaşdırıcıları yarada və onlardan istifadə edə bilərik. Bu, istifadə edə biləcəyimiz şeylərin birbaşa üstünlüyüdür. Çünki bulud balansı, birincisi, onun necə işlədiyinə, konfiqurasiyasına görə məsuliyyəti bizdən sadəcə axmaqcasına götürür. Üstəlik bu çox rahatdır, çünki adi Kubernetlər buludlarla inteqrasiya edə bilir.
Eyni şey miqyaslamaya da aiddir. Daimi Kubernetes bulud provayderləri ilə inteqrasiya edə bilər. Klasterdə qovşaqlar bitibsə, yəni qovşaq sahəsi tükənibsə, onda əlavə etmək lazım olduğunu necə başa düşməyi bilir - Kubernetes özü klasterinizə yeni qovşaqlar əlavə edəcək və onlar üzərində podları işə salmağa başlayacaq. Yəni yükün gələndə ocaqların sayı artmağa başlayır. Klasterdəki qovşaqlar bu podlar üçün tükəndikdə, Kubernetes yeni qovşaqları işə salır və müvafiq olaraq podların sayı hələ də arta bilər. Və çox rahatdır. Bu, klasteri tez bir zamanda genişləndirmək üçün birbaşa fürsətdir. Çox sürətli deyil, o mənada ki, bu bir saniyə deyil, yeni qovşaqlar əlavə etmək üçün bir dəqiqəyə bənzəyir.
Ancaq təcrübəmdən təkrar edirəm, bu, gördüyüm ən gözəl şeydir. Cloudnative klaster günün vaxtı əsasında miqyaslandıqda. Bu, arxa ofisdəki insanlar tərəfindən istifadə edilən bir xidmət idi. Yəni səhər saat 9-da işə gəlirlər, sistemə daxil olmağa başlayırlar və müvafiq olaraq hamısının işlədiyi Cloudnative klaster şişməyə başlayır və işə gələn hər kəs proqramla işləyə bilsin deyə yeni podlar işə salır. Axşam saat 8 və ya 6:30-da işdən çıxanda Kubernetes qrupları artıq heç kimin tətbiqdən istifadə etmədiyini görür və kiçilməyə başlayır. XNUMX faizə qədər qənaətə zəmanət verilir. O vaxt Amazonda işləyirdi, o vaxt Rusiyada bunu bu qədər yaxşı bacaran yox idi.
Sizə düz deyirəm, qənaət 30 faizdir, çünki biz Kubernetes-dən istifadə edirik və buludun imkanlarından istifadə edirik. İndi bunu Rusiyada etmək olar. Əlbəttə ki, heç kimə reklam etməyəcəyəm, amma deyək ki, bunu edə bilən provayderlər var, onu qutudan dərhal bir düymə ilə təmin edin.
Son bir məqam var ki, onu da diqqətinizə çatdırmaq istərdim. Tətbiqinizin, infrastrukturunuzun Cloudnative olması üçün, nəhayət, İnfrastruktur adlı yanaşmanı Kod kimi uyğunlaşdırmağa başlamaq mənasızdır.Yəni, bu o deməkdir ki, tətbiqiniz, daha doğrusu, infrastrukturunuz eyni şəkildə tələb olunur. kod Tətbiqinizi, biznes məntiqinizi kod şəklində təsvir edin. Və onunla kod kimi işləyin, yəni sınayın, açın, git-də saxlayın, ona CICD tətbiq edin.
Və bu, ilk növbədə, həmişə infrastrukturunuza nəzarət etməyə, onun hansı vəziyyətdə olduğunu həmişə başa düşməyə imkan verən şeydir. İkincisi, səhvlərə səbəb olan əl əməliyyatlarından çəkinin. Üçüncüsü, daim eyni əl işlərini yerinə yetirmək lazım olduqda, sadəcə olaraq dövriyyə deyilən şeydən çəkinin. Dördüncüsü, uğursuzluq halında daha sürətli bərpa etməyə imkan verir. Rusiyada hər dəfə bu barədə danışanda həmişə çoxlu sayda insan var: “Bəli, aydındır, amma yanaşmalarınız var, bir sözlə, heç nəyi düzəltməyə ehtiyac yoxdur”. Amma doğrudur. İnfrastrukturunuzda nəsə pozulubsa, onda Cloudnative yanaşma nöqteyi-nəzərindən və İnfrastrukturun Kod kimi olması nöqteyi-nəzərindən onu düzəltmək, serverə getmək, nəyin xarab olduğunu tapmaq və düzəltmək daha asandır. serveri silmək və yenidən yaratmaq üçün. Və bütün bunları bərpa edəcəyəm.
Bütün bu məsələlər burada daha ətraflı müzakirə olunur . Linkə daxil olaraq proqram və şərtlərlə tanış ola bilərsiniz. Rahat olan odur ki, siz evdə oxuyaraq və ya gündə 1-2 saat işləyərək Kubernetes-i mənimsəyə bilərsiniz.
Mənbə: www.habr.com