ProHoster > Blog > podávání > Ze života s Kubernetes: Jak HTTP server neupřednostnil Španěly
Ze života s Kubernetes: Jak HTTP server neupřednostnil Španěly
Zástupce našeho klienta, jehož aplikační zásobník je umístěn v cloudu Microsoftu (Azure), řešil problém: v poslední době začaly některé požadavky některých klientů z Evropy končit chybou 400 (Špatný požadavek). Všechny aplikace jsou napsány v .NET, nasazeny v Kubernetes...
Jednou z aplikací je API, přes které nakonec přichází veškerý provoz. Tomuto provozu naslouchá server HTTP Poštolka, nakonfigurovaný klientem .NET a hostovaný v podu. Při ladění jsme měli štěstí v tom smyslu, že existoval konkrétní uživatel, který problém konzistentně reprodukoval. Vše však zkomplikoval dopravní řetězec:
Zdálo by se, že tento problém pomůže vyřešit pouze tcpdump... ale zopakuji se o dopravním řetězci:
Vyšetřování
Je zřejmé, že je lepší poslouchat provoz na tom konkrétním uzlu, kde Kubernetes nasadil pod: objem výpisu bude takový, že bude možné celkem rychle najít alespoň něco. A skutečně, při jeho zkoumání byl zaznamenán následující rámec:
Při bližším prozkoumání skládky si toho slova všimli M.laga. Je snadné uhodnout, že ve Španělsku není žádné město M.laga (ale existuje Malaga). S touto myšlenkou jsme se podívali na konfigurace Ingress, kde jsme viděli tu vloženou před měsícem (na žádost klienta) "neškodný" úryvek:
Vrátí se 400 Bad request — v protokolu aplikace se zobrazí chyba, která je nám již známá:
{
"@t":"2019-03-31T12:59:54.3746446Z",
"@mt":"Connection id "{ConnectionId}" bad request data: "{message}"",
"@x":"Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Malformed request: invalid headers.n at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TryParseRequest(ReadResult result, Boolean& endConnection)n at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.<ProcessRequestsAsync>d__185`1.MoveNext()",
"ConnectionId":"0HLLLR1J974L9",
"message":"Malformed request: invalid headers.",
"EventId":{
"Id":17,
"Name":"ConnectionBadRequest"
},
"SourceContext":"Microsoft.AspNetCore.Server.Kestrel",
"ThreadId":71
}
Výsledky
Konkrétně Kestrel nemůže správně zpracovávat HTTP hlavičky se správnými znaky v UTF-8, které jsou obsaženy v názvech poměrně velkého množství měst.
Dalším faktorem v našem případě je, že klient aktuálně neplánuje změnu implementace Kestrel v aplikaci. Problémy v samotném AspNetCore (№ 4318, № 7707) říkají, že to nepomůže...
Abych to shrnul: poznámka už není o konkrétních problémech Kestrel nebo UTF-8 (v roce 2019?!), ale o tom, že všímavost a důsledné studium Každý krok, který při hledání problémů uděláte, dříve či později přinese ovoce. Hodně štěstí!