kubectl 또는 다른 타사 도구가 API 서버에 연결하는 경우 TCP 제한 시간

아티클
11/19/2024

이 문서에서는 kubectl 또는 다른 타사 도구를 사용하여 AKS(Microsoft Azure Kubernetes Service)의 API 서버에 연결할 때 발생하는 TCP 시간 초과 문제를 해결하는 방법을 설명합니다. AKS는 SLO(서비스 수준 목표) 및 SLA(서비스 수준 계약)를 보장하기 위해 코어 수에 따라 수직 및 수평으로 스케일링되는 HA(고가용성) 제어 평면을 사용합니다.

증상

반복된 연결 시간 초과가 발생합니다.

원인 1: 노드-제어 평면 통신을 담당하는 Pod가 실행되고 있지 않음

API 명령 중 일부만 일관되게 시간 초과되는 경우 다음 Pod가 실행 중 상태가 아닐 수 있습니다.

konnectivity-agent
tunnelfront
aks-link

참고 항목

최신 AKS 버전 tunnelfront aks-link 에서는 대체되므로 konnectivity-agent표시됩니다 konnectivity-agent.

이러한 Pod는 노드와 컨트롤 플레인 간의 통신을 담당합니다.

해결 방법: 노드 호스트의 사용률 또는 스트레스 줄이기

이러한 Pod를 호스트하는 노드가 지나치게 활용되거나 스트레스를 받지 않는지 확인합니다. 노드를 자체 시스템 노드 풀로 이동하는 것이 좋습니다.

Pod가 konnectivity-agent 호스트되는 노드와 노드의 사용량을 확인하려면 다음 명령을 실행합니다.

# Check which node the konnectivity-agent pod is hosted on
$ kubectl get pod -n kube-system -o wide
    
# Check the usage of the node hosting the pod
$ kubectl top node

원인 2: 일부 필수 포트, FQDN 및 IP 주소에서 액세스가 차단됨

필요한 포트, FQDN(정규화된 도메인 이름) 및 IP 주소가 모두 열려 있지 않으면 여러 명령 호출이 실패할 수 있습니다. API 서버와 kubelet (Pod를 통해 konnectivity-agent ) 간의 AKS에서 안전하고 터널된 통신을 수행하려면 이러한 항목 중 일부가 성공적으로 작동해야 합니다.

해결 방법: 필요한 포트, FQDN 및 IP 주소 열기

열어야 하는 포트, FQDN 및 IP 주소에 대한 자세한 내용은 AKS(Azure Kubernetes Service) 클러스터에 대한 아웃바운드 네트워크 및 FQDN 규칙을 참조 하세요.

원인 3: 애플리케이션 계층 프로토콜 협상 TLS 확장이 차단됨

컨트롤 플레인과 노드 간에 연결을 설정하려면 Pod에 konnectivity-agent ALPN(애플리케이션 계층 프로토콜 협상)에 대한 TLS(전송 계층 보안) 확장이 필요합니다. 이전에 이 확장을 차단했을 수 있습니다.

해결 방법: ALPN 확장 사용

TCP 시간 초과를 konnectivity-agent 방지하려면 Pod에서 ALPN 확장을 사용하도록 설정합니다.

원인 4: API 서버의 IP 권한 있는 범위가 현재 IP 주소를 포함하지 않음

API 서버에서 권한 있는 IP 주소 범위를 사용하는 경우 IP가 권한 있는 범위에 포함되지 않으면 API 호출이 차단됩니다.

해결 방법: IP 주소를 처리할 수 있도록 권한 있는 IP 주소 범위를 수정합니다.

IP 주소가 포함되도록 권한 있는 IP 주소 범위를 변경합니다. 자세한 내용은 클러스터의 API 서버 권한 있는 IP 범위 업데이트를 참조 하세요.

원인 5: 클라이언트 또는 애플리케이션이 API 서버에 대한 호출을 누수합니다.

빈번한 GET 호출은 API 서버를 누적하고 오버로드할 수 있습니다.

해결 방법: GET 호출 대신 감시를 사용하지만 애플리케이션이 해당 호출을 누수하지 않는지 확인합니다.

API 서버에 대한 잦은 GET 호출 대신 감시를 사용해야 합니다. 또한 타사 애플리케이션이 감시 연결 또는 GET 호출을 누출하지 않도록 해야 합니다. 예를 들어 Istio 마이크로 서비스 아키텍처 에서 믹서 애플리케이션의 버그는 비밀을 내부적으로 읽을 때마다 새 API 서버 조사식 연결을 만듭니다. 이 동작은 정기적으로 발생하므로 시계 연결이 빠르게 누적됩니다. 이러한 연결은 결국 크기 조정 패턴에 관계없이 API 서버가 오버로드됩니다.

원인 6: Helm 배포에 릴리스가 너무 많습니다.

Helm(Kubernetes 패키지 관리자) 배포에 너무 많은 릴리스를 사용하는 경우 노드에서 너무 많은 메모리를 사용하기 시작합니다. 또한 많은 양의 ConfigMap (구성 데이터) 개체가 생성되므로 API 서버에서 불필요한 사용량 급증이 발생할 수 있습니다.

해결 방법: 각 릴리스에 대한 최대 수정 버전 수 제한

각 릴리스의 최대 수정 버전 수는 기본적으로 무한하므로 명령을 실행하여 이 최대 개수를 적절한 값으로 설정해야 합니다. Helm 2의 경우 명령은 helm init입니다. Helm 3의 경우 명령은 helm 업그레이드입니다. --history-max <value> 명령을 실행할 때 매개 변수를 설정합니다.

버전	명령
Helm 2	`helm init --history-max <maximum-number-of-revisions-per-release> ...`
Helm 3	`helm upgrade ... --history-max <maximum-number-of-revisions-per-release> ...`

원인 7: 노드 간의 내부 트래픽이 차단되고 있습니다.

AKS 클러스터의 노드 간에 내부 트래픽 차단이 있을 수 있습니다.

해결 방법: "다이얼 tcp <Node_IP>:10250: i/o 시간 제한" 오류 문제 해결

"다이얼 tcp Node_IP>:10250: i/o 시간 제한"과 같은 TCP <시간 제한 문제 해결을 참조하세요.

원인 8: 클러스터가 프라이빗입니다.

클러스터는 프라이빗 클러스터이지만 API 서버에 액세스하려는 클라이언트는 AKS에서 사용하는 서브넷에 연결할 수 없는 공용 또는 다른 네트워크에 있습니다.

해결 방법: AKS 서브넷에 액세스할 수 있는 클라이언트 사용

클러스터는 프라이빗이고 해당 컨트롤 플레인은 AKS 서브넷에 있으므로 AKS 서브넷에 연결할 수 있는 네트워크에 있지 않으면 API 서버에 연결할 수 없습니다. 예상되는 동작입니다.

이 경우 AKS 서브넷과 통신할 수 있는 네트워크의 클라이언트에서 API 서버에 액세스합니다. 또한 NSG(네트워크 보안 그룹) 또는 네트워크 간의 다른 어플라이언스가 패킷을 차단하지 않는지 확인합니다.

타사 정보 고지 사항

이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이들 제품의 성능이나 안정성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나 Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.

다음을 통해 공유