कुबेरनेट्स के साथ जीवन से: Spaniards HTTP सर्वर ने कैसे शिकायत नहीं की

हमारे क्लाइंट का प्रतिनिधि, जिसका एप्लिकेशन स्टैक Microsoft (Azure) से क्लाउड में रहता है, को एक समस्या का सामना करना पड़ा: हाल ही में, यूरोप के कुछ ग्राहकों के अनुरोधों का हिस्सा त्रुटि 400 ( खराब अनुरोध ) के साथ समाप्त होने लगा। सभी अनुप्रयोग .NET में लिखे गए हैं, कुबेरनेट्स में तैनात हैं ...

एक एप्लिकेशन एपीआई है जिसके माध्यम से अंततः सभी ट्रैफ़िक आते हैं। इस ट्रैफ़िक को .NET क्लाइंट द्वारा कॉन्फ़िगर किए गए Kestrel HTTP सर्वर द्वारा और पॉड में होस्ट किए जाने पर सुना जाता है। डिबगिंग के साथ, हम इस अर्थ में भाग्यशाली थे कि एक विशिष्ट उपयोगकर्ता था, जिसे निश्चित रूप से पुन: पेश करने में समस्या थी। हालाँकि, यातायात श्रृंखला द्वारा सब कुछ जटिल था:



इनग्रेड में त्रुटि इस तरह दिखती है:

{ "number_fields":{ "status":400, "request_time":0.001, "bytes_sent":465, "upstream_response_time":0, "upstream_retries":0, "bytes_received":2328 }, "stream":"stdout", "string_fields":{ "ingress":"app", "protocol":"HTTP/1.1", "request_id":"f9ab8540407208a119463975afda90bc", "path":"/api/sign-in", "nginx_upstream_status":"400", "service":"app", "namespace":"production", "location":"/front", "scheme":"https", "method":"POST", "nginx_upstream_response_time":"0.000", "nginx_upstream_bytes_received":"120", "vhost":"api.app.example.com", "host":"api.app.example.com", "user":"", "address":"83.41.81.250", "nginx_upstream_addr":"10.240.0.110:80", "referrer":"https://api.app.example.com/auth/login?long_encrypted_header", "service_port":"http", "user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36", "time":"2019-03-06T18:29:16+00:00", "content_kind":"cache-headers-not-present", "request_query":"" }, "timestamp":"2019-03-06 18:29:16", "labels":{ "app":"nginx", "pod-template-generation":"6", "controller-revision-hash":"1682636041" }, "namespace":"kube-nginx-ingress", "nsec":6726612, "source":"kubernetes", "host":"k8s-node-55555-0", "pod_name":"nginx-v2hcb", "container_name":"nginx", "boolean_fields":{} } 

उसी समय, Kestrel ने दिया:

 HTTP/1.1 400 Bad Request Connection: close Date: Wed, 06 Mar 2019 12:34:20 GMT Server: Kestrel Content-Length: 0 

अधिकतम वाचालता के साथ भी, केस्टेल त्रुटि में बहुत कम उपयोगी जानकारी थी :

 { "number_fields":{"ThreadId":76}, "stream":"stdout", "string_fields":{ "EventId":"{\"Id\"=>17, \"Name\"=>\"ConnectionBadRequest\"}", "SourceContext":"Microsoft.AspNetCore.Server.Kestrel", "ConnectionId":"0HLL2VJSST5KV", "@mt":"Connection id \"{ConnectionId}\" bad request data: \"{message}\"", "@t":"2019-03-07T13:06:48.1449083Z", "@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()", "message":"Malformed request: invalid headers." }, "timestamp":"2019-03-07 13:06:48", "labels":{ "pod-template-hash":"2368795483", "service":"app" }, "namespace":"production", "nsec":145341848, "source":"kubernetes", "host":"k8s-node-55555-1", "pod_name":"app-67bdcf98d7-mhktx", "container_name":"app", "boolean_fields":{} } 

ऐसा लगता है कि केवल tcpdump इस समस्या को हल करने में मदद करेगा ... लेकिन मैं यातायात श्रृंखला के बारे में दोहराऊंगा:

जांच

जाहिर है, उस विशेष नोड पर ट्रैफ़िक को सुनना बेहतर है जहां कुबेरनेट्स ने फली को तैनात किया: डंप मात्रा ऐसी होगी कि कम से कम कुछ बहुत तेज़ी से ढूंढना संभव होगा। वास्तव में, इस पर विचार करते समय, ऐसा फ्रेम देखा गया था:

 GET /back/user HTTP/1.1 Host: api.app.example.com X-Request-ID: 27ceb14972da8c21a8f92904b3eff1e5 X-Real-IP: 83.41.81.250 X-Forwarded-For: 83.41.81.250 X-Forwarded-Host: api.app.example.com X-Forwarded-Port: 443 X-Forwarded-Proto: https X-Original-URI: /front/back/user X-Scheme: https X-Original-Forwarded-For: 83.41.81.250 X-Nginx-Geo-Client-Country: Spain X-Nginx-Geo-Client-City: M.laga Accept-Encoding: gzip CF-IPCountry: ES CF-RAY: 4b345cfd1c4ac691-MAD CF-Visitor: {"scheme":"https"} pragma: no-cache cache-control: no-cache accept: application/json, text/plain, */* origin: https://app.example.com user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36 referer: https://app.example.com/auth/login accept-language: en-US,en;q=0.9,en-GB;q=0.8,pl;q=0.7 cookie: many_encrypted_cookies; .AspNetCore.Identity.Application=something_encrypted; CF-Connecting-IP: 83.41.81.250 True-Client-IP: 83.41.81.250 CDN-Loop: cloudflare HTTP/1.1 400 Bad Request Connection: close Date: Wed, 06 Mar 2019 12:34:20 GMT Server: Kestrel Content-Length: 0 

डंप की सावधानीपूर्वक जांच करने पर, M.laga । M.laga शब्द देखा गया। यह अनुमान लगाना आसान है कि स्पेन में कोई शहर M.laga नहीं है (लेकिन मलागा है )। इस विचार को स्वीकार करते हुए, हमने इनग्रेड कॉन्फ़िगरेशन को देखा, जहां हमने एक महीने पहले (क्लाइंट के अनुरोध पर) "हानिरहित" स्निपेट डाला था:

  ingress.kubernetes.io/configuration-snippet: | proxy_set_header X-Nginx-Geo-Client-Country $geoip_country_name; proxy_set_header X-Nginx-Geo-Client-City $geoip_city; 

जब आप इन हेडर को अग्रेषित करना अक्षम करते हैं, तो सब कुछ अच्छा हो जाता है! (यह जल्द ही स्पष्ट हो गया कि एप्लिकेशन को अब इन हेडर की आवश्यकता नहीं है।)

अब समस्या को और सामान्य तरीके से देखते हैं । यदि आप localhost:80 लिए टेलनेट अनुरोध करते हैं तो आवेदन के अंदर इसे आसानी से पुन: प्रस्तुत किया जा सकता है localhost:80 :

 GET /back/user HTTP/1.1 Host: api.app.example.com cache-control: no-cache accept: application/json, text/plain, */* origin: https://app.example.com Cookie: test=Desiree 

... 401 Unauthorized रिटर्न, उम्मीद के 401 Unauthorized । और अगर हम करते हैं तो क्या होता है:

 GET /back/user HTTP/1.1 Host: api.app.example.com cache-control: no-cache accept: application/json, text/plain, */* origin: https://app.example.com Cookie: test=Désirée 

?

400 Bad request वापस आएगा - एप्लिकेशन लॉग में हमें वह त्रुटि मिलेगी जो हम पहले से जानते हैं:

 { "@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 } 

परिणाम

विशेष रूप से, Kestrel सही ढंग से HTTP हेडर को UTF-8 में सही वर्णों के साथ संसाधित नहीं कर सकता है, जो कि काफी बड़ी संख्या में शहरों के नामों में शामिल हैं।

हमारे मामले में एक अतिरिक्त कारक यह है कि ग्राहक वर्तमान में आवेदन में केस्टेल के कार्यान्वयन को बदलने की योजना नहीं बनाता है। हालांकि, AspNetCore में ही ( नंबर 4318 , नंबर 7707 ) के मुद्दों का कहना है कि यह मदद नहीं करेगा ...

संक्षेप में बताएं: नोट अब Kestrel या UTF-8 (2019, वर्ष में?) की विशिष्ट समस्याओं के बारे में नहीं है, लेकिन यह है कि किसी समस्या की खोज के दौरान प्रत्येक चरण का ध्यान और लगातार अध्ययन जल्द या बाद में फल होगा। अ छा!

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

• " कुबेरनेट्स [और उनके समाधान] के संचालन में 6 मनोरंजक प्रणाली कीड़े ";
• कुबेरनेट्स टिप्स एंड ट्रिक्स: एनजीआईएनएक्स इनग्रेड में व्यक्तिगत त्रुटि पृष्ठ ;
• " कुबेरनेट्स के लिए इनग्रेड कंट्रोलर्स का अवलोकन और तुलना ";
• " कुबेरनेट्स मेजबानों के बीच निगरानी पिंग हमारा नुस्खा है ";
• " लिनक्स नेटवर्क सबसिस्टम के बारे में 3 असामान्य मामले ।"