27 април на конференцијата , како дел од делот „DevOps“, беше даден извештајот „Автоматско мерење и управување со ресурси во Kubernetes“. Зборува за тоа како можете да ги користите K8 за да обезбедите висока достапност на вашите апликации и да обезбедите врвни перформанси.
По традиција, со задоволство ви претставуваме (44 минути, многу поинформативно од написот) и главното резиме во текстуална форма. Оди!
Ајде да ја анализираме темата на извештајот збор по збор и да почнеме од крајот.
Кубернети
Да речеме дека имаме Docker контејнери на нашиот домаќин. За што? За да се обезбеди повторливост и изолација, што пак овозможува едноставно и добро распоредување, CI/CD. Имаме многу такви возила со контејнери.
Што обезбедува Kubernetes во овој случај?
- Престануваме да размислуваме за овие машини и почнуваме да работиме со „облакот“ кластер на контејнери или мешунки (групи контејнери).
- Покрај тоа, ние дури и не размислуваме за поединечни мешунки, туку управуваме со повеќеопоголеми групи. Таков примитивци на високо ниво дозволете ни да кажеме дека постои шаблон за извршување на одреден обем на работа и еве го потребниот број на примероци за да се изврши. Ако последователно го смениме шаблонот, сите примероци ќе се променат.
- Со декларативно API Наместо да извршиме низа од специфични команди, ја опишуваме „структурата на светот“ (во YAML), која е создадена од Кубернетес. И повторно: кога ќе се промени описот, ќе се промени и неговиот вистински приказ.
Менаџирање со ресурси
Процесорот
Дозволете ни да извршиме nginx, php-fpm и mysql на серверот. Овие услуги всушност ќе имаат уште повеќе процеси кои се извршуваат, од кои секоја бара компјутерски ресурси:
(броевите на слајдот се „папагали“, апстрактната потреба на секој процес за компјутерска моќ)
За да може полесно да се работи со ова, логично е да се комбинираат процесите во групи (на пример, сите процеси на nginx во една група „nginx“). Едноставен и очигледен начин да го направите ова е да ја ставите секоја група во контејнер:
За да продолжите, треба да запомните што е контејнер (во Linux). Нивниот изглед беше овозможен благодарение на трите клучни карактеристики во кернелот, имплементирани многу одамна: , и . И понатамошниот развој беше олеснет со други технологии (вклучувајќи удобни „школки“ како Докер):
Во контекст на извештајот не интересира само групите, бидејќи контролните групи се дел од функционалноста на контејнерите (Docker и сл.) што го имплементира управувањето со ресурсите. Процесите комбинирани во групи, како што сакавме, се контролни групи.
Да се вратиме на барањата на процесорот за овие процеси, а сега и за групите процеси:
(Повторувам дека сите бројки се апстрактен израз на потребата од ресурси)
Во исто време, самиот процесор има одреден конечен ресурс (во примерот ова е 1000), што може да му недостига на сите (збирот на потребите на сите групи е 150+850+460=1460). Што ќе се случи во овој случај?
Кернелот почнува да дистрибуира ресурси и го прави тоа „фер“, давајќи иста количина на ресурси за секоја група. Но, во првиот случај, ги има повеќе од потребното (333>150), па вишокот (333-150=183) останува во резерва, кој исто така е подеднакво распределен помеѓу два други контејнери:
Како резултат на тоа: првиот контејнер имаше доволно ресурси, вториот - немаше доволно ресурси, третиот - немаше доволно ресурси. Ова е резултат на акции „искрен“ распоредувач во Linux - . Нејзината работа може да се прилагоди со помош на задачата тегови секој од контејнерите. На пример, вака:
Да го погледнеме случајот со недостаток на ресурси во вториот контејнер (php-fpm). Сите ресурси за контејнери се распределуваат подеднакво помеѓу процесите. Како резултат на тоа, главниот процес работи добро, но сите работници забавуваат, добивајќи помалку од половина од она што им е потребно:
Вака функционира распоредувачот на CFS. Понатаму ќе ги наречеме тежините што ги доделуваме на контејнерите барања. Зошто е тоа така - погледнете понатаму.
Да ја погледнеме целата ситуација од друга страна. Како што знаете, сите патишта водат до Рим, а во случај на компјутер, до процесорот. Еден процесор, многу задачи - потребен ви е семафор. Наједноставниот начин за управување со ресурсите е „семафорот“: тие му дадоа на еден процес фиксно време за пристап до процесорот, потоа на следниот, итн.
Овој пристап се нарекува тврди квоти (тешко ограничување). Да го запомниме едноставно како граници. Меѓутоа, ако дистрибуирате ограничувања на сите контејнери, се јавува проблем: mysql возел по патот и во одреден момент неговата потреба за процесор завршила, но сите други процеси се принудени да чекаат додека процесорот неактивен.
Да се вратиме на кернелот Линукс и неговата интеракција со процесорот - целокупната слика е следна:
cgroup има две поставки - во суштина ова се две едноставни „пресврти“ што ви дозволуваат да одредите:
- тежина за контејнер (барања) е акции;
- процент од вкупното време на процесорот за работа на контејнерски задачи (лимити) е квота.
Како да се измери процесорот?
Постојат различни начини:
- Што е папагали, никој не знае - треба да преговарате секој пат.
- Интерес појасно, но релативно: 50% од сервер со 4 јадра и со 20 јадра се сосема различни работи.
- Можете да ги користите веќе споменатите тегови, кои Линукс ги знае, но и тие се релативни.
- Најсоодветната опција е да се измерат компјутерските ресурси во секунди. Оние. во секунди од времето на процесорот во однос на секунди во реално време: 1 секунда од времето на процесорот беше дадено на 1 реална секунда - ова е едно цело јадро на процесорот.
За да може уште полесно да се зборува, почнаа директно да се мерат кернели, што значи исто време на процесорот во однос на вистинското. Бидејќи Linux ги разбира тежините, но не толку многу време/јадра на процесорот, потребен беше механизам за преведување од еден на друг.
Да разгледаме едноставен пример со сервер со 3 јадра на процесорот, каде што на три подлоги ќе им бидат дадени тежини (500, 1000 и 1500) кои лесно се претвораат во соодветните делови од јадрата доделени за нив (0,5, 1 и 1,5).
Ако земете втор сервер, каде што ќе има двојно повеќе јадра (6) и ги поставите истите подлоги таму, распределбата на јадрата може лесно да се пресмета со едноставно множење со 2 (1, 2 и 3, соодветно). Но, важен момент се случува кога на овој сервер се појавува четвртиот pod, чија тежина, за погодност, ќе биде 3000. Одзема дел од ресурсите на процесорот (половина јадра), а за останатите подови тие се пресметуваат (преполовени):
Кубернетис и ресурси на процесорот
Во Kubernetes, ресурсите на процесорот обично се мерат во милијадракс, т.е. Како основна тежина се земаат 0,001 јадра. (Истото во терминологијата на Linux/cgroups се нарекува удел на процесорот, иако, поточно, 1000 миликори = 1024 споделувања на процесорот.) K8s осигурува дека не поставува повеќе места на серверот отколку што има ресурси на процесорот за збирот на тежините на сите подлоги.
Како се случува ова? Кога додавате сервер во кластерот Kubernetes, се известува колку јадра на процесорот има на располагање. И кога креирате нова подлога, распоредувачот на Kubernetes знае колку јадра ќе му требаат на овој подлога. Така, pod ќе биде доделен на сервер каде што има доволно јадра.
Што ќе се случи ако Нема барањето е наведено (т.е. подлогата нема дефиниран број на јадра што му се потребни)? Ајде да откриеме како Kubernetes генерално ги брои ресурсите.
За подлога можете да наведете и барања (распоредувач на CFS) и ограничувања (се сеќавате на семафорот?):
- Ако тие се наведени еднакви, тогаш на подот му е доделена QoS класа гарантира. Овој број на јадра секогаш достапни за него е загарантиран.
- Ако барањето е помало од лимитот - QoS класа пукна. Оние. Очекуваме pod, на пример, секогаш да користи 1 јадро, но оваа вредност не е ограничување за него: понекогаш pod може да користи повеќе (кога серверот има бесплатни ресурси за ова).
- Исто така постои и QoS класа најдобриот напор — ги вклучува токму оние подлоги за кои барањето не е наведено. Последни им се дадени ресурси.
меморија
Со меморијата, ситуацијата е слична, но малку поинаква - на крајот на краиштата, природата на овие ресурси е различна. Општо земено, аналогијата е како што следува:
Ајде да видиме како барањата се имплементираат во меморијата. Оставете ги подлогите да живеат на серверот, менувајќи ја потрошувачката на меморија, додека еден од нив не стане толку голем што ќе остане без меморија. Во овој случај, убиецот OOM се појавува и го убива најголемиот процес:
Ова не ни одговара секогаш, па затоа е можно да се регулира кои процеси ни се важни и не треба да се убиваат. За да го направите ова, користете го параметарот oom_score_adj.
Да се вратиме на QoS класите на процесорот и да направиме аналогија со вредностите oom_score_adj кои ги одредуваат приоритетите за потрошувачка на меморија за подлоги:
- Најниската вредност oom_score_adj за pod - -998 - значи дека таков pod треба да биде убиен последен, ова гарантира.
- Највисоката - 1000 - е најдобриот напор, прво се убиваат такви мешунки.
- За да се пресметаат преостанатите вредности (пукна) постои формула, чија суштина се сведува на фактот дека колку повеќе ресурси побарал мешунката, толку е помала веројатноста да биде убиен.
Вториот „пресврт“ - ограничување_во_бајти - за граници. Со него, сè е поедноставно: ние едноставно го доделуваме максималниот износ на издадена меморија, и тука (за разлика од процесорот) нема прашање како да се измери (меморија).
Во вкупен
Секој под во Кубернетес е даден requests и limits - двата параметри за процесорот и меморијата:
- врз основа на барањата, распоредувачот Кубернетес работи, кој дистрибуира подови меѓу серверите;
- врз основа на сите параметри, се одредува QoS класата на подлогата;
- Релативните тежини се пресметуваат врз основа на барањата на процесорот;
- распоредувачот на CFS е конфигуриран врз основа на барањата на процесорот;
- OOM убиец е конфигуриран врз основа на барања за меморија;
- „семафор“ е конфигуриран врз основа на границите на процесорот;
- Врз основа на ограничувањата на меморијата, се конфигурира ограничување за cгрупата.
Општо земено, оваа слика одговара на сите прашања за тоа како главниот дел од управувањето со ресурсите се случува во Кубернетес.
Автоматско скалирање
K8s кластер-автоматско мерење
Да замислиме дека целиот кластер е веќе окупиран и треба да се создаде нов под. Додека подлогата не може да се појави, таа виси во статус Во очекување. За да се појави, можеме да поврземе нов сервер со кластерот или... да инсталираме cluster-autoscaler, кој ќе го направи тоа за нас: нарачајте виртуелна машина од облак-провајдерот (со користење на барање API) и поврзете ја со кластерот , по што ќе се додаде подлогата .
Ова е автоматско скалирање на кластерот Kubernetes, кој функционира одлично (во нашето искуство). Сепак, како и на друго место, тука има некои нијанси...
Сè додека ја зголемувавме големината на кластерот, сè беше во ред, но што се случува кога кластерот почна да се ослободува? Проблемот е што мигрирањето на подови (за ослободување на хостовите) е многу технички тешко и скапо во однос на ресурсите. Kubernetes користи сосема поинаков пристап.
Размислете за кластер од 3 сервери што имаат распоредување. Има 6 подови: сега има по 2 за секој сервер. Поради некоја причина сакавме да исклучиме еден од серверите. За да го направите ова, ќе ја користиме командата kubectl drain, кои:
- ќе забрани испраќање нови подлоги на овој сервер;
- ќе ги избрише постоечките подлоги на серверот.
Бидејќи Kubernetes е одговорен за одржување на бројот на парчиња (6), тоа едноставно ќе се пресоздаде нив на други јазли, но не и на оној што е оневозможен, бидејќи веќе е означен како недостапен за хостирање на нови подлоги. Ова е основен механичар за Кубернет.
Сепак, тука има и една нијанса. Во слична ситуација, за StatefulSet (наместо Deployment), дејствата ќе бидат различни. Сега веќе имаме државна апликација - на пример, три подлоги со MongoDB, од кои еден има некаков проблем (податоците се расипани или друга грешка што го спречува правилното стартување на подот). И повторно одлучуваме да оневозможиме еден сервер. Што ќе се случи?
MongoDB можеше умре затоа што му треба кворум: за кластер од три инсталации, мора да функционираат најмалку две. Сепак, ова не се случува - благодарение на PodDisruptionBudget. Овој параметар го одредува минималниот потребен број работни мешунки. Знаејќи дека еден од подлогите на MongoDB веќе не работи и гледајќи дека PodDisruptionBudget е поставен за MongoDB minAvailable: 2, Kubernetes нема да ви дозволи да избришете подлога.
Крајна линија: за да може движењето (и всушност повторното создавање) на мешунките да работи правилно кога ќе се ослободи кластерот, неопходно е да се конфигурира PodDisruptionBudget.
Хоризонтално скалирање
Да разгледаме друга ситуација. Има апликација која работи како Распоредување во Кубернетес. Корисничкиот сообраќај доаѓа до неговите подлоги (на пример, има три од нив), и ние мериме одреден индикатор во нив (да речеме, оптоварување на процесорот). Кога оптоварувањето се зголемува, го снимаме на распоред и го зголемуваме бројот на подлоги за дистрибуција на барања.
Денес во Kubernetes ова не треба да се прави рачно: се конфигурира автоматско зголемување/намалување на бројот на парчиња во зависност од вредностите на измерените индикатори за оптоварување.
Главните прашања овде се: што точно да се измери и како да се толкува добиени вредности (за донесување одлука за промена на бројот на мешунки). Можете да измерите многу:
Како да го направите ова технички - собирајте метрика, итн. - Детално зборував во извештајот за . И главниот совет за избор на оптимални параметри е експеримент!
Постои (Заситеност на користење и грешки), чие значење е следново. На која основа има смисла да се скалира, на пример, php-fpm? Врз основа на фактот дека работниците снемуваат, ова е искористување. А ако работниците завршија и не се прифатат нови врски, ова е веќе сатурација. Мора да се измерат двата параметри, а во зависност од вредностите мора да се изврши скалирање.
Наместо заклучок
Извештајот има продолжение: за вертикалното скалирање и како да се изберат вистинските ресурси. Ќе зборувам за ова во следните видеа на - претплатете се за да не пропуштите!
Видеа и слајдови
Видео од настапот (44 минути):
Презентација на извештајот:
PS
Други извештаи за Kubernetes на нашиот блог:
- «» (Андреј Половов; 8 април 2019 година на Saint HighLoad++);
- «» (Дмитриј Столјаров; 8 ноември 2018 година на HighLoad++);
- «» (Дмитриј Столјаров; 28 мај 2018 година на RootConf);
- «» (Дмитриј Столјаров; 7 ноември 2017 година на HighLoad++);
- «» (Дмитриј Столјаров; 6 јуни 2017 година на RootConf).
Извор: www.habr.com