7장. 문제 해결

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

프로세스

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 Enterprise Linux(RHEL) 7 이상에서는 netstat 대신 ss 명령을 사용하는 것이 좋습니다. ss는 iproute 패키지에서 제공합니다. ss 명령에 대한 자세한 내용은 Red Hat Enterprise Linux (RHEL) 7 성능 조정 가이드를 참조하십시오.

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

   $ dig <wildcard_fqdn> @<dns_server>

프로세스

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

프로세스

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 설치 요구 사항을 충족하는지 확인합니다.

프로세스

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. OVN-Kubernetes 상태를 확인합니다.

   1. openshift-ovn-kubernetes 네임스페이스에서 ovnkube-node 데몬 세트 상태를 검토합니다.

      $ oc get daemonsets -n openshift-ovn-kubernetes

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

      $ oc get pods -n openshift-ovn-kubernetes

   3. openshift-ovn-kubernetes 네임스페이스에서 실패한 OpenShift Container Platform OVN-Kubernetes Pod와 관련된 로그를 확인합니다.

      $ oc logs <ovn-k_pod> -n openshift-ovn-kubernetes

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

      참고

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

프로세스

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>

      참고

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

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

프로세스

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

      참고

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

프로세스

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

      참고

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

프로세스

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

프로세스

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 지원 케이스를 만들 경우 압축된 로그를 케이스에 포함해야 합니다.