터널 연결 문제

아티클
04/12/2024

AKS(Microsoft Azure Kubernetes Service)는 노드와 컨트롤 플레인 간의 터널형 보안 통신에 특정 구성 요소를 사용합니다. 터널은 컨트롤 플레인 쪽의 서버와 클러스터 노드 쪽의 클라이언트로 구성됩니다. 이 문서에서는 AKS의 터널 연결과 관련된 문제를 해결하고 resolve 방법에 대해 설명합니다.

참고

기본적으로 및 지역에 따라 터널 구성 요소는 이었습니다 tunnel-front. 작동 시간 SLA(서비스 수준 계약) 기능 tunnel-front 으로 업데이트할 때 는 OpenVPN을 aks-link 사용하는 터널 구성 요소로 대체되었습니다. AKS는 Konnectivity로 마이그레이션됩니다. 및 를 모두 tunnel-frontaks-link대체하는 Kubernetes 업스트림 구성 요소입니다. 터널 구성 요소로 Konnectivity로 마이그레이션하는 방법에 대한 자세한 내용은 AKS 릴리스 정보 및 변경 로그를 참조하세요.

필수 구성 요소

Azure CLI

증상

포트 10250에 대한 다음 예제와 유사한 오류 메시지가 표시됩니다.

서버에서 오류: "https:// aks-node-name>:10250/containerLogs/namespace>/<<pod-name/<container-name>>": dial tcp <aks-node-ip>:10250: i/o 시간 제한<

서버 오류: 백 엔드 전화 걸기 오류: tcp <aks-node-ip>:10250: i/o 시간 초과

Kubernetes API 서버는 포트 10250을 사용하여 노드의 kubelet에 연결하여 로그를 검색합니다. 포트 10250이 차단되면 kubectl 로그 및 기타 기능은 터널 구성 요소가 예약된 노드에서 실행되는 Pod에 대해서만 작동합니다. 자세한 내용은 Kubernetes 포트 및 프로토콜: 작업자 노드를 참조하세요.

터널 구성 요소 또는 서버와 클라이언트 간의 연결을 설정할 수 없으므로 다음과 같은 기능이 예상대로 작동하지 않습니다.

허용 컨트롤러 웹후크
로그 검색 기능( kubectl logs 명령 사용)
컨테이너에서 명령 실행 또는 컨테이너 내부 가져오기( kubectl exec 명령 사용)
Pod의 하나 이상의 로컬 포트 전달( kubectl 포트 전달 명령 사용)

원인 1: NSG(네트워크 보안 그룹)가 포트 10250을 차단하고 있습니다.

참고

이 원인은 AKS 클러스터에 있을 수 있는 모든 터널 구성 요소에 적용할 수 있습니다.

Azure NSG( 네트워크 보안 그룹 )를 사용하여 Azure 가상 네트워크의 Azure 리소스 간 네트워크 트래픽을 필터링할 수 있습니다. 네트워크 보안 그룹에는 여러 유형의 Azure 리소스 간에 인바운드 및 아웃바운드 네트워크 트래픽을 허용하거나 거부하는 보안 규칙이 포함되어 있습니다. 각 규칙에 대해 원본 및 대상, 포트 및 프로토콜을 지정할 수 있습니다. 자세한 내용은 네트워크 보안 그룹이 네트워크 트래픽을 필터링하는 방법을 참조하세요.

NSG가 가상 네트워크 수준에서 포트 10250을 차단하는 경우 터널 기능(예: 로그 및 코드 실행)은 터널 Pod가 예약된 노드에서 예약된 Pod에 대해서만 작동합니다. 노드가 터널에 연결할 수 없고 터널이 다른 노드에서 예약되므로 다른 Pod는 작동하지 않습니다. 이 상태를 확인하려면 netcat (nc) 또는 텔넷 명령을 사용하여 연결을 테스트할 수 있습니다. az vmss run-command invoke 명령을 실행하여 연결 테스트를 수행하고 성공, 시간 초과 또는 다른 문제 발생 여부를 확인할 수 있습니다.

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "nc -v -w 2 <ip-of-node-that-schedules-the-tunnel-component> 10250" \
    --output tsv \
    --query 'value[0].message'

해결 방법 1: 포트 10250에 대한 액세스를 허용하는 NSG 규칙 추가

NSG를 사용하고 특정 제한이 있는 경우 가상 네트워크 수준에서 포트 10250에 대한 트래픽을 허용하는 보안 규칙을 추가해야 합니다. 다음 Azure Portal 이미지는 예제 보안 규칙을 보여줍니다.

Azure Portal 인바운드 보안 규칙 추가 창의 스크린샷 대상 포트 범위 상자는 새 보안 규칙에 대해 10250으로 설정됩니다.

더 제한적인 경우 서브넷 수준에서만 포트 10250에 대한 액세스를 허용할 수 있습니다.

참고

우선 순위 필드는 그에 따라 조정되어야 합니다. 예를 들어 여러 포트(포트 10250 포함)를 거부하는 규칙이 있는 경우 이미지에 표시된 규칙은 우선 순위가 낮아야 합니다(낮은 숫자는 더 높은 우선 순위를 갖습니다). 우선 순위에 대한 자세한 내용은 보안 규칙을 참조하세요.
이 솔루션을 적용한 후 동작이 변경되지 않으면 터널 구성 요소 Pod를 다시 만들 수 있습니다. 이러한 Pod를 삭제하면 다시 만들어집니다.

원인 2: UFW(복잡하지 않은 방화벽) 도구가 포트 10250을 차단하고 있습니다.

참고

이 원인은 AKS 클러스터에 있는 모든 터널 구성 요소에 적용됩니다.

UFW(복잡하지 않은 방화벽)는 netfilter 방화벽을 관리하기 위한 명령줄 프로그램입니다. AKS 노드는 Ubuntu를 사용합니다. 따라서 UFW는 기본적으로 AKS 노드에 설치되지만 UFW는 사용하지 않도록 설정됩니다.

기본적으로 UFW를 사용하도록 설정하면 포트 10250을 포함한 모든 포트에 대한 액세스를 차단합니다. 이 경우 SSH(Secure Shell)를 사용하여 문제 해결을 위해 AKS 클러스터 노드에 연결할 수 없습니다. UFW가 포트 22를 차단할 수도 있기 때문입니다. 문제를 해결하려면 az vmss run-command invoke 명령을 실행하여 UFW가 사용하도록 설정되어 있는지 여부를 확인하는 ufw 명령을 호출할 수 있습니다.

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw status" \
    --output tsv \
    --query 'value[0].message'

결과에 UFW가 사용하도록 설정되어 있고 포트 10250을 구체적으로 허용하지 않는 경우 어떻게 해야 할까요? 이 경우 UFW를 사용하도록 설정한 노드에서 예약된 Pod에 대해 터널 기능(예: 로그 및 코드 실행)이 작동하지 않습니다. 문제를 해결하려면 UFW에 다음 솔루션 중 하나를 적용합니다.

중요

이 도구를 사용하여 변경하기 전에 AKS 지원 정책 (특히 노드 유지 관리 및 액세스)을 검토하여 클러스터가 지원되지 않는 시나리오에 들어가지 않도록 합니다.

참고

솔루션을 적용한 후 동작이 변경되지 않으면 터널 구성 요소 Pod를 다시 만들 수 있습니다. 이러한 Pod를 삭제하면 다시 만들어집니다.

해결 방법 2a: 복잡하지 않은 방화벽 사용 안 함

다음 az vmss run-command invoke 명령을 실행하여 UFW를 사용하지 않도록 설정합니다.

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw disable" \
    --output tsv \
    --query 'value[0].message'

해결 방법 2b: 포트 10250에 대한 액세스를 허용하도록 복잡하지 않은 방화벽 구성

UFW가 포트 10250에 대한 액세스를 허용하도록 강제하려면 다음 az vmss run-command invoke 명령을 실행합니다.

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw allow 10250" \
    --output tsv \
    --query 'value[0].message'

원인 3: iptables 도구가 포트 10250을 차단하고 있습니다.

참고

이 원인은 AKS 클러스터에 있는 모든 터널 구성 요소에 적용됩니다.

iptables 도구를 사용하면 시스템 관리자가 Linux 방화벽의 IP 패킷 필터 규칙을 구성할 수 있습니다. 포트 10250에서 통신을 차단하도록 규칙을 구성할 iptables 수 있습니다.

노드에 대한 규칙을 확인하여 포트 10250이 차단되었는지 또는 연결된 패킷이 삭제되었는지 여부를 검사 수 있습니다. 이렇게 하려면 다음 명령을 실행합니다 iptables .

iptables --list --line-numbers

출력에서 데이터는 체인을 포함한 INPUT 여러 체인으로 그룹화됩니다. 각 체인에는 다음 열 머리글 아래에 규칙 테이블이 포함되어 있습니다.

num (규칙 번호)
target
prot (프로토콜)
opt
source
destination

체인에 INPUT 대상이 이고 프로토콜tcp이 DROP이고 대상이 tcp dpt:10250인 규칙이 포함되어 있나요? 이 경우 대상 iptables 포트 10250에 대한 액세스를 차단합니다.

해결 방법 3: 포트 10250에 대한 액세스를 차단하는 iptables 규칙 삭제

다음 명령 중 하나를 실행하여 포트 10250에 대한 액세스를 방지하는 규칙을 삭제 iptables 합니다.

iptables --delete INPUT --jump DROP --protocol tcp --source <ip-number> --destination-port 10250

iptables --delete INPUT <input-rule-number>

정확하거나 잠재적인 시나리오를 해결하려면 명령을 실행 iptables --help 하여 iptables 수동을 검사 것이 좋습니다.

중요

원인 4: 송신 포트 1194 또는 9000이 열리지 않음

참고

이 원인은 및 aks-link Pod에 tunnel-front 만 적용됩니다.

AKS 방화벽과 같은 송신 트래픽 제한이 있나요? 있는 경우 Pod의 올바른 기능을 사용하려면 포트 9000이 tunnel-front 필요합니다. 마찬가지로 Pod에는 포트 1194가 aks-link 필요합니다.

Konnectivity는 포트 443에 의존합니다. 기본적으로 이 포트는 열려 있습니다. 따라서 해당 포트의 연결 문제에 대해 걱정할 필요가 없습니다.

해결 방법 4: 포트 1194 또는 9000 열기

가상 어플라이언스 포트 1194 또는 포트 9000에 대한 액세스를 허용하는지 확인합니다. 필요한 규칙 및 종속성에 대한 자세한 내용은 Azure Global 필수 네트워크 규칙을 참조하세요.

원인 5: SNAT(원본 네트워크 주소 변환) 포트 소모

참고

이 원인은 AKS 클러스터에 있는 모든 터널 구성 요소에 적용됩니다. 그러나 프라이빗 AKS 클러스터에는 적용되지 않습니다. 원본 SNAT(네트워크 주소 변환) 포트 소모는 공용 통신에만 발생할 수 있습니다. 프라이빗 AKS 클러스터의 경우 API 서버는 AKS 가상 네트워크 또는 서브넷 내에 있습니다.

SNAT 포트 소모(실패한 SNAT 포트)가 발생하는 경우 노드는 API 서버에 연결할 수 없습니다. 터널 컨테이너는 API 서버 쪽에 있습니다. 따라서 터널 연결은 설정되지 않습니다.

SNAT 포트 리소스가 소진되면 기존 흐름이 일부 SNAT 포트를 해제할 때까지 아웃바운드 흐름이 실패합니다. Azure Load Balancer 흐름이 닫히면 SNAT 포트를 회수합니다. 4분 유휴 시간 초과를 사용하여 유휴 흐름에서 SNAT 포트를 회수합니다.

다음 섹션에 설명된 대로 AKS 부하 분산 장치 메트릭 또는 서비스 진단 SNAT 포트를 볼 수 있습니다. SNAT 포트를 보는 방법에 대한 자세한 내용은 내 아웃바운드 연결 통계 어떻게 할까요? 검사?을 참조하세요.

AKS 부하 분산 장치 메트릭

AKS 부하 분산 장치 메트릭을 사용하여 SNAT 포트를 보려면 다음 단계를 수행합니다.

Azure PortalKubernetes 서비스를 검색하여 선택합니다.
Kubernetes 서비스 목록에서 클러스터의 이름을 선택합니다.
클러스터의 메뉴 창에서 설정 제목을 찾은 다음 속성을 선택합니다.
인프라 리소스 그룹 아래에 나열된 이름을 선택합니다.
kubernetes 부하 분산 장치를 선택합니다.
부하 분산 장치의 메뉴 창에서 모니터링 제목을 찾은 다음 메트 릭을 선택합니다.
메트릭 유형에 대해 SNAT 연결 수를 선택합니다.
분할 적용을 선택합니다.
분할 기준 을 연결 상태로 설정합니다.

서비스 진단

서비스 진단 사용하여 SNAT 포트를 보려면 다음 단계를 수행합니다.

Azure PortalKubernetes 서비스를 검색하여 선택합니다.
Kubernetes 서비스 목록에서 클러스터의 이름을 선택합니다.
클러스터의 메뉴 창에서 문제 진단 및 해결을 선택합니다.
연결 문제를 선택합니다.
SNAT 연결 및 포트 할당에서 세부 정보 보기를 선택합니다.
필요한 경우 시간 범위 단추를 사용하여 시간 프레임을 사용자 지정합니다.

해결 방법 5a: 애플리케이션이 연결 풀링을 사용하고 있는지 확인

이 동작은 애플리케이션이 기존 연결을 다시 사용하지 않기 때문에 발생할 수 있습니다. 요청당 하나의 아웃바운드 연결을 만들지 않는 것이 좋습니다. 이러한 구성으로 인해 연결이 소진될 수 있습니다. 애플리케이션 코드가 모범 사례를 따르고 연결 풀링을 사용하는지 확인합니다. 대부분의 라이브러리는 연결 풀링을 지원합니다. 따라서 요청당 새 아웃바운드 연결을 만들 필요가 없습니다.

해결 방법 5b: 할당된 아웃바운드 포트 조정

애플리케이션 내에서 모든 것이 정상인 경우 할당된 아웃바운드 포트를 조정해야 합니다. 아웃바운드 포트 할당에 대한 자세한 내용은 할당된 아웃바운드 포트 구성을 참조하세요.

해결 방법 5c: 클러스터를 만들 때 NAT(관리형 네트워크 주소 변환) 게이트웨이 사용

아웃바운드 연결에 NAT(관리형 네트워크 주소 변환) 게이트웨이를 사용하도록 새 클러스터를 설정할 수 있습니다. 자세한 내용은 관리형 NAT 게이트웨이를 사용하여 AKS 클러스터 만들기를 참조하세요.

타사 연락처 고지

Microsoft는 이 항목에 대한 추가 정보를 찾는 데 도움이 되는 타사 연락처 정보를 제공합니다. 이 연락처 정보는 공지 없이 변경될 수 있습니다. Microsoft는 타사 연락처 정보의 정확성을 보장하지 않습니다.

도움을 요청하십시오.

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

다음을 통해 공유