ਕੁਬਰਨੇਟਸ ਦੇ ਨਾਲ ਜੀਵਨ ਤੋਂ: ਕਿਵੇਂ HTTP ਸਰਵਰ ਨੇ ਸਪੈਨਿਸ਼ੀਆਂ ਦਾ ਪੱਖ ਨਹੀਂ ਲਿਆ

ਸਾਡੇ ਕਲਾਇੰਟ ਦਾ ਇੱਕ ਪ੍ਰਤੀਨਿਧੀ, ਜਿਸਦਾ ਐਪਲੀਕੇਸ਼ਨ ਸਟੈਕ ਮਾਈਕ੍ਰੋਸਾੱਫਟ (ਅਜ਼ੂਰ) ਤੋਂ ਕਲਾਉਡ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਨੇ ਇੱਕ ਸਮੱਸਿਆ ਨੂੰ ਸੰਬੋਧਿਤ ਕੀਤਾ: ਹਾਲ ਹੀ ਵਿੱਚ, ਯੂਰਪ ਤੋਂ ਕੁਝ ਗਾਹਕਾਂ ਦੀਆਂ ਕੁਝ ਬੇਨਤੀਆਂ ਗਲਤੀ 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":{}
}

ਉਸੇ ਸਮੇਂ, ਕੇਸਟਰਲ ਨੇ ਦਿੱਤਾ:

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 ਵਿੱਚ ਹੀ ਮੁੱਦੇ (ਨੰਬਰ XXX, ਨੰਬਰ XXX) ਉਹ ਕਹਿੰਦੇ ਹਨ ਕਿ ਇਹ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ ...

ਸੰਖੇਪ ਵਿੱਚ: ਨੋਟ ਹੁਣ ਕੇਸਟਰਲ ਜਾਂ UTF-8 (2019 ਵਿੱਚ?!) ਦੀਆਂ ਖਾਸ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਨਹੀਂ ਹੈ, ਪਰ ਇਸ ਤੱਥ ਬਾਰੇ ਹੈ ਕਿ ਧਿਆਨ ਅਤੇ ਨਿਰੰਤਰ ਅਧਿਐਨ ਸਮੱਸਿਆਵਾਂ ਦੀ ਖੋਜ ਕਰਦੇ ਹੋਏ ਤੁਹਾਡੇ ਦੁਆਰਾ ਚੁੱਕਿਆ ਗਿਆ ਹਰ ਕਦਮ ਜਲਦੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਫਲ ਦੇਵੇਗਾ। ਖੁਸ਼ਕਿਸਮਤੀ!

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਕੁਬਰਨੇਟਸ [ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਹੱਲ] ਦੇ ਸੰਚਾਲਨ ਵਿੱਚ 6 ਮਨੋਰੰਜਕ ਸਿਸਟਮ ਬੱਗ";
• «ਕੁਬਰਨੇਟਸ ਟਿਪਸ ਅਤੇ ਟ੍ਰਿਕਸ: NGINX ਇਨਗਰੇਸ ਵਿੱਚ ਕਸਟਮ ਐਰਰ ਪੇਜ";
• «ਕੁਬਰਨੇਟਸ ਲਈ ਇੰਗ੍ਰੇਸ ਕੰਟਰੋਲਰਾਂ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਅਤੇ ਤੁਲਨਾ";
• «ਕੁਬਰਨੇਟਸ ਨੋਡਸ ਦੇ ਵਿਚਕਾਰ ਪਿੰਗਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ - ਸਾਡੀ ਵਿਅੰਜਨ";
• «ਲੀਨਕਸ ਨੈੱਟਵਰਕ ਸਬ-ਸਿਸਟਮ ਬਾਰੇ 3 ​​ਅਸਾਧਾਰਨ ਮਾਮਲੇ".

ਸਰੋਤ: www.habr.com