«Kubernetes увеличи забавянето 10 пъти»: кой е виновен за това?

Прим. прев.: Тази статия, написана от Galo Navarro, който заема длъжността Главен софтуерен инженер в европейската компания Adevinta, е интересен и поучителен „разследващ” материал за експлоатацията на инфраструктурата. Нейното оригинално заглавие беше малко разширено в превода по причина, която авторът обяснява в самото начало.

Забележка от автора: Изглежда, че тази публикация привлече много повече внимание, отколкото се очакваше. Все още получавам гневни коментари относно това, че заглавието на статията е подвеждащо и че някои читатели са разочаровани. Разбирам причините за случващото се, затова, въпреки риска да разваля цялата интрига, искам веднага да ви кажа за какво става въпрос в тази статия. Когато екипите преминават на Kubernetes, наблюдавам любопитно явление: всеки път, когато възникне проблем (например, увеличение на забавянията след миграция), първото нещо, за което обвиняват, е Kubernetes, но после се оказва, че оркестраторът всъщност не е виновен. Тази статия разказва за един от тези случаи. Нейното заглавие повтаря възклицанието на един от нашите разработчици (ще се уверите, че Kubernetes тук изобщо не е замесен). В нея няма да намерите изненадващи разкрития за Kubernetes, но можете да разчитате на няколко добри урока за сложни системи.

Преди няколко седмици моят екип се занимаваше с миграцията на един микросервис на основната платформа, включваща CI/CD, работна среда, базирана на Kubernetes, метрики и други полезни неща. Преместването беше пробно: планирахме да го вземем за основа и да пренесем още около 150 услуги в близките месеци. Всички те отговарят за работата на някои от най-големите онлайн платформи в Испания (Infojobs, Fotocasa и др.).

След като разгорихме приложението в Kubernetes и пренасочихме част от трафика към него, ни очакваше тревожен изненада. Забавянето (latency) на заявките в Kubernetes беше 10 пъти по-високо, отколкото в EC2. В общи линии, беше необходимо или да търсим решение на този проблем, или да се откажем от миграцията на микросервиза (и, вероятно, от целия проект).

Защо забавянето в Kubernetes е толкова по-високо, отколкото в EC2?

За да намерим тясното място, събрахме метрики по целия път на заявката. Нашата архитектура е проста: API шлюз (Zuul) проксирова заявки към инстанции на микросервиза в EC2 или Kubernetes. В Kubernetes използваме NGINX Ingress Сontroller, а бекендовете представляват обикновени обекти тип Deployment с JVM приложение на платформата Spring.

                                  EC2
                            +---------------+
                            |  +---------+  |
                            |  |         |  |
                       +-------< BACKEND |  |
                       |    |  |         |  |
                       |    |  +---------+  |                   
                       |    +---------------+
             +------+  |
Public       |      |  |
      -------< ZUUL +--+
traffic      |      |  |              Kubernetes
             +------+  |    +-----------------------------+
                       |    |  +-------+      +---------+ |
                       |    |  |       |  xx  |         | |
                       +------- BACKEND | |
                            |  |       |  xx  |         | |
                            |  +-------+      +---------+ |
                            +-----------------------------+

Изглежда, че проблемът беше свързан със закъснение в началния етап на работа в бекенда (означих проблемната част на графиката като «хх»). В EC2 отговорът на приложението беше около 20 мс. В Kubernetes закъснението нарасна до 100—200 мс.

Бързо отхвърлихме вероятните подозрителни в свързани с промяната на средата за изпълнение. Версията на JVM остана същата. Проблемите с контейнеризацията също не бяха причина: приложението вече работеше успешно в контейнери в EC2. Натоварване? Но наблюдавахме високи закъснения дори при 1 заявка в секунда. Пауза за събиране на боклук също беше пренебрегната.

Един от нашите администратори на Kubernetes попита дали приложението има външни зависимости, тъй като в миналото заявките към DNS причиняваха подобни проблеми.

Хипотеза 1: разрешаване на имена DNS

При всяко запитване нашето приложение прави от едно до три запитвания към инстанция на AWS Elasticsearch в домейн, подобен на elastic.spain.adevinta.com. Вътре в контейнерите имаме shell, така че можем да проверим дали действително търсенето на домейна отнема много време.

DNS-запитвания от контейнера:

[root@be-851c76f696-alf8z \/]# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 22 msec
;; Query time: 22 msec
;; Query time: 29 msec
;; Query time: 21 msec
;; Query time: 28 msec
;; Query time: 43 msec
;; Query time: 39 msec

Подобни запитвания от един от инстанциите EC2, където работи приложението:

bash-4.4# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 77 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec

Като вземем предвид, че търсенето отнема около 30 мс, стана ясно, че разрешаването на DNS при достъп до Elasticsearch действително допринася за нарастването на закъснението.

Но това беше странно по две причини:

1. Вече имаме много приложения в Kubernetes, които взаимодействат с ресурсите на AWS, без да страдат от големи забавяния. Каквата и да е причината, тя се отнася конкретно за този случай.
2. Знаем, че JVM осъществява кеширане на DNS в паметта. В нашите образи стойността на TTL е зададена на $JAVA_HOME/jre/lib/security/java.security и е установена на 10 секунди: networkaddress.cache.ttl = 10. С други думи, JVM трябва да кешира всички DNS заявки за 10 секунди.

За да потвърдим първата хипотеза, решихме временно да се откажем от обращенията към DNS и да видим дали проблемът ще изчезне. Първо решихме да пренастроим приложението, за да се свърже с Elasticsearch директно по IP адрес, а не чрез доменно име. Това би наложило корекции в кода и ново разгръщане, затова просто съпоставихме домена с неговия IP адрес в /etc/hosts:

34.55.5.111 elastic.spain.adevinta.com

Сега контейнерът получаваше IP почти мигновено. Това доведе до известно подобрение, но ние само леко се приближихме до очакваното ниво на забавяне. Въпреки че разрешаването на DNS отнемаше много време, истинската причина все още ни убягваше.

Диагностика чрез мрежата

Решихме да анализираме трафика от контейнера с помощта на tcpdump, за да проследим какво точно се случва в мрежата:

[root@be-851c76f696-alf8z /]# tcpdump -leni any -w capture.pcap

След това изпратихме няколко заявки и изтеглихме техния capture (kubectl cp my-service:/capture.pcap capture.pcap) за допълнителен анализ в Wireshark.

В DNS заявките нямаше нищо подозрително (освен една малка подробност, за която ще говоря по-късно). Но имаше определени странности в начина, по който нашият сервис обработваше всяка заявка. По-долу е показан скрийншот на capture’а, демонстриращ приемането на заявката преди началото на отговора:

Номерата на пакетите са посочени в първата колона. За яснота съм оцветил различните TCP потоци.

Зеленият поток, започващ от 328-ия пакет, показва как клиентът (172.17.22.150) е установил TCP връзка с контейнера (172.17.36.147). След първоначалното ръкостискане (328-330), пакет 331 донесе HTTP GET /v1/.. — входяща заявка към нашия сервис. Целият процес отне 1 мс.

Сивият поток (от пакет 339) показва, че нашият сервис е изпратил HTTP заявка към инстанция на Elasticsearch (TCP ръкостискането отсъства, тъй като се използва вече установена връзка). Това отне 18 мс.

За момента всичко изглежда нормално, и времето е приблизително в съответствие с очакваните забавяния (20-30 мс при измервания от клиента).

Въпреки това, синята секция отнема 86 мс. Какво се случва там? С пакет 333 нашият сервис изпрати HTTP GET запитване на /latest/meta-data/iam/security-credentials, а веднага след него, по същата TCP връзка, още едно GET запитване на /latest/meta-data/iam/security-credentials/arn:...

Установихме, че това се повтаря с всяко запитване в цялата трасировка. Разрешаването на DNS наистина е малко по-бавно в нашите контейнери (обяснението на това явление е много интересно, но ще го запазя за отделна статия). Оказа се, че причината за големите забавяния са повикванията към услугата AWS Instance Metadata при всяко запитване.

Хипотеза 2: излишни повиквания към AWS

И двата ендпойнта принадлежат на AWS Instance Metadata API. Нашият микросервис използва тази услуга по време на работа с Elasticsearch. И двете повиквания са част от основния процес на авторизация. Ендпойнтът, към който се извършва повикването при първото запитване, предоставя IAM роля, свързана с екземпляра.

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
arn:aws:iam::<account_id>:role/some_role

Второто запитване отправя искане към втория ендпойнт за временни привилегии за този екземпляр:

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/arn:aws:iam::<account_id>:role/some_role`
{
    "Code" : "Success",
    "LastUpdated" : "2012-04-26T16:39:16Z",
    "Type" : "AWS-HMAC",
    "AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
    "SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "Token" : "token",
    "Expiration" : "2017-05-17T15:09:54Z"
}

Клиентът може да ги използва за кратък период от време и периодично трябва да получава нови сертификати (преди техните Expiration). Моделът е прост: AWS извършва честа ротация на временните ключове по съображения за сигурност, но клиентите могат да ги кешират за няколко минути, компенсирайки намалението на производителността, свързано с получаването на нови сертификати.

AWS Java SDK трябва да поеме отговорностите за организацията на този процес, но по някаква причина това не се случва.

Следвайки търсене по проблеми в GitHub, се натъкнахме на проблема #1921. Той ни помогна да определим посоката, в която трябва да "копаем" по-нататък.

AWS SDK обновява сертификатите при настъпването на едно от следните условия:

• Срокът на действие им (Expiration) попада в EXPIRATION_THRESHOLD, зададен в кода на 15 минути.
• От последния опит за обновяване на сертификатите е минало повече време, отколкото REFRESH_THRESHOLD, зададен на 60 минути.

За да видим действителния срок на изтичане на получените от нас сертификати, изпълнихме горепосочените cURL команди от контейнера и от EC2 инстанцията. Времето на действие на сертификата, получен от контейнера, се оказа значително по-кратко: точно 15 минути.

Сега всичко е ясно: за първото запитване нашият сервис получаваше временни сертификати. Тъй като срокът им на валидност не надвишаваше 15 минути, при следващото запитване AWS SDK решаваше да ги обнови. И това се случваше с всяко запитване.

Защо срокът на валидност на сертификатите стана по-кратък?

Сервизът AWS Instance Metadata е предназначен за работа с EC2 инстанции, а не с Kubernetes. От една страна, не искахме да променяме интерфейса на приложенията. За това използвахме KIAM — инструмент, който чрез агенти на всеки възел в Kubernetes позволява на потребителите (инженерите, разгръщащи приложения в клъстера) да присвояват IAM роли на контейнери в pod'ове, така сякаш те са инстанции EC2. KIAM улавя повиквания към AWS Instance Metadata сервиза и ги обработва от своя кеш, преди да ги получи от AWS. От гледна точка на приложението нищо не се променя.

KIAM доставя краткосрочни сертификати на pod'ове. Това е разумно, като се има предвид, че средната продължителност на живота на pod'а е по-кратка от тази на EC2 инстанцията. По подразбиране срокът на валидност на сертификатите е равен на същите тези 15 минути..

В крайна сметка, ако наложим и двете подразбиращи се стойности една върху друга, възниква проблем. Всеки сертификат, предоставен на приложението, изтича след 15 минути. В същото време AWS Java SDK принудително обновява всеки сертификат, чийто срок на валидност остава по-малко от 15 минути.

В резултат на това, временият сертификат принудително се обновява с всяко запитване, което води до няколко повиквания към AWS API и причинява значително увеличаване на закъснението. В AWS Java SDK открихме искания за функции, в който се споменава подобен проблем.

Решението се оказа просто. Просто преконфигурирахме KIAM да запитва сертификати с по-дълъг срок на валидност. След като това стана, запитванията започнаха да преминават без участието на AWS Metadata сервиза, а закъснението спадна до дори по-ниско ниво от това в EC2.

Изводи

Въз основа на нашия опит с миграциите, можем да кажем, че един от най-честите източници на проблеми не е свързан с грешки в Kubernetes или други елементи на платформата. Той също така не е свързан с никакви фундаментални дефекти в микросервисите, които пренасяме. Проблемите често възникват просто защото свързваме различни елементи заедно.

Ние комбинираме сложни системи, които никога преди не са взаимодействали помежду си, с надеждата, че заедно те ще образуват една по-голяма, единна система. За съжаление, колкото повече елементи, толкова повече пространство за грешки, толкова по-висока ентропия.

В нашия случай високата забавяне не беше резултат от грешки или лоши решения в Kubernetes, KIAM, AWS Java SDK или нашия микросервис. Тя стана резултат от комбинирането на два независими параметъра, зададени по подразбиране: един в KIAM, другият — в AWS Java SDK. Поотделно и двата параметъра имат смисъл: и активната политика за обновяване на сертификати в AWS Java SDK, и краткият срок на действие на сертификатите в KAIM. Но когато ги комбинираме, резултатите стават непредсказуеми. Два независими и логични решения не е задължително да имат смисъл при комбиниране.

P.S. от преводача

Можете да научите повече за архитектурата на утилитата KIAM за интеграция на AWS IAM с Kubernetes в тази статия от нейните създатели.

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

• «3 истории за неуспехи в Kubernetes в продукция: anti-affinity, graceful shutdown, webhook»;
• «Как приоритетите на pod-овете в Kubernetes предизвикаха престои в Grafana Labs»;
• «6 интересни системни грешки при експлоатация на Kubernetes [и тяхното решение]»;
• «6 практични истории от нашата SRE действителност».

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