7.8.3. 애플리케이션 오류 조사를 위한 애플리케이션 진단 데이터 수집

프로세스

1. 특정 애플리케이션 Pod와 관련된 이벤트를 나열합니다. 다음 예에서는 my-app-1-akdlg라는 애플리케이션 Pod의 이벤트를 검색합니다.

   $ oc describe pod/my-app-1-akdlg

2. 애플리케이션 Pod에서 로그를 검토합니다.

   $ oc logs -f pod/my-app-1-akdlg

3. 실행 중인 애플리케이션 Pod 내에서 특정 로그를 쿼리합니다. stdout으로 전송되는 로그는 OpenShift Logging 프레임 워크에서 수집되며 위의 명령의 출력에 포함됩니다. 다음 쿼리는 stdout으로 전송되지 않은 로그에만 필요합니다.

   1. Pod 내에서 루트 권한 없이 애플리케이션 로그에 액세스할 수 있는 경우 다음과 같이 로그 파일을 연결합니다.

      $ oc exec my-app-1-akdlg -- cat /var/log/my-application.log

   2. 애플리케이션 로그를 보기 위해 root 액세스가 필요한 경우 root 권한으로 디버그 컨테이너를 시작한 다음 컨테이너 내에서 로그 파일을 볼 수 있습니다. 프로젝트의 DeploymentConfig 개체에서 디버그 컨테이너를 시작합니다. 일반적으로 Pod 사용자는 루트 이외의 권한으로 실행되지만 임시 루트 권한으로 문제 해결 Pod를 실행하면 문제 해결에 유용할 수 있습니다.

      $ oc debug dc/my-deployment-configuration --as-root -- cat /var/log/my-application.log

      참고

      -- <command>를 추가하지 않고 oc debug dc/<deployment_configuration> --as-root를 실행하면 디버그 Pod에서 루트 액세스 권한으로 대화형 쉘에 액세스할 수 있습니다.

4. 대화형 쉘이 있는 애플리케이션 컨테이너에서 대화형으로 애플리케이션 기능을 테스트하고 진단 도구를 실행합니다.

   1. 애플리케이션 컨테이너에서 대화형 쉘을 시작합니다.

      $ oc exec -it my-app-1-akdlg /bin/bash

   2. 쉘에서 대화형으로 애플리케이션 기능을 테스트합니다. 예를 들어 컨테이너의 엔트리 포인트 명령을 실행하고 결과를 확인할 수 있습니다. 그런 다음 S2I 프로세스를 통해 소스 코드를 업데이트하고 애플리케이션 컨테이너를 다시 빌드하기 전에 명령 줄에서 직접 변경 사항을 테스트합니다.

   3. 컨테이너에서 사용 가능한 진단 바이너리를 실행합니다.

      참고

      일부 진단 바이너리를 실행하려면 root 권한이 필요합니다. 이러한 상황에서는 oc debug dc/<deployment_configuration> --as-root를 실행하여 문제가 있는 Pod의 DeploymentConfig 개체에 따라 루트 액세스 권한으로 디버그 Pod를 시작할 수 있습니다. 그런 다음 디버그 Pod 내에서 루트로 진단 바이너리를 실행할 수 있습니다.

5. 컨테이너 내에서 진단 바이너리를 사용할 수 없는 경우 nsenter를 사용하여 컨테이너의 네임 스페이스에서 호스트의 진단 바이너리를 실행할 수 있습니다. 다음 예제는 호스트의 IP 바이너리를 사용하여 컨테이너의 네임 스페이스에서 ip ad를 실행합니다.

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

      $ oc debug node/my-cluster-node

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

      # chroot /host

      참고

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

   3. 대상 컨테이너 ID를 확인합니다.

      # crictl ps

   4. 컨테이너의 프로세스 ID를 확인합니다. 이 예에서 대상 컨테이너 ID는 a7fe32346b120입니다.

      # crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'

   5. 호스트의 ip 바이너리를 사용하여 컨테이너의 네임 스페이스에서 ip ad를 실행합니다. 이 예에서는 컨테이너의 프로세스 ID로 31150을 사용합니다. nsenter 명령은 대상 프로세스의 네임 스페이스를 입력하고 네임 스페이스에서 명령을 실행합니다. 이 경우 대상 프로세스는 컨테이너의 프로세스 ID이므로 ip ad 명령은 호스트의 컨테이너 네임 스페이스에서 실행됩니다.

      # nsenter -n -t 31150 -- ip ad

      참고

      컨테이너의 네임 스페이스 에서 호스트의 진단 바이너리를 실행하는 것은 디버그 노드와 같은 권한 있는 컨테이너를 사용하는 경우에만 가능합니다.