7.2. 노드 상태 확인

7.2.1. 노드 상태, 리소스 사용량 및 구성 확인

클러스터 노드 상태, 리소스 사용량 통계 및 노드 로그를 확인합니다. 또한 개별 노드에서 kubelet 상태를 쿼리합니다.

사전 요구 사항

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

프로세스

  • 클러스터의 모든 노드 이름, 상태 및 역할을 나열합니다.

    $ oc get nodes
  • 클러스터 내의 각 노드에 대한 CPU 및 메모리 사용량을 요약합니다.

    $ oc adm top nodes
  • 특정 노드의 CPU 및 메모리 사용량을 요약합니다.

    $ oc adm top node my-node

7.2.2. 노드에서 kubelet의 상태 쿼리

클러스터 노드 상태, 리소스 사용량 통계 및 노드 로그를 확인할 수 있습니다. 또한 개별 노드에서 kubelet 상태를 쿼리할 수 있습니다.

사전 요구 사항

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

프로세스

  1. kubelet은 각 노드에서 systemd 서비스를 사용하여 관리됩니다. 디버그 Pod 내에서 kubelet systemd 서비스를 쿼리하여 kubelet의 상태를 검토합니다.

    1. 노드의 디버그 Pod를 시작합니다.

      $ oc debug node/my-node
      참고

      컨트롤 플레인 노드에서 oc debug 를 실행하는 경우 /etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs 디렉터리에서 관리 kubeconfig 파일을 찾을 수 있습니다.

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

      # chroot /host
      참고

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

    3. kubelet systemd 서비스가 노드에서 활성화되어 있는지 여부를 확인합니다.

      # systemctl is-active kubelet
    4. 더 자세한 kubelet.service 상태 요약을 출력합니다.

      # systemctl status kubelet

7.2.3. 클러스터 노드의 저널 로그 쿼리

개별 클러스터 노드의 /var/log 내에 journald 장치 로그 및 기타 로그를 수집할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • API 서비스가 작동하고 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 호스트에 대한 SSH 액세스 권한이 있어야 합니다.

프로세스

  1. OpenShift Container Platform 클러스터 노드에서 kubelet journald 장치 로그를 쿼리합니다. 다음 예제에서는 컨트롤 플레인 노드만 쿼리합니다.

    $ oc adm node-logs --role=master -u kubelet  1
    1
    다른 장치 로그를 쿼리하려면 kubelet을 적절하게 대체합니다.
  2. 클러스터 노드의 /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
      참고

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