കുബർനെറ്റസിനൊപ്പമുള്ള ജീവിതത്തിൽ നിന്ന്: HTTP സെർവർ സ്പെയിൻകാരെ എങ്ങനെ അനുകൂലിച്ചില്ല

മൈക്രോസോഫ്റ്റ് ക്ലൗഡിൽ (അസുർ) ആപ്ലിക്കേഷൻ സ്റ്റാക്ക് താമസിക്കുന്ന ഞങ്ങളുടെ ക്ലയന്റിന്റെ ഒരു പ്രതിനിധി ഒരു പ്രശ്നം പരിഹരിച്ചു: അടുത്തിടെ, യൂറോപ്പിൽ നിന്നുള്ള ചില ക്ലയന്റുകളിൽ നിന്നുള്ള ചില അഭ്യർത്ഥനകൾ പിശക് 400 ൽ അവസാനിക്കാൻ തുടങ്ങി (മോശം അഭ്യർത്ഥന). എല്ലാ ആപ്ലിക്കേഷനുകളും .NET-ൽ എഴുതിയിരിക്കുന്നു, കുബർനെറ്റസിൽ വിന്യസിച്ചിരിക്കുന്നു...

ആപ്ലിക്കേഷനുകളിലൊന്ന് API ആണ്, അതിലൂടെ എല്ലാ ട്രാഫിക്കും ആത്യന്തികമായി വരുന്നു. ഈ ട്രാഫിക് 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
}

ഫലങ്ങൾ

പ്രത്യേകിച്ച് കെസ്ട്രൽ കഴിയില്ല UTF-8 ലെ ശരിയായ പ്രതീകങ്ങളുള്ള HTTP തലക്കെട്ടുകൾ ശരിയായി പ്രോസസ്സ് ചെയ്യുക, അവ വളരെ വലിയ നഗരങ്ങളുടെ പേരുകളിൽ അടങ്ങിയിരിക്കുന്നു.

ആപ്ലിക്കേഷനിൽ കെസ്ട്രൽ നടപ്പിലാക്കുന്നത് മാറ്റാൻ ക്ലയന്റ് നിലവിൽ ഉദ്ദേശിക്കുന്നില്ല എന്നതാണ് ഞങ്ങളുടെ കാര്യത്തിൽ ഒരു അധിക ഘടകം. എന്നിരുന്നാലും, AspNetCore-ൽ തന്നെ പ്രശ്നങ്ങൾ (No.4318, No.7707) ഇത് സഹായിക്കില്ലെന്ന് അവർ പറയുന്നു ...

ചുരുക്കത്തിൽ: കുറിപ്പ് ഇനി കെസ്ട്രൽ അല്ലെങ്കിൽ യുടിഎഫ്-8 (2019-ൽ?!) ന്റെ നിർദ്ദിഷ്ട പ്രശ്നങ്ങളെക്കുറിച്ചല്ല, മറിച്ച് വസ്തുതയെക്കുറിച്ചാണ് ശ്രദ്ധയും സ്ഥിരമായ പഠനവും പ്രശ്‌നങ്ങൾക്കായി നിങ്ങൾ എടുക്കുന്ന ഓരോ ചുവടും താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട് ഫലം പുറപ്പെടുവിക്കും. നല്ലതുവരട്ടെ!

പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «കുബെർനെറ്റസിന്റെ പ്രവർത്തനത്തിലെ 6 രസകരമായ സിസ്റ്റം ബഗുകളും [അവയുടെ പരിഹാരവും]";
• «Kubernetes നുറുങ്ങുകളും തന്ത്രങ്ങളും: NGINX പ്രവേശനത്തിലെ ഇഷ്‌ടാനുസൃത പിശക് പേജുകൾ";
• «കുബെർനെറ്റസിനായുള്ള ഇൻഗ്രെസ്സ് കൺട്രോളറുകളുടെ അവലോകനവും താരതമ്യവും";
• «കുബെർനെറ്റസ് നോഡുകൾക്കിടയിൽ മോണിറ്ററിംഗ് പിംഗുകൾ - ഞങ്ങളുടെ പാചകക്കുറിപ്പ്";
• «Linux നെറ്റ്‌വർക്ക് സബ്സിസ്റ്റത്തെക്കുറിച്ചുള്ള അസാധാരണമായ 3 കേസുകൾ".

അവലംബം: www.habr.com