Kubernetes API로 작업자 노드 디버깅
클러스터에 대한 액세스 권한이 있는 경우 Node
리소스에서 Kubernetes API를 사용하여 작업자 노드를 디버그할 수 있습니다.
시작하기 전에 ** RBAC 역할에 해당하는, 클러스터의 모든 네임스페이스에 **관리자cluster-admin
서비스 액세스 역할이 있는지 확인하십시오.
-
클러스터의 작업자 노드를 나열하고
Ready
상태에 있지 않은 작업자 노드의 이름을 기록합니다. 이름은 작업자 노드의 사설 IP 주소입니다.oc get nodes
-
각 작업자 노드를 설명하고 출력의
Conditions
섹션을 검토하십시오.Type
: 작업자 노드에 영향을 줄 수 있는 조건의 유형입니다(예: 메모리 또는 디스크 압력).LastTransitionTime
: 상태가 업데이트된 최근 시간입니다. 이 시간을 사용하여 작업자 노드에 대한 문제가 시작된 시기를 식별하십시오. 이 시기를 알면 문제 해결에 도움이 될 수 있습니다.
oc describe node <name>
-
작업자 노드의 사용량을 확인하십시오.
- 이전 명령의
Allocated resources
출력에서 작업자 노드의 CPU 및 메모리 리소스를 사용하는 워크로드를 검토하십시오. 일부 팟(Pod)이 리소스 한계를 설정하지 않고 예상보다 많은 리소스를 이용하고 있음을 알 수 있습니다. 그렇다면 팟(Pod)의 리소스 사용량을 조정하십시오. - 클러스터의 작업자 노드에서 CPU 및 메모리 사용량 백분율을 검토하십시오. 사용량이 지속적으로 80%를 초과하는 경우 클러스터에 워커 노드를 더 추가하여 워크로드를 지원하세요.
- 이전 명령의
-
클러스터에 설치된 사용자 정의 승인 제어기를 확인하십시오. 승인 제어기는 종종 필수 팟(Pod) 실행을 방해하며, 이 경우 작업자 노드가 위험 상태가 될 수 있습니다. 사용자 정의 승인 제어기가 있는 경우
oc delete
를 사용하여 제거를 시도하십시오. 그런 다음 작업자 노드 문제가 해결되었는지 확인하십시오.kubectl get mutatingwebhookconfigurations --all-namespaces
kubectl get validatingwebhookconfigurations --all-namespaces
-
로그 전달을 구성한 경우 다음 경로에서 노드 관련 로그를 검토하십시오.
/var/log/kubelet.log /var/log/syslog /var/log/messages
-
워크로드 배치로 인해 작업자 노드 문제가 발생하지 않는지 확인하십시오.
- 문제로 작업자 노드를 오염시키십시오.
oc taint node NODEIP ibm-cloud-debug-isolate-customer-workload=true:NoExecute
- 5단계에서 설명한 대로 사용자 정의 승인 제어기를 삭제했는지 확인하십시오.
- 작업자 노드를 다시 시작하십시오.
- 클래식: 작업자 노드를 다시 로드하십시오.
ibmcloud oc worker reload -c <cluster_name_or_ID> --worker <worker_ID>
- VPC: 작업자 노드를 대체하십시오.
ibmcloud oc worker replace -c <cluster_name_or_ID> --worker <worker_ID> --update
- 클래식: 작업자 노드를 다시 로드하십시오.
- 작업자 노드가 다시 시작을 완료할 때까지 기다리십시오. 작업자 노드가 정상 상태가 되면 워크로드에 의해 문제가 발생할 수 있습니다.
- 문제의 원인이 되는 워크로드를 보려면 작업자 노드에 한 번에 하나의 워크로드를 스케줄하십시오. 워크로드를 스케줄하려면 다음 결함 허용을 추가하십시오.
tolerations: - effect: NoExecute key: ibm-cloud-debug-isolate-customer-workload operator: Exists
- 문제의 원인이 되는 워크로드를 식별한 후 앱 배치 디버깅을 계속하십시오.
- 문제로 작업자 노드를 오염시키십시오.