Critical
또는 NotReady
상태의 작업자 노드 문제점 해결
클러스터 작업자 노드가 클러스터 마스터와의 통신을 중지하면 Critical
또는 NotReady
상태가 됩니다. 이 경우 작업자 노드는 IBM Cloud UI에서 또는 ibmcloud ks worker
명령을 실행할 때 Critical
로 표시되고 Kubernetes 대시보드에서 및 kubectl get nodes
를
실행할 때 NotReady
로 표시됩니다. 작업자 노드와 클러스터 마스터 간에 통신이 중지되는 몇 가지 이유가 있습니다. 다음 단계에 따라 이러한 상태의 작업자 노드에 대한 문제점을 해결하십시오.
IBM Cloud 상태 대시보드에서 작업자 노드와 관련된 알림 또는 유지보수 업데이트를 확인하십시오. 이러한 알림 또는 업데이트는 작업자 노드 실패의 원인을 판별하는 데 도움이 될 수 있습니다.
작업자 노드 실패의 공통 원인 확인
작업자 노드와 클러스터 마스터 간에 통신이 중지되는 몇 가지 이유가 있습니다. 다음 공통 문제가 중단의 원인인지 확인하십시오.
- 작업자가 삭제, 다시 로드, 업데이트, 대체 또는 재부팅되었습니다.
- 작업자 노드는 삭제, 다시 로드, 업데이트 또는 대체될 때 임시로
Critical
또는NotReady
상태를 표시할 수 있습니다. 수동으로 또는 클러스터 오토스케일러와 같은 자동화 설정의 일부로 작업자 노드에서 이러한 조치가 시작된 경우 조치가 완료될 때까지 기다리십시오. 그런 다음 작업자 노드의 상태를 다시 확인하십시오. 작업자가Critical
또는NotReady
상태로 남아 있는 경우, 영향을 받는 작업자를 다시 로드 하거나 교체 하십시오. - 작업자 노드가 다시 로드되거나 대체되었고 처음에 올바르게 작동하지만 일정 시간 후에
Critical
또는NotReady
상태가 되면 작업자의 일부 워크로드 또는 컴포넌트가 문제의 원인이 될 수 있습니다. 문제점 워크로드를 분리하려면 작업자 노드 디버깅 을 참조하십시오.
작업자 노드가 먼저 손상 및 드레인되지 않고 다시 부팅된 경우 Critical
또는 NotReady
상태가 될 수 있습니다. 이 경우 재부팅이 완료될 때까지 대기해도 문제가 해결되지 않습니다. 영향을 받는 작업자를 다시 로드 하거나 대체 하십시오. 문제가 지속되면 문제점 해결 단계를 계속하십시오.
- 작업자 노드의 전원이 의도하지 않게 꺼짐
- 클래식 클러스터IBM Cloud 콘솔 리소스 목록에서 클래식 인프라의 작업자 노드는 컴퓨팅 리소스또는 가상 머신으로 분류됩니다. 때때로 사용자는 이러한 리소스가 클러스터
작업자 노드로 작동하는 것을 인식하지 못할 수 있으며 의도하지 않게 작업자 노드의 전원을 차단할 수 있습니다. 전원이 꺼진 작업자 노드는
Critical
또는NotReady
상태로 표시될 수 있습니다. 영향을 받는 작업자 노드의 전원이 꺼지지 않았는지 확인하십시오.
문제점 해결 단계
공통 원인 을 해결한 후에도 작업자 노드가 Critical
또는 NotReady
상태로 남아 있는 경우 다음 문제점 해결 단계를 계속하십시오.
ibmcloud ks workers
를 실행할 때 이전에 다시 로드하거나 대체한 작업자 노드가 deploy_failed
또는 provision_failed
상태인 경우 모든 노드가 영향을 받지 않는 경우에도 클러스터의 모든 작업자 노드가 영향을 받음 섹션의 단계를 따르십시오. 다른
상태가 표시되는 경우 새 작업자의 문제점을 해결하는 단계는 작업자 노드 상태 를 참조하십시오. 추가 작업자 노드를 대체하거나 다시 로드하지 마십시오.
하나 이상의 작업자 노드가 영향을 받는 경우
클러스터에 있는 작업자 노드의 전부가 아닌 일부만 Critical
또는 NotReady
상태인 경우 다음 단계를 수행하여 중단의 원인을 판별하고 문제를 해결하십시오. 영향을 받는 작업자 노드가 모두 동일한 구역, 서브넷 또는 VLAN의 노드인 경우 다음 섹션으로 계속 진행하십시오.
-
특정 노드에 대한 세부 정보를 가져옵니다.
kubectl describe node <node-IP-address>
-
출력에서 조건 섹션을 확인하여 노드에 메모리, 디스크 또는 PID 문제가 있는지 판별하십시오. 이 정보는 노드가 해당 유형의 자원에서 낮은 상태로 실행 중임을 표시할 수 있습니다. 이 상황은 다음 중 한 가지 이유로 발생할 수 있습니다:
- 팟 (Pod) 에 대한 적절한 요청 및 한계가 부족하여 발생하는 메모리 또는 CPU 소모입니다.
- 작업자 디스크는 노드 자체에 대한 대형 팟 (Pod) 로그 또는 팟 (Pod) 출력으로 인해 가득 찼습니다.
- 시간이 지남에 따라 빌드되는 느린 메모리 누수로 인해 한 달 이상 업데이트되지 않은 작업자에게 문제가 발생할 수 있습니다.
- Linux 커널에 영향을 주는 버그 및 충돌입니다.
-
조건 섹션의 정보에서 문제의 원인을 판별할 수 있는 경우 작업자 노드 디버깅 의 단계에 따라 문제점 워크로드를 분리하십시오.
-
이전 단계에서 문제가 해결되지 않으면 영향을 받는 작업자를 한 번에 하나씩 다시 로드 하거나 대체 하십시오.
작업자 노드의 일부 (전부는 아님) 가 Critical
또는 NotReady
상태에 자주 진입하는 경우 작업자 자동 복구 를 사용으로 설정하여 이러한 복구 단계를 자동화하는 것을 고려하십시오.
단일 구역, 서브넷 또는 VLAN의 모든 작업자 노드가 영향을 받는 경우
한 영역, 서브넷 또는 VLAN의 모든 작업자 노드가 Critical
또는 NotReady
상태이지만 클러스터의 다른 모든 작업자 노드가 정상적으로 작동하는 경우 네트워킹 구성 요소에 문제가 있는 것일 수 있습니다. 클러스터의 모든 작업자 노드가 영향을 받는 경우, 특히 방화벽 또는 게이트웨이 규칙,
ACL 또는 사용자 정의 라우트 또는 Calico 및 Kubernetes 네트워크 정책과 같이 구역, 서브넷 또는 VLAN에 영향을 줄 수 있는 네트워킹 컴포넌트에 관한 단계를 따르십시오.
네트워킹 컴포넌트를 확인했지만 여전히 문제를 해결할 수 없는 경우 작업자 노드 데이터를 수집 하고 지원 티켓을 여십시오.
클러스터의 모든 작업자 노드가 영향을 받는 경우
클러스터의 모든 작업자 노드가 동시에 Critical
또는 NotReady
를 표시하는 경우, 클러스터 apiserver
또는 작업자와 apiserver
간의 네트워킹 경로에 문제가 있을 수 있습니다. 다음 문제점 해결 단계에 따라 원인을 판별하고 문제를 해결하십시오.
일부 단계는 네트워킹 또는 자동화와 같은 특수 영역에 특정합니다. 이러한 단계를 완료하기 전에 조직의 관련 관리자 또는 팀에 문의하십시오.
-
작업자 노드에 영향을 줄 수 있는 클러스터, 환경 또는 계정에 대한 최신 변경사항이 있는지 확인하십시오. 그런 경우 변경사항을 되돌리고 작업자 노드 상태를 확인하여 변경사항으로 인해 문제가 발생했는지 판별하십시오.
- 클래식 클러스터의 경우 클러스터 작업자의 트래픽을 관리하는 방화벽 또는 게이트웨이 (예: Virtual Router Appliance, Vyatta 또는 Juniper) 를 확인하십시오. 클러스터 작업자의 트래픽을 삭제하거나 경로 재지정할 수 있는 변경사항 또는 문제를 찾으십시오.
- VPC 클러스터의 경우, VPC 또는 작업자 노드에서 기본 보안 그룹 및 ACL이 변경되었는지 확인하십시오. 수정사항이 작성된 경우 클러스터 작업자 노드에서 클러스터 마스터, 컨테이너 레지스트리 및 기타 중요 서비스로의 모든 필수 트래픽을 허용하는지 확인하십시오. 자세한 정보는 VPC 보안 그룹으로 트래픽 제어 및 ACL로 트래픽 제어 를 참조하십시오.
- VPC 클러스터의 경우 클러스터
apiserver
의 트래픽을 차단할 수 있는 변경사항에 대한 사용자 정의 라우팅 규칙을 확인하십시오. - 클러스터에 적용되는 Calico 또는 Kubernetes 네트워크 정책을 확인하고 작업자 노드에서 클러스터
apiservice
, 컨테이너 레지스트리 또는 기타 중요 서비스로의 트래픽을 차단하지 않는지 확인하십시오.
-
클러스터의 애플리케이션, 보안 또는 모니터링 컴포넌트가 요청으로 클러스터
apiserver
에 과부하를 발생시키는지 확인하십시오. 이로 인해 작업자 노드가 중단될 수 있습니다. -
최근에 클러스터에 구성요소를 추가한 경우 해당 구성요소를 제거하십시오. 클러스터의 기존 컴포넌트를 변경한 경우 변경사항을 되돌리십시오. 그런 다음 작업자 노드의 상태를 확인하여 새 컴포넌트 또는 변경사항으로 인해 문제가 발생했는지 확인하십시오.
-
apiserver
요청을 방해하거나 작업자 노드가apiserver
에 연결하는 기능을 차단할 수 있는 클러스터 웹훅의 변경사항을 확인하십시오. 요청을 거부하는 웹훅이 있는지 확인합니다. 다음 명령을 실행하여 요청을 거부하는 웹훅 목록을 가져옵니다.kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
-
'
rejected="true"
' 상태인 웹훅의 출력을 검토합니다. -
워커 노드의 상태를 확인합니다.
Normal
상태에 있는 경우 작업자 노드 중단의 원인이 되는 구성 또는 컴포넌트를 판별할 수 있을 때까지 삭제된 컴포넌트를 다시 추가하고 되돌린 변경사항을 하나씩 다시 작성하십시오. -
문제가 여전히 해결되지 않으면 작업자 노드 데이터 수집 단계를 수행하고 지원 티켓을 여십시오.
작업자 노드가 정상 상태와 위험 상태 사이에서 전환되는 경우
작업자 노드가 Normal
및 Critical
또는 NotReady
상태 사이에서 전환되는 경우 다음 컴포넌트에서 작업자 노드를 방해할 수 있는 문제 또는 최근 변경사항을 확인하십시오.
-
클래식 클러스터의 경우 방화벽 또는 게이트웨이를 확인하십시오. 대역폭 한계 또는 오작동 유형이 있는 경우 문제를 해결하십시오. 그런 다음 작업자 노드를 다시 확인하십시오.
-
클러스터의 애플리케이션, 보안 또는 모니터링 컴포넌트가 요청으로 클러스터
apiserver
에 과부하를 발생시키는지 확인하십시오. 이로 인해 작업자 노드가 중단될 수 있습니다. -
최근에 클러스터에 구성요소를 추가한 경우 해당 구성요소를 제거하십시오. 클러스터의 기존 컴포넌트를 변경한 경우 변경사항을 되돌리십시오. 그런 다음 작업자 노드의 상태를 확인하여 새 컴포넌트 또는 변경사항으로 인해 문제가 발생했는지 확인하십시오.
-
apiserver
요청을 방해하거나 작업자 노드가apiserver
에 연결하는 기능을 차단할 수 있는 클러스터 웹훅의 변경사항을 확인하십시오. 요청을 거부하는 웹훅이 있는지 확인합니다. 다음 명령을 실행하여 요청을 거부하는 웹훅 목록을 가져옵니다.kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
-
'
rejected="true"
' 상태인 웹훅의 출력을 검토합니다. -
문제가 여전히 해결되지 않으면 작업자 노드 데이터 수집 단계를 수행하고 지원 티켓을 여십시오.
지원 케이스에 대한 데이터 수집
문제점 해결 단계에서 문제를 해결할 수 없는 경우 작업자 노드에 대한 정보를 수집하십시오. 그런 다음 지원 티켓을 열고 수집한 작업자 노드 정보를 포함시키십시오.
지원 티켓을 열기 전에 정보를 검토하고 작업자 노드 디버깅, 작업자 노드 상태 및 Critical
또는 NotReady
상태의 작업자 노드 문제점 해결 의 문제점 해결 단계를 따르십시오.
클러스터의 모든 작업자 노드 또는 하나의 리전, 서브넷 또는 VLAN이 영향을 받는 경우에는 데이터를 수집하지 않고도 초기 지원 티켓을 열 수 있습니다. 그러나 나중에 관련 데이터를 수집하도록 요청받을 수 있습니다. 작업자 노드 중 하나 또는 일부만 영향을 받는 경우 지원 티켓에 포함할 관련 데이터를 수집해야 합니다.
시작하기 전에
데이터를 수집하기 전에 작업자 노드 및 클러스터의 조건을 확인하십시오.
-
노드의 CPU및 메모리 레벨을 확인하십시오. CPU 또는 메모리 사용량에서 노드가 80%를 초과하는 경우 더 많은 노드를 프로비저닝하거나 워크로드를 줄이는 것을 고려하십시오.
kubectl top node
출력 예
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% 10.001.1.01 640m 16% 6194Mi 47% 10.002.2.02 2686m 68% 4024Mi 30% 10.003.3.03 2088m 53% 10735Mi 81%
-
apiserver
요청을 방해하거나 작업자 노드가apiserver
에 연결하는 기능을 차단할 수 있는 클러스터 웹훅의 변경사항을 확인하십시오. 요청을 거부하는 웹훅이 있는지 확인합니다. 다음 명령을 실행하여 요청을 거부하는 웹훅 목록을 가져옵니다.kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
-
'
rejected="true"
' 상태인 웹훅의 출력을 검토합니다.
데이터 수집 중
단계에 따라 관련 작업자 노드 데이터를 수집하십시오.
-
각 노드의 세부사항을 가져오십시오. 지원 티켓에 포함할 출력 세부사항을 저장하십시오.
kubectl describe node <node-ip-address>
-
진단 및 디버그 도구 를 실행하십시오. kube및 네트워크 테스트 결과를 압축 파일로 내보내고 지원 티켓에 포함할 파일을 저장하십시오. 클러스터의 모든 작업자가 영향을 받는 경우 모든 작업자 노드가 중단되면 디버그 도구가 제대로 작동할 수 없으므로 이 단계를 건너뛸 수 있습니다.
-
웹훅 세부사항을 가져와서 클러스터에 남아 있는 웹훅을 변형하거나 유효성 검증하는 추가된 웹훅이 없음을 표시합니다. 지원 티켓에 포함할 명령 출력을 저장하십시오.
alertmanagerconfigs.openshift
,managed-storage-validation-webhooks
,multus.openshift.io
,performance-addon-operator
,prometheusrules.openshift.io
,snapshot.storage.k8s.io
와 같이 변형된 웹훅이 남아 있을 수 있으며 삭제할 필요가 없습니다.kubectl get mutatingwebhookconfigurations
kubectl get validatingwebhookconfigurations
-
클래식 클러스터: 영향을 받는 작업자 중 하나의 KVM 콘솔에 액세스하십시오. 그런 다음 관련 로그 및 출력을 수집하십시오.
-
단계에 따라 KVM 콘솔 에 액세스하십시오.
-
다음 로그를 수집하여 저장하십시오. 작업자 노드 중단의 가능한 원인 (예: 메모리 또는 디스크 공간 부족, 디스크가 읽기 전용 모드로 전환됨 및 기타 문제) 에 대한 로그를 검토하십시오.
- /var/log/containerd.log
- /var/log/kern.log
- /var/log/kube-proxy.log
- /var/log/syslog
- /var/log/kubelet.log
-
다음 명령을 실행하고 출력을 저장하여 지원 티켓에 첨부하십시오.
ps -aux
# 덤프 실행 프로세스df -H
# 디스크 사용량 정보 덤프vmstat
# 메모리 사용량 정보 덤프lshw
# 하드웨어 정보 덤프last -Fxn2 shutdown reboot
# 마지막 다시 시작이 정상인지 여부 판별mount | grep -i "(ro"
# 디스크 읽기 전용 문제를 제외합니다. 참고:tmpfs
진행 중ro
은 양호합니다.touch /this
# 디스크 읽기 전용 문제 제외
-
-
VPC 클러스터: 다음 예제와 같이
kubectl top
명령을 사용하여 워커 노드에서 리소스 사용량을 수집합니다.kubectl top nodes
예제 출력은 CPU 사용량(밀리코어(m))과 메모리 사용량(메가바이트(Mi))을 보여줍니다.
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% k8s-node-1 250m 12% 800Mi 40% k8s-node-2 180m 9% 600Mi 30% k8s-node-3 250m 22% 700Mi 50%
- 이름
- 노드 이름입니다.
- CPU(코어)
- 현재 CPU 사용량(밀리코어(m) 단위)입니다. 1000m 1코어에 해당합니다.
- CPU%
- 노드에서 사용된 총 CPU 용량의 백분율입니다.
- 메모리(바이트)
- MiB (메가바이트) 또는 GiB (기가바이트)의 현재 메모리 사용량입니다.
- 메모리 %
- 사용된 총 메모리 용량의 백분율입니다.
CPU% 또는 MEMORY%(80% 이상)가 높은 노드는 과부하가 걸리고 추가 리소스가 필요할 수 있습니다. CPU% 또는 메모리%(20% 미만)가 낮은 노드는 활용도가 낮을 수 있으며, 이는 워크로드 재분배의 여지가 있음을 나타냅니다. 노드가 CPU 또는 메모리 사용량이 100%에 도달하면 새 워크로드가 예약에 실패하거나 성능 저하가 발생할 수 있습니다.
-
다음 명령을 사용하여 파드에서 리소스 사용량을 수집합니다.
kubectl top pods --all-namespaces
출력 예
NAMESPACE NAME CPU(cores) MEMORY(bytes) default my-app-564bc58dad-hk5gn 120m 256Mi default my-db-789d9c6c4f-tn7mv 300m 512Mi
- 이름
- 팟(Pod)의 이름입니다.
- CPU(코어)
- 모든 컨테이너에서 파드가 사용하는 총 CPU입니다.
- 메모리(바이트)
- 모든 컨테이너에서 파드가 사용하는 총 메모리입니다.
파드의 CPU 사용량이 많으면 성능에 영향을 주는 CPU 스로틀링이 발생하고 있을 수 있습니다. 파드의 메모리 사용량이 한계에 가까워지면 Kubernetes 에서 메모리를 확보하기 위해 프로세스를 종료하는 OOM(메모리 부족) 오류가 발생할 위험이 있습니다. 리소스 사용량이 적은 파드는 요청이 과도하게 할당되어 리소스가 낭비될 수 있습니다.
-
top pod
명령을 실행하여 컨테이너 수준 메트릭을 확인합니다.kubectl top pod pod-a --containers -n appns ```sh {: pre} Example output ```sh NAME CONTAINER CPU(cores) MEMORY(bytes) pod-a app-container 100m 300Mi pod-a db-container 50m 200Mi ```sh {: screen}
-
kubectl top
명령은 요청된 리소스나 제한된 리소스가 아닌 실제 사용량만 표시합니다.top
명령의 출력을 비교 및 분석하려면 다음 명령을 사용하여 파드 사양을 확인합니다.kubectl describe pod <pod-name> -n <namespace>
출력 예
Containers: app-container: Requests: cpu: 250m memory: 512Mi Limits: cpu: 500m memory: 1Gi
CPU 또는 메모리 사용량이 요청을 초과하는 경우 프로비저닝이 부족하여 성능 문제가 발생할 수 있습니다. 사용량이 제한에 가까워지면 리소스가 제한되면 컨테이너가 스로틀되거나 종료될 수 있습니다. 사용량이 요청보다 현저히 낮으면 파드가 오버프로비저닝되어 리소스가 낭비될 수 있습니다.
-
어떤 파드가 가장 많은 CPU를 소비하는지 파악합니다.
kubectl top pod --all-namespaces | sort -k3 -nr | head -10
-
메모리를 많이 사용하는 파드를 식별합니다.
kubectl top pod --all-namespaces | sort -k4 -nr | head -10
-
시스템 데몬 리소스 사용량을 모니터링합니다. DaemonSets,
kube-proxy
또는 모니터링 에이전트 등 예기치 않은 리소스를 사용할 수 있습니다.kubectl top pod -n kube-system ```sh {: pre}
-
특정 시스템 파드가 과도한 CPU 또는 메모리를 사용하는 경우 튜닝 요청 및 제한이 필요할 수 있습니다. 리소스 변경 사항을 지속적으로 추적하려면
watch
명령을 사용하세요.watch -n 5 kubectl top pod --all-namespaces ```sh {: pre} This command updates the output every 5 seconds, helping to spot spikes or anomalies in resource usage.
-
OOMKilled
이벤트를 확인하세요. Kubernetes 이OOMKilled
을 보고하면 파드가 메모리 제한을 초과하여 종료되었습니다. 파드의 상태가crashloopbackoff
로 변경됩니다.kubectl get events --field-selector involvedObject.name=your-pod-name -n your-namespace
-
로그에서
OOM
메시지를 찾습니다.kubectl logs your-pod-name -n your-namespace | grep -i "out of memory"
-
컨테이너의 마지막 상태(
OOM
종료)를 확인합니다.kubectl describe pod your-pod-name -n your-namespace | grep -A 10 "Last State"
워커 노드 로그 수집
단계에 따라 워커에 액세스하여 워커 노드 로그를 수집합니다.
-
다음 로그 파일을 수집하여 저장합니다. 작업자 노드 중단의 가능한 원인 (예: 메모리 또는 디스크 공간 부족, 디스크가 읽기 전용 모드로 전환됨 및 기타 문제) 에 대한 로그를 검토하십시오.
/var/log/containerd.log
/var/log/kern.log
/var/log/kube-proxy.log
/var/log/syslog
/var/log/kubelet.log
-
다음 명령을 실행하고 출력을 저장하여 지원 티켓에 첨부하십시오.
컨테이너 통계 가져오기(노드에 대한 SSH 액세스 권한 필요).
crictl stats
특정 컨테이너에 대한 자세한 통계를 확인하세요.
crictl stats --id <container-id> --output json
실행 중인 프로세스를 덤프하려면 명령을 실행합니다.
ps -aux
실행 중인 프로세스와 커널 관리 작업은 물론 CPU 및 메모리 사용량을 포함한 리소스 사용률을 실시간으로 동적으로 확인할 수 있습니다.
top
현재 시스템 상태를 가져옵니다.
htop
과거 데이터가 포함된 종합적인 모니터링 보고서를 받아보세요.
atop
시스템 프로세스에 대한 실시간 정보를 확인하세요.
btop
네트워크 연결 세부 정보를 확인합니다.
netstat
디스크 사용량 정보를 얻습니다.
df -H
vmstat
을 실행하여 프로세스, 메모리, 페이징, 블록 IO, 트랩 및 CPU 활동에 대한 보고서를 확인하세요. 이 명령은 2초 간격으로 5회 정보를 가져옵니다.vmstat 2 5
iostat
을 실행하여 처리량, 사용률, 대기열 길이, 트랜잭션 속도 등을 포함한 디스크 사용량 통계를 수집하세요.iostat -x 1 5
하드웨어 정보를 수집합니다.
lshw
아래 명령을 사용하여 마지막 재시작이 정상적으로 이루어졌는지 여부를 확인할 수 있습니다.
last -Fxn2 shutdown reboot
디스크 문제를 배제하려면 디스크가 쓰기 가능한지 확인합니다.
mount | grep -i "(ro" touch /this
-
문제가 지속되면 지원 티켓을 열고 이전 단계에서 저장한 모든 결과물을 첨부하세요.