🥇 Kubernetes को साथ जीवनबाट: HTTP सर्भरले स्पेनियार्डहरूलाई कसरी समर्थन गरेन

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

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

Ingress मा त्रुटि यस्तो देखिन्थ्यो:

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

अधिकतम verbosity संग पनि, Kestrel त्रुटि अत्यन्तै समावेश छ थोरै उपयोगी जानकारी:

{
   "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 ले यो समस्या समाधान गर्न मद्दत गर्दछ ... तर म ट्राफिक श्रृंखलाको बारेमा दोहोर्याउनेछु:

अनुसन्धान

जाहिर छ, यो ट्राफिक सुन्न राम्रो छ त्यो विशिष्ट नोडमा, जहाँ Kubernetes ले पोड तैनात गरेको छ: डम्पको भोल्युम यस्तो हुनेछ कि कम्तिमा केहि चाँडै फेला पार्न सम्भव हुनेछ। र वास्तवमा, यो जाँच गर्दा, निम्न फ्रेम याद गरिएको थियो:

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 शहर छैन (तर त्यहाँ छ मलागा)। यस विचारमा कब्जा गर्दै, हामीले इन्ग्रेस कन्फिगहरू हेर्यौं, जहाँ हामीले एक महिना अघि सम्मिलित गरेको देख्यौं (ग्राहकको अनुरोधमा) "हानिरहित" स्निपेट:

    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
}

परिणामहरू

विशेष गरी Kestrel सक्दैन सहि तरिकाले UTF-8 मा सहि वर्णहरू सहित HTTP हेडरहरू प्रशोधन गर्नुहोस्, जुन सहरहरूको ठूलो संख्याको नाममा समावेश छ।

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

संक्षेपमा: नोट अब Kestrel वा UTF-8 (2019 मा?!) को विशेष समस्याहरूको बारेमा होइन, तर तथ्यको बारेमा हो। ध्यान र निरन्तर अध्ययन समस्याहरूको खोजी गर्दा तपाईंले चाल्नुभएको हरेक कदमले ढिलो वा ढिलो फल फलाउनेछ। भाग्यले साथ दिओस्!

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

स्रोत: www.habr.com

Kubernetes को साथ जीवनबाट: HTTP सर्भरले स्पेनियार्डहरूलाई कसरी समर्थन गरेन

अनुसन्धान

परिणामहरू

PS

एक टिप्पणी थप्न Отменить ответ