🥇कुबेरनेट्स के साथ जीवन से: कैसे HTTP सर्वर ने स्पेनियों का पक्ष नहीं लिया

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

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

इनग्रेस में त्रुटि इस प्रकार दिखी:

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

उसी समय, केस्ट्रेल ने दिया:

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. यह अनुमान लगाना आसान है कि स्पेन में कोई एम.लागा शहर नहीं है (लेकिन है मलागा). इस विचार को समझते हुए, हमने इनग्रेस कॉन्फिगरेशन को देखा, जहां हमने एक महीने पहले डाला गया कॉन्फिगरेशन देखा (ग्राहक के अनुरोध पर) "हानिरहित" स्निपेट:

    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:

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, आशा के अनुसार। यदि हम ऐसा करें तो क्या होगा:

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
}

परिणाम

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

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

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

पुनश्च

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

स्रोत: www.habr.com

कुबेरनेट्स के साथ जीवन से: कैसे HTTP सर्वर ने स्पेनियों का पक्ष नहीं लिया

जांच

परिणाम

पुनश्च

एक टिप्पणी जोड़ें उत्तर रद्द