કુબરનેટ્સ સાથેના જીવનમાંથી: કેવી રીતે HTTP સર્વરે સ્પેનિયાર્ડ્સની તરફેણ કરી નથી

અમારા ક્લાયંટના પ્રતિનિધિ, જેની એપ્લિકેશન સ્ટેક Microsoft ક્લાઉડ (એઝ્યુર) માં રહે છે, તેણે એક સમસ્યાને સંબોધિત કરી: તાજેતરમાં, યુરોપના કેટલાક ક્લાયન્ટ્સની કેટલીક વિનંતીઓ ભૂલ 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. અનુમાન લગાવવું સરળ છે કે સ્પેનમાં કોઈ 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 હેડરોને યોગ્ય રીતે પ્રક્રિયા કરો, જે એકદમ મોટી સંખ્યામાં શહેરોના નામોમાં સમાયેલ છે.

અમારા કિસ્સામાં એક વધારાનું પરિબળ એ છે કે ક્લાયંટ હાલમાં એપ્લિકેશનમાં કેસ્ટ્રેલના અમલીકરણને બદલવાની યોજના નથી કરતું. જો કે, AspNetCore માં જ સમસ્યાઓ (ના .4318, ના .7707) તેઓ કહે છે કે આ મદદ કરશે નહીં ...

સારાંશ માટે: નોંધ હવે Kestrel અથવા UTF-8 (2019 માં?!) ની ચોક્કસ સમસ્યાઓ વિશે નથી, પરંતુ હકીકત એ છે કે માઇન્ડફુલનેસ અને સતત અભ્યાસ સમસ્યાઓની શોધ કરતી વખતે તમે જે દરેક પગલું ભરો છો તે વહેલા અથવા પછીના સમયમાં ફળ આપશે. સારા નસીબ!

PS

અમારા બ્લોગ પર પણ વાંચો:

• «કુબરનેટ્સના સંચાલનમાં 6 મનોરંજક સિસ્ટમ બગ્સ [અને તેમના ઉકેલ]»;
• «કુબરનેટ્સ ટીપ્સ અને યુક્તિઓ: NGINX પ્રવેશમાં કસ્ટમ ભૂલ પૃષ્ઠો»;
• «કુબરનેટ્સ માટે ઇન્ગ્રેસ કંટ્રોલર્સની ઝાંખી અને સરખામણી»;
• «કુબરનેટ્સ નોડ્સ વચ્ચે મોનિટરિંગ પિંગ્સ - અમારી રેસીપી»;
• «Linux નેટવર્ક સબસિસ્ટમ વિશે 3 અસામાન્ય કિસ્સાઓ».

સોર્સ: www.habr.com