Hər bir Kubernetes resursu üçün siz iki növ tələbi konfiqurasiya edə bilərsiniz - Sorğular və Limitlər. Birincisi, konteyner və ya podu işə salmaq üçün lazım olan pulsuz node resurslarının mövcudluğu üçün minimum tələbləri təsvir edir, ikincisi konteyner üçün mövcud olan resursları ciddi şəkildə məhdudlaşdırır.
Kubernetes podları planlaşdırdıqda, konteynerlərin düzgün işləməsi üçün kifayət qədər resurs olması çox vacibdir. Əgər siz resurs məhdud qovşaqda böyük bir tətbiq yerləşdirməyi planlaşdırırsınızsa, ola bilər ki, qovşağın yaddaşı və ya CPU gücü tükəndiyi üçün işləməsin. Bu yazıda biz resurs sorğuları və məhdudiyyətlərdən istifadə edərək hesablama gücü çatışmazlığını necə həll edə biləcəyinizi nəzərdən keçirəcəyik.
Sorğular və Limitlər Kubernetes-in CPU və yaddaş kimi resursları idarə etmək üçün istifadə etdiyi mexanizmlərdir. İstəklər konteynerin tələb olunan resursu almasını təmin edən şeydir. Konteyner resurs tələb edərsə, Kubernetes onu yalnız onu təmin edə bilən qovşaqda planlaşdıracaq. Konteyner tərəfindən tələb olunan resursların heç vaxt müəyyən bir dəyəri keçməyəcəyinə nəzarəti məhdudlaşdırır.
Konteyner yalnız müəyyən bir həddə qədər hesablama gücünü artıra bilər, bundan sonra məhdudlaşacaq. Gəlin görək necə işləyir. Beləliklə, iki növ resurs var - prosessor və yaddaş. Kubernetes planlayıcısı podlarınızı harada işə salacağınızı anlamaq üçün bu resurslar haqqında məlumatlardan istifadə edir. Pod üçün tipik resurs spesifikasiyası bu kimi görünür.
Poddakı hər bir konteyner öz sorğularını və məhdudiyyətlərini təyin edə bilər, hamısı əlavədir. Prosessor resursları millikorlarla müəyyən edilir. Konteynerinizin işləməsi üçün iki tam nüvəyə ehtiyacı varsa, dəyəri 2000m olaraq təyin edirsiniz. Konteyner yalnız nüvənin 1/4 hissəsinin gücünə ehtiyac duyarsa, dəyər 250 m olacaqdır. Nəzərə alın ki, CPU resurs dəyərini ən böyük qovşağın nüvələrinin sayından çox təyin etsəniz, podunuz ümumiyyətlə başlaması planlaşdırılmayacaq. Dörd nüvəyə ehtiyacı olan bir Podunuz varsa və Kubernetes klasteri yalnız iki əsas virtual maşından ibarətdirsə, oxşar vəziyyət yaranacaq.
Tətbiqiniz xüsusi olaraq çoxlu nüvələrdən faydalanmaq üçün nəzərdə tutulmayıbsa (mürəkkəb elmi hesablama və verilənlər bazası əməliyyatları kimi proqramlar ağlınıza gəlir), onda ən yaxşı təcrübə CPU Sorğularını 1 və ya daha aşağıya təyin etmək və sonra miqyaslılıq üçün daha çox replika işlətməkdir. Bu həll sistemə daha çox çeviklik və etibarlılıq verəcəkdir.
CPU məhdudiyyətlərinə gəldikdə, sıxılan bir resurs hesab edildiyi üçün işlər daha maraqlı olur. Tətbiqiniz prosessorun güc həddinə yaxınlaşmağa başlayarsa, Kubernetes prosessor tezliyini azaltmaqla CPU Dəyişikliyi istifadə edərək konteynerinizi yavaşlatmağa başlayacaq. Bu o deməkdir ki, CPU süni şəkildə tıxanacaq və tətbiqə potensial olaraq daha pis performans verəcək, lakin proses dayandırılmayacaq və ya çıxarılmayacaq.
Yaddaş resursları baytlarla müəyyən edilir. Adətən parametrlərdəki dəyər mebibayt Mib ilə ölçülür, lakin siz baytdan petabaytlara qədər istənilən dəyəri təyin edə bilərsiniz. Eyni vəziyyət CPU ilə olduğu kimi burada da tətbiq olunur - qovşaqlarınızdakı yaddaş miqdarından çox yaddaş miqdarı üçün sorğu yerləşdirsəniz, həmin podun icrası planlaşdırılmayacaq. Lakin CPU resurslarından fərqli olaraq yaddaş sıxılmır, çünki onun istifadəsini məhdudlaşdırmaq üçün heç bir yol yoxdur. Buna görə də, konteynerin icrası ona ayrılmış yaddaşdan kənara çıxan kimi dayandırılacaqdır.
Xatırlamaq vacibdir ki, siz qovşaqlarınızın təmin edə biləcəyi resursları aşan sorğuları konfiqurasiya edə bilməzsiniz. GKE virtual maşınları üçün paylaşılan resurs spesifikasiyası bu videonun altındakı linklərdə tapıla bilər.
İdeal bir dünyada, konteynerin standart parametrləri iş axınının rəvan işləməsini təmin etmək üçün kifayət edəcəkdir. Amma real dünya belə deyil, insanlar resurslardan istifadəni konfiqurasiya etməyi asanlıqla unuda bilərlər, yoxsa hakerlər infrastrukturun real imkanlarını aşan sorğular və məhdudiyyətlər təyin edəcəklər. Belə ssenarilərin baş verməsinin qarşısını almaq üçün siz ResourceQuota və LimitRange resurs kvotalarını konfiqurasiya edə bilərsiniz.
Ad sahəsi yaradıldıqdan sonra kvotalardan istifadə etməklə bloklana bilər. Məsələn, məhsul və inkişaf ad boşluqlarınız varsa, nümunə ondan ibarətdir ki, istehsal kvotaları ümumiyyətlə yoxdur və çox ciddi inkişaf kvotaları var. Bu, trafikin kəskin artması halında istehsalçıya bütün mövcud resursu ələ keçirməyə imkan verir, devi tamamilə bloklayır.
Resurs kvotası belə görünə bilər. Bu nümunədə 4 bölmə var - bunlar kodun 4 alt sətiridir.
Gəlin onların hər birinə nəzər salaq. Requests.cpu ad məkanındakı bütün konteynerlərdən gələ biləcək birləşdirilmiş CPU sorğularının maksimum sayıdır. Bu misalda, 50 m sorğu ilə 10 konteyner, 100 m sorğu ilə beş konteyner və ya 500 m sorğu ilə yalnız bir konteyner ola bilər. Müəyyən bir ad sahəsinin sorğularının ümumi sayı 500 m-dən az olduqda, hər şey yaxşı olacaq.
Yaddaş tələb olunan sorğular.yaddaş ad məkanındakı bütün konteynerlərin malik ola biləcəyi birləşmiş yaddaş sorğularının maksimum miqdarıdır. Əvvəlki halda olduğu kimi, ad məkanında tələb olunan yaddaşın ümumi həcmi 50 mebibaytdan az olduqda, 2 20 mib konteyner, beş 100 mib konteyner və ya tək 100 mib konteyner ola bilər.
Limits.cpu ad məkanındakı bütün konteynerlərin istifadə edə biləcəyi CPU gücünün maksimum ümumi miqdarıdır. Bunu prosessorun güc tələblərinin həddi hesab edə bilərik.
Nəhayət, limits.memory ad məkanındakı bütün konteynerlərin istifadə edə biləcəyi paylaşılan yaddaşın maksimum miqdarıdır. Bu, ümumi yaddaş sorğuları üçün məhdudiyyətdir.
Beləliklə, standart olaraq, Kubernetes klasterindəki konteynerlər məhdudiyyətsiz hesablama resursları ilə işləyir. Resurs kvotaları ilə klaster administratorları ad sahəsinə əsaslanaraq resurs istehlakını və resurs yaradılmasını məhdudlaşdıra bilər. Ad məkanında pod və ya konteyner ad sahəsi resursu kvotası ilə müəyyən edilən qədər CPU gücü və yaddaş istehlak edə bilər. Bununla belə, bir pod və ya konteynerin bütün mövcud resursları inhisara alması ilə bağlı narahatlıq var. Bu vəziyyətin qarşısını almaq üçün limit diapazonundan istifadə olunur - ad məkanında resursların (pod və ya konteynerlər üçün) ayrılmasını məhdudlaşdıran siyasət.
Limit diapazonu aşağıdakıları edə biləcək məhdudiyyətləri təmin edir:
- Adlar məkanında hər bir modul və ya konteyner üçün hesablama resurslarının minimum və maksimum istifadəsini təmin etmək;
- ad məkanında hər PersistentVolumeClaim üçün minimum və maksimum Starage Sorğu saxlama sorğularını tətbiq etmək;
- ad məkanında resurs üçün Sorğu və Limit arasında əlaqəni tətbiq etmək;
- adlar məkanında hesablama resursları üçün defolt Sorğular/Limitlər təyin edin və onları iş vaxtı avtomatik olaraq konteynerlərə daxil edin.
Bu yolla ad məkanınızda limit aralığı yarada bilərsiniz. Bütün ad sahəsinə aid olan kvotadan fərqli olaraq, Limit Range fərdi konteynerlər üçün istifadə olunur. Bu, istifadəçilərin ad məkanında çox kiçik və ya əksinə, nəhəng konteynerlər yaratmasının qarşısını ala bilər. Limit diapazonu belə görünə bilər.
Əvvəlki halda olduğu kimi burada da 4 bölməni ayırd etmək olar. Gəlin hər birinə baxaq.
Defolt bölmə poddakı konteyner üçün standart məhdudiyyətləri təyin edir. Bu dəyərləri həddindən artıq aralığa təyin etsəniz, bu dəyərlərin açıq şəkildə təyin olunmadığı hər hansı konteynerlər standart dəyərlərə əməl edəcəklər.
Defolt sorğu bölməsi defaultRequest poddakı konteyner üçün standart sorğuları konfiqurasiya edir. Yenə də, bu dəyərləri həddindən artıq aralığa təyin etsəniz, bu seçimləri açıq şəkildə təyin etməyən hər hansı konteynerlər bu dəyərlərə defolt olacaq.
Maksimum bölmə poddakı konteyner üçün təyin edilə bilən maksimum limitləri təyin edir. Defolt bölmədəki dəyərlər və konteyner limitləri bu limitdən yuxarı təyin edilə bilməz. Qeyd etmək vacibdir ki, dəyər maks olaraq təyin edilibsə və standart bölmə yoxdursa, maksimum dəyər standart dəyərə çevrilir.
Min bölməsi poddakı konteyner üçün təyin edilə bilən minimum sorğuları müəyyən edir. Bununla belə, standart bölmədəki dəyərlər və konteyner üçün sorğular bu limitdən aşağı təyin edilə bilməz.
Yenə də qeyd etmək lazımdır ki, əgər bu dəyər təyin edilibsə, defolt deyil, o zaman minimum dəyər standart sorğuya çevrilir.
Bu resurs sorğuları son nəticədə iş yüklərinizi yerinə yetirmək üçün Kubernetes planlaşdırıcısı tərəfindən istifadə olunur. Konteynerlərinizi düzgün konfiqurasiya etmək üçün onun necə işlədiyini başa düşmək çox vacibdir. Tutaq ki, siz klasterinizdə çoxlu podları işə salmaq istəyirsiniz. Pod spesifikasiyalarının etibarlı olduğunu fərz etsək, Kubernetes cədvəli iş yükünü işə salmaq üçün qovşağı seçmək üçün dairəvi balanslaşdırmadan istifadə edəcək.
Kubernetes Node 1-in pod konteynerlərindən gələn sorğuları yerinə yetirmək üçün kifayət qədər resursunun olub-olmadığını yoxlayacaq və əgər yoxdursa, növbəti node-a keçəcək. Sistemdəki qovşaqlardan heç biri sorğuları təmin edə bilmirsə, podlar Gözləmə vəziyyətinə keçəcək. Düyün avtomatik miqyası kimi Google Kubernetes mühərrik xüsusiyyətlərindən istifadə edərək, GKE gözləmə vəziyyətini avtomatik aşkarlaya və daha bir neçə əlavə qovşaq yarada bilər.
Əgər sonradan node tutumunuz tükənərsə, avtomatik miqyaslama sizə pula qənaət etmək üçün qovşaqların sayını azaldacaq. Buna görə Kubernetes sorğular əsasında podları planlaşdırır. Bununla belə, limit sorğulardan yüksək ola bilər və bəzi hallarda qovşaq həqiqətən resursları tükəndirə bilər. Biz bu dövlətin həddindən artıq öhdəlik vəziyyəti deyirik.
Dediyim kimi, CPU-ya gəldikdə, Kubernetes podları məhdudlaşdırmağa başlayacaq. Hər bir pod tələb etdiyi qədər alacaq, lakin limitə çatmazsa, tənzimləmə tətbiq edilməyə başlayacaq.
Yaddaş resurslarına gəldikdə, Kubernetes sistem resurslarını boşaltana qədər və ya bütün sistem çökənə qədər hansı podların silinəcəyi və hansının saxlanacağı barədə qərar qəbul etməyə məcbur olur.
Yaddaşınızın tükəndiyi bir ssenarini təsəvvür edək - Kubernetes bunu necə idarə edərdi?
Kubernetes tələb etdiyindən daha çox resurs istifadə edən podlar axtaracaq. Beləliklə, konteynerlərinizdə heç bir Sorğu yoxdursa, bu o deməkdir ki, onlar istədiklərindən daha çox istifadə etməyə məcburdurlar, sadəcə olaraq, ümumiyyətlə heç nə istəmədikləri üçün! Belə konteynerlər bağlanmağa əsas namizəd olurlar. Növbəti namizədlər bütün istəklərini təmin etmiş, lakin hələ də maksimum limitdən aşağı olan konteynerlərdir.
Beləliklə, Kubernetes sorğu parametrlərini aşmış bir neçə pod tapsa, o, onları prioritetlərə görə çeşidləyəcək və sonra ən aşağı prioritet podları siləcək. Bütün podlar eyni prioritetə malikdirsə, Kubernetes digər podlara nisbətən sorğularını aşan podları ləğv edəcək.
Çox nadir hallarda, Kubernetes hələ də sorğularının əhatə dairəsində olan podları dayandıra bilər. Bu, Kubelet agenti və ya Docker kimi kritik sistem komponentləri onlar üçün ayrılandan daha çox resurs istehlak etməyə başlayanda baş verə bilər.
Beləliklə, kiçik şirkətlərin ilkin mərhələlərində Kubernetes klasteri resurs sorğuları və məhdudiyyətlər qoymadan yaxşı işləyə bilər, lakin komandalarınız və layihələriniz böyüməyə başlayanda bu sahədə problemlərlə üzləşmək riskiniz var. Modullarınıza və ad boşluqlarınıza sorğular və məhdudiyyətlər əlavə etmək çox az əlavə səy tələb edir və bir çox çətinlikdən xilas ola bilər.
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