노드 및 Pod 상태 검사

아티클
11/24/2023

이 문서는 시리즈의 일부입니다. 개요부터 시작합니다.

이전 단계에서 수행한 클러스터 검사 명확하면 AKS(Azure Kubernetes Service) 작업자 노드의 상태를 검사. 이 문서의 6단계에 따라 노드 상태를 검사 비정상 노드의 이유를 확인하고 문제를 해결합니다.

1단계: 작업자 노드의 상태 확인

다양한 요소가 AKS 클러스터의 비정상 노드에 기여할 수 있습니다. 한 가지 일반적인 이유는 컨트롤 플레인과 노드 간의 통신 분석입니다. 이러한 잘못된 의사 소통은 라우팅 및 방화벽 규칙의 잘못된 구성으로 인해 발생하는 경우가 많습니다.

사용자 정의 라우팅을 위해 AKS 클러스터를 구성하는 경우 NVA(네트워크 가상 어플라이언스) 또는 방화벽(예: Azure Firewall)을 통해 송신 경로를 구성해야 합니다. 잘못된 구성 문제를 해결하려면 AKS 송신 트래픽 지침에 따라 필요한 포트와 FQDN(정규화된 do기본 이름)을 허용하도록 방화벽을 구성하는 것이 좋습니다.

비정상 노드의 또 다른 이유는 kubelet 압력을 만드는 컴퓨팅, 메모리 또는 스토리지 리소스가 부족할 수 있습니다. 이러한 경우 리소스를 확장하면 문제를 효과적으로 해결할 수 있습니다.

프라이빗 AKS 클러스터에서 DNS(Do기본 이름 시스템) 확인 문제로 인해 컨트롤 플레인과 노드 간의 통신 문제가 발생할 수 있습니다. Kubernetes API 서버 DNS 이름이 API 서버의 개인 IP 주소로 확인되는지 확인해야 합니다. 사용자 지정 DNS 서버의 잘못된 구성은 DNS 확인 실패의 일반적인 원인입니다. 사용자 지정 DNS 서버를 사용하는 경우 노드가 프로비전되는 가상 네트워크에서 DNS 서버로 올바르게 지정해야 합니다. 또한 사용자 지정 DNS 서버를 통해 AKS 프라이빗 API 서버를 확인할 수 있음을 확인합니다.

제어 평면 통신 및 DNS 확인과 관련된 이러한 잠재적인 문제를 해결한 후 AKS 클러스터 내에서 노드 상태 문제를 효과적으로 해결하고 해결할 수 있습니다.

다음 방법 중 하나를 사용하여 노드의 상태를 평가할 수 있습니다.

Azure Monitor 컨테이너 상태 보기

AKS 클러스터에서 노드, 사용자 Pod 및 시스템 Pod의 상태를 보려면 다음 단계를 수행합니다.

Azure Portal에서 Azure Monitor로 이동합니다.
탐색 창의 Insights 섹션에서 컨테이너를 선택합니다.
모니터링되는 AKS 클러스터 목록에 대해 모니터링되는 클러스터를 선택합니다.
목록에서 AKS 클러스터를 선택하여 노드, 사용자 Pod 및 시스템 Pod의 상태를 확인합니다.

AKS 노드 보기

AKS 클러스터의 모든 노드가 준비 상태인지 확인하려면 다음 단계를 수행합니다.

Azure Portal에서 AKS 클러스터로 이동합니다.
탐색 창의 설정 섹션에서 노드 풀을 선택합니다.
노드를 선택합니다.
모든 노드가 준비 상태인지 확인합니다.

Prometheus 및 Grafana를 사용하여 클러스터 내 모니터링

AKS 클러스터에 Prometheus 및 Grafana를 배포한 경우 K8 클러스터 세부 정보 대시보드를 사용하여 인사이트를 얻을 수 있습니다. 이 대시보드는 Prometheus 클러스터 메트릭을 표시하고 CPU 사용량, 메모리 사용량, 네트워크 활동 및 파일 시스템 사용량과 같은 중요한 정보를 제공합니다. 또한 개별 Pod, 컨테이너 및 시스템 서비스에 대한 자세한 통계를 보여 줍니다.

대시보드에서 노드 조건을 선택하여 클러스터의 상태 및 성능에 대한 메트릭을 확인합니다. 일정 문제, 네트워크, 디스크 압력, 메모리 압력, PID(비례 정수 파생) 압력 또는 디스크 공간과 같은 문제가 있을 수 있는 노드를 추적할 수 있습니다. 이러한 메트릭을 모니터링하여 AKS 클러스터의 가용성 및 성능에 영향을 주는 잠재적인 문제를 사전에 식별하고 해결할 수 있습니다.

Prometheus 및 Azure Managed Grafana에 대한 관리되는 서비스 모니터링

미리 빌드된 대시보드를 사용하여 Prometheus 메트릭을 시각화하고 분석할 수 있습니다. 이렇게 하려면 Prometheus용 Monitor 관리 서비스에서 Prometheus 메트릭을 수집하고 Monitor 작업 영역을 Azure Managed Grafana 작업 영역에 연결하도록 AKS 클러스터를 설정해야 합니다. 이러한 대시보드는 Kubernetes 클러스터의 성능 및 상태에 대한 포괄적인 보기를 제공합니다.

대시보드는 Managed Prometheus 폴더의 지정된 Azure Managed Grafana 인스턴스에 프로비전됩니다. 일부 대시보드에는 다음이 포함됩니다.

Kubernetes / Compute 리소스 / 클러스터
Kubernetes / Compute 리소스 / 네임스페이스(Pod)
Kubernetes / Compute 리소스 / 노드(Pod)
Kubernetes / Compute 리소스 / Pod
Kubernetes / Compute 리소스 / 네임스페이스(워크로드)
Kubernetes / Compute 리소스 / 워크로드
Kubernetes / Kubelet
노드 내보내기 / USE 메서드 / 노드
노드 내보내기/노드
Kubernetes / Compute 리소스 / 클러스터(Windows)
Kubernetes / Compute 리소스 / 네임스페이스(Windows)
Kubernetes / Compute 리소스 / Pod(Windows)
Kubernetes / USE 메서드 / 클러스터 (Windows)
Kubernetes / USE 메서드 / 노드 (Windows)

이러한 기본 제공 대시보드는 Prometheus 및 Grafana를 사용하여 Kubernetes 클러스터를 모니터링하기 위해 오픈 소스 커뮤니티에서 널리 사용됩니다. 이러한 대시보드를 사용하여 리소스 사용량, Pod 상태 및 네트워크 활동과 같은 메트릭을 볼 수 있습니다. 모니터링 요구 사항에 맞게 조정된 사용자 지정 대시보드를 만들 수도 있습니다. 대시보드를 사용하면 AKS 클러스터에서 Prometheus 메트릭을 효과적으로 모니터링하고 분석할 수 있으므로 성능을 최적화하고 문제를 해결하며 Kubernetes 워크로드의 원활한 작업을 보장할 수 있습니다.

Kubernetes/Compute 리소스/노드(Pod) 대시보드를 사용하여 Linux 에이전트 노드에 대한 메트릭을 볼 수 있습니다. 각 Pod에 대한 CPU 사용량, CPU 할당량, 메모리 사용량 및 메모리 할당량을 시각화할 수 있습니다.

클러스터에 Windows 에이전트 노드가 포함된 경우 Kubernetes/USE 메서드/노드(Windows) 대시보드를 사용하여 이러한 노드에서 수집된 Prometheus 메트릭을 시각화할 수 있습니다. 이 대시보드는 클러스터 내의 Windows 노드에 대한 리소스 사용량 및 성능에 대한 포괄적인 보기를 제공합니다.

이러한 전용 대시보드를 활용하여 Linux 및 Windows 에이전트 노드 모두에서 CPU, 메모리 및 기타 리소스와 관련된 중요한 메트릭을 쉽게 모니터링하고 분석할 수 있습니다. 이러한 가시성을 통해 잠재적인 병목 상태를 식별하고, 리소스 할당을 최적화하고, AKS 클러스터 전체에서 효율적인 작업을 보장할 수 있습니다.

2단계: 컨트롤 플레인 및 작업자 노드 연결 확인

작업자 노드가 정상인 경우 관리되는 AKS 컨트롤 플레인과 클러스터 작업자 노드 간의 연결을 검사해야 합니다. AKS를 사용하면 보안 터널 통신 방법을 통해 Kubernetes API 서버와 개별 노드 kubelets 간의 통신이 가능합니다. 이러한 구성 요소는 서로 다른 가상 네트워크에 있더라도 통신할 수 있습니다. 터널은 mTLS(상호 전송 계층 보안) 암호화로 보호됩니다. AKS에서 사용하는 기본 터널을 Konnectivity(이전의 apiserver-network-proxy)라고 합니다. 모든 네트워크 규칙 및 FQDN이 필요한 Azure 네트워크 규칙을 준수하는지 확인합니다.

관리되는 AKS 컨트롤 플레인과 AKS 클러스터의 클러스터 작업자 노드 간의 연결을 확인하려면 kubectl 명령줄 도구를 사용할 수 있습니다.

Konnectivity 에이전트 Pod가 제대로 작동하는지 확인하려면 다음 명령을 실행합니다.

kubectl get deploy konnectivity-agent -n kube-system

Pod가 준비 상태인지 확인합니다.

컨트롤 플레인과 작업자 노드 간의 연결에 문제가 있는 경우 필요한 AKS 송신 트래픽 규칙이 허용된 후 연결을 설정합니다.

다음 명령을 실행하여 Pod를 konnectivity-agent 다시 시작합니다.

kubectl rollout restart deploy konnectivity-agent -n kube-system

Pod를 다시 시작해도 연결이 해결되지 않으면 변칙에 대한 로그를 검사. 다음 명령을 실행하여 Pod의 로그를 konnectivity-agent 봅니다.

kubectl logs -l app=konnectivity-agent -n kube-system --tail=50

로그에는 다음 출력이 표시됩니다.

I1012 12:27:43.521795       1 options.go:102] AgentCert set to "/certs/client.crt".
I1012 12:27:43.521831       1 options.go:103] AgentKey set to "/certs/client.key".
I1012 12:27:43.521834       1 options.go:104] CACert set to "/certs/ca.crt".
I1012 12:27:43.521837       1 options.go:105] ProxyServerHost set to "sethaks-47983508.hcp.switzerlandnorth.azmk8s.io".
I1012 12:27:43.521841       1 options.go:106] ProxyServerPort set to 443.
I1012 12:27:43.521844       1 options.go:107] ALPNProtos set to [konnectivity].
I1012 12:27:43.521851       1 options.go:108] HealthServerHost set to
I1012 12:27:43.521948       1 options.go:109] HealthServerPort set to 8082.
I1012 12:27:43.521956       1 options.go:110] AdminServerPort set to 8094.
I1012 12:27:43.521959       1 options.go:111] EnableProfiling set to false.
I1012 12:27:43.521962       1 options.go:112] EnableContentionProfiling set to false.
I1012 12:27:43.521965       1 options.go:113] AgentID set to b7f3182c-995e-4364-aa0a-d569084244e4.
I1012 12:27:43.521967       1 options.go:114] SyncInterval set to 1s.
I1012 12:27:43.521972       1 options.go:115] ProbeInterval set to 1s.
I1012 12:27:43.521980       1 options.go:116] SyncIntervalCap set to 10s.
I1012 12:27:43.522020       1 options.go:117] Keepalive time set to 30s.
I1012 12:27:43.522042       1 options.go:118] ServiceAccountTokenPath set to "".
I1012 12:27:43.522059       1 options.go:119] AgentIdentifiers set to .
I1012 12:27:43.522083       1 options.go:120] WarnOnChannelLimit set to false.
I1012 12:27:43.522104       1 options.go:121] SyncForever set to false.
I1012 12:27:43.567902       1 client.go:255] "Connect to" server="e9df3653-9bd4-4b09-b1a7-261f6104f5d0"

참고 항목

AKS 클러스터가 API 서버 가상 네트워크 통합 및 Azure CNI(컨테이너 네트워킹 인터페이스) 또는 동적 Pod IP 할당을 사용하는 Azure CNI로 설정된 경우 Konnectivity 에이전트를 배포할 필요가 없습니다. 통합 API 서버 Pod는 프라이빗 네트워킹을 통해 클러스터 작업자 노드와 직접 통신을 설정할 수 있습니다.

그러나 Azure CNI 오버레이와 API 서버 가상 네트워크 통합을 사용하거나 BYOCNI(Bring Your Own CNI)를 사용하는 경우 Konnectivity는 API 서버와 Pod IP 간의 통신을 용이하게 하기 위해 배포됩니다. API 서버와 작업자 노드 간의 통신은 직접 기본.

로깅 및 모니터링 서비스에서 컨테이너 로그를 검색하여 로그를 검색할 수도 있습니다. aks-link 연결 오류를 검색하는 예제는 컨테이너 인사이트에서 쿼리 로그를 참조하세요.

다음 쿼리를 실행하여 로그를 검색합니다.

ContainerLogV2 
| where _ResourceId =~ "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedClusters/<cluster-ID>" // Use the IDs and names of your resources for these values.
| where ContainerName has "aks-link"
| project LogSource,LogMessage, TimeGenerated, Computer, PodName, ContainerName, ContainerId
| order by TimeGenerated desc
| limit 200

다음 쿼리를 실행하여 특정 네임스페이스에서 실패한 Pod에 대한 컨테이너 로그를 검색합니다.

let KubePodInv = KubePodInventory
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where _ResourceId =~ "<cluster-resource-ID>" // Use your resource ID for this value.
    | where Namespace == "<pod-namespace>" // Use your target namespace for this value.
    | where PodStatus == "Failed"
    | extend ContainerId = ContainerID
    | summarize arg_max(TimeGenerated, *)  by  ContainerId, PodStatus, ContainerStatus
    | project ContainerId, PodStatus, ContainerStatus;

    KubePodInv
    | join
    (
        ContainerLogV2
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where PodNamespace == "<pod-namespace>" //update with target namespace
    ) on ContainerId
    | project TimeGenerated, PodName, PodStatus, ContainerName, ContainerId, ContainerStatus, LogMessage, LogSource

쿼리 또는 kubectl 도구를 사용하여 로그를 가져올 수 없는 경우 SSH(Secure Shell) 인증을 사용합니다. 이 예제에서는 SSH를 통해 노드에 연결한 후 tunnelfront Pod를 찾습니다.

kubectl pods -n kube-system -o wide | grep tunnelfront
ssh azureuser@<agent node pod is on, output from step above>
docker ps | grep tunnelfront
docker logs …
nslookup <ssh-server_fqdn>
ssh -vv azureuser@<ssh-server_fqdn> -p 9000
docker exec -it <tunnelfront_container_id> /bin/bash -c "ping bing.com"
kubectl get pods -n kube-system -o wide | grep <agent_node_where_tunnelfront_is_running>
kubectl delete po <kube_proxy_pod> -n kube-system

3단계: 송신을 제한할 때 DNS 확인 유효성 검사

DNS 확인은 AKS 클러스터의 중요한 측면입니다. DNS 확인이 제대로 작동하지 않으면 컨트롤 플레인 오류 또는 컨테이너 이미지 끌어오기 오류가 발생할 수 있습니다. Kubernetes API 서버에 대한 DNS 확인이 제대로 작동하는지 확인하려면 다음 단계를 수행합니다.

kubectl exec 명령을 실행하여 Pod에서 실행되는 컨테이너에서 명령 셸을 엽니다.
```
kubectl exec --stdin --tty your-pod --namespace <namespace-name> -- /bin/bash
```
nslookup 또는 dig 도구가 컨테이너에 설치되어 있는지 확인합니다.
두 도구가 모두 Pod에 설치되어 있지 않은 경우 다음 명령을 실행하여 동일한 네임스페이스에 유틸리티 Pod를 만듭니다.
```
kubectl run -i --tty busybox --image=busybox --namespace <namespace-name> --rm=true -- sh
```
Azure Portal에서 AKS 클러스터의 개요 페이지에서 API 서버 주소를 검색하거나 다음 명령을 실행할 수 있습니다.
```
az aks show --name <aks-name> --resource-group <resource-group-name> --query fqdn --output tsv
```
다음 명령을 실행하여 AKS API 서버를 확인합니다. 자세한 내용은 작업자 노드가 아닌 Pod 내부에서 DNS 확인 오류 문제를 해결하세요.
```
nslookup myaks-47983508.hcp.westeurope.azmk8s.io
```
Pod에서 업스트림 DNS 서버를 확인하여 DNS 확인이 제대로 작동하는지 확인합니다. 예를 들어 Azure DNS의 경우 명령을 실행합니다 nslookup .
```
nslookup microsoft.com 168.63.129.16
```
이전 단계에서 인사이트를 제공하지 않는 경우 작업자 노드 중 하나에 연결하고 노드에서 DNS 확인을 시도합니다. 이 단계는 문제가 AKS 또는 네트워킹 구성과 관련이 있는지 여부를 식별하는 데 도움이 됩니다.
노드에서 DNS 확인이 성공하지만 Pod에서 수행되지 않는 경우 문제는 Kubernetes DNS와 관련이 있을 수 있습니다. Pod에서 DNS 확인을 디버그하는 단계는 DNS 확인 오류 문제를 참조 하세요.

노드에서 DNS 확인이 실패하는 경우 네트워킹 설정을 검토하여 DNS 확인을 용이하게 하기 위해 적절한 라우팅 경로 및 포트가 열려 있는지 확인합니다.

4단계: kubelet 오류 확인

각 작업자 노드에서 실행되는 kubelet 프로세스의 상태를 확인하고 어떤 압력도 받지 않는지 확인합니다. 잠재적인 압력은 CPU, 메모리 또는 스토리지와 관련될 수 있습니다. 개별 노드 kubelets의 상태 확인하려면 다음 방법 중 하나를 사용할 수 있습니다.

AKS kubelet 통합 문서

에이전트 노드 kubelets가 제대로 작동하도록 하려면 다음 단계를 수행합니다.

Azure Portal에서 AKS 클러스터로 이동합니다.
탐색 창의 모니터링 섹션에서 통합 문서를 선택합니다.
Kubelet 통합 문서를 선택합니다.
작업을 선택하고 모든 작업자 노드에 대한 작업이 완료되었는지 확인합니다.

Prometheus 및 Grafana를 사용하여 클러스터 내 모니터링

AKS 클러스터에 Prometheus 및 Grafana를 배포한 경우 Kubernetes/Kubelet 대시보드를 사용하여 개별 노드 kubelets의 상태 및 성능에 대한 인사이트를 얻을 수 있습니다.

Prometheus 및 Azure Managed Grafana에 대한 관리되는 서비스 모니터링

Kubernetes/Kubelet 미리 빌드된 대시보드를 사용하여 작업자 노드 kubelets에 대한 Prometheus 메트릭을 시각화하고 분석할 수 있습니다. 이렇게 하려면 Prometheus용 Monitor 관리 서비스에서 Prometheus 메트릭을 수집하고 Monitor 작업 영역을 Azure Managed Grafana 작업 영역에 연결하도록 AKS 클러스터를 설정해야 합니다.

kubelet이 다시 시작될 때 압력이 증가하고 산발적이고 예측할 수 없는 동작이 발생합니다. 오류 수가 지속적으로 증가하지 않는지 확인합니다. 가끔 오류가 발생할 수 있지만 지속적인 증가는 조사하고 해결해야 하는 기본 문제를 나타냅니다.

5단계: NPD(노드 문제 감지기) 도구를 사용하여 노드 상태를 검사

NPD 는 노드 관련 문제를 식별하고 보고하는 데 사용할 수 있는 Kubernetes 도구입니다. 클러스터 내의 모든 노드에서 시스템 서비스로 작동합니다. CPU 사용량, 디스크 사용량 및 네트워크 연결 상태 같은 메트릭 및 시스템 정보를 수집합니다. 문제가 감지되면 NPD 도구는 이벤트 및 노드 조건에 대한 보고서를 생성합니다. AKS에서 NPD 도구는 Azure 클라우드에서 호스트되는 Kubernetes 클러스터의 노드를 모니터링하고 관리하는 데 사용됩니다. 자세한 내용은 AKS 노드의 NPD를 참조 하세요.

6단계: 디스크 IOPS(초당 디스크 I/O 작업) 제한 확인

IOPS가 제한되고 AKS 클러스터 내의 서비스 및 워크로드에 영향을 주지 않도록 하려면 다음 방법 중 하나를 사용할 수 있습니다.

AKS 노드 디스크 I/O 통합 문서

AKS 클러스터에서 작업자 노드의 디스크 I/O 관련 메트릭을 모니터링하려면 노드 디스크 I/O 통합 문서를 사용할 수 있습니다. 통합 문서에 액세스하려면 다음 단계를 수행합니다.

Azure Portal에서 AKS 클러스터로 이동합니다.
탐색 창의 모니터링 섹션에서 통합 문서를 선택합니다.
노드 디스크 IO 통합 문서를 선택합니다.
I/O 관련 메트릭을 검토합니다.

Prometheus 및 Grafana를 사용하여 클러스터 내 모니터링

AKS 클러스터에 Prometheus 및 Grafana를 배포한 경우 USE 메서드/노드 대시보드를 사용하여 클러스터 작업자 노드의 디스크 I/O에 대한 인사이트를 얻을 수 있습니다.

Prometheus 및 Azure Managed Grafana에 대한 관리되는 서비스 모니터링

노드 내보내기/노드 미리 빌드된 대시보드를 사용하여 작업자 노드에서 디스크 I/O 관련 메트릭을 시각화하고 분석할 수 있습니다. 이렇게 하려면 Prometheus용 Monitor 관리 서비스에서 Prometheus 메트릭을 수집하고 Monitor 작업 영역을 Azure Managed Grafana 작업 영역에 연결하도록 AKS 클러스터를 설정해야 합니다.

IOPS 및 Azure 디스크

물리적 스토리지 디바이스에는 대역폭 및 처리할 수 있는 최대 파일 작업 수 측면에서 내재된 제한 사항이 있습니다. Azure 디스크는 AKS 노드에서 실행되는 운영 체제를 저장하는 데 사용됩니다. 디스크에는 운영 체제와 동일한 물리적 스토리지 제약 조건이 적용됩니다.

처리량의 개념을 고려합니다. 평균 I/O 크기를 IOPS로 곱하여 처리량을 초당 메가바이트(MBps)로 확인할 수 있습니다. I/O 크기가 클수록 디스크의 고정 처리량으로 인해 IOPS가 줄어듭니다.

워크로드가 Azure 디스크에 할당된 최대 IOPS 서비스 제한을 초과하면 클러스터가 응답하지 않고 I/O 대기 상태가 될 수 있습니다. Linux 기반 시스템에서는 네트워크 소켓, CNI, Docker 및 네트워크 I/O에 의존하는 기타 서비스와 같은 많은 구성 요소가 파일로 처리됩니다. 따라서 디스크를 읽을 수 없는 경우 오류가 이러한 모든 파일로 확장됩니다.

여러 이벤트 및 시나리오는 다음을 포함하여 IOPS 제한을 트리거할 수 있습니다.

Docker I/O가 운영 체제 디스크를 공유하므로 노드에서 실행되는 컨테이너의 상당수입니다.
운영 체제 디스크에서 추가 I/O 작업을 생성할 수 있는 보안, 모니터링 및 로깅에 사용하는 사용자 지정 또는 타사 도구입니다.
노드 장애 조치(failover) 이벤트 및 워크로드를 강화하거나 Pod 수를 조정하는 정기적인 작업입니다. 이로 인해 부하가 증가하면 제한 발생 가능성이 높아져 I/O 작업이 끝날 때까지 모든 노드가 준비되지 않은 상태로 전환될 수 있습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

파올로 살바토리 | 수석 고객 엔지니어
Francis Simy Nazareth | 선임 기술 전문가

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

워크로드 배포 모니터링

노드 및 Pod 상태 검사

1단계: 작업자 노드의 상태 확인

Azure Monitor 컨테이너 상태 보기

AKS 노드 보기

Prometheus 및 Grafana를 사용하여 클러스터 내 모니터링

Prometheus 및 Azure Managed Grafana에 대한 관리되는 서비스 모니터링

2단계: 컨트롤 플레인 및 작업자 노드 연결 확인

3단계: 송신을 제한할 때 DNS 확인 유효성 검사

4단계: kubelet 오류 확인

AKS kubelet 통합 문서

Prometheus 및 Grafana를 사용하여 클러스터 내 모니터링

Prometheus 및 Azure Managed Grafana에 대한 관리되는 서비스 모니터링

5단계: NPD(노드 문제 감지기) 도구를 사용하여 노드 상태를 검사

6단계: 디스크 IOPS(초당 디스크 I/O 작업) 제한 확인

AKS 노드 디스크 I/O 통합 문서

Prometheus 및 Grafana를 사용하여 클러스터 내 모니터링

Prometheus 및 Azure Managed Grafana에 대한 관리되는 서비스 모니터링

IOPS 및 Azure 디스크

참가자

다음 단계

피드백

피드백

추가 리소스

노드 및 Pod 상태 검사

1단계: 작업자 노드의 상태 확인

Azure Monitor 컨테이너 상태 보기

AKS 노드 보기

Prometheus 및 Grafana를 사용하여 클러스터 내 모니터링

Prometheus 및 Azure Managed Grafana에 대한 관리되는 서비스 모니터링

2단계: 컨트롤 플레인 및 작업자 노드 연결 확인

3단계: 송신을 제한할 때 DNS 확인 유효성 검사

4단계: kubelet 오류 확인

AKS kubelet 통합 문서

Prometheus 및 Grafana를 사용하여 클러스터 내 모니터링

Prometheus 및 Azure Managed Grafana에 대한 관리되는 서비스 모니터링

5단계: NPD(노드 문제 감지기) 도구를 사용하여 노드 상태를 검사

6단계: 디스크 IOPS(초당 디스크 I/O 작업) 제한 확인

AKS 노드 디스크 I/O 통합 문서

Prometheus 및 Grafana를 사용하여 클러스터 내 모니터링

Prometheus 및 Azure Managed Grafana에 대한 관리되는 서비스 모니터링

IOPS 및 Azure 디스크

참가자

다음 단계

관련 참고 자료

피드백

피드백

추가 리소스