1.10. 확인된 문제

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

현재 NUMA Resources Operator(NRO)에서 제공하는 topo-aware-scheduler 는 Kubernetes 우선순위 기반 선점을 지원하지 않습니다. 우선순위가 낮은 Pod에서 사용 가능한 모든 NUMA 영역을 완전히 사용하는 경우 우선순위가 낮은 Pod가 우선순위가 낮은 Pod를 우선순위가 낮은 Pod를 선점하지 않고 보류 중 상태로 유지됩니다. 결과적으로 topo-aware-scheduler 를 사용할 때 복구 예약을 위해 우선 순위 기반 선점에 의존하는 워크로드가 제대로 작동하지 않습니다. (OCPBUGS-77930)
IBM Z®에서 실행되는 OpenShift Container Platform 4.22 클러스터에서 oc adm top pods 명령은 메트릭을 표시하지 못할 수 있으며 crictl inspect 및 컨테이너 메트릭을 사용하는 기타 구성 요소와 같은 툴이 오류를 반환할 수 있습니다. 이 문제는 CRI-O 1.35에서 도입된 회귀 문제로 인해 goccy/go-json 라이브러리의 버그로 인해 s390x 시스템에서 잘못된 형식의 JSON 출력이 발생합니다. 결과적으로 kubelet, cAdvisor, 컨테이너 메트릭을 사용하는 모니터링 또는 디버깅 툴과 같은 구성 요소가 예상대로 작동하지 않을 수 있습니다. 이 문제는 다른 아키텍처 또는 이전 CRI-O 버전에는 영향을 미치지 않습니다. 이 문제를 해결하려면 s390x 클러스터에서 영향을 받는 메트릭 API에 의존하지 않도록 합니다. (OCPBUGS-87805)
현재 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)
현재, RT 커널을 사용하여 openshift-node-performance PerformanceProfile을 적용하면 타이머 마이그레이션 (kernel.timer_migration)이 활성화되지 않습니다. 결과적으로 TCP 시간 제한 및 keep-alive 타이머와 같은 커널 타이머는 대기 시간에 민감한 워크로드에 할당된 CPU에 고정되어 해당 워크로드에 대한 원치 않는 중단을 유발할 수 있습니다. 이 문제를 해결하려면 TuneD 사용자 정의 리소스를 사용하여 kernel.timer_migration=1 sysctl 매개변수를 설정하여 타이머 마이그레이션을 활성화합니다. TuneD 구성에 대한 자세한 내용은 Performance addons operator 고급 구성 을 참조하십시오. (OCPBUGS-86541)
OpenShift Container Platform은 스냅샷이 있는 데이터 저장소에 액세스할 수 없는 토폴로지 도메인에서 볼륨 스냅샷 복원을 지원하지 않습니다. 스냅샷을 스냅샷과 함께 리전 및 영역에 복원하는 PVC(영구 볼륨 클레임)를 사용하는 Pod를 수동으로 예약해야 합니다. 모든 지역 및 영역의 공유 데이터 저장소를 사용하면 이 요구 사항이 충족됩니다. (OCPBUGS-84702)
Azure 사설, 공용 Azure OpenShift Container Platform 및 프라이빗 Azure OpenShift Container Platform과 같은 일부 Microsoft Azure 구성에서는 VM 네트워크 인터페이스 컨트롤러(NIC)의 기본 IP 주소 풀에 연결된 아웃 바운드 규칙을 통해 아웃바운드 연결을 수행할 수 있습니다. 이번 업데이트 이전에는 OutBoundRule 매개변수가 지정되지 않은 경우 공용 로드 밸런서 백엔드 주소 풀에 Egress IP 주소가 추가되었습니다. OutBoundRule 매개변수의 존재 여부에 관계없이 Azure에서 호스팅되는 OpenShift Container Platform 클러스터의 공용 로드 밸런서 백엔드 풀에 Egress IP 주소가 더 이상 추가되지 않습니다. 결과적으로 Azure OpenShift Container Platform 클러스터의 인프라 서브넷을 제외하고 Egress IP 주소에는 아웃바운드 연결이 없습니다. (OCPBUGS-57447)
PTP 프로필 간에 전환할 때 이전에 적용한 프로필의 메트릭이 올바르게 정리되지 않을 수 있습니다. 이 문제는 NIC(네트워크 인터페이스)를 변경할 때 가장 중요합니다. 이 문제를 해결하려면 Pod를 다시 시작하여 메트릭을 정리할 수 있습니다. (OCPBUGS-66413)
현재 BGP(Border Gateway Protocol) 데몬이 -p 0 구성의 포트 179에서 수신 대기하지 않아 관리 라우팅 모드에서 완전한 iBGP(Interior Gateway Protocol) 토폴로지가 실패합니다. 이 문제를 해결하려면 기본 네트워크에서 관리형 라우팅을 비활성화합니다. (OCPBUGS-84702)
no-overlay 관리 라우팅 모드를 사용하는 CUDN(클러스터 사용자 정의 네트워크)에 알려진 문제가 있습니다. 이 구성에서 Pod는 outboundSNAT 매개 변수를 사용할 때 드롭된 SYN 패킷으로 인해 원격 노드 IP와 관련된 연결 문제가 있습니다. 이 문제는 ExternalTrafficPolicy 가 Cluster 로 설정된 NodePort 서비스에 액세스할 때 NodePort 서비스, 호스트 네트워크 pod 및 노드 간 트래픽에 영향을 미칩니다. 현재 해결방법이 없습니다. (OCPBUGS-79682)
ovn-kubernetes-control-plane 서비스 계정(SA)이 관리되는 라우팅 모드를 활성화하는 openshift-ovn-kubernetes 네임스페이스에 필요한 RouteAdvertisement CR을 생성하지 못하는 알려진 문제가 있습니다. 결과적으로 이 구성에서 no-overlay 모드가 작동하지 않습니다. 현재 해결방법이 없습니다. (OCPBUGS-83406)
이번 릴리스에서는 NoOverlay 로 설정된 전송 모드로 CUDN(클러스터 사용자 정의 네트워크)을 생성할 때 문제가 발생하면 CRD(사용자 정의 리소스 정의)에 필요한 NoOverlay 구성 필드가 없다는 것을 확인할 수 있습니다. 이 누락으로 인해 네트워크 오류가 발생하여 CRD에서 누락된 NoOverlay 필드로 인해 동서 트래픽 경로에 영향을 미칩니다. 이 문제를 해결하려면 기본 전송 모드를 사용할 수 있습니다. (OCPBUGS-86761)
OpenShift Container Platform 클러스터에서 CNF(Cloud-native Network Functions) 대기 시간 테스트를 실행하는 경우 테스트에서 cyclictest 테스트를 위해 대기 시간 임계값을 초과하는 결과를 반환할 수 있습니다. 이로 인해 대기 시간이 짧은 워크로드에 대해 클러스터가 올바르게 구성된 경우에도 간헐적인 테스트 오류가 발생할 수 있습니다. 이 문제를 해결하려면 stalld 백엔드를 sched_debug 로 되돌려 대기 시간 급증 빈도와 규모를 줄입니다. (OCPBUGS-86339)
Telecom Grandmaster(T-GM) PTP 구성의 경쟁 조건으로 인해 시스템 시작 시 37초 오프셋이 발생할 수 있습니다. 이는 phc2sys 가 ts2phc 가 GNSS 신호에서 하드웨어 클록(PHC)을 동기화하기 전에 시스템 시계를 동기화하기 때문에 발생합니다. 37초 오프셋은 현재 UTC-TAI 윤초 차이에 해당합니다. 이 문제는 GNSS 신호에서 CryostatC가 올바르게 동기화되면 자체적으로 해결됩니다. (OCPBUGS-85586)
cloud-event-proxy 사이드카가 다시 시작되면 linuxptp-daemon 의 오래된 재생 데이터는 이벤트 소켓을 통해 실시간 데이터로 경쟁할 수 있습니다. 이로 인해 openshift_ptp_clock_state 메트릭과 집계 /master SyncStateChange 클라우드 이벤트가 FreeRUN 또는 HOLDOVER에서 유지되도록 할 수 있습니다. ptp4l 이 LOCKED 상태로 복구된 경우에도 마찬가지입니다. 이 문제를 해결하려면 linuxptp-daemon Pod를 다시 시작합니다. (OCPBUGS-85092)
Telecom Boundary Clock(T-BC)이 holdover에 진입하면 event.sync.sync-status.synchronization-state-change 이벤트는 HOLDOVER 대신 FREERUN을 보고할 수 있습니다. 이는 전체 노드 동기화 상태 계산에 문제가 있기 때문입니다. 해결 방법으로 올바르게 계산되는 event.sync.ptp-status.ptp-state-change 및 event.sync.sync-status.os-clock-sync-state-change 이벤트에서 최악 상태를 사용합니다. 시계가 홀드오버에서 전환되면 이벤트는 동기화로 돌아갑니다. (OCPBUGS-86530)
BlueField-3 NIC를 사용하여 테스트 워크로드를 삭제하고 다시 생성하면 일관성 없는 PTP 동기화로 인해 클럭이 이동됩니다. 이렇게 하면 테스트 워크로드의 시간 동기화가 중단됩니다. 시간 동기화는 워크로드가 안정될 때 안정화됩니다. (RHEL-93579)
현재 cert-manager가 설치된 클러스터에서 EUS (Extended Update Support)에서 EUS 이미지 기반 업그레이드가 지원되지 않습니다. (OCPBUGS-86967)

1.10. 확인된 문제

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

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

Red Hat 문서 정보

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links