RHEL 7에서 실행되는 단일 노드 Kubernetes 클러스터가 있습니다.
Windows Server 2019 서버도 있습니다.
Windows와 RHEL 서버는 모두 동일한 호스트에 있는 가상 머신입니다.
RHEL의 명령 프롬프트에 앉아 curlIIS의 URL에서 500kb 문서를 가져오기 위해 실행하면 요청이 "빠릅니다"(1초 미만).
Kubernetes Pod에서 실행되는 컨테이너 내부에서 동일한 요청을 실행하면 요청이 "느립니다"(4초 이상).
이는 Kubernetes 포드 네트워크 공급자인 Calico(원본)와 Weave(현재 대신 배포됨) 모두에서 발생합니다.
컨테이너 내부에서 실행 tcpdump하고 HTTP 요청 과정에서 많은 수의 TCP 재전송 및 창 크기 업데이트가 있음을 확인했습니다.
이것은 (내 제한된 지식으로는) MTU 관련 문제처럼 보입니다. 그러나 IIS 끝과 Weave 네트워크 내에서 MTU를 줄이는 것은 도움이 되지 않았습니다.
패킷이 삭제되는 위치를 설정할 수 있도록 IIS 끝과 RHEL 시스템 모두에서 직접 실행되는 고객의 패킷 덤프를 기다리고 있습니다.
한편, 어떤 아이디어라도 환영합니다.
답변1
문제를 해결했지만 근본 원인을 100% 확신할 수는 없었습니다.
패킷 덤프에서는 IIS에서 K8s 상자에 도착하는 점보 프레임(1500바이트보다 훨씬 큼)이 Linux에 의해 "조각화 필요"와 함께 거부되는 것으로 나타났습니다. 왜냐하면 Weave MTU는 표준 1376이었기 때문입니다.
링크 양쪽 끝의 MTU는 1500이었지만 아마도 TCP 분할 오프로딩이 진행 중이었던 것 같습니다(고객은 VMWare를 사용하고게이트웨이 VM에서 알 수 없는 "조각화 필요" 거부다소 관련이 있는 것 같습니다)
우리는 Weave 네트워크에서 매우 높은 MTU(65404)를 설정했는데, 이 MTU는 모두 단일 VM 내에 있으므로 왜 안 될까요?
이로 인해 패킷 조각화가 해결되었으며 컨테이너 내부의 HTTP 요청은 이제 K8s 호스트 외부의 요청만큼 빠릅니다.