„Kubernetes увеличи латентността с 10 пъти“: кой е виновен за това?

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

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

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

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

Защо латентността е много по-висока в Kubernetes, отколкото в EC2?

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

                                  EC2
                            +---------------+
                            |  +---------+  |
                            |  |         |  |
                       +-------> BACKEND |  |
                       |    |  |         |  |
                       |    |  +---------+  |                   
                       |    +---------------+
             +------+  |
Public       |      |  |
      -------> ZUUL +--+
traffic      |      |  |              Kubernetes
             +------+  |    +-----------------------------+
                       |    |  +-------+      +---------+ |
                       |    |  |       |  xx  |         | |
                       +-------> NGINX +------> BACKEND | |
                            |  |       |  xx  |         | |
                            |  +-------+      +---------+ |
                            +-----------------------------+

Проблемът изглежда е свързан с първоначалното забавяне в бекенда (маркирах проблемната област на графиката като "xx"). При EC2 отговорът на приложението отне около 20 ms. В Kubernetes латентността се увеличи до 100-200 ms.

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

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

Хипотеза 1: Резолюция на DNS имена

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

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 ms, стана ясно, че резолюцията на 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

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

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

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

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

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

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

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

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

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

И двете крайни точки принадлежат на API за метаданни на екземпляр на AWS. Нашата микроуслуга използва тази услуга, докато изпълнява 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 са проектирани да работят с екземпляри EC2, а не с Kubernetes. От друга страна, не искахме да променяме интерфейса на приложението. За това използвахме КИАМ - инструмент, който, използвайки агенти на всеки Kubernetes възел, позволява на потребителите (инженери, внедряващи приложения в клъстер) да присвояват IAM роли на контейнери в pods, сякаш са EC2 инстанции. KIAM прихваща обажданията към услугата AWS Instance Metadata и ги обработва от своя кеш, като преди това ги е получил от AWS. От гледна точка на приложението нищо не се променя.

КИАМ доставя краткосрочни удостоверения на подс. Това има смисъл, като се има предвид, че средната продължителност на живота на под е по-кратка от екземпляр 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. Но когато ги съберете, резултатите стават непредвидими. Две независими и логични решения не трябва да имат смисъл, когато се комбинират.

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

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

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

• «3 истории за грешки на Kubernetes в производството: анти-афинитет, грациозно изключване, webhook»;
• «Как приоритетите на pod в Kubernetes причиниха прекъсване в Grafana Labs»;
• «6 забавни системни грешки в работата на Kubernetes [и тяхното решение]»;
• «6 практически истории от нашето SRE ежедневие".

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