시작하기 전에

관측성 서비스를 사용하여 클러스터를 디버그하기 전에, 다음 요구 사항이 충족되는지 확인하십시오.

• 귀하의 클러스터는 IBM Cloud Monitoring 인스턴스에 연결되어 있습니다. 클러스터를 연결하려면 ‘ Red Hat OpenShift on IBM Cloud 에서 메트릭 활성화’를 참조하십시오.
• 클러스터가 IBM Cloud Logs 인스턴스에 연결되어 있습니다. 클러스터를 연결하려면 ‘로깅 활성화’를 참조하십시오.
• 귀하의 계정에 있는 IBM Cloud Monitoring 및 IBM Cloud Logs 서비스 인스턴스에 대해 최소한 ‘조회자(Viewer)’ 권한을 가지고 있습니다.

다음 명령어를 사용하여 워커 노드의 리소스 사용량을 확인하십시오. IBM Cloud Monitoring

워커 노드가 ‘ Critical ’ 또는 ‘ NotReady ’ 상태로 전환될 때, CPU 또는 메모리 사용량이 높은 것이 흔한 원인입니다. IBM Cloud Monitoring 의 사전 구축된 대시보드를 사용하여 리소스 부하를 신속하게 파악하십시오.

1. 클러스터에 대한 ‘ IBM Cloud Monitoring ’ 대시보드를 엽니다.

   1. IBM Cloud 콘솔에서 클러스터 리소스 페이지로 이동한 후 해당 클러스터를 클릭하십시오.
   2. '통합 '에서 '모니터링 ' 옵션을 찾아 '실행'을 클릭하세요. IBM Cloud Monitoring UI가 새 창에서 열립니다.

2. 다음으로 이동하세요. Kubernetes > '노드' 사전 구축 대시보드로 이동하여 노드별 CPU 및 메모리 사용량을 확인하십시오.

   • CPU 사용률 또는 메모리 사용률이 80%를 초과하는 노드를 찾아보세요. 이 임계값 이상인 노드는 과부하 상태에 빠질 위험이 있으며, 새로운 파드의 스케줄링이 실패하기 시작할 수 있습니다.
   • 지난 1시간 또는 1일 동안 CPU 또는 메모리 사용량이 갑자기 급증했거나 지속적으로 높은 수준을 유지한 노드를 찾아보세요. 이를 통해 문제가 일시적인 것인지, 아니면 지속되고 있는 것인지 파악하는 데 도움이 될 수 있습니다.

3. 특정 노드를 확인하려면 대시보드에서 해당 노드 이름을 클릭하여 모든 차트를 해당 노드로 필터링하십시오. 다음 지표를 확인해 주세요:

   • CPU 사용률(%) — 90%를 지속적으로 초과하는 값은 CPU 포화 상태를 나타냅니다.
   • 메모리 사용률(% ) — 이 수치가 지속적으로 85%를 초과하면 메모리 부족(OOM) 현상이 발생할 위험이 높아집니다.
   • 네트워크 입출력 바이트 — 예상치 못한 트래픽 급증은 워크로드가 통제 불능 상태에 빠졌거나 네트워크 공격이 발생했음을 나타낼 수 있습니다.

4. 노드에서 어떤 파드가 가장 많은 리소스를 소비하고 있는지 확인하려면 Kubernetes > 'Pods' 대시보드로 이동하여 해당 노드를 기준으로 필터링하십시오. CPU 또는 메모리 사용량이 지속적으로 높은 포드의 이름을 기록해 두십시오. 이러한 포드들이 워커 노드 불안정성의 주요 원인이 될 가능성이 높기 때문입니다.

다음 명령어를 사용하여 포드 상태와 재시작 횟수를 확인하세요. IBM Cloud Monitoring

자주 충돌 루프에 빠지거나 재시작되는 Pod는 OOM 종료나 잘못 구성된 준비 상태 확인(readiness probe)과 같은 애플리케이션 수준의 문제가 있는 흔한 징후입니다. oc get pods 를 반복해서 실행하지 않고도 IBM Cloud Monitoring 를 사용하여 이러한 포드를 식별할 수 있습니다.

1. IBM Cloud Monitoring UI에서 Kubernetes > ‘Pods’ 사전 구축 대시보드로 이동합니다.

2. '컨테이너 재시작 ' 패널을 확인하십시오. 지난 15분 동안 재시작 횟수가 0보다 큰 포드나, 더 긴 기간에 걸쳐 재시작 횟수가 급격히 증가한 포드를 찾아보세요.

   • 재시작 횟수가 계속해서 증가한다면, 이는 크래시 루프를 의미합니다. 후속 로그 조사 단계에서 사용할 수 있도록 포드 이름과 네임스페이스를 기록해 두십시오.
   • 재시작 횟수가 0이지만 상태가 ‘보류 중’ 또는 ‘알 수 없음’인 경우, 이는 애플리케이션 오류가 아닌 스케줄링 문제나 노드 연결 문제를 의미합니다.

3. 향후 포드 재시작 이벤트에 대한 알림을 설정하려면, ‘ IBM Cloud Monitoring ’ UI에서 ‘알림’ 아이콘을 클릭하고 ‘ kubernetes.pod.restart.count ’ 메트릭에 대한 메트릭 알림을 생성하세요. 어떤 포드에서든 5분 이내에 재시작 횟수가 2회를 초과할 때 트리거되도록 임계값을 설정합니다. 이를 통해 크래시 루프가 시스템에 지장을 주기 전에 미리 경고를 받을 수 있습니다. 알림 설정에 대한 자세한 내용은 ‘ IBM Cloud® Monitoring 알림 설정’을 참조하십시오

다음 명령어를 사용하여 컨테이너 로그를 조사합니다. IBM Cloud Logs

포드가 재시작되었거나 노드에 문제가 발생한 경우, 근본 원인을 파악하기 위해서는 컨테이너 로그를 검토하는 것이 필수적입니다. IBM Cloud Logs는 컨테이너가 재시작된 후 oc logs 을 통해 확인할 수 없는 과거 로그 데이터를 보관합니다.

1. IBM Cloud Logs 대시보드를 여십시오.

   1. IBM Cloud 콘솔에서 클러스터 리소스 페이지로 이동한 후 해당 클러스터를 클릭하십시오.
   2. '통합 '에서 '로깅 ' 옵션을 찾아 '실행'을 클릭하세요. IBM Cloud Logs UI가 새 창에서 열립니다.

2. 문제가 발생한 기간이 포함되도록 시간 범위를 설정하십시오. 문제가 계속되고 있다면, 범위를 지난 1시간으로 설정하세요. 과거의 사건을 조사하고 있다면, 구체적인 시작 시간과 종료 시간을 설정하여 검색 결과를 좁히세요.

3. 영향을 받은 파드 또는 네임스페이스를 검색합니다. UI 상단의 검색 창을 사용하여 로그를 필터링하세요. 예를 들어, default 네임스페이스 내의 모든 파드에서 생성된 로그를 표시하려면 다음 쿼리를 입력하세요:

   kubernetes.namespace_name:"default"
   

   이름을 지정하여 특정 포드에 대한 결과만 필터링하려면 다음을 사용하세요:

   kubernetes.pod_name:"MY_POD_NAME"
   

4. 오류 수준 항목에 대한 로그 라인을 검토하십시오. 다음과 같은 일반적인 고장 양상을 나타내는 징후가 있는지 확인하십시오:

   • OOMKilled 또는 out of memory — 컨테이너가 메모리 한도를 초과하여 커널에 의해 종료되었습니다.
   • CrashLoopBackOff — 컨테이너가 반복적으로 재시작되고 있는데, 이는 대개 시작 시 발생하는 애플리케이션 오류 때문입니다.
   • failed to pull image 또는 ImagePullBackOff — 노드가 레지스트리에서 컨테이너 이미지를 가져올 수 없습니다.
   • Connection refused 또는 context deadline exceeded — 애플리케이션이 종속 서비스나 Kubernetes API 서버에 연결할 수 없습니다.

5. OOM과 관련된 로그 항목을 발견하면, 타임스탬프를 확인한 후 IBM Cloud Monitoring Kubernetes > Pods 대시보드를 확인하여, 해당 시간대 내에서 포드의 메모리 사용량이 재시작 직전에 한도에 도달했는지 확인하십시오.

Kubernetes 의 이벤트를 다음을 통해 확인하세요. IBM Cloud Logs

Kubernetes 이벤트는 파드 스케줄링 실패, 노드 상태, 볼륨 마운트 오류와 같은 중요한 클러스터 활동을 기록합니다. IBM Cloud Logs 는 이러한 이벤트를 자동으로 수집하며, 사용자는 과거 기록을 검색하고 필터링할 수 있습니다. 반면 oc get events 는 현재 세션의 최근 이벤트만 표시합니다.

1. IBM Cloud Logs UI에서 다음 쿼리를 사용하여 클러스터 전체의 모든 Kubernetes 경고 이벤트를 표시합니다

   kubernetes.event.type:"Warning"
   

2. 특정 워커 노드의 이벤트만 필터링하려면 쿼리에 해당 노드 이름을 추가하십시오. NODE_NAME을 문제가 발생한 노드의 이름으로 바꾸십시오:

   kubernetes.event.type:"Warning" AND kubernetes.event.involvedObject.name:"NODE_NAME"
   

3. 이벤트 로그 항목의 ‘이유’ 필드를 확인하십시오. 워커 노드 및 워크로드 문제 해결에 있어 다음의 원인이 가장 관련성이 높습니다:

NodeNotReady

해당 노드가 ‘ NotReady ’ 상태를 보고하고 있습니다. 이 이벤트는 대개 워커 노드가 ‘ Critical ’ 상태로 진입하기 전이나 그와 동시에 발생합니다.

OOMKilling

커널이 메모리 부족으로 인해 해당 노드에서 프로세스를 종료했습니다.

FailedScheduling

스케줄러가 사용 가능한 노드 중 어느 곳에도 포드를 배치할 수 없었습니다. 일반적으로 메시지 필드에는 CPU나 메모리 부족, 노드 선택기 불일치 등 그 원인이 설명되어 있습니다.

BackOff

컨테이너가 크래시 루프에 빠져 있습니다. kubelet 가 컨테이너를 다시 시작하기 전에 대기 시간을 거칠 때마다 이 이벤트가 발생합니다.

FailedMount 또는 FailedAttachVolume

영구 볼륨을 마운트하거나 포드에 연결할 수 없어, 포드가 시작되지 않습니다.

1. 관련이 있어 보이는 모든 이벤트에 대해 ‘ involvedObject.name ’ 및 ‘ involvedObject.namespace ’ 값을 기록해 두고, 이를 활용하여 이전 섹션에서 수집한 로그 및 메트릭 데이터와 상호 연관성을 분석하십시오.

다음 단계

• 리소스 부족 상태에 있는 워커 노드를 확인한 경우, 해당 워커 노드를 재시작하거나 교체하거나, 해당 노드에서 실행 중인 파드의 리소스 요청량과 제한을 조정하는 것을 고려해 보십시오.
• OOM(메모리 부족)으로 인한 강제 종료로 인해 포드가 계속 충돌하는 경우, 해당 컨테이너의 메모리 제한을 늘리거나 메모리 사용량이 많은 워크로드를 더 큰 노드가 있는 워커 풀로 이동시키십시오.
• 로그에서 이미지 가져오기 실패가 확인되면, 이미지 가져오기 시크릿을 확인하고 워커 노드가 컨테이너 레지스트리에 접속할 수 있는지 확인하십시오.
• 여기에서 수집한 정보만으로는 해결할 수 없는 문제의 경우, ‘지원 사례 데이터 수집’을 참조하여 지원 티켓을 등록하는 데 필요한 정보를 수집하시기 바랍니다.

관련 링크

• 클러스터 상태 모니터링
• 시작하기 IBM Cloud Monitoring
• 시작하기 IBM Cloud Logs
• Critical 또는 NotReady 상태인 워커 노드의 문제 해결
• IBM Cloud® Monitoring 경보 설정