ຈາກຊີວິດກັບ Kubernetes: ວິທີທີ່ເຄື່ອງແມ່ຂ່າຍ HTTP ບໍ່ມັກຊາວສະເປນ

ຜູ້ຕາງຫນ້າຂອງລູກຄ້າຂອງພວກເຮົາ, ເຊິ່ງ stack ຄໍາຮ້ອງສະຫມັກຢູ່ໃນ Microsoft cloud (Azure), ໄດ້ແກ້ໄຂບັນຫາ: ບໍ່ດົນມານີ້, ບາງຄໍາຮ້ອງຂໍຂອງລູກຄ້າຈາກເອີຣົບເລີ່ມສິ້ນສຸດລົງດ້ວຍຄວາມຜິດພາດ 400 (.ຄຳ ຂໍທີ່ບໍ່ດີ). ແອັບພລິເຄຊັນທັງໝົດຖືກຂຽນໄວ້ໃນ .NET, ນຳໃຊ້ໃນ Kubernetes...

ຫນຶ່ງໃນຄໍາຮ້ອງສະຫມັກແມ່ນ API, ໂດຍຜ່ານທີ່ການຈະລາຈອນທັງຫມົດມາ. ການຈະລາຈອນນີ້ຖືກຟັງໂດຍເຄື່ອງແມ່ຂ່າຍ HTTP kestrel, ຕັ້ງຄ່າໂດຍລູກຄ້າ .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 ຈະຊ່ວຍແກ້ໄຂບັນຫານີ້ ... ແຕ່ຂ້ອຍຈະເວົ້າຄືນກ່ຽວກັບລະບົບຕ່ອງໂສ້ການຈະລາຈອນ:

ການສືບສວນ

ແນ່ນອນ, ມັນດີກວ່າທີ່ຈະຟັງການຈະລາຈອນ ໃນ node ສະເພາະນັ້ນ, ບ່ອນທີ່ Kubernetes ໄດ້ນໍາໃຊ້ຝັກ: ປະລິມານຂອງ dump ຈະເປັນເຊັ່ນວ່າມັນຈະເປັນໄປໄດ້ທີ່ຈະຊອກຫາຢ່າງຫນ້ອຍບາງສິ່ງບາງຢ່າງຢ່າງໄວວາ. ແລະແທ້ຈິງແລ້ວ, ເມື່ອກວດເບິ່ງມັນ, ກອບດັ່ງຕໍ່ໄປນີ້ໄດ້ຖືກສັງເກດເຫັນ:

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 ໃນສະເປນ (ແຕ່ມີ Málaga). ການຍຶດເອົາຄວາມຄິດນີ້, ພວກເຮົາເບິ່ງຢູ່ໃນການຕັ້ງຄ່າ Ingress, ບ່ອນທີ່ພວກເຮົາເຫັນອັນທີ່ໃສ່ໃນຫນຶ່ງເດືອນກ່ອນຫນ້ານີ້ (ຕາມຄໍາຮ້ອງຂໍຂອງລູກຄ້າ) "ບໍ່ເປັນອັນຕະລາຍ".:

    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;

ຫຼັງຈາກປິດການສົ່ງຕໍ່ຂອງສ່ວນຫົວເຫຼົ່ານີ້, ທຸກຢ່າງດີຂື້ນ! (ມັນທັນທີທີ່ຈະແຈ້ງວ່າແອັບພລິເຄຊັນຕົວມັນເອງບໍ່ຕ້ອງການສ່ວນຫົວເຫຼົ່ານີ້ອີກຕໍ່ໄປ.)

ຕອນນີ້ໃຫ້ເບິ່ງບັນຫາ ໂດຍທົ່ວໄປແລ້ວ. ມັນ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ຜະ​ລິດ​ໄດ້​ຢ່າງ​ງ່າຍ​ດາຍ​ພາຍ​ໃນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ໂດຍ​ການ​ຮ້ອງ​ຂໍ telnet ກັບ​ 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 ສາມາດບໍ່ໄດ້ ປະມວນຜົນສ່ວນຫົວ HTTP ຢ່າງຖືກຕ້ອງດ້ວຍຕົວອັກສອນທີ່ຖືກຕ້ອງໃນ UTF-8, ເຊິ່ງບັນຈຸຢູ່ໃນຊື່ຂອງເມືອງຈຳນວນຫຼວງຫຼາຍ.

ປັດໄຈເພີ່ມເຕີມໃນກໍລະນີຂອງພວກເຮົາແມ່ນວ່າລູກຄ້າບໍ່ໄດ້ວາງແຜນທີ່ຈະປ່ຽນແປງການປະຕິບັດ Kestrel ໃນຄໍາຮ້ອງສະຫມັກ. ຢ່າງໃດກໍຕາມ, ບັນຫາໃນ AspNetCore ຕົວຂອງມັນເອງ (No4318, No7707) ພວກເຂົາເວົ້າວ່ານີ້ຈະບໍ່ຊ່ວຍ ...

ເພື່ອສະຫຼຸບ: ບັນທຶກບໍ່ແມ່ນກ່ຽວກັບບັນຫາສະເພາະຂອງ Kestrel ຫຼື UTF-8 (ໃນປີ 2019?!), ແຕ່ກ່ຽວກັບຄວາມຈິງທີ່ວ່າ ສະຕິແລະການສຶກສາທີ່ສອດຄ່ອງ ທຸກໆບາດກ້າວທີ່ເຈົ້າເຮັດໃນຂະນະທີ່ຊອກຫາບັນຫາຈະເກີດຜົນໃນບໍ່ຊ້າຫຼືຕໍ່ມາ. ໂຊກ​ດີ!

PS

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «6 ແມງໄມ້ລະບົບທີ່ຫນ້າສົນໃຈເມື່ອໃຊ້ Kubernetes [ແລະການແກ້ໄຂຂອງມັນ]"
• «ຄຳແນະນຳ ແລະເຄັດລັບ Kubernetes: ໜ້າຂໍ້ຜິດພາດແບບກຳນົດເອງໃນ NGINX Ingress"
• «ພາບລວມແລະການປຽບທຽບຕົວຄວບຄຸມ Ingress ສໍາລັບ Kubernetes"
• «ການຕິດຕາມ pings ລະຫວ່າງຂໍ້ Kubernetes - ສູດຂອງພວກເຮົາ"
• «3 ກໍລະນີທີ່ຜິດປົກກະຕິກ່ຽວກັບລະບົບຍ່ອຍເຄືອຂ່າຍ Linux".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com