Kubernetes සමඟ ජීවිතයෙන්: HTTP සේවාදායකය ස්පාඤ්ඤ ජාතිකයින්ට අනුග්රහය නොදැක්වූ ආකාරය

මයික්‍රොසොෆ්ට් ක්ලවුඩ් (Azure) හි යෙදුම් තොගය පවතින අපගේ සේවාදායකයාගේ නියෝජිතයෙකු ගැටළුවක් ආමන්ත්‍රණය කළේය: මෑතකදී, යුරෝපයේ සමහර සේවාදායකයින්ගේ සමහර ඉල්ලීම් 400 දෝෂයකින් අවසන් වීමට පටන් ගත්තේය (නරක ඉල්ලීම) සියලුම යෙදුම් .NET හි ලියා ඇත, Kubernetes හි යොදවා ඇත...

එක් යෙදුමක් වන්නේ 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":{}
}

ඒ අතරම, Kestrel දුන්නේ:

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

උපරිම වාචිකත්වය සමඟ වුවද, 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 දී?!), නමුත් ඒ ගැන සිහිකල්පනාව සහ ස්ථාවර අධ්යයනය ගැටළු සොයමින් ඔබ ගන්නා සෑම පියවරක්ම ඉක්මනින් හෝ පසුව පල දරනු ඇත. වාසනාව!

ප්රාදේශීය සභා

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

• «Kubernetes ක්‍රියාත්මක කිරීමේදී විනෝදාත්මක පද්ධති දෝෂ 6ක් [සහ ඒවායේ විසඳුම]»;
• «Kubernetes ඉඟි සහ උපක්‍රම: NGINX ඇතුල්වීමේ අභිරුචි දෝෂ පිටු»;
• «Kubernetes සඳහා Ingress controllers පිළිබඳ දළ විශ්ලේෂණය සහ සංසන්දනය»;
• «Kubernetes නෝඩ් අතර අධීක්ෂණ පිං - අපගේ වට්ටෝරුව»;
• «Linux ජාල උප පද්ධතිය පිළිබඳ අසාමාන්‍ය අවස්ථා 3ක්".

මූලාශ්රය: www.habr.com