5.4. OpenShift Container Platform 클러스터 노드의 sosreport 아카이브 생성

프로세스

1. 클러스터 노드 목록을 가져옵니다.

   $ oc get nodes

2. 대상 노드에서 디버그 세션으로 들어갑니다. 이 단계는 <node_name>-debug라는 디버그 Pod를 인스턴스화합니다.

   $ oc debug node/my-cluster-node

   NoExecute 효과로 테인트된 대상 노드에서 디버그 세션에 들어가려면 더미 네임스페이스에 허용 오차를 추가하고 더미 네임스페이스에서 디버그 Pod를 시작합니다.

   $ oc new-project dummy

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

   $ oc debug node/my-cluster-node

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

   # chroot /host

   참고

   RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 OpenShift Container Platform 4.9 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않으며 노드는 accessed 테인트로 표시됩니다. 그러나 OpenShift Container Platform API를 사용할 수 없거나 kubelet이 대상 노드에서 제대로 작동하지 않는 경우 oc 작업이 영향을 받습니다. 이러한 상황에서 대신 ssh core @ <node>.<cluster_name>.<base_domain>을 사용하여 노드에 액세스할 수 있습니다.

4. sosreport 를 실행하는 데 필요한 바이너리 및 플러그인이 포함된 toolbox 컨테이너를 시작합니다.

   # toolbox

   참고

   기존 toolbox Pod가 이미 실행 중인 경우 toolbox 명령은 'toolbox-' already exists를 출력합니다. Trying to start…​를 출력합니다. podman rm toolbox-에서 실행중인 toolbox 컨테이너를 제거하고 새 toolbox 컨테이너를 생성하여 sosreport 플러그인 문제를 방지합니다.

5. sosreport 아카이브를 수집합니다.

   1. sosreport 명령을 실행하고 crio.all 및 crio.logs CRI-O 컨테이너 엔진 sosreport 플러그인을 활성화합니다.

      # sosreport -k crio.all=on -k crio.logs=on 1

      1

      -k 를 사용하면 기본값 외부에서 sosreport 플러그인 매개 변수를 정의할 수 있습니다.

   2. 프롬프트가 표시되면 Enter를 눌러 계속 진행합니다.
   3. Red Hat 지원 사례 ID를 제공합니다. sosreport는 아카이브의 파일 이름에 ID를 추가합니다.

   4. sosreport 출력은 아카이브의 위치와 체크섬을 제공합니다. 다음 예에서는 케이스 ID 01234567을 참조합니다.

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

      1

      toolbox 컨테이너가 호스트의 root 디렉토리를 /host에 마운트하기 때문에 sosreport 아카이브의 파일 경로는 chroot 환경 외부에 있습니다.

6. 다음 방법 중 하나를 사용하여 분석을 위해 Red Hat 지원에 sosreport 아카이브를 제공합니다.

   • OpenShift Container Platform 클러스터에서 직접 기존 Red Hat 지원 케이스에 파일을 업로드합니다.

     1. toolbox 컨테이너 내에서 redhat-support-tool 을 실행하여 기존 Red Hat 지원 케이스에 아카이브를 직접 연결합니다. 이 예에서는 지원 사례 ID 01234567을 사용합니다.

        # redhat-support-tool addattachment -c 01234567 /host/var/tmp/my-sosreport.tar.xz 1

        1

        toolbox 컨테이너는 /host에 호스트의 root 디렉토리를 마운트합니다. redhat-support-tool 명령에 업로드할 파일을 지정할 때 /host/를 포함하여 toolbox 컨테이너의 root 디렉토리에서 절대 경로를 참조합니다.

   • 기존 Red Hat 지원 케이스에 파일을 업로드합니다.

     1. oc debug node/<node_name> 명령을 실행하여 sosreport 아카이브를 연결하고 출력을 파일로 리디렉션합니다. 이 명령은 이전 oc debug 세션을 종료했다고 가정합니다.

        $ 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 1

        1

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

        참고

        RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 OpenShift Container Platform 4.9 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. scp를 사용하여 클러스터 노드에서 sosreport 아카이브를 전송하는 것은 권장되지 않으며 노드는 accessed된 테인트로 표시됩니다. 그러나 OpenShift Container Platform API를 사용할 수 없거나 kubelet이 대상 노드에서 제대로 작동하지 않는 경우 oc 작업이 영향을 받습니다. 이러한 상황에서는 scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path>를 실행하여 노드에서 sosreport 아카이브를 복사할 수 있습니다.

     2. https://access.redhat.com/support/cases/ 내에서 기존 지원 케이스로 이동합니다.
     3. Attach files를 선택하고 메시지에 따라 파일을 업로드합니다.