Как приоритетите на pod в Kubernetes причиниха прекъсване в Grafana Labs

Забележка. превод: Представяме на вашето внимание технически подробности за причините за скорошния престой в облачната услуга, поддържана от създателите на Grafana. Това е класически пример за това как нова и на пръв поглед изключително полезна функция, предназначена да подобри качеството на инфраструктурата... може да причини вреда, ако не предвидите многобройните нюанси на нейното приложение в реалностите на производството. Чудесно е, когато се появяват материали като този, които ви позволяват да се учите не само от грешките си. Подробности в превода на този текст от вицепрезидента по продукта от Grafana Labs.

В петък, 19 юли, услугата Hosted Prometheus в Grafana Cloud спря да функционира за приблизително 30 минути. Извинявам се на всички клиенти, засегнати от прекъсването. Нашата работа е да предоставим инструментите за наблюдение, от които се нуждаете, и разбираме, че липсата им може да направи живота ви по-труден. Ние приемаме този инцидент изключително сериозно. Тази бележка обяснява какво се е случило, как реагирахме и какво правим, за да гарантираме, че няма да се случи отново.

праистория

Услугата Grafana Cloud Hosted Prometheus е базирана на Кора — Проект на CNCF за създаване на хоризонтално мащабируема, високодостъпна услуга Prometheus с множество клиенти. Архитектурата на Cortex се състои от набор от отделни микроуслуги, всяка от които изпълнява своя собствена функция: репликация, съхранение, заявки и др. Cortex е в процес на активно развитие и непрекъснато добавя нови функции и подобрява производителността. Ние редовно внедряваме нови версии на Cortex в клъстери, така че клиентите да могат да се възползват от тези функции - за щастие, Cortex може да се актуализира без прекъсване.

За безпроблемни актуализации услугата Ingester Cortex изисква допълнителна реплика на Ingester по време на процеса на актуализация. (Забележка. превод: поглъщам - основният компонент на кората. Неговата задача е да събира постоянен поток от проби, да ги групира в парчета Prometheus и да ги съхранява в база данни като DynamoDB, BigTable или Cassandra.) Това позволява на старите Ingesters да препращат текущи данни към нови Ingesters. Струва си да се отбележи, че Ingesters изискват ресурси. За да работят, трябва да имате 4 ядра и 15 GB памет на pod, т.е. 25% от процесорната мощност и паметта на основната машина в случая на нашите Kubernetes клъстери. Като цяло обикновено имаме много повече неизползвани ресурси в клъстера от 4 ядра и 15 GB памет, така че можем лесно да завъртим тези допълнителни инжести по време на надстройки.

Често обаче се случва при нормална работа никоя от машините да няма тези 25% неизползвани ресурси. Да, ние дори не се стремим: процесорът и паметта винаги ще бъдат полезни за други процеси. За да разрешим този проблем, решихме да използваме Приоритети на Kubernetes Pod. Идеята е да се даде на Ingesters по-висок приоритет от други микроуслуги (без състояние). Когато трябва да стартираме допълнителен (N+1) Ingester, ние временно изместваме други, по-малки капсули. Тези модули се прехвърлят към безплатни ресурси на други машини, оставяйки достатъчно голяма „дупка“ за стартиране на допълнителен Ingester.

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

злополука

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

Клъстерът Kubernetes нямаше достатъчно ресурси за новия клъстер Cortex и съществуващият производствен клъстер Cortex не беше актуализиран (Ingesters останаха без Високо приоритет). Тъй като Ingesters на новия клъстер по подразбиране имаше среден приоритет и съществуващите капсули в производството работеха без приоритет изобщо, Ingesters на новия клъстер замениха Ingesters от съществуващия производствен клъстер Cortex.

ReplicaSet за изгонения Ingester в производствения клъстер откри изгонения под и създаде нов, за да поддържа определения брой копия. Новата група беше зададена по подразбиране среден приоритет, а друг „стар“ Ingester в производство загуби ресурсите си. Резултатът беше лавинен процес, което доведе до изместването на всички капсули от производствените клъстери Ingester за Cortex.

Ингестерите поддържат състояние и съхраняват данни за предходните 12 часа. Това ни позволява да ги компресираме по-ефективно, преди да ги запишем в дългосрочно хранилище. За да постигне това, Cortex разделя данни в серии с помощта на разпределена хеш-таблица (DHT) и репликира всяка серия в три Ingesters, използвайки последователност на кворума в стил Dynamo. Cortex не записва данни в Ingesters, които са деактивирани. По този начин, когато голям брой Ingesters напуснат DHT, Cortex не може да осигури достатъчна репликация на записите и те се сриват.

Откриване и отстраняване

Нови известия на Prometheus въз основа на „бюджет за грешки“ (базиран на бюджет на грешки — подробности ще се появят в бъдеща статия) започна да звучи алармата 4 минути след началото на изключването. През следващите около пет минути проведохме известна диагностика и увеличихме основния клъстер на Kubernetes, за да хостваме както новите, така и съществуващите производствени клъстери.

След още пет минути старите Ingesters записаха успешно данните си, новите стартираха и клъстерите Cortex отново станаха достъпни.

Още 10 минути бяха изразходвани за диагностициране и коригиране на грешки при липса на памет (OOM) от обратни проксита за удостоверяване, разположени пред Cortex. Грешките на OOM са причинени от десетократно увеличение на QPS (смятаме, че се дължи на прекалено агресивни заявки от сървърите Prometheus на клиента).

вещи

Общото време на престой беше 26 минути. Няма загубени данни. Поглъщащите успешно са заредили всички данни в паметта в дългосрочно хранилище. По време на изключването клиентските сървъри на Prometheus са изтрити в буфер (Дистанционно) записи с помощта на нов API remote_write базиран на WAL (автор на Калъм Стиян от Grafana Labs) и повтори неуспешните записи след срива.

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

Данни

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

Погледнато назад, не трябваше да задаваме по подразбиране среден приоритет, докато всички Ingesters в производството не бъдат получени високо приоритет. Освен това беше необходимо да се погрижим за тях предварително Високо приоритет. Вече всичко е поправено. Надяваме се, че нашият опит ще помогне на други организации, които обмислят използването на приоритети на под в Kubernetes.

Ще добавим допълнително ниво на контрол върху внедряването на всички допълнителни обекти, чиито конфигурации са глобални за клъстера. Отсега нататък такива промени ще бъдат оценявани bоповече хора. Освен това модификацията, която е причинила срива, се счита за твърде незначителна за отделен проектен документ - тя беше обсъдена само в издание на GitHub. Отсега нататък всички подобни промени в конфигурациите ще бъдат придружени от подходяща проектна документация.

И накрая, ние ще автоматизираме преоразмеряването на обратния прокси сървър за удостоверяване, за да предотвратим претоварването на OOM, на което станахме свидетели, и ще прегледаме настройките по подразбиране на Prometheus, свързани с резервен вариант и мащабиране, за да предотвратим подобни проблеми в бъдеще.

Провалът имаше и някои положителни последици: след като получи необходимите ресурси, Cortex се възстанови автоматично без допълнителна намеса. Натрупахме и ценен опит в работата с Графана Локи - нашата нова система за агрегиране на регистрационни файлове - която помогна да се гарантира, че всички потребители се държат правилно по време и след повредата.

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

Прочетете също в нашия блог:

• «Автоматично мащабиране и управление на ресурсите в Kubernetes (общ преглед и видео отчет)»;
• «Kubernetes приключение Dailymotion: създаване на инфраструктура в облаците + локално»;
• «Преходът на Tinder към Kubernetes»;
• «Истории за успех на Kubernetes в производството. Част 10: Reddit".

Източник: www.habr.com