1.8. 확인된 문제
OpenShift Container Platform 4.19에서 네트워크 암호화에 IPsec을 사용하는 클러스터는 pod-to-pod 연결이 간헐적으로 손실될 수 있습니다. 이렇게 하면 특정 노드의 일부 Pod가 다른 노드의 서비스에 도달하지 못하도록 연결이 시간 초과됩니다.
내부 테스트에서 120개의 노드가 있는 클러스터에서 이 문제를 재현할 수 없었습니다.
이 문제에 대한 해결방법이 없습니다. (OCPBUGS-55453)
-
AWS의 멕시코 중부 지역
mx-central-1
에 설치된 OpenShift Container Platform 클러스터는 삭제할 수 없습니다. (OCPBUGS-56020) -
Azure에 클러스터를 설치할 때 `compute.platform.azure.identity.type`,
`controlplane.platform.azure.identity.type`
또는`platform.azure.defaultMachinePlatform.identity.type`
필드 값을None
으로 설정하면 클러스터가 Azure Container Registry에서 이미지를 가져올 수 없습니다. 사용자가 할당한 ID를 제공하거나 ID 필드를 비워 두면 이 문제를 피할 수 있습니다. 두 경우 모두 설치 프로그램은 사용자에게 할당된 ID를 생성합니다. (OCPBUGS-56008) -
AWS에 클러스터를 설치할 때
openshift-install create
명령을 실행하기 전에 AWS 자격 증명을 구성하지 않으면 설치 프로그램이 실패합니다. (OCPBUGS-56658)
이전에는 kubelet이 syncPod
메서드에서 실행되는 프로브를 고려하지 않았습니다. 이 메서드는 주기적으로 Pod 상태를 확인하고 일반 프로브 기간 외에 준비 프로브를 수행합니다. 이 릴리스에서는 kubelet이 readinessProbe
기간을 잘못 계산하는 버그가 수정되었습니다. 그러나 포드 작성자는 준비 프로브로 구성된 포드의 준비 지연 시간이 증가할 수 있음을 알 수 있습니다. 이 동작은 구성된 프로브에 더 정확합니다. 자세한 내용은 ( OCPBUGS-50522 )를 참조하세요.
-
cgroupv1
Linux 제어 그룹(cgroup)을 사용하는 RHEL 8 워커 노드에는 알려진 문제가 있습니다. 영향을 받은 노드에 대해 표시되는 오류 메시지의 예는 다음과 같습니다.UDN은 cgroup v1을 사용하므로 노드 ip-10-0-51-120.us-east-2.compute.internal에서 지원되지 않습니다.
해결 방법으로, 작업자 노드를cgroupv1
에서cgroupv2
로 마이그레이션합니다. (OCPBUGS-49933) -
그랜드마스터 클록(T-GM)이 너무 빨리
잠금
상태로 전환되는 경우 알려진 문제가 있습니다. 이 작업은 DPLL(Digital Phase-Locked Loop)이Locked-HO-Acquired
상태로의 전환을 완료하기 전과 GNSS(Global Navigation Satellite Systems) 시간 소스가 복원된 후에 발생합니다. (OCPBUGS-49826) - 포드가 다른 CNI 플러그인과 함께 DHCP 주소 할당을 위해 CNI 플러그인을 사용하는 경우, 포드의 네트워크 인터페이스가 예기치 않게 삭제될 수 있습니다. 결과적으로 포드의 DHCP 임대가 만료되면 DHCP 프록시가 새로운 임대를 다시 만들려고 할 때 루프에 들어가 노드가 응답하지 않게 됩니다. 현재로선 알려진 해결 방법이 없습니다. (OCPBUGS-45272)
-
Azure에 클러스터를 설치할 때
compute.platform.azure.identity.type
,controlplane.platform.azure.identity.type
,platform.azure.defaultMachinePlatform.identity.type
필드 값을None
으로 설정하면 클러스터가 Azure Container Registry에서 이미지를 가져올 수 없습니다. 사용자가 할당한 ID를 제공하거나 ID 필드를 비워 두면 이 문제를 피할 수 있습니다. 두 경우 모두 설치 프로그램은 사용자에게 할당된 ID를 생성합니다. (OCPBUGS-56008) -
AWS에 클러스터를 설치할 때
openshift-install create
명령을 실행하기 전에 AWS 자격 증명을 구성하지 않으면 설치 프로그램이 실패합니다. (OCPBUGS-56658) Must-gather
도구는 OpenShift Container Platform 4.14에서 업그레이드된 클러스터에 대한 IPsec 정보를 수집하지 않습니다. 이 문제는networks.operator.openshift.io 클러스터
CR의ipsecConfig
구성에 빈 구문{}
이 있기 때문에 발생합니다. 빈 구조는 업그레이드된 버전의 OpenShift Container Platform으로 전달됩니다. 이 문제를 해결하려면 클러스터 네트워크 운영자(CNO) CR에서 다음ipsecConfig
구성을 사용하여 다음 명령을 실행합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 명령을 실행하면 CNO가 검사할 수 있는
필수
로그를 수집합니다.
-
충돌이 발생하면
mlx5_core
NIC 드라이버로 인해 메모리 부족 문제가 발생하고kdump
에서vmcore
파일을/var/crash
에 저장하지 않습니다.vmcore
파일을 저장하려면crashkernel
설정을 사용하여kdump
커널의 1024MB 메모리를 예약합니다. (OCPBUGS-54520, RHEL-90663) - 4th#159 Intel Xeon 프로세서에서는 알려진 대기 시간 문제가 있습니다. (OCPBUGS-42495)
-
현재
보장된
QoS 클래스를 사용하고 전체 CPU를 요청하는 Pod는 노드 재부팅 또는 kubelet 재시작 후 자동으로 다시 시작되지 않을 수 있습니다. 이 문제는 정적 CPU 관리자 정책으로 구성되고전체-pcpus 전용
사양으로 구성된 노드에서 발생할 수 있으며 노드의 대부분의 CPU 또는 모든 CPU가 이미 이러한 워크로드에 의해 할당되는 경우 문제가 발생할 수 있습니다. 이 문제를 해결하려면 영향을 받는 Pod를 수동으로 삭제하고 다시 생성합니다. (OCPBUGS-43280) -
현재
irqbalance
서비스가 특정 AArch64 시스템에서 실행되면 버퍼 오버플로 문제로 인해 서비스가 중단될 수 있습니다. 결과적으로 대기 시간에 민감한 워크로드가 CPU에 올바르게 분산되지 않은 관리되지 않는 인터럽트의 영향을 받을 수 있으므로 성능 저하가 발생할 수 있습니다. 현재 이 문제에 대한 해결방법이 없습니다. (RHEL-89986) - 현재 SR-IOV 네트워크 가상 기능이 구성된 클러스터에서는 네트워크 장치 이름 변경을 담당하는 시스템 서비스와 노드 튜닝 운영자가 관리하는 TuneD 서비스 간에 경쟁 조건이 발생할 수 있습니다. 결과적으로 노드가 재시작된 후 TuneD 프로필이 저하되어 성능이 저하될 수 있습니다. 해결 방법으로 TuneD Pod를 다시 시작하여 프로필 상태를 복원하세요. (OCPBUGS-41934)
- RHEL-83435로 인해 OpenShift Container Platform 4.19를 실행하는 클러스터에서는 VMWare vSAN 파일에서 내보낸 NFS 볼륨을 마운트할 수 없습니다. 이 문제를 방지하려면 8.0 P05 이상의 최신 패치 버전에서 VMWare ESXi 및 vSAN을 실행하고 있는지 확인하세요. (OCPBUGS-55978)