7.8. Source-to-Image 프로세스 문제 해결

1. 빌드 구성 단계에서 빌드 Pod는 기본 이미지 및 애플리케이션 소스 코드에서 애플리케이션 컨테이너 이미지를 만드는 데 사용됩니다.
2. 배포 구성 단계에서 배포 Pod는 빌드 구성 단계에서 빌드된 애플리케이션 컨테이너 이미지에서 애플리케이션 Pod를 배포하는 데 사용됩니다. 배포 Pod는 서비스 및 경로와 같은 다른 리소스도 배포합니다. 배포 구성은 빌드 구성이 성공한 후에 시작됩니다.
3. 배포 Pod에서 애플리케이션 Pod를 시작한 후 실행 중인 애플리케이션 Pod 내에서 애플리케이션 오류가 발생할 수 있습니다. 예를 들어 애플리케이션 Pod가 Running 상태인 경우에도 애플리케이션이 예상대로 작동하지 않을 수 있습니다. 이 시나리오에서는 실행 중인 애플리케이션 Pod에 액세스하여 Pod 내의 애플리케이션 오류를 조사할 수 있습니다.

1. 빌드, 배포 및 애플리케이션 Pod 상태 모니터링
2. 문제가 발생한 S2I 프로세스 단계 확인
3. 실패한 단계에 해당하는 로그 확인

프로세스

1. S2I 프로세스 전체에서 Pod의 상태를 확인하고 오류가 발생하는 단계를 확인합니다.

   $ oc get pods -w  1

   1

   Ctrl+C를 사용하여 명령을 종료할 때까지 -w를 사용하여 Pod의 변경 사항을 모니터링합니다.

2. 실패한 Pod 로그에서 오류가 있는지 확인합니다.

   • 빌드 Pod가 실패하면 빌드 Pod의 로그를 검토합니다.

     $ oc logs -f pod/<application_name>-<build_number>-build

     참고

     또는 oc logs -f bc/<application_name>을 사용하여 빌드 구성의 로그를 확인할 수 있습니다. 빌드 구성의 로그에는 빌드 Pod의 로그가 포함됩니다.

   • 배포 Pod가 실패하면 배포 Pod의 로그를 검토합니다.

     $ oc logs -f pod/<application_name>-<build_number>-deploy

     참고

     또는 oc logs -f dc/<application_name>을 사용하여 배포 구성의 로그를 확인할 수 있습니다. 이렇게 하면 배포 Pod가 성공적으로 완료될 때까지 배포 Pod의 로그가 출력됩니다. 이 명령을 배포 Pod가 완료된 후 실행하면 애플리케이션 Pod에서 로그를 출력합니다. 배포 Pod가 완료된 후에도 oc logs -f pod/<application_name>-<build_number>-deploy를 실행하여 로그에 계속 액세스할 수 있습니다.

   • 애플리케이션 Pod가 실패하거나 애플리케이션이 실행 중인 애플리케이션 Pod 내에서 예상대로 작동하지 않으면 애플리케이션 Pod의 로그를 확인합니다.

     $ oc logs -f pod/<application_name>-<build_number>-<random_string>

프로세스

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

      참고

      RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 OpenShift Container Platform 4.17 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않습니다. 그러나 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

      참고

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