AKS 클러스터에서 호스트되는 앱에 대한 연결 문제 해결
AKS(Microsoft Azure Kubernetes Service) 클러스터에 대한 연결 문제는 서로 다른 것을 의미할 수 있습니다. 경우에 따라 API 서버에 대한 연결이 영향을 받을 수 있습니다(예: kubectl 사용). 다른 경우에는 일반적인 연결 문제가 AKS 클러스터에서 호스트되는 애플리케이션에 영향을 줄 수 있습니다. 이 문서에서는 AKS 클러스터 연결 문제를 해결하는 방법을 설명합니다.
참고
AKS API 서버에 연결하려고 할 때 발생하는 일반적인 문제를 해결하려면 API 서버와 관련된 클러스터 연결 문제의 기본 문제 해결을 참조하세요.
필수 구성 요소
클라이언트 URL(cURL) 도구 또는 유사한 명령줄 도구입니다.
패키지를 처리하기 위한 apt-get 명령줄 도구입니다.
Kubernetes kubectl 도구 또는 클러스터에 연결하는 유사한 도구입니다. Azure CLI를 사용하여 kubectl을 설치하려면 az aks install-cli 명령을 실행합니다.
고려해야 할 요소
이 섹션에서는 AKS 클러스터에서 호스트되는 애플리케이션에 연결하려고 할 때 문제가 발생하는 경우 수행할 문제 해결 단계를 설명합니다.
모든 네트워킹 시나리오에서 관리자는 문제 해결 시 다음과 같은 중요한 요소를 고려해야 합니다.
요청의 원본 및 대상은 무엇인가요?
원본과 대상 사이의 홉은 무엇인가요?
요청-응답 흐름은 무엇인가요?
다음 항목과 같이 위에 추가 보안 계층이 있는 홉은 다음과 같습니다.
- 방화벽
- NSG(네트워크 보안 그룹)
- 네트워크 정책
각 구성 요소를 검사 HTTP 응답 코드를 가져와 분석합니다. 이러한 코드는 문제의 특성을 식별하는 데 유용하며 애플리케이션이 HTTP 요청에 응답하는 시나리오에서 특히 유용합니다.
다른 문제 해결 단계에서 결정적인 결과를 제공하지 않는 경우 클라이언트 및 서버에서 패킷 캡처를 수행합니다. 패킷 캡처는 클라이언트와 서버 간에 HTTP가 아닌 트래픽이 관련된 경우에도 유용합니다. AKS 환경에 대한 패킷 캡처를 수집하는 방법에 대한 자세한 내용은 데이터 수집 가이드의 다음 문서를 참조하세요.
HTTP 응답 코드를 가져와 패킷 캡처를 수행하는 방법을 알면 네트워크 연결 문제를 더 쉽게 해결할 수 있습니다.
AKS의 애플리케이션에 대한 기본 네트워크 흐름
일반적으로 AKS 클러스터에서 호스트되는 애플리케이션에 액세스하기 위한 요청 흐름은 다음과 같습니다.
클라이언트 >> DNS 이름 >> AKS 부하 분산 장치 IP 주소 >> AKS 노드 >> Pod
추가 구성 요소가 포함될 수 있는 다른 가능한 상황이 있습니다. 예시:
- 애플리케이션 게이트웨이는 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가 또는 Running 상태가 아니 Ready 거나 여러 번 다시 시작한 경우 출력을 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 run, apt-get, 및 cURL 명령을 실행합니다.
# 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
# After the packages are installed, test the connectivity to the application pod:
curl -Iv http://<pod-ip-address>:<port>
다른 프로토콜에서 수신 대기하는 애플리케이션의 경우 테스트 Pod 내에 관련 도구를 설치한 다음 애플리케이션 Pod에 대한 연결을 검사 수 있습니다.
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
# After the packages are installed, test the connectivity to the service:
curl -Iv http://<service-ip-address>:<port>
이전 명령이 적절한 응답을 반환하지 않는 경우 오류에 대해 서비스 이벤트를 검사.
LoadBalancer 서비스에 액세스
LoadBalancer 서비스의 경우 클러스터 외부에서 부하 분산 장치 IP 주소에 액세스할 수 있습니다.
curl -Iv http://<service-ip-address>:<port>
서비스 IP 주소가 LoadBalancer 올바른 응답을 반환하나요? 그렇지 않은 경우 다음 단계를 수행합니다.
서비스의 이벤트를 확인합니다.
AKS 노드 및 AKS 서브넷과 연결된 NSG(네트워크 보안 그룹)가 서비스 포트에서 들어오는 트래픽을 허용하는지 확인합니다.
서비스 문제를 해결하는 더 많은 명령은 디버그 서비스를 참조하세요.
서비스 대신 수신을 사용하는 시나리오
리소스를 사용하여 Ingress 애플리케이션이 노출되는 시나리오의 경우 트래픽 흐름은 다음과 유사합니다.
클라이언트 >> DNS 이름 >> 부하 분산 장치 또는 애플리케이션 게이트웨이 IP 주소 >> 클러스터 >> 서비스 또는 Pod 내의 수신 Pod
여기에서 문제 해결의 내부 아웃 접근 방식을 적용할 수도 있습니다. 자세한 내용은 수신 및 수신 컨트롤러 세부 정보를 검사 수도 있습니다.
$ 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 될 수 있습니다.
또 다른 가능성은 수신 Pod 위에 있는 구성 요소(예: Load Balancer 또는 Application Gateway)가 요청을 클러스터로 올바르게 라우팅하지 않는 것입니다. 이 경우 이러한 리소스의 백 엔드 구성을 검사 수 있습니다.
오류 메시지가 표시 Connection Timed Out 되면 AKS 노드와 연결된 네트워크 보안 그룹을 검사. 또한 AKS 서브넷을 검사. 부하 분산 장치 또는 애플리케이션 게이트웨이에서 AKS 노드로의 트래픽을 차단할 수 있습니다.
수신 문제를 해결하는 방법(예: Nginx 수신)에 대한 자세한 내용은 ingress-nginx 문제 해결을 참조하세요.
도움을 요청하십시오.
질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.
타사 연락처 고지
Microsoft는 이 항목에 대한 추가 정보를 찾는 데 도움이 되는 타사 연락처 정보를 제공합니다. 이 연락처 정보는 공지 없이 변경될 수 있습니다. Microsoft는 타사 연락처 정보의 정확성을 보장하지 않습니다.