AKS 클러스터에서 호스트되는 앱에 대한 연결 문제 해결
현재 동적 클라우드 환경에서 AKS(Azure Kubernetes Service) 클러스터에서 호스트되는 애플리케이션에 원활하게 연결되도록 하는 것은 최적의 성능 및 사용자 환경을 유지하는 데 매우 중요합니다. 이 문서에서는 애플리케이션 쪽 문제, 네트워크 정책, NSG(네트워크 보안 그룹) 규칙 등을 비롯한 다양한 요인으로 인한 연결 문제를 해결하고 해결하는 방법을 설명합니다.
참고 항목
AKS API 서버에 연결하려고 할 때 발생하는 일반적인 문제를 해결하려면 API 서버와 관련된 클러스터 연결 문제의 기본 문제 해결을 참조하세요.
필수 조건
클라이언트 URL(cURL) 도구 또는 유사한 명령줄 도구입니다.
패키지를 처리하기 위한 apt-get 명령줄 도구입니다.
TCP 연결에 대한 Netcat(
nc) 명령줄 도구입니다.Kubernetes kubectl 도구 또는 클러스터에 연결할 유사한 도구입니다. Azure CLI를 사용하여 kubectl을 설치하려면 az aks install-cli 명령을 실행합니다.
고려해야 할 요소
이 섹션에서는 AKS 클러스터에서 호스트되는 애플리케이션에 연결하려고 할 때 문제가 발생하는 경우 수행할 문제 해결 단계를 설명합니다.
모든 네트워킹 시나리오에서 관리자는 문제 해결 시 다음과 같은 중요한 요소를 고려해야 합니다.
요청의 원본 및 대상은 무엇인가요?
원본과 대상 사이의 홉은 무엇인가요?
요청-응답 흐름은 무엇인가요?
다음 항목과 같이 위쪽에 추가 보안 계층이 있는 홉은 다음과 같습니다.
- 방화벽
- NSG(네트워크 보안 그룹) 이름
- 네트워크 정책
각 구성 요소를 확인할 때 HTTP 응답 코드를 가져오고 분석합니다. 이러한 코드는 문제의 특성을 식별하는 데 유용하며 애플리케이션이 HTTP 요청에 응답하는 시나리오에서 특히 유용합니다.
다른 문제 해결 단계에서 결정적인 결과를 제공하지 않는 경우 클라이언트 및 서버에서 패킷 캡처를 수행합니다. 패킷 캡처는 클라이언트와 서버 간에 HTTP가 아닌 트래픽이 관련된 경우에도 유용합니다. AKS 환경에 대한 패킷 캡처를 수집하는 방법에 대한 자세한 내용은 데이터 수집 가이드의 다음 문서를 참조하세요.
AKS 클러스터의 Linux 노드에서 TCP 덤프를 캡처합니다.
AKS 클러스터의 Windows 노드에서 TCP 덤프를 캡처합니다.
AKS 클러스터의 Pod에서 TCP 패킷을 캡처합니다.
HTTP 응답 코드를 가져오고 패킷 캡처를 수행하는 방법을 알면 네트워크 연결 문제를 보다 쉽게 해결할 수 있습니다.
AKS의 애플리케이션에 대한 기본 네트워크 흐름
일반적으로 애플리케이션이 Azure Load Balancer 서비스 유형을 사용하여 노출되는 경우 액세스 요청 흐름은 다음과 같습니다.
클라이언트 >> DNS 이름 >> AKS 부하 분산 장치 IP 주소 >> AKS 노드 >> Pod
추가 구성 요소가 포함될 수 있는 다른 가능한 상황이 있습니다. 예시:
- 애플리케이션 라우팅 추가 기능으로 관리되는 NGINX 수신이 사용하도록 설정됩니다.
- 애플리케이션 게이트웨이는 Azure Load Balancer 대신 AGIC(Application Gateway 수신 컨트롤러)를 통해 사용됩니다.
- Azure Front Door 및 API Management는 부하 분산 장치 위에 사용될 수 있습니다.
- 프로세스는 내부 부하 분산 장치를 사용합니다.
- 연결이 Pod 및 요청된 URL에서 종료되지 않을 수 있습니다. 이는 Pod가 데이터베이스 또는 동일한 클러스터의 다른 서비스와 같은 다른 엔터티에 연결할 수 있는지 여부에 따라 달라질 수 있습니다.
애플리케이션에 대한 요청 흐름을 이해하는 것이 중요합니다.
AKS 클러스터의 애플리케이션에 대한 기본 요청 흐름은 다음 다이어그램에 표시된 흐름과 유사합니다.
내부 출력 문제 해결
연결 문제 해결에는 많은 검사가 포함될 수 있지만 내부 아웃 접근 방식은 문제의 원인을 찾고 병목 상태를 식별하는 데 도움이 될 수 있습니다. 이 방법에서는 Pod 자체에서 시작하여 애플리케이션이 Pod의 IP 주소에 응답하는지 확인합니다. 그런 다음 각 구성 요소를 최종 클라이언트로 차례로 확인합니다.
1단계: Pod가 실행 중이고 Pod 내의 앱 또는 컨테이너가 올바르게 응답하는지 확인합니다.
Pod가 실행 중인지 확인하려면 다음 kubectl get 명령 중 하나를 실행합니다.
# List pods in the specified namespace.
kubectl get pods -n <namespace-name>
# List pods in all namespaces.
kubectl get pods -A
Pod가 실행되고 있지 않으면 어떻게 해야 할까요? 이 경우 kubectl describe 명령을 사용하여 Pod 이벤트를 확인합니다.
kubectl describe pod <pod-name> -n <namespace-name>
Pod가 상태가 아니 Ready 거나 Running 여러 번 다시 시작한 경우 출력을 확인합니다 kubectl describe . 이벤트는 Pod를 시작할 수 없는 문제를 표시합니다. 또는 Pod가 시작된 경우 Pod 내의 애플리케이션이 실패하여 Pod가 다시 시작될 수 있습니다. 적절하게 Pod 문제를 해결하여 적절한 상태인지 확인합니다.
Pod가 실행 중인 경우 Pod 내에 있는 컨테이너의 로그를 확인하는 것도 유용할 수 있습니다. 다음 일련의 kubectl 로그 명령을 실행합니다.
kubectl logs <pod-name> -n <namespace-name>
# Check logs for an individual container in a multicontainer pod.
kubectl logs <pod-name> -n <namespace-name> -c <container-name>
# Dump pod logs (stdout) for a previous container instance.
kubectl logs <pod-name> --previous
# Dump pod container logs (stdout, multicontainer case) for a previous container instance.
kubectl logs <pod-name> -c <container-name> --previous
Pod가 실행되고 있나요? 이 경우 클러스터에서 테스트 Pod를 시작하여 연결을 테스트합니다. 테스트 Pod에서 애플리케이션의 Pod IP 주소에 직접 액세스하고 애플리케이션이 올바르게 응답하는지 확인할 수 있습니다. kubectl 실행 및 cURL 명령을 다음과 같이 실행apt-get합니다.
# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable
# After the test pod is running, you will gain access to the pod.
# Then you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y && apt-get install netcat-traditional -y
# After the packages are installed, test the connectivity to the application pod:
curl -Iv http://<pod-ip-address>:<port>
다른 프로토콜에서 수신 대기하는 애플리케이션의 경우 netcat 도구와 같은 테스트 Pod 내에 관련 도구를 설치한 다음, 다음 명령을 실행하여 애플리케이션 Pod에 대한 연결을 확인할 수 있습니다.
# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-ip-address> <port>
Pod 문제를 해결하는 더 많은 명령은 실행 중인 Pod 디버그를 참조 하세요.
2단계: 서비스에서 애플리케이션에 연결할 수 있는지 확인
Pod 내의 애플리케이션이 실행되는 시나리오의 경우 주로 Pod가 노출되는 방식의 문제 해결에 집중할 수 있습니다.
Pod가 서비스로 노출되었나요? 이 경우 서비스 이벤트를 확인합니다. 또한 서비스 설명에서 Pod IP 주소 및 애플리케이션 포트를 엔드포인트로 사용할 수 있는지 확인합니다.
# Check the service details.
kubectl get svc -n <namespace-name>
# Describe the service.
kubectl describe svc <service-name> -n <namespace-name>
다음 예제와 같이 Pod의 IP 주소가 서비스의 엔드포인트로 존재하는지 확인합니다.
$ kubectl get pods -o wide # Check the pod's IP address.
NAME READY STATUS RESTARTS AGE IP NODE
my-pod 1/1 Running 0 12m 10.244.0.15 aks-agentpool-000000-vmss000000
$ kubectl describe service my-cluster-ip-service # Check the endpoints in the service.
Name: my-cluster-ip-service
Namespace: default
Selector: app=my-pod
Type: ClusterIP
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.0.174.133
IPs: 10.0.174.133
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: 10.244.0.15:80 # <--- Here
$ kubectl get endpoints # Check the endpoints directly for verification.
NAME ENDPOINTS AGE
my-cluster-ip-service 10.244.0.15:80 14m
엔드포인트가 올바른 Pod IP 주소를 가리키지 않는 경우 Pod 및 Selectors 서비스에 대해 확인 Labels 합니다.
서비스의 엔드포인트가 올바른가요? 그렇다면 서비스에 액세스하고 애플리케이션에 연결할 수 있는지 확인합니다.
ClusterIP 서비스에 액세스
ClusterIP 서비스의 경우 클러스터에서 테스트 Pod를 시작하고 서비스 IP 주소에 액세스할 수 있습니다.
# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable
# After the test pod is running, you will gain access to the pod.
# Then, you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y && apt-get install netcat-traditional -y
# After the packages are installed, test the connectivity to the service:
curl -Iv http://<service-ip-address>:<port>
다른 프로토콜에서 수신 대기하는 애플리케이션의 경우 netcat 도구와 같은 테스트 Pod 내에 관련 도구를 설치한 다음, 다음 명령을 실행하여 애플리케이션 Pod에 대한 연결을 확인할 수 있습니다.
# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-ip-address> <port>
이전 명령이 적절한 응답을 반환하지 않는 경우 서비스 이벤트에서 오류가 있는지 확인합니다.
LoadBalancer 서비스에 액세스
LoadBalancer 서비스의 경우 클러스터 외부에서 부하 분산 장치 IP 주소에 액세스할 수 있습니다.
curl -Iv http://<service-ip-address>:<port>
다른 프로토콜에서 수신 대기하는 애플리케이션의 경우 netcat 도구와 같은 테스트 Pod 내에 관련 도구를 설치한 다음, 다음 명령을 실행하여 애플리케이션 Pod에 대한 연결을 확인할 수 있습니다.
nc -z -v <pod-ip-address> <port>
서비스 IP 주소가 LoadBalancer 올바른 응답을 반환하나요? 그렇지 않은 경우 다음 단계를 수행합니다.
서비스의 이벤트를 확인합니다.
AKS 노드 및 AKS 서브넷과 연결된 NSG(네트워크 보안 그룹)가 서비스 포트에서 들어오는 트래픽을 허용하는지 확인합니다.
서비스 문제를 해결하는 더 많은 명령은 디버그 서비스를 참조 하세요.
서비스 대신 수신을 사용하는 시나리오
리소스를 사용하여 Ingress 애플리케이션이 노출되는 시나리오의 경우 트래픽 흐름은 다음과 유사합니다.
클러스터 서비스 또는 Pod 내의 클라이언트 >> DNS 이름 >> 부하 분산 장치 또는 애플리케이션 게이트웨이 IP 주소 >> 수신 >> 컨트롤러 Pod
여기에서도 문제 해결의 내부 아웃 접근 방식을 적용할 수 있습니다. 자세한 내용은 수신 kubernetes 리소스 및 수신 컨트롤러 세부 정보를 확인할 수도 있습니다.
$ kubectl get ing -n <namespace-of-ingress> # Checking the ingress details and events.
NAME CLASS HOSTS ADDRESS PORTS AGE
hello-world-ingress <none> myapp.com 20.84.x.x 80, 443 7d22h
$ kubectl describe ing -n <namespace-of-ingress> hello-world-ingress
Name: hello-world-ingress
Namespace: <namespace-of-ingress>
Address: 20.84.x.x
Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
tls-secret terminates myapp.com
Rules:
Host Path Backends
---- ---- --------
myapp.com
/blog blog-service:80 (10.244.0.35:80)
/store store-service:80 (10.244.0.33:80)
Annotations: cert-manager.io/cluster-issuer: letsencrypt
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/rewrite-target: /$1
nginx.ingress.kubernetes.io/use-regex: true
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Sync 5m41s nginx-ingress-controller Scheduled for sync
Normal Sync 5m41s nginx-ingress-controller Scheduled for sync
이 예제에는 다음과 같은 Ingress 리소스가 포함되어 있습니다.
- 호스트에서 수신 대기
myapp.com합니다. - 두
Path개의 문자열이 구성되어 있습니다. - 백 엔드에서 2
Services로 라우팅합니다.
백 엔드 서비스가 실행 중인지 확인하고 수신 설명에 언급된 포트에 응답합니다.
$ kubectl get svc -n <namespace-of-ingress>
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
ingress-basic blog-service ClusterIP 10.0.155.154 <none> 80/TCP
ingress-basic store-service ClusterIP 10.0.61.185 <none> 80/TCP
ingress-basic nginx-ingress-ingress-nginx-controller LoadBalancer 10.0.122.148 20.84.x.x 80:30217/TCP,443:32464/TCP
오류가 있는 경우 수신 컨트롤러 Pod에 대한 로그를 확인합니다.
$ kubectl get pods -n <namespace-of-ingress> # Get the ingress controller pods.
NAME READY STATUS RESTARTS AGE
aks-helloworld-one-56c7b8d79d-6zktl 1/1 Running 0 31h
aks-helloworld-two-58bbb47f58-rrcv7 1/1 Running 0 31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q 1/1 Running 0 31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-grzdr 1/1 Running 0 31h
$ # Check logs from the pods.
$ kubectl logs -n ingress-basic nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q
클라이언트가 수신 호스트 이름 또는 IP 주소를 요청하지만 수신 컨트롤러 Pod의 로그에 항목이 표시되지 않는 경우 어떻게 해야 할까요? 이 경우 요청이 클러스터에 도달하지 않을 수 있으며 사용자에게 오류 메시지가 표시 Connection Timed Out 될 수 있습니다.
또 다른 가능성은 Load Balancer 또는 Application Gateway와 같은 수신 Pod 위에 있는 구성 요소가 요청을 클러스터로 올바르게 라우팅하지 않는 것입니다. 이 경우 이러한 리소스의 백 엔드 구성을 확인할 수 있습니다.
오류 메시지가 표시 Connection Timed Out 되면 AKS 노드와 연결된 네트워크 보안 그룹을 확인합니다. 또한 AKS 서브넷을 확인합니다. 부하 분산 장치 또는 애플리케이션 게이트웨이에서 AKS 노드로의 트래픽을 차단할 수 있습니다.
수신 문제를 해결하는 방법(예: Nginx 수신)에 대한 자세한 내용은 ingress-nginx 문제 해결을 참조 하세요.
도움을 요청하십시오.
질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.
타사 연락처 고지
이 문서에 포함된 타사의 연락처 정보는 이 항목에 대한 추가 정보를 찾는 데 도움을 주기 위한 것입니다. 이 연락처 정보는 공지 없이 변경될 수 있습니다. Microsoft는 타사 연락처 정보의 정확성을 보증하지 않습니다.