AKS에서 애플리케이션에 액세스할 때 일시적인 시간 제한 또는 서버 문제
이 문서에서는 AKS(Azure Kubernetes Service) 클러스터에서 호스트되는 애플리케이션에 영향을 주는 일시적인 연결 문제를 해결하는 방법을 설명합니다.
필수 구성 요소
클라이언트 URL(cURL) 도구 또는 유사한 명령줄 도구입니다.
Kubernetes kubectl 도구 또는 클러스터에 연결하는 유사한 도구입니다. Azure CLI를 사용하여 kubectl을 설치하려면 az aks install-cli 명령을 실행합니다.
증상
cURL 명령을 실행하면 때때로 "시간 초과" 오류 메시지가 표시됩니다. 출력은 다음 텍스트와 유사할 수 있습니다.
$ # One connection is successful, which results in a HTTP 200 response.
$ curl -Iv http://20.62.x.x
* Trying 20.62.x.x:80...
* Connected to 20.62.x.x (20.62.x.x) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
$ # Another connection is unsuccessful, because it gets timed out.
$ curl -Iv http://20.62.x.x
* Trying 20.62.x.x:80...
* connect to 20.62.x.x port 80 failed: Timed out
* Failed to connect to 20.62.x.x port 80 after 21050 ms: Timed out
* Closing connection 0
curl: (28) Failed to connect to 20.62.x.x port 80 after 21050 ms: Timed out
$ # Then the next connection is again successful.
$ curl -Iv http://20.62.x.x
* Trying 20.62.x.x:80...
* Connected to 20.62.x.x (20.62.x.x) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
원인
간헐적인 시간 제한은 네트워킹 문제와는 달리 구성 요소 성능 문제를 제안합니다.
이 시나리오에서는 구성 요소의 사용량과 상태를 검사 것이 중요합니다. 내부 출력 기술을 사용하여 Pod의 상태 검사 수 있습니다. 다음과 같이 kubectl top 및 kubectl get 명령을 실행합니다.
$ kubectl top pods # Check the health of the pods and the nodes.
NAME CPU(cores) MEMORY(bytes)
my-deployment-fc94b7f98-m9z2l 1m 32Mi
$ kubectl top nodes
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
aks-agentpool-42617579-vmss000000 120m 6% 2277Mi 49%
$ kubectl get pods # Check the state of the pod.
NAME READY STATUS RESTARTS AGE
my-deployment-fc94b7f98-m9z2l 2/2 Running 1 108s
출력은 Pod 및 노드의 현재 사용이 허용되는 것으로 보인다는 것을 보여 줍니다.
Pod가 Running 상태에 있지만 Pod가 실행되는 첫 108초 후에 다시 시작됩니다. 이 발생은 일부 문제가 Pod에서 실행되는 Pod 또는 컨테이너에 영향을 미친다는 것을 나타낼 수 있습니다.
문제가 지속되면 Pod의 상태 일정 시간 후에 변경됩니다.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
my-deployment-fc94b7f98-m9z2l 1/2 CrashLoopBackOff 42 3h53m
이 예제에서는 상태가 변경되고 Pod가 여러 차례 다시 시작되었음을 보여 Ready 줍니다. 컨테이너 CrashLoopBackOff 중 하나가 상태입니다.
이 상황은 시작 후 컨테이너가 실패하고 Kubernetes가 컨테이너를 다시 시작하여 강제로 작동하도록 하기 때문에 발생합니다. 그러나 문제가 지속되면 애플리케이션이 일정 시간 동안 실행된 후에도 계속 실패합니다. Kubernetes는 결국 상태 으로 변경합니다CrashLoopBackOff.
Pod에 대한 로그를 검사 다음 kubectl logs 명령을 실행합니다.
$ kubectl logs my-deployment-fc94b7f98-m9z2l
error: a container name must be specified for pod my-deployment-fc94b7f98-m9z2l, choose one of: [webserver my-app]
$ # Since the pod has more than one container, the name of the container has to be specified.
$ kubectl logs my-deployment-fc94b7f98-m9z2l -c webserver
[...] [mpm_event:notice] [pid 1:tid 140342576676160] AH00489: Apache/2.4.52 (Unix) configured -- resuming normal operations
[...] [core:notice] [pid 1:tid 140342576676160] AH00094: Command line: 'httpd -D FOREGROUND'
10.244.0.1 - - ... "GET / HTTP/1.1" 200 45
10.244.0.1 - - ... "GET /favicon.ico HTTP/1.1" 404 196
10.244.0.1 - - ... "-" 408 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "POST /boaform/admin/formLogin HTTP/1.1" 404 196
$ # The webserver container is running fine. Check the logs for other container (my-app).
$ kubectl logs my-deployment-fc94b7f98-m9z2l -c my-app
$ # No logs observed. The container could be starting or be in a transition phase.
$ # So logs for the previous execution of this container can be checked using the --previous flag:
$ kubectl logs my-deployment-fc94b7f98-m9z2l -c my-app --previous
<Some Logs from the container>
..
..
Started increasing memory
로그 항목은 컨테이너가 실행된 이전 시간에 이루어졌습니다. 이러한 항목이 존재하면 애플리케이션이 시작되었지만 몇 가지 문제로 인해 닫혔습니다.
다음 단계는 kubectl describe 명령을 실행하여 Pod의 이벤트를 검사 것입니다.
$ kubectl describe pod my-deployment-fc94b7f98-m9z2l
Name: my-deployment-fc94b7f98-m9z2l
Namespace: default
...
...
Labels: app=my-pod
...
...
Containers:
webserver:
...
...
my-app:
Container ID: containerd://a46e5062d53039d0d812c57c76b740f8d1ffb222de35203575bf8e4d10d6b51e
Image: my-repo/my-image:latest
Image ID: docker.io/my-repo/my-image@sha256:edcc4bedc7b...
State: Running
Started: <Start Date>
Last State: Terminated
Reason: OOMKilled
Exit Code: 137
Ready: True
Restart Count: 44
Limits:
memory: 500Mi
Requests:
cpu: 250m
memory: 500Mi
...
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Pulling 49m (x37 over 4h4m) kubelet Pulling image "my-repo/my-image:latest"
Warning BackOff 4m10s (x902 over 4h2m) kubelet Back-off restarting failed container
관찰:
종료 코드는 137입니다. 종료 코드에 대한 자세한 내용은 특별한 의미를 가진 Docker 실행 참조 및 종료 코드를 참조하세요.
종료 이유는 입니다
OOMKilled.컨테이너에 대해 지정된 메모리 제한은 500Mi입니다.
메모리 제한을 초과하여 컨테이너가 종료되고 있음을 이벤트에서 알 수 있습니다. 컨테이너 메모리 제한에 도달하면 애플리케이션에 간헐적으로 액세스할 수 없게 되고 컨테이너가 종료되고 다시 시작됩니다.
해결 방법
메모리 제한을 제거하고 애플리케이션을 모니터링하여 실제로 필요한 메모리 양을 확인할 수 있습니다. 메모리 사용량을 학습한 후 컨테이너의 메모리 제한을 업데이트할 수 있습니다. 메모리 사용량이 계속 증가하는 경우 애플리케이션에 메모리 누수가 있는지 확인합니다.
Azure Kubernetes Service 워크로드에 대한 리소스를 계획하는 방법에 대한 자세한 내용은 리소스 관리 모범 사례를 참조하세요.
도움을 요청하십시오.
질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기