27 aprel konfransda , "DevOps" bölməsinin bir hissəsi olaraq "Kubernetes-də avtomatik ölçmə və resurs idarəetməsi" hesabatı verildi. Tətbiqlərinizin yüksək əlçatanlığını təmin etmək və ən yüksək performansı təmin etmək üçün K8-lərdən necə istifadə edə biləcəyinizdən bəhs edir.
Ənənəyə uyğun olaraq təqdim etməkdən məmnunuq (44 dəqiqə, məqalədən daha çox məlumatlandırıcı) və mətn şəklində əsas xülasə. Get!
Hesabat mövzusunu sözbəsöz təhlil edək və sondan başlayaq.
Kubernetes
Deyək ki, hostumuzda Docker konteynerləri var. Nə üçün? Təkrarlanabilirliyi və izolyasiyanı təmin etmək, bu da öz növbəsində sadə və yaxşı yerləşdirməyə imkan verir, CI/CD. Konteynerli belə maşınlarımız çoxdur.
Bu halda Kubernetes nə təmin edir?
- Bu maşınlar haqqında düşünməyi dayandırırıq və "bulud" ilə işləməyə başlayırıq. konteynerlərin çoxluğu və ya pods (qablar qrupları).
- Üstəlik, biz fərdi podlar haqqında düşünmürük, lakin daha çox idarə edirikоdaha böyük qruplar. Bu cür yüksək səviyyəli primitivlər müəyyən bir iş yükünü yerinə yetirmək üçün bir şablon olduğunu söyləməyə icazə verin və burada onu işə salmaq üçün lazımi sayda nümunələr var. Əgər şablonu sonradan dəyişdirsək, bütün nümunələr dəyişəcək.
- Ilə deklarativ API Xüsusi əmrlər ardıcıllığını yerinə yetirmək əvəzinə, biz Kubernetes tərəfindən yaradılan “dünyanın strukturunu” (YAML-də) təsvir edirik. Və yenə: təsvir dəyişdikdə, onun həqiqi ekranı da dəyişəcək.
Resursların idarə edilməsi
CPU
Gəlin serverdə nginx, php-fpm və mysql işlədək. Bu xidmətlər əslində hər biri hesablama resursları tələb edən daha çox prosesə sahib olacaq:
(slayddakı nömrələr "tutuquşular", hesablama gücü üçün hər bir prosesin mücərrəd ehtiyacıdır)
Bununla işləməyi asanlaşdırmaq üçün prosesləri qruplara (məsələn, bütün nginx proseslərini bir qrup “nginx”ə) birləşdirmək məntiqlidir. Bunun sadə və aydın yolu hər bir qrupu bir konteynerə qoymaqdır:
Davam etmək üçün konteynerin nə olduğunu xatırlamalısınız (Linux-da). Onların görünüşü nüvədə çoxdan tətbiq edilmiş üç əsas xüsusiyyət sayəsində mümkün olmuşdur: , и . Və sonrakı inkişaf digər texnologiyalar (o cümlədən Docker kimi rahat "qabıqlar") tərəfindən asanlaşdırıldı:
Hesabat kontekstində bizi yalnız maraqlandırır qruplar, çünki nəzarət qrupları resurs idarəetməsini həyata keçirən konteynerlərin (Docker və s.) funksionallığının bir hissəsidir. Qruplara birləşdirilən proseslər, istədiyimiz kimi, nəzarət qruplarıdır.
Bu proseslər üçün CPU tələblərinə, indi isə proses qruplarına qayıdaq:
(Təkrar edirəm ki, bütün rəqəmlər resurslara ehtiyacın mücərrəd ifadəsidir)
Eyni zamanda, CPU-nun özü müəyyən məhdud resursa malikdir (nümunədə bu 1000-dir), hər kəsdə çatışmazlıq ola bilər (bütün qrupların ehtiyaclarının cəmi 150+850+460=1460). Bu halda nə olacaq?
Kernel resursları paylamağa başlayır və hər qrupa eyni miqdarda resurs verərək bunu "ədalətli" edir. Lakin birinci halda onların sayı lazım olandan çoxdur (333>150), ona görə də artıqlıq (333-150=183) ehtiyatda qalır ki, bu da digər iki konteyner arasında bərabər paylanır:
Nəticədə: birinci konteynerin kifayət qədər resursları var idi, ikincinin - kifayət qədər resursu yox idi, üçüncünün - kifayət qədər resursu yox idi. Bu, hərəkətlərin nəticəsidir Linux-da "dürüst" planlaşdırıcı - . Onun işi tapşırıqdan istifadə edərək tənzimlənə bilər çəkilər konteynerlərin hər biri. Məsələn, bu kimi:
İkinci konteynerdə (php-fpm) resursların olmaması halına baxaq. Bütün konteyner resursları proseslər arasında bərabər paylanır. Nəticədə, master proses yaxşı işləyir, lakin bütün işçilər ehtiyaclarının yarısından azını alaraq yavaşlayır:
CFS planlayıcısı belə işləyir. Konteynerlərə təyin etdiyimiz çəkiləri daha sonra adlandıracağıq istək. Niyə belədir - daha çox baxın.
Bütün vəziyyətə digər tərəfdən baxaq. Bildiyiniz kimi, bütün yollar Romaya, kompüter vəziyyətində isə CPU-ya aparır. Bir CPU, bir çox tapşırıq - sizə işıqfor lazımdır. Resursları idarə etməyin ən sadə yolu “svetofor”dur: onlar bir prosesə CPU-ya sabit giriş vaxtı verdilər, sonra növbəti prosesə və s.
Bu yanaşma sərt kvotalar adlanır (sərt məhdudlaşdırma). Bunu sadəcə olaraq xatırlayaq məhdudiyyətlər. Bununla belə, limitləri bütün konteynerlərə paylasanız, problem yaranır: mysql yol boyu sürürdü və bir anda CPU ehtiyacı bitdi, lakin bütün digər proseslər CPU-ya qədər gözləmək məcburiyyətində qaldı. boş.
Linux nüvəsinə və onun CPU ilə qarşılıqlı əlaqəsinə qayıdaq - ümumi şəkil aşağıdakı kimidir:
cgroup-un iki parametri var - mahiyyətcə bunlar müəyyən etməyə imkan verən iki sadə "twist"dir:
- konteyner (istəklər) üçün çəkidir səhmlərin;
- konteyner tapşırıqları üzərində işləmək üçün ümumi CPU vaxtının faizi (limitlər) təşkil edir pay.
CPU-nu necə ölçmək olar?
Müxtəlif yollar var:
- Nədir papağanlar, heç kim bilmir - hər dəfə danışıqlar aparmaq lazımdır.
- Faiz daha aydın, lakin nisbi: 50 nüvəli və 4 nüvəli bir serverin 20% -i tamamilə fərqli şeylərdir.
- Artıq qeyd olunanlardan istifadə edə bilərsiniz çəkilər, bunu Linux bilir, lakin onlar da nisbidir.
- Ən adekvat variant hesablama resurslarını ölçməkdir saniyə. Bunlar. real vaxt saniyələrinə nisbətən prosessor vaxtının saniyələri ilə: 1 real saniyəyə 1 saniyə prosessor vaxtı verildi - bu, bir CPU nüvəsidir.
Danışığı daha da asanlaşdırmaq üçün birbaşa ölçməyə başladılar ləpələr, onlar tərəfindən real prosesə nisbətən eyni CPU vaxtı deməkdir. Linux çəkiləri başa düşdüyündən, lakin CPU vaxtı/nüvələri o qədər də çox deyil, birindən digərinə tərcümə etmək üçün mexanizm lazım idi.
3 CPU nüvəsi olan bir server ilə sadə bir nümunəni nəzərdən keçirək, burada üç podmaya çəkilər (500, 1000 və 1500) veriləcək ki, onlar asanlıqla onlara ayrılmış nüvələrin müvafiq hissələrinə (0,5, 1 və 1,5) çevrilir.
Əgər nüvələrin iki dəfə çox olacağı (6) ikinci server götürsəniz və orada eyni podları yerləşdirsəniz, nüvələrin paylanmasını sadəcə olaraq 2-yə (müvafiq olaraq 1, 2 və 3) vurmaqla asanlıqla hesablamaq olar. Lakin bu serverdə çəkisi 3000-ə bərabər olan dördüncü pod görünəndə mühüm məqam baş verir. O, CPU resurslarının bir hissəsini (nüvələrin yarısı) götürür, qalan podlar üçün isə yenidən hesablanır (yarıya endirilir):
Kubernetes və CPU resursları
Kubernetes-də CPU resursları adətən ölçülür milliadraks, yəni. Əsas çəki kimi 0,001 nüvə qəbul edilir. (Linux/cgroups terminologiyasında eyni şey CPU payı adlanır, baxmayaraq ki, daha dəqiq desək, 1000 millicores = 1024 CPU payı.) K8s serverdə bütün podların çəkilərinin cəminə görə CPU resurslarından daha çox pods yerləşdirməməsini təmin edir.
Bu necə baş verir? Kubernetes klasterinə server əlavə etdiyiniz zaman onun nə qədər CPU nüvəsi olduğu bildirilir. Yeni pod yaratarkən, Kubernetes planlaşdırıcısı bu podun neçə nüvəyə ehtiyac duyacağını bilir. Beləliklə, pod kifayət qədər nüvənin olduğu bir serverə təyin ediləcək.
Nə olarsa heç bir sorğu göstərilib (yəni podda ehtiyac duyduğu müəyyən sayda nüvə yoxdur)? Gəlin Kubernetesin ümumiyyətlə resursları necə saydığını anlayaq.
Pod üçün siz həm sorğuları (CFS planlaşdırıcısı) həm də limitləri (svetoforu xatırlayırsınız?) təyin edə bilərsiniz:
- Əgər onlar bərabər göstərilibsə, o zaman poda QoS sinfi təyin edilir zəmanətli. Onun üçün həmişə mövcud olan bu sayda nüvəyə zəmanət verilir.
- Sorğu limitdən azdırsa - QoS sinfi partlaya bilən. Bunlar. Məsələn, bir podun həmişə 1 nüvədən istifadə etməsini gözləyirik, lakin bu dəyər onun üçün məhdudiyyət deyil: bəzən pod daha çox istifadə edə bilər (serverdə bunun üçün pulsuz resurslar olduqda).
- QoS sinfi də var ən yaxşı səy — bu, sorğunun göstərilmədiyi podları ehtiva edir. Resurslar ən son onlara verilir.
yaddaş
Yaddaşla vəziyyət oxşardır, lakin bir qədər fərqlidir - axırda bu resursların təbiəti fərqlidir. Ümumiyyətlə, bənzətmə aşağıdakı kimidir:
Sorğuların yaddaşda necə həyata keçirildiyinə baxaq. Podlar yaddaş istehlakını dəyişdirərək serverdə yaşasın, onlardan biri yaddaşı tükənəcək qədər böyüyənə qədər. Bu halda, OOM qatili görünür və ən böyük prosesi öldürür:
Bu, həmişə bizə uyğun gəlmir, ona görə də hansı proseslərin bizim üçün vacib olduğunu və öldürülməməli olduğunu tənzimləmək mümkündür. Bunu etmək üçün parametrdən istifadə edin oom_score_adj.
CPU-nun QoS siniflərinə qayıdaq və podlar üçün yaddaş istehlakı prioritetlərini müəyyən edən oom_score_adj dəyərlərinə bənzətmə aparaq:
- Pod üçün ən aşağı oom_score_adj dəyəri - -998 - o deməkdir ki, belə bir pod ən son öldürülməlidir, bu zəmanətli.
- Ən yüksək - 1000-dir ən yaxşı səy, belə podlar əvvəlcə öldürülür.
- Qalan dəyərləri hesablamaq üçün (partlaya bilən) bir düstur var, onun mahiyyəti ondan ibarətdir ki, pod nə qədər çox resurs tələb etsə, onun öldürülmə ehtimalı bir o qədər azdır.
İkinci "twist" - limit_bayt - məhdudiyyətlər üçün. Bununla hər şey daha sadədir: biz sadəcə verilən yaddaşın maksimum miqdarını təyin edirik və burada (CPU-dan fərqli olaraq) onu (yaddaş) necə ölçmək barədə heç bir sual yoxdur.
Ümumi
Kubernetesdəki hər bir pod verilir requests и limits - CPU və yaddaş üçün hər iki parametr:
- sorğular əsasında serverlər arasında podları paylayan Kubernetes planlaşdırıcısı işləyir;
- bütün parametrlər əsasında podun QoS sinfi müəyyən edilir;
- Nisbi çəkilər CPU sorğuları əsasında hesablanır;
- CFS planlaşdırıcısı CPU sorğuları əsasında konfiqurasiya edilir;
- OOM killer yaddaş sorğuları əsasında konfiqurasiya edilir;
- "svetofor" CPU limitlərinə əsasən konfiqurasiya edilir;
- Yaddaş məhdudiyyətlərinə əsasən, qrup üçün limit konfiqurasiya edilir.
Ümumiyyətlə, bu şəkil resursların idarə edilməsinin əsas hissəsinin Kubernetes-də necə baş verdiyinə dair bütün suallara cavab verir.
Avtomatik miqyaslama
K8s klaster-avtomatik miqyaslayıcı
Təsəvvür edək ki, bütün klaster artıq işğal olunub və yeni pod yaratmaq lazımdır. Pod görünə bilməsə də, statusunda qalır Bekleyen. Onun görünməsi üçün biz klasterə yeni server qoşa və ya... klaster-avtomiqyaslayıcı quraşdıra bilərik ki, bu da bizim üçün bunu edəcək: bulud provayderindən virtual maşın sifariş edin (APİ sorğusundan istifadə etməklə) və onu klasterə birləşdirin. , bundan sonra pod əlavə olunacaq.
Bu, əla işləyən Kubernetes klasterinin avtomatik miqyasıdır (təcrübəmizdə). Ancaq hər yerdə olduğu kimi burada da bəzi nüanslar var...
Nə qədər ki, biz çoxluq ölçüsünü artırdıq, hər şey yaxşı idi, amma çoxluq yarandıqda nə olur özünü azad etməyə başladı? Problem ondadır ki, podların köçürülməsi (hostları boşaltmaq üçün) texniki cəhətdən çox çətin və resurslar baxımından bahalıdır. Kubernetes tamamilə fərqli bir yanaşmadan istifadə edir.
Yerləşdirməyə malik 3 serverdən ibarət klasteri nəzərdən keçirək. 6 pods var: indi hər server üçün 2 var. Nədənsə serverlərdən birini söndürmək istədik. Bunu etmək üçün əmrdən istifadə edəcəyik kubectl drain, hansı:
- bu serverə yeni podların göndərilməsini qadağan edəcək;
- serverdəki mövcud podları siləcək.
Kubernetes podların sayının (6) saxlanmasına cavabdeh olduğundan, sadəcə olaraq yenidən yaradacaq onları digər qovşaqlarda, lakin qeyri-aktiv olanda deyil, çünki o, artıq yeni podların yerləşdirilməsi üçün əlçatmaz kimi qeyd olunub. Bu Kubernetes üçün əsas mexanikdir.
Ancaq burada da bir nüans var. Bənzər bir vəziyyətdə, StatefulSet üçün (yerləşdirmə əvəzinə) hərəkətlər fərqli olacaq. İndi bizdə artıq statuslu bir proqram var - məsələn, MongoDB ilə üç pod, onlardan birində problem var (məlumatlar pozulub və ya podun düzgün başlamasına mane olan başqa bir səhv). Və yenə bir serveri söndürməyə qərar verdik. Nə olacaq?
MongoDB bilərdi ölmək lazımdır, çünki onun kvoruma ehtiyacı var: üç qurğudan ibarət klaster üçün ən azı ikisi fəaliyyət göstərməlidir. Bununla belə, bu baş vermir - sayəsində PodDisruptionBudget. Bu parametr minimum tələb olunan işçi podların sayını müəyyən edir. MongoDB podlarından birinin artıq işləmədiyini bilmək və PodDisruptionBudget-ın MongoDB üçün qurulduğunu görmək minAvailable: 2, Kubernetes sizə podu silməyə icazə verməyəcək.
Aşağı xətt: klaster buraxıldıqda podların hərəkətinin (və əslində yenidən yaradılmasının) düzgün işləməsi üçün PodDisruptionBudget-ı konfiqurasiya etmək lazımdır.
Üfüqi miqyaslama
Başqa bir vəziyyəti nəzərdən keçirək. Kubernetes-də Deployment kimi işləyən proqram var. İstifadəçi trafiki öz podlarına gəlir (məsələn, onlardan üçü var) və biz onlarda müəyyən bir göstəricini ölçürük (məsələn, CPU yükü). Yük artdıqda, biz onu cədvəldə qeyd edirik və sorğuları yaymaq üçün podların sayını artırırıq.
Bu gün Kubernetesdə bunu əl ilə etmək lazım deyil: ölçülən yük göstəricilərinin dəyərlərindən asılı olaraq podların sayında avtomatik artım/azalma konfiqurasiya edilir.
Burada əsas suallar bunlardır: dəqiq nə ölçmək lazımdır и necə şərh etmək olar əldə edilmiş dəyərlər (podların sayını dəyişdirmək barədə qərar qəbul etmək üçün). Çox ölçə bilərsiniz:
Bunu texniki cəhətdən necə etmək olar - ölçüləri toplamaq və s. - Hesabatda ətraflı danışdım . Və optimal parametrləri seçmək üçün əsas məsləhətdir təcrübə!
Yoxdur (İstifadə Doyması və Səhvlər), mənası aşağıdakı kimidir. Məsələn, php-fpm-i miqyaslandırmağın nəyə əsaslanaraq mənası var? İşçilərin tükənməsinə əsaslanaraq, bu istifadəsi. Və işçilər bitibsə və yeni əlaqələr qəbul edilmirsə, bu artıqdır saturasiya. Bu parametrlərin hər ikisi ölçülməlidir və dəyərlərdən asılı olaraq miqyaslama aparılmalıdır.
Bunun əvəzinə bir nəticəyə
Hesabatın davamı var: şaquli miqyaslama və düzgün resursların necə seçiləcəyi haqqında. Bu haqda gələcək videolarda danışacam - qaçırmamaq üçün abunə olun!
Videolar və slaydlar
Tamaşadan video (44 dəqiqə):
Hesabat təqdimatı:
PS
Bloqumuzda Kubernetes haqqında digər hesabatlar:
- «» (Andrey Polovov; 8 aprel 2019-cu il Saint HighLoad++-da);
- «» (Dmitri Stolyarov; 8 noyabr 2018-ci il HighLoad++ ilə);
- «» (Dmitri Stolyarov; 28 may 2018-ci il, RootConf-da);
- «» (Dmitri Stolyarov; 7 noyabr 2017-ci il HighLoad++ ilə);
- «» (Dmitri Stolyarov; 6 iyun 2017-ci ildə RootConf-da).
Mənbə: www.habr.com