1단계: 작업자 노드 상태 가져오기

클러스터가 위험, 삭제에 실패함 또는 경고 상태이거나 오랜 기간 동안 보류 중 상태에 있으면 작업자 노드의 상태를 검토하십시오.

ibmcloud oc worker ls --cluster CLUSTER_NAME_OR_ID

2단계: 작업자 노드 상태 검토

CLI 출력의 모든 작업자 노드에 대한 상태(State 및 Status) 필드를 검토하십시오.

자세한 정보는 작업자 노드 상태를 참조하십시오.

3단계: 각 작업자 노드에 대한 세부사항을 가져오기

작업자 노드의 세부사항을 가져오십시오. 세부사항에 오류 메시지가 포함되는 경우 작업자 노드에 대한 일반 오류 메시지의 목록을 검토하여 문제점 해결 방법을 알아보십시오.

ibmcloud oc worker get --cluster CLUSTER_NAME_OR_ID --worker WORKER_NODE_ID

4단계: 작업자 노드에 대한 인프라 제공자 검토

인프라 환경을 검토하여 작업자 노드 문제를 일으킬 수 있는 기타 이유를 확인하십시오.

1. 방화벽 또는 서브넷 업데이트와 같은 최신 유지보수가 작업자 노드 연결에 영향을 줄 수 없는지 확인하려면 네트워킹 팀을 확인하십시오.
2. 리뷰 IBM Cloud 다음에 대한 Red Hat OpenShift on IBM Cloud 및 기본 인프라 제공업체(예: Virtual Servers 클래식, VPC 관련 구성 요소의 경우, 또는 Satellite.
3. 기본 인프라(예: 클래식 가상 서버)에 대한 액세스 권한이 있는 경우, 작업자 노드의 해당 시스템에 대한 세부사항을 검토하십시오.

5단계: 워커 노드에 대한 로그 및 기타 세부 정보 수집하기

must-gather 명령 실행

oc adm must-gather CLI 명령은 문제 디버깅을 위해 클러스터에서 정보를 수집합니다. 필수 수집 도구는 리소스 정의, 서비스 로그 등을 수집합니다. 파일 크기를 줄이기 위해 감사 로그는 기본 정보 집합의 일부로 수집되지 않습니다.

oc adm must-gather 을 실행하면 클러스터의 새 프로젝트에 임의의 이름을 가진 새 파드가 만들어집니다. 데이터는 해당 포드에서 수집되어 must-gather.local 로 시작하는 새 디렉터리에 저장됩니다.

다음 예제 명령어를 살펴보세요.

oc adm must-gather

예제 하나 이상의 특정 기능과 관련된 데이터를 수집하려면 특정 이미지와 함께 --image 인수를 사용합니다.

oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

감사 로그를 수집하는 명령의 예입니다.

oc adm must-gather -- /usr/bin/gather_audit_logs

특정 네임스페이스에서 must-gather를 실행하는 명령 예시입니다.

oc adm must-gather --run-namespace NAMESPACE \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

지정된 시간의 로그를 수집하는 명령어 예시입니다.

oc adm must-gather --since=24h

oc adm must-gather --since-time=$(date -d '-24 hours' +%Y-%m-%dT%T.%9N%:z )

네트워크 로그를 수집하는 명령 예시.

oc adm must-gather -- gather_network_logs

더 많은 예제와 인수를 보려면 다음 명령을 실행하세요

oc adm must-gather -h

필수 수집 디렉터리에서 압축 파일을 생성하는 명령 예제입니다.

tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/

지원 케이스에 압축 파일을 첨부하세요.

SOS 보고서 수집

sosreport 는 Red Hat Enterprise Linux (RHEL) 및 Red Hat Enterprise Linux CoreOS (RHCOS) 시스템에서 구성 세부 정보, 시스템 정보 및 진단 데이터를 수집하는 도구입니다. 노드와 관련된 진단 정보를 수집하는 표준화된 방법을 제공하여 문제 진단을 위한 지원팀에 제공할 수 있습니다.

일부 지원 상호작용에서 지원팀은 특정 OpenShift Container Platform 노드에 대한 sosreport 아카이브를 수집하도록 요청할 수 있습니다. 예를 들어 oc adm must-gather 의 출력에 포함되지 않은 시스템 로그 또는 기타 노드별 데이터를 검토해야 할 수 있습니다.

sosreport 를 수집하는 방법은 워커 노드의 운영 체제에 따라 다릅니다. RHCOS 노드는 toolbox 명령을 사용합니다. RHEL 8 및 RHEL 9 노드는 toolbox``을 지원하지 않으므로, 대신 Red Hat sosreport 스크립트를 사용하십시오.

OpenShift Container Platform 클러스터 노드에 대해 sosreport 를 생성하는 권장 방법은 디버그 파드를 사용하는 것입니다.

Red Hat OpenShift 클러스터에 액세스하십시오.

1. 작업자 노드 목록을 제시하여 대상 노드와 해당 노드의 운영 체제를 확인하십시오.

   oc get nodes -o wide
   

   sosreport 를 수집할 워커 노드의 이름을 기록해 두십시오. OS-IMAGE 열은 해당 노드가 RHCOS를 실행하는지, 아니면 RHEL을 실행하는지를 나타냅니다.

2. 대상 노드에서 디버그 세션을 시작합니다.

   oc debug node/node_name
   

   NoExecute 효과로 오염된 대상 노드에서 디버그 세션에 들어가려면 임시 네임스페이스에 톨러레이션을 추가하고 임시 네임스페이스에서 디버그 파드를 시작하세요.

   oc new-project temp oc patch namespace temp --type=merge -p '{"metadata": {"annotations": { "scheduler.alpha.kubernetes.io/defaultTolerations": "[{\"operator\": \"Exists\"}]"}}}'
   

   oc debug node/my-cluster-node
   

3. 디버그 셸 내에서 /host 을 루트 디렉터리로 설정합니다. 디버그 포드는 호스트의 루트 파일 시스템을 포드 내부의 /host 에 마운트합니다. 루트 디렉터리를 /host 로 변경하면, 호스트의 실행 파일 경로에 포함된 바이너리 파일을 실행할 수 있습니다.

   chroot /host
   

   OpenShift Container Platform Red Hat Enterprise LinuxCoreOS (RHCOS)를 실행하는 클러스터 노드는 불변이며, 클러스터 변경 사항을 적용하기 위해 오퍼레이터에 의존합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장하지 않습니다. 그러나 OpenShift Container Platform API가 사용 불가능하거나 대상 노드에서 kubelet이 제대로 작동하지 않을 경우, oc operations에 영향을 미칠 수 있습니다. 이러한 상황에서는 대신 ssh core@NODE.CLUSTER_NAME.BASE_DOMAIN 을 사용하여 노드에 액세스할 수 있습니다.

4. 워커 노드의 운영 체제에 맞는 방법을 사용하여 sosreport 를 수집하십시오.

   • RHCOS 노드 : toolbox 명령을 사용하십시오.

     1. sosreport 을 실행하는 데 필요한 바이너리와 플러그인이 포함된 도구 상자 컨테이너를 시작합니다. toolbox 명령어는 RHCOS 노드에서만 지원됩니다.

        toolbox
        

        기존 도구 상자 파드가 이미 실행 중인 경우, 도구 상자 명령은 'toolbox-' already exists. Trying to start…. podman rm toolbox- 으로 실행 중인 도구 상자 컨테이너를 제거하고 새 도구 상자 컨테이너를 시작합니다.

     2. sos report 명령을 실행하고 메시지에 따라 문제 해결 데이터를 수집합니다.

        sos report -k crio.all=on -k crio.logs=on -k podman.all=on -k podman.logs=on
        

        보고서에 노드의 OVN- Kubernetes 네트워킹 구성에 대한 정보를 포함하는 명령의 예입니다.

        sos report --all-logs
        

        sosreport 출력 결과에는 아카이브의 위치와 체크섬이 표시됩니다. 다음 샘플 출력 참조는 지원 사례 ID 01234567. 툴박스 컨테이너가 호스트의 루트 디렉터리를 /host 에 마운트하기 때문에, 해당 파일 경로는 chroot 환경 밖에 위치합니다.

        Your sosreport has been generated and saved in:
        /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz
        The checksum is: 382ffc167510fd71b4f12a4f40b97a4e
        

   • RHEL 8 및 RHEL 9 노드 : RHEL 노드에서는 toolbox 명령어가 지원되지 않습니다. 대신 Red Hat 의 sosreport 수집 스크립트를 사용하십시오.

     1. Red Hat 지식 기반 문서에 있는 지침에 따라 Red Hat 의 sosreport 스크립트를 다운로드하여 실행하십시오.

     2. 스크립트의 안내에 따라 문제 해결 데이터를 수집하십시오. 스크립트 출력에서 생성된 아카이브 파일의 위치를 확인하십시오.

5. sosreport 을 파일로 출력합니다.

   디버그 컨테이너는 호스트의 루트 디렉터리를 /host 경로에 마운트합니다. 연결할 대상 파일을 지정할 때는 /host 를 포함하여 디버그 컨테이너의 루트 디렉터리에서 시작하는 절대 경로를 참조하십시오.

   oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz' > /tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz
   

   OpenShift Container Platform Red Hat Enterprise LinuxCoreOS (RHCOS)를 실행하는 클러스터 노드는 불변이며, 클러스터 변경 사항을 적용하기 위해 오퍼레이터에 의존합니다. scp 을 사용하여 클러스터 노드에서 sosreport 아카이브를 전송하는 것은 권장되지 않습니다. 그러나 OpenShift Container Platform API가 사용 불가능하거나 대상 노드에서 kubelet이 제대로 작동하지 않을 경우 작업에 차질이 oc 발생할 수 있습니다. 이러한 상황에서는 scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path> 을 실행하여 노드에서 sosreport 아카이브를 복사할 수 있습니다.

6. 지원 케이스에 파일을 업로드하세요.