15.4. OpenShift Virtualization에서 호스트된 클러스터 문제 해결


OpenShift Virtualization에서 호스트된 클러스터의 문제를 해결할 때 최상위 HostedClusterNodePool 리소스로 시작한 다음 근본 원인을 찾을 때까지 스택을 축소합니다. 다음 단계는 일반적인 문제의 근본 원인을 찾는 데 도움이 될 수 있습니다.

15.4.1. HostedCluster 리소스가 부분적인 상태로 유지됨

HostedCluster 리소스가 보류 중이므로 호스트 컨트롤 플레인이 완전히 온라인 상태가 아닌 경우 사전 요구 사항, 리소스 조건 및 노드 및 Operator 상태를 확인하여 문제를 식별합니다.

프로세스

  • OpenShift Virtualization에서 호스트된 클러스터의 모든 사전 요구 사항을 충족하는지 확인합니다.
  • 진행을 방지하는 검증 오류는 HostedClusterNodePool 리소스의 조건을 확인합니다.
  • 호스팅 클러스터의 kubeconfig 파일을 사용하여 호스트 클러스터의 상태를 검사합니다.

    • oc get clusteroperators 명령의 출력을 보고 보류 중인 클러스터 Operator를 확인합니다.
    • oc get nodes 명령의 출력을 보고 작업자 노드가 준비되었는지 확인합니다.

15.4.2. 등록된 작업자 노드 없음

호스팅된 컨트롤 플레인에 작업자 노드가 등록되지 않았기 때문에 호스팅된 컨트롤 플레인이 완전히 온라인 상태가 아닌 경우 호스트 컨트롤 플레인의 다양한 부분의 상태를 확인하여 문제를 확인합니다.

프로세스

  • 문제가 발생할 수 있음을 나타내는 실패의 HostedClusterNodePool 조건을 확인합니다.
  • 다음 명령을 입력하여 NodePool 리소스의 KubeVirt 작업자 노드 VM(가상 머신) 상태를 확인합니다.

    $ oc get vm -n <namespace>
    Copy to Clipboard Toggle word wrap
  • VM이 프로비저닝 상태에 있는 경우 다음 명령을 입력하여 가져오기 Pod가 완료되지 않은 이유에 대한 이해를 위해 VM 네임스페이스 내에서 CDI 가져오기 Pod를 확인합니다.

    $ oc get pods -n <namespace> | grep "import"
    Copy to Clipboard Toggle word wrap
  • VM이 시작 상태에 있는 경우 다음 명령을 입력하여 virt-launcher Pod의 상태를 확인합니다.

    $ oc get pods -n <namespace> -l kubevirt.io=virt-launcher
    Copy to Clipboard Toggle word wrap

    virt-launcher Pod가 보류 중 상태인 경우 Pod가 예약되지 않은 이유를 조사합니다. 예를 들어 virt-launcher Pod를 실행하는 데 리소스가 부족할 수 있습니다.

  • VM이 실행 중이지만 작업자 노드로 등록되지 않은 경우 웹 콘솔을 사용하여 영향을 받는 VM 중 하나에 대한 VNC 액세스를 얻습니다. VNC 출력은 Ignition 구성이 적용되었는지 여부를 나타냅니다. VM이 시작 시 호스팅된 컨트롤 플레인 ignition 서버에 액세스할 수 없는 경우 VM을 올바르게 프로비저닝할 수 없습니다.
  • Ignition 구성이 적용되지만 VM이 여전히 노드로 등록되지 않은 경우 문제 식별을 참조하십시오. 시작 중에 VM 콘솔 로그에 액세스하는 방법을 알아보려면 VM 콘솔 로그에 액세스합니다.

15.4.3. 작업자 노드는 NotReady 상태에 있습니다.

클러스터 생성 중에 네트워킹 스택이 롤아웃되는 동안 노드가 일시적으로 NotReady 상태로 들어갑니다. 이 과정의 일부는 정상입니다. 그러나 프로세스의 이 부분이 15분 이상 걸리는 경우 노드 오브젝트 및 Pod를 조사하여 문제를 식별합니다.

프로세스

  1. 다음 명령을 입력하여 노드 오브젝트의 조건을 확인하고 노드가 준비되지 않은 이유를 확인합니다.

    $ oc get nodes -o yaml
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 입력하여 클러스터 내에서 실패한 Pod를 찾습니다.

    $ oc get pods -A --field-selector=status.phase!=Running,status,phase!=Succeeded
    Copy to Clipboard Toggle word wrap

15.4.4. Ingress 및 콘솔 클러스터 Operator는 온라인 상태가 아닙니다.

Ingress 및 콘솔 클러스터 Operator가 온라인 상태가 아니므로 호스팅 컨트롤 플레인이 완전히 온라인 상태가 아닌 경우 와일드카드 DNS 경로 및 로드 밸런서를 확인합니다.

프로세스

  • 클러스터에서 기본 Ingress 동작을 사용하는 경우 다음 명령을 입력하여 가상 머신(VM)이 호스팅되는 OpenShift Container Platform 클러스터에서 와일드카드 DNS 경로가 활성화되어 있는지 확인합니다.

    $ oc patch ingresscontroller -n openshift-ingress-operator \
      default --type=json -p \
      '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
    Copy to Clipboard Toggle word wrap
  • 호스팅된 컨트롤 플레인에 사용자 정의 기본 도메인을 사용하는 경우 다음 단계를 완료합니다.

    • 로드 밸런서가 VM pod를 올바르게 대상으로 지정 중인지 확인합니다.
    • 와일드카드 DNS 항목이 로드 밸런서 IP 주소를 대상으로 하는지 확인합니다.

15.4.5. 호스팅된 클러스터의 로드 밸런서 서비스를 사용할 수 없음

로드 밸런서 서비스를 사용할 수 없기 때문에 호스팅되는 컨트롤 플레인이 완전히 온라인 상태가 되지 않는 경우 이벤트, 세부 정보 및 Kubernetes Cluster Configuration Manager(KCCM) Pod를 확인합니다.

프로세스

  • 호스팅된 클러스터 내에서 로드 밸런서 서비스와 연결된 이벤트 및 세부 정보를 찾습니다.
  • 기본적으로 호스팅된 클러스터의 로드 밸런서는 호스팅된 컨트롤 플레인 네임스페이스 내의 kubevirt-cloud-controller-manager에 의해 처리됩니다. KCCM Pod가 온라인 상태인지 확인하고 오류 또는 경고에 대한 로그를 확인합니다. 호스팅된 컨트롤 플레인 네임스페이스에서 KCCM Pod를 식별하려면 다음 명령을 입력합니다.

    $ oc get pods -n <hosted_control_plane_namespace> \
      -l app=cloud-controller-manager
    Copy to Clipboard Toggle word wrap

15.4.6. 호스트된 클러스터 PVC를 사용할 수 없음

호스팅된 클러스터의 PVC(영구 볼륨 클레임)를 사용할 수 없기 때문에 호스팅된 컨트롤 플레인이 완전히 온라인 상태가 아닌 경우 PVC 이벤트 및 세부 정보 및 구성 요소 로그를 확인합니다.

프로세스

  • PVC와 연결된 이벤트 및 세부 정보를 찾아 발생하는 오류를 파악합니다.
  • PVC가 Pod에 연결하지 못하는 경우 호스트 클러스터 내에서 kubevirt-csi-node 데몬 세트 구성 요소의 로그를 확인하여 문제를 추가로 조사합니다. 각 노드의 kubevirt-csi-node Pod를 식별하려면 다음 명령을 입력합니다.

    $ oc get pods -n openshift-cluster-csi-drivers -o wide \
      -l app=kubevirt-csi-driver
    Copy to Clipboard Toggle word wrap
  • PVC가 PV(영구 볼륨)에 바인딩할 수 없는 경우 호스팅된 컨트롤 플레인 네임스페이스 내에서 kubevirt-csi-controller 구성 요소의 로그를 확인합니다. 호스팅된 컨트롤 플레인 네임스페이스 내에서 kubevirt-csi-controller Pod를 식별하려면 다음 명령을 입력합니다.

    $ oc get pods -n <hcp namespace> -l app=kubevirt-csi-driver
    Copy to Clipboard Toggle word wrap

15.4.7. VM 노드가 클러스터에 올바르게 참여하지 않음

VM 노드가 클러스터에 올바르게 참여하지 않기 때문에 호스팅된 컨트롤 플레인이 완전히 온라인 상태가 아닌 경우 VM 콘솔 로그에 액세스합니다.

15.4.8. RHCOS 이미지 미러링 실패

연결이 끊긴 환경의 OpenShift Virtualization의 호스팅된 컨트롤 플레인의 경우 oc-mirror 가 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 내부 레지스트리에 자동으로 미러링하지 못합니다. 첫 번째 호스트 클러스터를 생성할 때 내부 레지스트리에서 부팅 이미지를 사용할 수 없기 때문에 Kubevirt 가상 머신이 부팅되지 않습니다.

이 문제를 해결하려면 RHCOS 이미지를 내부 레지스트리에 수동으로 미러링합니다.

프로세스

  1. 다음 명령을 실행하여 내부 레지스트리 이름을 가져옵니다.

    $ oc get imagecontentsourcepolicy -o json \
      | jq -r '.items[].spec.repositoryDigestMirrors[0].mirrors[0]'
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 페이로드 이미지를 가져옵니다.

    $ oc get clusterversion version -ojsonpath='{.status.desired.image}'
    Copy to Clipboard Toggle word wrap
  3. 호스팅된 클러스터의 페이로드 이미지에서 부팅 이미지가 포함된 0000_50_installer_coreos-bootimages.yaml 파일을 추출합니다. & lt;payload_image >를 페이로드 이미지 이름으로 바꿉니다. 다음 명령을 실행합니다.

    $ oc image extract \
      --file /release-manifests/0000_50_installer_coreos-bootimages.yaml \
      <payload_image> --confirm
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 RHCOS 이미지를 가져옵니다.

    $ cat 0000_50_installer_coreos-bootimages.yaml | yq -r .data.stream \
      | jq -r '.architectures.x86_64.images.kubevirt."digest-ref"'
    Copy to Clipboard Toggle word wrap
  5. RHCOS 이미지를 내부 레지스트리에 미러링합니다. < rhcos_image >를 RHCOS 이미지로 바꿉니다(예: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:d9643ead36b1c026be664c9c65c11433c6cdffd93ba229141d134a4a 694 . < internal_registry >를 내부 레지스트리의 이름으로 바꿉니다(예: virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev ). 다음 명령을 실행합니다.

    $ oc image mirror <rhcos_image> <internal_registry>
    Copy to Clipboard Toggle word wrap
  6. ImageDigestMirrorSet 오브젝트를 정의하는 rhcos-boot-kubevirt.yaml 이라는 YAML 파일을 생성합니다. 다음 예제 구성을 참조하십시오.

    apiVersion: config.openshift.io/v1
    kind: ImageDigestMirrorSet
    metadata:
      name: rhcos-boot-kubevirt
    spec:
      repositoryDigestMirrors:
        - mirrors:
            - virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev 
    1
    
          source: quay.io/openshift-release-dev/ocp-v4.0-art-dev 
    2
    Copy to Clipboard Toggle word wrap
    1
    내부 레지스트리의 이름을 지정합니다(예: virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev ).
    2
    다이제스트 없이 RHCOS 이미지를 지정합니다(예: quay.io/openshift-release-dev/ocp-v4.0-art-dev ).
  7. 다음 명령을 실행하여 rhcos-boot-kubevirt.yaml 파일을 적용하여 ImageDigestMirrorSet 오브젝트를 생성합니다.

    $ oc apply -f rhcos-boot-kubevirt.yaml
    Copy to Clipboard Toggle word wrap

15.4.9. 베어 메탈이 아닌 클러스터를 late binding 풀로 반환

BareMetalHosts 없이 늦은 바인딩 관리 클러스터를 사용하는 경우 늦은 바인딩 클러스터를 삭제하고 노드를 Discovery ISO로 돌아가려면 추가 수동 단계를 완료해야 합니다.

BareMetalHosts 가 없는 최신 바인딩 관리 클러스터의 경우 클러스터 정보를 제거해도 모든 노드를 Discovery ISO로 자동으로 반환하지는 않습니다.

프로세스

늦은 바인딩으로 베어 메탈 노드가 아닌 노드를 바인딩 해제하려면 다음 단계를 완료하십시오.

  1. 클러스터 정보를 제거합니다. 자세한 내용은 관리에서 클러스터 제거를 참조하십시오.
  2. 루트 디스크를 정리합니다.
  3. Discovery ISO를 사용하여 수동으로 재부팅합니다.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat