Menu Close
Settings Close

Language and Page Formatting Options

7장. 문제 해결

7.1. 설치 문제 해결

7.1.1. 설치 문제가 발생하는 위치 확인

OpenShift Container Platform 설치 문제를 해결할 때 설치 로그를 모니터링하여 문제가 발생하는 단계를 확인할 수 있습니다. 그런 다음 해당 단계와 관련된 진단 데이터를 검색합니다.

OpenShift Container Platform 설치는 다음 단계에 따라 진행됩니다.

  1. Ignition 구성 파일이 생성됩니다.
  2. 부트스트랩 머신이 부팅되고 컨트롤 플레인 머신 (마스터 미신 이라고도 함)을 부팅하는 데 필요한 원격 리소스 호스팅이 시작됩니다.
  3. 컨트롤 플레인 머신은 부트스트랩 머신에서 원격 리소스를 가져오고 부팅을 완료합니다.
  4. 컨트롤 플레인 머신은 부트스트랩 머신을 사용하여 etcd 클러스터를 만듭니다.
  5. 부트스트랩 머신은 새로운 etcd 클러스터를 사용하여 임시 Kubernetes 컨트롤 플레인을 시작합니다.
  6. 임시 컨트롤 플레인은 프로덕션 컨트롤러 플레인을 컨트롤 플레인 머신에 예약합니다.
  7. 임시 컨트롤 플레인이 종료되고 제어를 프로덕션 컨트롤 플레인에 전달합니다.
  8. 부트스트랩 머신은 OpenShift Container Platform 구성 요소를 프로덕션 컨트롤 플레인에 추가합니다.
  9. 설치 프로그램이 부트 스트랩 머신을 종료합니다.
  10. 컨트롤 플레인이 작업자 노드를 설정합니다.
  11. 컨트롤 플레인은 일련의 Operator 형태로 추가 서비스를 설치합니다.
  12. 클러스터는 지원되는 환경에서 작업자 머신 생성을 포함하여 일상적인 작업에 필요한 나머지 구성 요소를 다운로드하고 구성합니다.

7.1.2. 사용자 프로비저닝 인프라 설치 고려 사항

기본 설치 방법은 설치 프로그램에서 프로비저닝한 인프라를 사용하는 것입니다. 설치 프로그램에서 프로비저닝한 인프라 클러스터를 통해 OpenShift Container Platform은 운영 체제 자체를 포함하여 클러스터의 모든 측면을 관리합니다. 가능하면 이 기능을 사용하여 클러스터 인프라를 프로비저닝 및 유지 관리의 부담을 덜 수 있습니다.

사용자가 제공하는 인프라에 OpenShift Container Platform 4.6을 설치할 수도 있습니다. 이 설치 방법을 사용하는 경우 사용자가 제공하는 인프라 설치 설명서를 주의 깊게 따르십시오. 또한 설치 전에 다음 고려 사항을 확인하십시오.

  • RHEL (Red Hat Enterprise Linux) Ecosystem을 확인하고 선택한 서버 하드웨어 또는 가상화 기술에 대해 제공되는 RHCOS (Red Hat Enterprise Linux CoreOS) 지원 수준을 결정합니다.
  • 많은 가상화 및 클라우드 환경에서는 게스트 운영 체제에 에이전트를 설치해야 합니다. 이러한 에이전트가 데몬 세트를 통해 배포되는 컨테이너화된 워크로드로 설치되어 있는지 확인합니다.
  • 동적 스토리지, 온디맨드 서비스 라우팅, 노드 호스트 이름을 Kubernetes 호스트 이름으로 확인, 클러스터 자동 스케일링과 같은 기능을 사용하려면 클라우드 공급자 통합을 설치합니다.

    참고

    서로 다른 클라우드 공급자의 리소스를 결합하거나 여러 물리적 또는 가상 플랫폼에 걸쳐있는 OpenShift Container Platform 환경에서는 클라우드 공급자 통합을 활성화할 수 없습니다. 노드 라이프 사이클 컨트롤러는 기존 공급자 외부에 있는 노드를 클러스터에 추가하는 것을 허용하지 않으며 둘 이상의 클라우드 공급자 통합을 지정할 수 없습니다.

  • 머신 세트 또는 자동 스케일링을 사용하여 OpenShift Container Platform 클러스터 노드를 자동으로 프로비저닝하려면 공급자별 Machine API를 구현해야 합니다.
  • 선택한 클라우드 공급자가 초기 배포의 일부로 Ignition 구성 파일을 호스트에 삽입하는 방법을 제공하는지 확인합니다. 제공하지 않는 경우 HTTP 서버를 사용하여 Ignition 구성 파일을 호스팅해야합니다. Ignition 구성 파일의 문제 해결 단계는 이 두 가지 방법 중 배포되는 방법에 따라 달라집니다.
  • 포함된 컨테이너 레지스트리, Elasticsearch 또는 Prometheus와 같은 선택적 프레임워크 구성 요소를 활용하려면 스토리지를 수동으로 프로비저닝해야 합니다. 이를 명시적으로 구성하지 않는 한 기본 스토리지 클래스는 사용자 프로비저닝 인프라 설치에 정의되지 않습니다.
  • 고가용성 OpenShift Container Platform 환경의 모든 컨트롤 플레인 노드 (마스터 노드라고도 함)에 API 요청을 분산하려면 로드 밸런서가 필요합니다. OpenShift Container Platform DNS 라우팅 및 포트 요구 사항을 충족하는 모든 TCP 기반 부하 분산 솔루션을 사용할 수 있습니다.

7.1.3. OpenShift Container Platform 설치 전에 로드 밸런서 구성 확인

OpenShift Container Platform 설치를 시작하기 전에 로드 밸런서 구성을 확인하십시오.

사전 요구 사항

  • OpenShift Container Platform 설치를 준비하기 위해 선택한 외부로드 밸런서를 구성하고 있어야 합니다. 다음 예에서는 HAProxy를 사용하여 클러스터에 로드 밸런싱 서비스를 제공하는 Red Hat Enterprise Linux (RHEL) 호스트를 기반으로합니다.
  • OpenShift Container Platform 설치를 준비하기 위해 DNS를 구성하고 있어야 합니다.
  • 로드 밸런서에 SSH 액세스 권한이 있어야합니다.

프로세스

  1. haproxy systemd 서비스가 활성화되어 있는지 확인합니다.

    $ ssh <user_name>@<load_balancer> systemctl status haproxy
  2. 로드 밸런서가 필요한 포트에서 수신하고 있는지 확인합니다. 다음 예에서는 포트 80, 443, 6443, 22623을 참조합니다.

    • RHEL (Red Hat Enterprise Linux) 6에서 실행되는 HAProxy 인스턴스의 경우 netstat 명령을 사용하여 포트 상태를 확인합니다.

      $ ssh <user_name>@<load_balancer> netstat -nltupe | grep -E ':80|:443|:6443|:22623'
    • RHEL (Red Hat Enterprise Linux) 7 또는 8에서 실행되는 HAProxy 인스턴스의 경우 ss 명령을 사용하여 포트 상태를 확인합니다.

      $ ssh <user_name>@<load_balancer> ss -nltupe | grep -E ':80|:443|:6443|:22623'
      참고

      Red Hat은 RHEL (Red Hat Enterprise Linux) 7 이상에서 netstat 대신 ss 명령을 권장합니다. ss는 iproute 패키지에서 제공합니다. ss 명령에 대한 자세한 내용은 Red Hat Enterprise Linux (RHEL) 7 성능 조정 가이드를 참조하십시오.

  3. 와일드 카드 DNS 레코드가 로드 밸런서로 해결되어 있는지 확인합니다.

    $ dig <wildcard_fqdn> @<dns_server>

7.1.4. OpenShift Container Platform 설치 프로그램 로그 수준 지정

기본적으로 OpenShift Container Platform 설치 프로그램 로그 수준은 info로 설정됩니다. 실패한 OpenShift Container Platform 설치를 진단할 때 보다 자세한 로깅이 필요한 경우 다시 설치를 시작할 때 openshift-install 로그 수준을 debug로 높일 수 있습니다.

사전 요구 사항

  • 설치 호스트에 대한 액세스 권한이 있어야 합니다.

프로세스

  • 설치를 시작할 때 debug로 설치 로그 수준을 설정합니다.

    $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete --log-level debug  1
    1
    가능한 로그 수준에는 info, warn, error, debug가 있습니다.

7.1.5. openshift-install 명령 문제 해결

openshift-install 명령을 실행하는데 문제가 있는 경우 다음을 확인하십시오.

  • 설치는 Ignition 구성 파일 생성 후 24 시간 이내에 시작되고 있습니다. 다음 명령을 실행하면 Ignition 파일이 생성됩니다.

    $ ./openshift-install create ignition-configs --dir=./install_dir
  • install-config.yaml 파일은 설치 프로그램과 동일한 디렉토리에 있습니다. ./openshift-install --dir 옵션을 사용하여 대체 설치 경로를 선언한 경우 해당 디렉토리에 install-config.yaml 파일이 있는지 확인합니다.

7.1.6. 설치 진행 상황 모니터링

OpenShift Container Platform 설치가 진행됨에 따라 상위 수준 설치, 부트 스트랩 및 컨트롤 플레인 로그를 모니터링할 수 있습니다. 이렇게 하면 설치 진행 방식에 대한 가시성이 향상되고 설치 실패가 발생하는 단계를 식별할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 호스트에 대한 SSH 액세스 권한이 있어야 합니다.
  • 부트 스트랩 및 컨트롤 플레인 노드 (마스터 노드라고도 함)의 정규화된 도메인 이름이 있어야 합니다.

    참고

    초기 kubeadmin 암호는 설치 호스트의 <install_directory>/auth/kubeadmin-password에서 찾을 수 있습니다.

프로세스

  1. 설치가 진행되는 동안 설치 로그를 모니터링합니다.

    $ tail -f ~/<installation_directory>/.openshift_install.log
  2. 부트스트랩 노드에서 bootkube.service journald 장치 로그를 모니터링합니다. 이를 통해 첫 번째 컨트롤 플레인의 부트 스트랩을 시각화할 수 있습니다. <bootstrap_fqdn>을 부트 스트랩 노드의 정규화된 도메인 이름으로 바꿉니다.

    $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service
    참고

    부트스트랩 노드의 bootkube.service 로그는 etcd connection rejectd 오류를 출력하고 부트스트랩 서버가 컨트롤 플레인 노드의 etcd에 연결할 수 없음을 나타냅니다. 각 컨트롤 플레인 노드에서 etcd를 시작하고 노드가 클러스터에 가입되면 오류가 중지됩니다.

  3. 컨트롤 플레인 노드가 부팅된 후 kubelet.service journald 장치 로그를 모니터링합니다. 이를 통해 컨트롤 플레인 노드 에이전트 활동을 시각화할 수 있습니다.

    1. oc를 사용하여 로그를 모니터링합니다.

      $ oc adm node-logs --role=master -u kubelet
    2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다. <master-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service
  4. 컨트롤 플레인 노드가 부팅된 후 crio.service journald 장치 로그를 모니터링합니다. 이를 통해 컨트롤 플레인 노드 CRI-O 컨테이너 런타임 활동을 시각화할 수 있습니다.

    1. oc를 사용하여 로그를 모니터링합니다.

      $ oc adm node-logs --role=master -u crio
    2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다. <master-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

      $ ssh core@master-N.cluster_name.sub_domain.domain journalctl -b -f -u crio.service

7.1.7. 부트 스트랩 노드 진단 데이터 수집

부트 스트랩 관련 문제가 발생하면 부트 스트랩 노드에서 bootkube.service journald 장치 로그 및 컨테이너 로그를 수집할 수 있습니다.

사전 요구 사항

  • 부트 스트랩 노드에 대한 SSH 액세스 권한이 있어야 합니다.
  • 부트 스트랩 노드의 정규화된 도메인 이름이 있어야 합니다.
  • HTTP 서버를 사용하여 Ignition 구성 파일을 호스팅하는 경우 HTTP 서버의 정규화된 도메인 이름과 포트 번호가 있어야합니다. 또한 HTTP 호스트에 대한 SSH 액세스 권한이 있어야합니다.

프로세스

  1. 부트 스트랩 노드의 콘솔에 액세스할 경우 노드가 로그인 프롬프트에 도달할 때까지 콘솔을 모니터링합니다.
  2. Ignition 파일 구성을 확인합니다.

    • HTTP 서버를 사용하여 Ignition 구성 파일을 호스팅하는 경우:

      1. 부트 스트랩 노드 Ignition 파일 URL을 확인합니다. <http_server_fqdn>을 HTTP 서버의 정규화된 도메인 이름으로 바꿉니다.

        $ curl -I http://<http_server_fqdn>:<port>/bootstrap.ign  1
        1
        -I 옵션은 헤더만 반환합니다. 지정된 URL에서 Ignition 파일을 사용할 수있는 경우 명령은 200 OK 상태를 반환합니다. 사용할 수없는 경우 명령은 404 file not found를 반환합니다.
      2. 부트 스트랩 노드에서 Ignition 파일을 수신했는지 확인하려면 제공 호스트에서 HTTP 서버 로그를 쿼리합니다. 예를 들어 Apache 웹 서버를 사용하여 Ignition 파일을 제공하는 경우 다음 명령을 입력합니다.

        $ grep -is 'bootstrap.ign' /var/log/httpd/access_log

        부트 스트랩 Ignition 파일이 수신되면 연결된 HTTP GET 로그 메시지에 요청이 성공했음을 나타내는 200 OK 성공 상태가 포함됩니다.

      3. Ignition 파일이 수신되지 않은 경우 Ignition 파일이 존재하고 제공 호스트에 대한 적절한 파일 및 웹 서버 권한이 있는지 직접 확인합니다.
    • 클라우드 공급자 메커니즘을 사용하여 초기 배포의 일부로 호스트에 Ignition 구성 파일을 삽입하는 경우:

      1. 부트 스트랩 노드의 콘솔을 확인하고 부트 스트랩 노드 Ignition 파일을 삽입하는 메커니즘이 올바르게 작동하고 있는지 확인합니다.
  3. 부트 스트랩 노드에 할당된 저장 장치의 가용성을 확인합니다.
  4. 부트 스트랩 노드에 DHCP 서버의 IP 주소가 할당되었는지 확인합니다.
  5. 부트 스트랩 노드에서 bootkube.service journald 장치 로그를 수집합니다. <bootstrap_fqdn>을 부트 스트랩 노드의 정규화된 도메인 이름으로 바꿉니다.

    $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service
    참고

    부트스트랩 노드의 bootkube.service 로그는 etcd connection rejectd 오류를 출력하고 부트스트랩 서버가 컨트롤 플레인 노드 (마스터 노드라고도 함)의 etcd에 연결할 수 없음을 나타냅니다. 각 컨트롤 플레인 노드에서 etcd를 시작하고 노드가 클러스터에 가입되면 오류가 중지됩니다.

  6. 부트 스트랩 노드 컨테이너에서 로그를 수집합니다.

    1. 부트 스트랩 노드에서 podman 을 사용하여 로그를 수집합니다. <bootstrap_fqdn>을 부트 스트랩 노드의 정규화된 도메인 이름으로 바꿉니다.

      $ ssh core@<bootstrap_fqdn> 'for pod in $(sudo podman ps -a -q); do sudo podman logs $pod; done'
  7. 부트 스트랩 프로세스가 실패한 경우 다음을 확인하십시오.

    • 설치 호스트에서 api.<cluster_name>.<base_domain>을 확인할 수 있습니다.
    • 로드 밸런서는 부트 스트랩 및 컨트롤 플레인 노드에 포트 6443 연결을 프록시합니다. 프록시 구성이 OpenShift Container Platform 설치 요구 사항을 충족하는지 확인합니다.

7.1.8. 컨트롤 플레인 노드 설치 문제 조사

컨트롤 플레인 노드(마스터 노드라고도 함) 설치에 문제가 발생하는 경우 컨트롤 플레인 노드, OpenShift Container Platform 소프트웨어 정의 네트워크 (SDN) 및 네트워크 Operator의 상태를 확인합니다. kubelet.service, crio.service journald 장치 로그 및 컨트롤 플레인 노드 컨테이너 로그를 수집하여 컨트롤 플레인 노드 에이전트, CRI-O 컨테이너 런타임, Pod 활동에 대한 가시성을 확보합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 호스트에 대한 SSH 액세스 권한이 있어야 합니다.
  • 부트 스트랩 및 컨트롤 플레인 노드의 완전한 도메인 이름이 있어야 합니다.
  • HTTP 서버를 사용하여 Ignition 구성 파일을 호스팅하는 경우 HTTP 서버의 정규화된 도메인 이름과 포트 번호가 있어야합니다. 또한 HTTP 호스트에 대한 SSH 액세스 권한이 있어야합니다.

    참고

    초기 kubeadmin 암호는 설치 호스트의 <install_directory>/auth/kubeadmin-password에서 찾을 수 있습니다.

절차

  1. 컨트롤 플레인 노드의 콘솔에 액세스할 경우 노드가 로그인 프롬프트에 도달할 때 까지 콘솔을 모니터링합니다. 설치 중에 Ignition 로그 메시지가 콘솔에 출력됩니다.
  2. Ignition 파일 설정을 확인합니다.

    • HTTP 서버를 사용하여 Ignition 구성 파일을 호스팅하는 경우:

      1. 컨트롤 플레인 노드의 Ignition 파일 URL을 확인합니다. <http_server_fqdn>을 HTTP 서버의 정규화된 도메인 이름으로 바꿉니다.

        $ curl -I http://<http_server_fqdn>:<port>/master.ign  1
        1
        -I 옵션은 헤더만 반환합니다. 지정된 URL에서 Ignition 파일을 사용할 수있는 경우 명령은 200 OK 상태를 반환합니다. 사용할 수없는 경우 명령은 404 file not found를 반환합니다.
      2. Ignition 파일이 컨트롤 플레인 노드에서 수신되었는지 확인하려면 제공 호스트에서 HTTP 서버 로그를 쿼리합니다. 예를 들어 Apache 웹 서버를 사용하여 Ignition 파일을 제공하는 경우 다음을 확인합니다.

        $ grep -is 'master.ign' /var/log/httpd/access_log

        마스터 Ignition 파일이 수신되면 연결된 HTTP GET 로그 메시지에 요청이 성공했음을 나타내는 200 OK 성공 상태가 포함됩니다.

      3. Ignition 파일이 수신되지 않은 경우 제공 호스트에 존재하는지 확인합니다. 적절한 파일 및 웹 서버 권한이 있는지 확인합니다.
    • 클라우드 공급자 메커니즘을 사용하여 초기 배포의 일부로 호스트에 Ignition 구성 파일을 삽입하는 경우:

      1. 컨트롤 플레인 노드의 콘솔을 확인하고 컨트롤 플레인 노드의 Ignition 파일을 삽입하는 메커니즘이 올바르게 작동하고 있는지 확인합니다.
  3. 컨트롤 플레인 노드에 할당된 스토리지 장치의 가용성을 확인합니다.
  4. 컨트롤 플레인 노드에 DHCP 서버의 IP 주소가 지정되었는지 확인합니다.
  5. 컨트롤 플레인 노드 상태를 확인합니다.

    1. 컨트롤 플레인 노드 상태를 쿼리합니다.

      $ oc get nodes
    2. 컨트롤 플레인 노드 중 하나가 Ready 상태에 도달하지 않으면 자세한 노드 설명을 검색합니다.

      $ oc describe node <master_node>
      참고

      설치 문제로 인해 OpenShift Container Platform API가 실행되지 않거나 kubelet이 각 노드에서 실행되지 않는 경우 oc 명령을 실행할 수 없습니다.

  6. OpenShift Container Platform SDN의 상태를 확인합니다.

    1. openshift-sdn 네임스페이스에서 sdn-controller, sdn, ovs 데몬 세트 상태를 검토합니다.

      $ oc get daemonsets -n openshift-sdn
    2. 해당 리소스가 Not found로 나열되어 있는 경우 openshift-sdn 네임스페이스의 Pod를 검토합니다.

      $ oc get pods -n openshift-sdn
    3. openshift-sdn 네임스페이스에서 실패한 OpenShift Container Platform SDN Pod에 대한 로그를 검토합니다.

      $ oc logs <sdn_pod> -n openshift-sdn
  7. 클러스터의 네트워크 구성 상태를 확인합니다.

    1. 클러스터의 네트워크 구성이 존재하는지 확인합니다.

      $ oc get network.config.openshift.io cluster -o yaml
    2. 설치 프로그램이 네트워크 구성을 만드는 데 실패한 경우 Kubernetes 매니페스트를 다시 생성하고 메시지 출력을 확인합니다.

      $ ./openshift-install create manifests
    3. openshift-network-operator 네임스페이스에서 Pod 상태를 검토하고 CNO(Cluster Network Operator)가 실행 중인지 확인합니다.

      $ oc get pods -n openshift-network-operator
    4. openshift-network-operator 네임스페이스에서 네트워크 Operator Pod 로그를 수집합니다.

      $ oc logs pod/<network_operator_pod_name> -n openshift-network-operator
  8. 컨트롤 플레인 노드가 부팅된 후 kubelet.service journald 장치 로그를 모니터링합니다. 이를 통해 컨트롤 플레인 노드 에이전트 활동을 시각화할 수 있습니다.

    1. oc를 사용하여 로그를 검색합니다.

      $ oc adm node-logs --role=master -u kubelet
    2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다. <master-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service
      참고

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

  9. 컨트롤 플레인 노드가 부팅 된 후 crio.service journald 장치 로그를 검색합니다. 이를 통해 컨트롤 플레인 노드 CRI-O 컨테이너 런타임 활동을 시각화할 수 있습니다.

    1. oc를 사용하여 로그를 검색합니다.

      $ oc adm node-logs --role=master -u crio
    2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service
  10. 컨트롤 플레인 노드의 /var/log/ 아래에있는 특정 하위 디렉터리에서 로그를 수집합니다.

    1. /var/log/ 하위 디렉토리에 포함된 로그 목록을 검색합니다. 다음 예제는 모든 컨트롤 플레인 노드의 /var/log/openshift-apiserver/에 있는 파일을 나열합니다.

      $ oc adm node-logs --role=master --path=openshift-apiserver
    2. /var/log/ 하위 디렉터리 내의 특정 로그를 확인합니다. 다음 예제는 모든 컨트롤 플레인 노드에서 /var/log/openshift-apiserver/audit.log 내용을 출력합니다.

      $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log
    3. API가 작동하지 않는 경우 SSH를 사용하여 각 노드의 로그를 확인합니다. 다음은 /var/log/openshift-apiserver/audit.log 예제입니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log
  11. SSH를 사용하여 컨트롤 플레인 노드 컨테이너 로그를 확인합니다.

    1. 컨테이너를 나열합니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps -a
    2. crictl를 사용하여 컨테이너의 로그를 검색합니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>
  12. 컨트롤 플레인 노드 구성 문제가 발생하는 경우 MCO, MCO 엔드 포인트 및 DNS 레코드가 작동하는지 확인합니다. MCO (Machine Config Operator)는 설치 시 운영 체제 구성을 관리합니다. 또한 시스템 클럭의 정확성과 인증서의 유효성을 확인하합니다.

    1. MCO 엔드 포인트를 사용할 수 있는지 테스트합니다. <cluster_name>을 적절한 값으로 바꿉니다.

      $ curl https://api-int.<cluster_name>:22623/config/master
    2. 엔드 포인트가 응답하지 않는 경우 로드 밸런서 구성을 확인합니다. 엔드 포인트가 포트 22623에서 실행되도록 구성되었는지 확인합니다.
    3. MCO 엔드 포인트의 DNS 레코드가 구성되어 로드 밸런서 문제를 해결하고 있는지 확인합니다.

      1. 정의된 MCO 엔드 포인트 이름에 대한 DNS 조회를 실행합니다.

        $ dig api-int.<cluster_name> @<dns_server>
      2. 로드 밸런서에서 할당된 MCO IP 주소에 대한 역방향 조회를 실행합니다.

        $ dig -x <load_balancer_mco_ip_address> @<dns_server>
    4. MCO가 부트 스트랩 노드에서 직접 작동하는지 확인합니다. <bootstrap_fqdn>을 부트 스트랩 노드의 정규화된 도메인 이름으로 바꿉니다.

      $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/master
    5. 시스템 클럭은 부트 스트랩, 마스터 및 작업자 노드 간에 동기화되어야 합니다. 각 노드의 시스템 클럭 참조 시간 및 시간 동기화 통계를 확인합니다.

      $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking
    6. 인증서의 유효성을 확인합니다.

      $ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

7.1.9. etcd 설치 문제 조사

설치 중에 etcd 문제가 발생하면 etcd Pod 상태를 확인하고 etcd Pod 로그를 수집할 수 있습니다. etcd DNS 레코드를 확인하고 컨트롤 플레인 (마스터 노드라고도 함)에서 DNS 가용성을 확인할 수도 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 호스트에 대한 SSH 액세스 권한이 있어야 합니다.
  • 컨트롤 플레인 노드의 정규화된 도메인 이름이 있어야 합니다.

절차

  1. etcd Pod의 상태를 확인합니다.

    1. openshift-etcd 네임스페이스에서 Pod 상태를 검토합니다.

      $ oc get pods -n openshift-etcd
    2. openshift-etcd-operator 네임스페이스에서 Pod 상태를 검토합니다.

      $ oc get pods -n openshift-etcd-operator
  2. 이전 명령으로 나열된 Pod 중 Running 또는 Completed 상태가 표시되지 않는 경우 Pod의 진단 정보를 수집합니다.

    1. Pod의 이벤트를 검토합니다.

      $ oc describe pod/<pod_name> -n <namespace>
    2. Pod의 로그를 검사합니다.

      $ oc logs pod/<pod_name> -n <namespace>
    3. Pod에 여러 컨테이너가 있는 경우 위의 명령에서 오류가 생성되고 컨테이너 이름이 오류 메시지에 제공됩니다. 각 컨테이너의 로그를 검사합니다.

      $ oc logs pod/<pod_name> -c <container_name> -n <namespace>
  3. API가 작동하지 않는 경우 대신 SSH를 사용하여 각 컨트롤 플레인 노드에서 etcd Pod 및 컨테이너 로그를 검토합니다. <master-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

    1. 각 컨트롤 플레인 노드에 etcd Pod를 나열합니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods --name=etcd-
    2. Ready 상태가 표시되지 않는 Pod의 경우 Pod 상태를 자세히 검사합니다. <pod_id>를 이전 명령의 출력에 나열된 Pod ID로 교체합니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <pod_id>
    3. Pod와 관련된 컨테이너를 나열합니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps | grep '<pod_id>'
    4. Ready 상태가 표시되지 않는 컨테이너의 경우 컨테이너 상태를 자세히 검사합니다. <container_id>를 이전 명령의 출력에 나열된 컨테이너 ID로 바꿉니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>
    5. Ready 상태가 표시되지 않는 컨테이너의 로그를 확인합니다. <container_id>를 이전 명령의 출력에 나열된 컨테이너 ID로 바꿉니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>
      참고

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

  4. 컨트롤 플레인 노드에서 기본 및 보조 DNS 서버 연결을 확인합니다.

7.1.10. 컨트롤 플레인 노드 kubelet 및 API 서버 문제 조사

설치 중 컨트롤 플레인 노드 (마스터 노드라고도 함) kubelet 및 API 서버 문제를 조사하려면 DNS, DHCP 및 로드 밸런서 기능을 확인합니다. 또한 인증서가 만료되지 않았는지 확인합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 호스트에 대한 SSH 액세스 권한이 있어야 합니다.
  • 컨트롤 플레인 노드의 정규화된 도메인 이름이 있어야 합니다.

절차

  1. API 서버의 DNS 레코드가 컨트롤 플레인 노드의 kubelet을 https://api-int.<cluster_name>.<base_domain>:6443으로 전송하는지 확인합니다. 레코드가 로드 밸런서를 참조하는지 확인합니다.
  2. 로드 밸런서의 포트 6443 정의가 각 컨트롤 플레인 노드를 참조하는지 확인합니다.
  3. DHCP에서 고유한 컨트롤 플레인 노드 호스트 이름이 지정되어 있는지 확인합니다.
  4. 각 컨트롤 플레인 노드에서 kubelet.service journald 장치 로그를 검사합니다.

    1. oc를 사용하여 로그를 검색합니다.

      $ oc adm node-logs --role=master -u kubelet
    2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다. <master-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service
      참고

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

  5. 컨트롤 플레인 노드 kubelet 로그에서 인증서 만료 메시지를 확인합니다.

    1. oc를 사용하여 로그를 검색합니다.

      $ oc adm node-logs --role=master -u kubelet | grep -is 'x509: certificate has expired'
    2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다. <master-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service  | grep -is 'x509: certificate has expired'

7.1.11. 작업자 노드 설치 문제 조사

작업자 노드 설치 문제가 발생하는 경우 작업자 노드 상태를 확인할 수 있습니다. kubelet.service, crio.service journald 장치 로그 및 작업자 노드 컨테이너 로그를 수집하여 작업자 노드 에이전트, CRI-O 컨테이너 런타임, Pod 활동에 대한 가시성을 확보합니다. 또한 Ignition 파일 및 Machine API Operator 기능을 확인할 수 있습니다. 작업자 노드 설치 후 구성이 실패하면 MCO (Machine Config Operator) 및 DNS 기능을 확인합니다. 또한 부트 스트랩, 마스터 및 작업자 노드 간의 시스템 클럭 동기화를 확인하고 인증서의 유효성을 확인할 수도 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 호스트에 대한 SSH 액세스 권한이 있어야 합니다.
  • 부트 스트랩 및 작업자 노드의 완전한 도메인 이름이 있어야 합니다.
  • HTTP 서버를 사용하여 Ignition 구성 파일을 호스팅하는 경우 HTTP 서버의 정규화된 도메인 이름과 포트 번호가 있어야합니다. 또한 HTTP 호스트에 대한 SSH 액세스 권한이 있어야합니다.

    참고

    초기 kubeadmin 암호는 설치 호스트의 <install_directory>/auth/kubeadmin-password에서 찾을 수 있습니다.

프로세스

  1. 작업자 노드의 콘솔에 액세스할 경우 노드가 로그인 프롬프트에 도달할 때 까지 콘솔을 모니터링합니다. 설치 중에 Ignition 로그 메시지가 콘솔에 출력됩니다.
  2. Ignition 파일 설정을 확인합니다.

    • HTTP 서버를 사용하여 Ignition 구성 파일을 호스팅하는 경우:

      1. 작업자 노드의 Ignition 파일 URL을 확인합니다. <http_server_fqdn>을 HTTP 서버의 정규화된 도메인 이름으로 바꿉니다.

        $ curl -I http://<http_server_fqdn>:<port>/worker.ign  1
        1
        -I 옵션은 헤더만 반환합니다. 지정된 URL에서 Ignition 파일을 사용할 수있는 경우 명령은 200 OK 상태를 반환합니다. 사용할 수없는 경우 명령은 404 file not found를 반환합니다.
      2. Ignition 파일이 작업자 노드에서 수신 된 것을 확인하려면 HTTP 호스트의 HTTP 서버 로그를 쿼리합니다. 예를 들어 Apache 웹 서버를 사용하여 Ignition 파일을 제공하는 경우 다음을 확인합니다.

        $ grep -is 'worker.ign' /var/log/httpd/access_log

        작업자 Ignition 파일이 수신되면 연결된 HTTP GET 로그 메시지에 요청이 성공했음을 나타내는 200 OK 성공 상태가 포함됩니다.

      3. Ignition 파일이 수신되지 않은 경우 제공 호스트에 존재하는지 확인합니다. 적절한 파일 및 웹 서버 권한이 있는지 확인합니다.
    • 클라우드 공급자 메커니즘을 사용하여 초기 배포의 일부로 호스트에 Ignition 구성 파일을 삽입하는 경우:

      1. 작업자 노드의 콘솔을 확인하고 작업자 노드의 Ignition 파일을 삽입하는 메커니즘이 올바르게 작동하고 있는지 확인합니다.
  3. 작업자 노드에 할당된 스토리지 장치의 가용성을 확인합니다.
  4. 작업자 노드에 DHCP 서버의 IP 주소가 지정되었는지 확인합니다.
  5. 작업자 노드 상태를 확인합니다.

    1. 노드의 상태를 쿼리합니다.

      $ oc get nodes
    2. Ready 상태를 표시하지 않는 작업자 노드에 대한 자세한 노드 설명을 가져옵니다.

      $ oc describe node <worker_node>
      참고

      설치 문제로 인해 OpenShift Container Platform API가 실행되지 않거나 kubelet이 각 노드에서 실행되지 않는 경우 oc 명령을 실행할 수 없습니다.

  6. 컨트롤 플레인 노드 (마스터 노드라고도 함)와 달리 작업자 노드는 Machine API Operator를 사용하여 배포 및 조정됩니다. Machine API Operator의 상태를 확인합니다.

    1. Machine API Operator Pod의 상태를 검토합니다.

      $ oc get pods -n openshift-machine-api
    2. Machine API Operator Pod의 상태가 Ready가 아닌 경우 Pod의 이벤트를 자세히 설명합니다.

      $ oc describe pod/<machine_api_operator_pod_name> -n openshift-machine-api
    3. machine-api-operator 컨테이너 로그를 검사합니다. 컨테이너는 machine-api-operator Pod 내에서 실행됩니다.

      $ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c machine-api-operator
    4. 또한 kube-rbac-proxy 컨테이너 로그도 검사합니다. 컨테이너는 machine-api-operator Pod 내에서도 실행됩니다.

      $ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c kube-rbac-proxy
  7. 작업자 노드가 부팅된 후 작업자 노드에서 kubelet.service journald 장치 로그를 모니터링합니다. 이를 통해 작업자 노드 에이전트 활동을 시각화할 수 있습니다.

    1. oc를 사용하여 로그를 검색합니다.

      $ oc adm node-logs --role=worker -u kubelet
    2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다. <worker-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service
      참고

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

  8. 작업자 노드가 부팅 된 후 crio.service journald 장치 로그를 검색합니다. 이를 통해 작업자 노드 CRI-O 컨테이너 런타임 활동을 시각화할 수 있습니다.

    1. oc를 사용하여 로그를 검색합니다.

      $ oc adm node-logs --role=worker -u crio
    2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다.

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service
  9. 작업자 노드의 /var/log/ 아래에 있는 특정 하위 디렉토리에서 로그를 수집합니다.

    1. /var/log/ 하위 디렉토리에 포함된 로그 목록을 검색합니다. 다음 예제는 모든 작업자 노드의 /var/log/sssd/에있는 파일을 나열합니다.

      $ oc adm node-logs --role=worker --path=sssd
    2. /var/log/ 하위 디렉터리 내의 특정 로그를 확인합니다. 다음 예제는 모든 작업자 노드에서 /var/log/sssd/audit.log 컨텐츠를 출력합니다.

      $ oc adm node-logs --role=worker --path=sssd/sssd.log
    3. API가 작동하지 않는 경우 SSH를 사용하여 각 노드의 로그를 확인합니다. 다음은 /var/log/sssd/sssd.log의 예제입니다.

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/sssd/sssd.log
  10. SSH를 사용하여 작업자 노드 컨테이너 로그를 확인합니다.

    1. 컨테이너를 나열합니다.

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl ps -a
    2. crictl를 사용하여 컨테이너의 로그를 검색합니다.

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>
  11. 작업자 노드 구성 문제가 발생하는 경우 MCO, MCO 엔드 포인트 및 DNS 레코드가 작동하는지 확인합니다. MCO (Machine Config Operator)는 설치 시 운영 체제 구성을 관리합니다. 또한 시스템 클럭의 정확성과 인증서의 유효성을 확인하합니다.

    1. MCO 엔드 포인트를 사용할 수 있는지 테스트합니다. <cluster_name>을 적절한 값으로 바꿉니다.

      $ curl https://api-int.<cluster_name>:22623/config/worker
    2. 엔드 포인트가 응답하지 않는 경우 로드 밸런서 구성을 확인합니다. 엔드 포인트가 포트 22623에서 실행되도록 구성되었는지 확인합니다.
    3. MCO 엔드 포인트의 DNS 레코드가 구성되어 로드 밸런서 문제를 해결하고 있는지 확인합니다.

      1. 정의된 MCO 엔드 포인트 이름에 대한 DNS 조회를 실행합니다.

        $ dig api-int.<cluster_name> @<dns_server>
      2. 로드 밸런서에서 할당된 MCO IP 주소에 대한 역방향 조회를 실행합니다.

        $ dig -x <load_balancer_mco_ip_address> @<dns_server>
    4. MCO가 부트 스트랩 노드에서 직접 작동하는지 확인합니다. <bootstrap_fqdn>을 부트 스트랩 노드의 정규화된 도메인 이름으로 바꿉니다.

      $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/worker
    5. 시스템 클럭은 부트 스트랩, 마스터 및 작업자 노드 간에 동기화되어야 합니다. 각 노드의 시스템 클럭 참조 시간 및 시간 동기화 통계를 확인합니다.

      $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking
    6. 인증서의 유효성을 확인합니다.

      $ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

7.1.12. 설치 후 Operator 상태 쿼리

설치가 끝나면 Operator의 상태를 확인할 수 있습니다. 사용할 수 없는 Operator에 대한 진단 데이터를 검색합니다. Pending 중으로 나열되거나 오류 상태인 Operator Pod의 로그를 검토합니다. 문제가 있는 Pod에서 사용하는 기본 이미지의 유효성을 검사합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. 설치가 끝나면 클러스터 Operator가 모두 사용 가능한 상태인지 확인합니다.

    $ oc get clusteroperators
  2. 필요한 모든 CSR(인증서 서명 요청)이 모두 승인되었는지 확인합니다. 일부 노드는 Ready 상태로 이동하지 않을 수 있으며 보류 중인 CSR이 있는 경우 일부 클러스터 Operator를 사용하지 못할 수 있습니다.

    1. CSR의 상태를 검토하고 클러스터에 추가된 각 시스템에 대해 Pending 또는 Approved 상태의 클라이언트 및 서버 요청이 표시되어 있는지 확인합니다.

      $ oc get csr

      출력 예

      NAME        AGE     REQUESTOR                                                                   CONDITION
      csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 1
      csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
      csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending 2
      csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
      ...

      1
      클라이언트 요청 CSR.
      2
      서버 요청 CSR.

      예에서는 두 시스템이 클러스터에 참여하고 있습니다. 목록에는 승인된 CSR이 더 많이 나타날 수도 있습니다.

    2. CSR이 승인되지 않은 경우, 추가된 시스템에 대한 모든 보류 중인 CSR이 Pending 상태로 전환된 후 클러스터 시스템의 CSR을 승인합니다.

      참고

      CSR은 교체 주기가 자동으로 만료되므로 클러스터에 시스템을 추가한 후 1시간 이내에 CSR을 승인하십시오. 한 시간 내에 승인하지 않으면 인증서가 교체되고 각 노드에 대해 두 개 이상의 인증서가 표시됩니다. 이러한 인증서를 모두 승인해야 합니다. 첫 번째 CSR을 승인한 후 후속 노드 클라이언트 CSR은 클러스터 kube-controller-manager에 의해 자동으로 승인됩니다.

      참고

      베어 메탈 및 기타 사용자 프로비저닝 인프라와 같이 머신 API를 사용하도록 활성화되지 않는 플랫폼에서 실행되는 클러스터의 경우 CSR(Kubelet service Certificate Request)을 자동으로 승인하는 방법을 구현해야 합니다. 요청이 승인되지 않으면 API 서버가 kubelet에 연결될 때 서비스 인증서가 필요하므로 oc exec, oc rsh, oc logs 명령을 성공적으로 수행할 수 없습니다. Kubelet 엔드 포인트에 연결하는 모든 작업을 수행하려면 이 인증서 승인이 필요합니다. 이 방법은 새 CSR을 감시하고 CSR이 system:node 또는 system:admin 그룹의 node-bootstrapper 서비스 계정에 의해 제출되었는지 확인하고 노드의 ID를 확인합니다.

      • 개별적으로 승인하려면 유효한 CSR 각각에 대해 다음 명령을 실행하십시오.

        $ oc adm certificate approve <csr_name> 1
        1
        <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.
      • 보류 중인 CSR을 모두 승인하려면 다음 명령을 실행하십시오.

        $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
  3. Operator 이벤트를 표시합니다.

    $ oc describe clusteroperator <operator_name>
  4. Operator의 네임스페이스 내에서 Operator Pod의 상태를 검토합니다.

    $ oc get pods -n <operator_namespace>
  5. 상태가 Running이 아닌 Pod에 대한 자세한 설명을 가져옵니다.

    $ oc describe pod/<operator_pod_name> -n <operator_namespace>
  6. Pod 로그를 검사합니다.

    $ oc logs pod/<operator_pod_name> -n <operator_namespace>
  7. Pod 기본 이미지 관련 문제가 발생하면 기본 이미지 상태를 검토합니다.

    1. 문제가 있는 Pod에서 사용되는 기본 이미지의 세부 정보를 가져옵니다.

      $ oc get pod -o "jsonpath={range .status.containerStatuses[*]}{.name}{'\t'}{.state}{'\t'}{.image}{'\n'}{end}" <operator_pod_name> -n <operator_namespace>
    2. 기본 이미지 릴리스 정보를 나열합니다.

      $ oc adm release info <image_path>:<tag> --commits

7.1.13. 실패한 설치에서 로그 수집

설치 프로그램에 SSH 키를 지정한 경우 실패한 설치에 대한 데이터를 수집할 수 있습니다.

참고

실패한 설치에 대한 로그를 수집하는데 사용되는 명령은 실행중인 클러스터에서 로그를 수집할 때 사용되는 명령과 다릅니다. 실행중인 클러스터에서 로그를 수집해야하는 경우 oc adm must-gather 명령을 사용하십시오.

사전 요구 사항

  • 부트스트랩 프로세스가 완료되기 전에 OpenShift Container Platform 설치에 실패합니다. 부트스트랩 노드가 실행 중이며 SSH를 통해 액세스할 수 있습니다.
  • ssh-agent 프로세스는 컴퓨터에서 활성화되어 있으며 ssh-agent 프로세스 및 설치 프로그램에 동일한 SSH 키를 제공하고 있습니다.
  • 프로비저닝하는 인프라에 클러스터를 설치하려는 경우 부트스트랩 또는 컨트롤 플레인 (마스터 노드라고도 함)의 정규화된 도메인 이름이 있어야합니다.

프로세스

  1. 부트스트랩 및 컨트롤 플레인 시스템에서 설치 로그를 가져오는데 필요한 명령을 생성합니다.

    • 설치 관리자 프로비저닝 인프라를 사용한 경우 설치 프로그램이 포함된 디렉터리로 변경하고 다음 명령을 실행합니다.

      $ ./openshift-install gather bootstrap --dir <installation_directory> 1
      1
      installation_directory./openshift-install create cluster를 실행할 때 지정한 디렉터리입니다. 이 디렉터리에는 설치 프로그램이 생성한 OpenShift Container Platform 정의 파일이 포함되어 있습니다.

      설치 프로그램이 프로비저닝한 인프라의 경우 설치 프로그램은 클러스터에 대한 정보를 저장하므로 호스트 이름 또는 IP 주소를 지정할 필요가 없습니다.

    • 자체적으로 프로비저닝한 인프라를 사용한 경우 설치 프로그램이 포함된 디렉터리로 변경하고 다음 명령을 실행합니다.

      $ ./openshift-install gather bootstrap --dir <installation_directory> \ 1
          --bootstrap <bootstrap_address> \ 2
          --master <master_1_address> \ 3
          --master <master_2_address> \ 4
          --master <master_3_address>" 5
      1
      installation_directory의 경우 ./openshift-install create cluster를 실행할 때 지정한 것과 동일한 디렉터리를 지정합니다. 이 디렉터리에는 설치 프로그램이 생성한 OpenShift Container Platform 정의 파일이 포함되어 있습니다.
      2
      <bootstrap_address>는 클러스터 부트스트랩 시스템의 정규화된 도메인 이름 또는 IP 주소입니다.
      3 4 5
      클러스터의 각 컨트롤 플레인 또는 마스터 시스템에 대해 <master_*_address>를 정규화된 도메인 이름 또는 IP 주소로 변경합니다.
      참고

      기본 클러스터에는 세 개의 컨트롤 플레인 시스템이 있습니다. 클러스터가 사용하는 수에 관계없이 표시된대로 모든 컨트롤 플레인 시스템을 나열합니다.

    출력 예

    INFO Pulling debug logs from the bootstrap machine
    INFO Bootstrap gather logs captured here "<installation_directory>/log-bundle-<timestamp>.tar.gz"

    설치 실패에 대한 Red Hat 지원 케이스를 만들 경우 압축된 로그를 케이스에 포함해야 합니다.

7.1.14. 추가 리소스

  • OpenShift Container Platform 설치 유형 및 프로세스에 대한 자세한 내용은 설치 프로세스를 참조하십시오.