Како приоритетите на pod во Kubernetes предизвикаа прекини во Grafana Labs

Забелешка. превод.: Ви презентираме технички детали за причините за неодамнешниот прекин на услугата облак што ја одржуваат креаторите на Графана. Ова е класичен пример за тоа како нова и навидум исклучително корисна карактеристика дизајнирана да го подобри квалитетот на инфраструктурата... може да предизвика штета ако не ги предвидите бројните нијанси на нејзината примена во реалноста на производството. Одлично е кога се појавуваат материјали како овој што ви дозволуваат да учите не само од вашите грешки. Деталите се во преводот на овој текст од потпретседателот на производот од Grafana Labs.

Во петокот, 19 јули, услугата Хостирано Прометеј во Графана Облак престана да функционира приближно 30 минути. Им се извинувам на сите клиенти погодени од прекинот. Нашата работа е да ги обезбедиме алатките за следење што ви се потребни и разбираме дека немањето на располагање може да ви го отежне животот. Овој инцидент го сфаќаме крајно сериозно. Оваа белешка објаснува што се случило, како реагиравме и што правиме за да се осигураме дека тоа нема да се повтори.

праисторијата

Се заснова на услугата Grafana Cloud Hosted Prometheus Кортекс — CNCF проект за создавање хоризонтално скалабилна, високо достапна услуга Prometheus со повеќе закупци. Архитектурата Cortex се состои од збир на поединечни микросервиси, од кои секоја врши своја функција: репликација, складирање, прашања итн. Cortex е во активен развој и постојано додава нови функции и ги подобрува перформансите. Редовно распоредуваме нови изданија на Cortex во кластери за да можат клиентите да ги искористат овие карактеристики - за среќа, Cortex може да се ажурира без прекини.

За беспрекорни ажурирања, услугата Ingester Cortex бара дополнителна реплика на Ingester за време на процесот на ажурирање. (Забелешка. превод.: Ингестер - основната компонента на кортексот. Неговата задача е да собере постојан прилив на примероци, да ги групира во делови од Prometheus и да ги складира во база на податоци како DynamoDB, BigTable или Cassandra.) Ова им овозможува на старите ингестери да ги препраќаат тековните податоци на нови ингестери. Вреди да се напомене дека голтачите бараат ресурси. За да работат, треба да имате 4 јадра и 15 GB меморија по pod, т.е. 25% од процесорската моќ и меморијата на основната машина во случајот со нашите Kubernetes кластери. Општо земено, обично имаме многу повеќе неискористени ресурси во кластерот од 4 јадра и 15 GB меморија, така што можеме лесно да ги вртиме овие дополнителни внесувачи за време на надградбите.

Меѓутоа, често се случува при нормална работа ниту една од машините да ги нема овие 25% неискористени ресурси. Да, ние дури и не се стремиме: процесорот и меморијата секогаш ќе бидат корисни за други процеси. За да го решиме овој проблем, решивме да го користиме Приоритети на Kubernetes Pod. Идејата е да им се даде на ингестерите поголем приоритет од другите микроуслуги (без државјанство). Кога треба да извршиме дополнителен (N+1) внесувач, привремено поместуваме други, помали парчиња. Овие мешунки се префрлаат на слободни ресурси на други машини, оставајќи доволно голема „дупка“ за да се изврши дополнителен Ingester.

Во четврток, на 18 јули, воведовме четири нови приоритетни нивоа за нашите кластери: критички, висок, медиум и ниска. Тие беа тестирани на внатрешен кластер без сообраќај на клиенти околу една недела. Стандардно, се добиваат подлоги без наведен приоритет медиум приоритет, класата беше поставена за ингестери со висока приоритет. Критички беше резервиран за мониторинг (Prometheus, Alertmanager, node-exporter, kube-state-metrics итн.). Нашата конфигурација е отворена и можете да ја видите ПР тука.

Несреќа

Во петокот, 19 јули, еден од инженерите лансираше нов посветен Cortex кластер за голем клиент. Конфигурацијата за овој кластер не вклучуваше приоритети за нови подлоги, така што на сите нови места им беше доделен стандарден приоритет - медиум.

Кластерот Kubernetes немаше доволно ресурси за новиот Cortex кластер, а постојниот производствен Cortex кластер не беше ажуриран (Ingesters останаа без високо приоритет). Бидејќи внесувачите на новиот кластер стандардно имаа медиум приоритет, а постојните мешунки во производството воопшто работеа без приоритет, ингестерите од новиот кластер ги заменија ингестерите од постојниот производствен кластер Cortex.

ReplicaSet за исфрлениот Ingester во производниот кластер го откри иселениот под и создаде нов за одржување на наведениот број копии. Новиот подлог беше стандардно доделен медиум приоритет, а уште еден „стар“ Ингестер во производството ги загуби своите ресурси. Резултатот беше процес на лавина, што доведе до поместување на сите мешунки од Ingester за производствени кластери на Cortex.

Внесувачите се содржани и складираат податоци за претходните 12 часа. Ова ни овозможува поефикасно да ги компресираме пред да ги запишеме на долгорочно складирање. За да се постигне ова, Cortex ги разделува податоците низ сериите користејќи дистрибуирана хаш табела (DHT) и ја реплицира секоја серија на три ингестери користејќи конзистентност на кворум во стилот на Динамо. Кортекс не запишува податоци на ингестери кои се оневозможени. Така, кога голем број ингестери го напуштаат DHT, кортекс не може да обезбеди доволно репликација на записите и тие се уриваат.

Откривање и санација

Нови известувања на Прометеј засновани на „буџет за грешка“ (врз основа на буџетски грешки — деталите ќе се појават во следната статија) почна да се огласува 4 минути по почетокот на исклучувањето. Во текот на следните пет минути, направивме дијагностика и го зголемивме основниот кластер Kubernetes за да биде домаќин на новите и постоечките производствени кластери.

По уште пет минути, старите ингестери успешно ги напишаа своите податоци, новите стартуваа, а кластерите Cortex повторно станаа достапни.

Уште 10 минути беа потрошени за дијагностицирање и исправување на грешките без меморија (OOM) од обратните прокси за автентикација лоцирани пред Cortex. Грешките на OOM беа предизвикани од десеткратно зголемување на QPS (веруваме дека поради премногу агресивни барања од серверите на клиентот Prometheus).

Последиците

Вкупниот прекин беше 26 минути. Нема изгубени податоци. Внесувачите успешно ги вчитаа сите податоци во меморијата во долгорочно складирање. За време на исклучувањето, серверите на клиентот Prometheus беа избришани во бафер (од далечина) снимки со користење нов API remote_write врз основа на WAL (авторство на Калум Стјан од Grafana Labs) и ги повтори неуспешните пишувања по падот.

Операциите за пишување на производниот кластер

Наоди

Важно е да се научи од овој инцидент и да се преземат неопходните чекори за да се избегне негово повторување.

Во ретроспектива, не требаше да го поставиме стандардното медиум приоритет додека не ги добијат сите ингестери во производството висок приоритет. Покрај тоа, неопходно беше однапред да се грижи за нив високо приоритет. Сега се е поправено. Се надеваме дека нашето искуство ќе им помогне на другите организации кои размислуваат да ги користат приоритетите на pod во Kubernetes.

Ќе додадеме дополнително ниво на контрола врз распоредувањето на какви било дополнителни објекти чии конфигурации се глобални за кластерот. Ваквите промени отсега ќе се оценуваат боповеќе луѓе. Дополнително, модификацијата што го предизвика падот се сметаше за премногу мала за посебен проектен документ - беше дискутирана само во издание на GitHub. Отсега па натаму, сите такви промени на конфигурациите ќе бидат придружени со соодветна проектна документација.

Конечно, ќе ја автоматизираме промената на големината на обратниот прокси за автентикација за да го спречиме преоптоварувањето на OOM на кое бевме сведоци, и ќе ги прегледаме стандардните поставки на Prometheus поврзани со резервни и скалирање за да спречиме слични проблеми во иднина.

Неуспехот имаше и некои позитивни последици: откако ги доби потребните ресурси, Кортекс автоматски се опорави без дополнителна интервенција. Стекнавме и драгоцено искуство работејќи со Графана Локи - нашиот нов систем за агрегација на дневници - кој помогна да се осигураме дека сите ингестери се однесуваат правилно за време и по неуспехот.

PS од преведувач

Прочитајте и на нашиот блог:

• «Автоматско скалирање и управување со ресурси во Kubernetes (преглед и видео извештај)";
• «Kubernetes авантура Dailymotion: создавање инфраструктура во облаците + во просториите";
• «Тиндер транзиција кон Кубернетес";
• «Успешни приказни на Кубернетис во производството. Дел 10: Редит".

Извор: www.habr.com