지원콘솔개발자평가판 시작연락처

1.10. 확인된 문제

OpenShift Container Platform 4.21에서 알려진 문제 목록을 검토하여 문제가 클러스터 또는 환경에 영향을 미치는지 확인할 수 있습니다.

  • 현재 알려진 문제로 인해 Cluster Resource Override Operator의 OpenShift Container Platform 4.21 버전과 DPU Operator는 향후 4.21 유지 관리 릴리스에서 사용할 수 있습니다. (OCPBUGS-74224)

  • oc adm release mirror 명령을 사용하여 연결이 끊긴 환경의 레지스트리에 OpenShift Container Platform 릴리스 이미지를 미러링하면 릴리스 이미지 Sigstore 서명이 이미지와 함께 미러링되지 않습니다.

    openshift 클러스터 이미지 정책이 기본적으로 클러스터에 배포되므로 OpenShift Container Platform 4.21에서 문제가 발생했습니다. 이 정책은 CRI-O가 이미지를 클러스터로 가져올 때 Sigstore 서명을 자동으로 확인합니다. (OCPBUGS-70297)

    Sigstore 서명이 없으면 연결이 끊긴 환경에서 OpenShift Container Platform 4.21로 업데이트한 후 향후 Cluster Version Operator Pod가 실행되지 않을 수 있습니다. oc-mirror 플러그인 v2를 설치하고 oc mirror 명령을 사용하여 OpenShift Container Platform 릴리스 이미지를 미러링하여 이 문제를 방지할 수 있습니다. oc-mirror 플러그인 v2는 미러 레지스트리에서 연결이 끊긴 환경으로 릴리스 이미지와 Sigstore 서명을 모두 미러링합니다.

    oc-mirror 플러그인 v2를 사용할 수 없는 경우 oc image mirror 명령을 사용하여 다음과 유사한 명령을 사용하여 Sigstore 서명을 미러 레지스트리에 미러링할 수 있습니다. 

    $ oc image mirror "quay.io/openshift-release-dev/ocp-release:${RELEASE_DIGEST}.sig" "${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${RELEASE_DIGEST}.sig"

    다음과 같습니다.

    RELEASE_DIGEST
    다이제스트 이미지를 - 문자로 교체 : 문자로 바꿉니다. 예: sha256:884e1ff5effa04467fab9725900e7f0ed1daa89a7734644f14783014cedee 는 sha256-884e1ff5effeaa04467fab9725900e7f0ed1daa89a773464f147830ceeesdee s가 됩니다.

    oc-mirror v2 플러그인에 대한 자세한 내용은 oc-mirror 플러그인 v2를 사용하여 연결이 끊긴 설치의 이미지 미러링 을 참조하십시오.

  • OpenShift Container Platform 4.21부터는 컨테이너의 기본 최대 열려 있는 파일 소프트 제한에 있는 감소가 있습니다. 결과적으로 최종 사용자에게 애플리케이션 오류가 발생할 수 있습니다. 이 문제를 해결하려면 ulimit 명령과 같은 선택한 방법을 사용하여 컨테이너 런타임(CRI-O) ulimit 구성을 늘립니다. OpenShift Container Platform 4.20에서 4.21로 클러스터를 업그레이드하는 경우 기존의 최대 열려 있는 파일 제한은 유지됩니다. (OCPBUGS-62095)
  • 현재 SR-IOV 네트워크 가상 기능이 구성된 클러스터에서는 네트워크 장치 이름을 담당하는 시스템 서비스와 Node Tuning Operator에서 관리하는 TuneD 서비스 간에 경쟁 조건이 발생할 수 있습니다. 결과적으로 노드가 재시작된 후 TuneD 프로필의 성능이 저하될 수 있었습니다. 이 문제를 해결하려면 TuneD Pod를 다시 시작하여 프로필 상태를 복원합니다. (OCPBUGS-41934)
  • 현재 보장된 QoS 클래스를 사용하고 전체 CPU를 요청하는 Pod는 노드 재부팅 또는 kubelet 재시작 후 자동으로 다시 시작되지 않을 수 있습니다. 이 문제는 정적 CPU 관리자 정책으로 구성되고 전체-pcpus 전용 사양으로 구성된 노드에서 발생할 수 있으며 노드의 대부분의 CPU 또는 모든 CPU가 이미 이러한 워크로드에 의해 할당되는 경우 문제가 발생할 수 있습니다. 이 문제를 해결하려면 영향을 받는 Pod를 수동으로 삭제하고 다시 생성합니다. (OCPBUGS-43280)
  • 특정 AMD EPYC 프로세서를 사용하는 시스템에서 일부 하위 수준 시스템 인터럽트(예: AMD-Vi )는 CPU 고정 워크로드와 겹치는 CPU 마스크의 CPU를 포함할 수 있습니다. 이 동작은 하드웨어 설계 때문입니다. 이러한 특정 오류 보고 인터럽트는 일반적으로 비활성화되어 있으며 현재 알려진 성능에 영향을 미치지 않습니다. (OCPBUGS-57787)

  • 이 릴리스에서 베어 메탈 호스트의 Day 2 펌웨어 업데이트 및 BIOS 속성 재구성을 사용할 수 있지만 Bare Metal Operator(BMO)는 시작한 펌웨어 업데이트 요청을 취소하기 위한 기본 메커니즘을 제공하지 않습니다. HostFirmwareComponents 또는 HostFirmwareSettings 리소스에 대한 펌웨어 업데이트 또는 설정 변경이 실패하거나 오류를 반환하거나 무기한 중단된 경우 다음 단계를 사용하여 복구할 수 있습니다.

    • HostFirmwareComponents 및 HostFirmwareSettings 리소스에 대한 변경 사항을 제거합니다.
    • 재부팅을 트리거하려면 노드를 online: false 로 설정합니다.
    • 문제가 지속되면 Ironic pod를 삭제합니다.

    서비스 작업에 대한 기본 중단 기능은 향후 릴리스에 대해 계획될 수 있습니다.

  • AWS 클러스터에서 gp3 스토리지 볼륨의 최대 처리량을 구성할 수 있는 알려진 문제가 있습니다. 이 기능은 컨트롤 플레인 머신 세트에서 작동하지 않습니다. 이 문제에 대한 해결방법은 없지만 4.21.1에서 해결되었습니다. (OCPBUGS-74478)
  • 사용자 프로비저닝 DNS가 있는 프록시 뒤의 Google Cloud에 프라이빗 클러스터를 설치할 때 부트스트랩이 완료되지 않았거나 클러스터 초기화에 실패했음을 나타내는 설치 오류가 발생할 수 있습니다. 두 경우 모두 설치에 성공하여 정상 클러스터가 생성됩니다. 이 문제를 해결하려면 배포할 클러스터와 동일한 VPC(가상 프라이빗 클라우드) 내에 있는 bastion 호스트에 프라이빗 클러스터를 설치합니다. (OCPBUGS-54901)
  • 현재 NUMA Resources Operator(NRO)에서 제공하는 topo-aware-scheduler 는 Kubernetes 우선순위 기반 선점을 지원하지 않습니다. 우선순위가 낮은 Pod에서 사용 가능한 모든 NUMA 영역을 완전히 사용하는 경우 우선순위가 낮은 Pod가 우선순위가 낮은 Pod를 우선순위가 낮은 Pod를 선점하지 않고 보류 중 상태로 유지됩니다. 결과적으로 topo-aware-scheduler 를 사용할 때 복구 예약을 위해 우선 순위 기반 선점에 의존하는 워크로드가 제대로 작동하지 않습니다. (OCPBUGS-77930)
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

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

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

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

Red Hat 문서 정보

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

Legal Notice

Theme

© 2026 Red Hat맨 위로 이동