Kubernetes 생활에서: HTTP 서버가 스페인 사람들을 선호하지 않은 이유

Microsoft 클라우드(Azure)에 애플리케이션 스택이 있는 클라이언트의 담당자가 문제를 해결했습니다. 최근 유럽의 일부 클라이언트의 일부 요청이 오류 400(잘못된 요청). 모든 애플리케이션은 .NET으로 작성되고 Kubernetes에 배포됩니다...

애플리케이션 중 하나는 모든 트래픽이 궁극적으로 통과하는 API입니다. 이 트래픽은 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":{}
}

동시에 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 구성을 살펴보았는데, 한 달 전에 (클라이언트의 요청에 따라) 삽입된 구성을 보았습니다. "무해한" 조각:

    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 헤더를 올바르게 처리합니다.

우리의 경우 추가 요소는 클라이언트가 현재 애플리케이션에서 Kestrel 구현을 변경할 계획이 없다는 것입니다. 그러나 AspNetCore 자체의 문제(№ 4318, № 7707) 그들은 이것이 도움이 되지 않을 것이라고 말합니다...

요약하자면, 이 노트는 더 이상 Kestrel 또는 UTF-8(2019년?!)의 특정 문제에 관한 것이 아니라 다음과 같은 사실에 관한 것입니다. 마음챙김과 꾸준한 공부 문제를 찾는 동안 취하는 모든 단계는 조만간 결실을 맺을 것입니다. 행운을 빌어요!

PS

블로그에서도 읽어보세요.

• «쿠버네티스 운영의 재미있는 시스템 버그 6가지 [및 해당 솔루션]";
• «Kubernetes 팁 및 요령: NGINX Ingress의 사용자 지정 오류 페이지";
• «Kubernetes용 Ingress 컨트롤러 개요 및 비교";
• «Kubernetes 노드 간 핑 모니터링 - 레시피";
• «Linux 네트워크 하위 시스템에 관한 3가지 특이한 사례".

출처 : habr.com