1.6. 버그 수정
베어 메탈 하드웨어 프로비저닝
-
이전에는 프로비저닝 네트워크를
Disabled
에서Managed
로 전환할 때 MAC 주소를 사용하여 provisioning 네트워크 인터페이스를 구성하는 것은 지원되지 않았습니다. 이번 업데이트를 통해provisioningMacAddresses
필드가provisioning.metal3.io
CRD에 추가되었습니다. 이 필드를 사용하여 이름이 아닌 MAC 주소를 사용하여 프로비저닝 네트워크 인터페이스를 식별합니다. (BZ#2000081) -
이전에 Ironic은 SuperMicro X11/X12 서버를 프로비저닝하기 위해 가상 미디어 이미지를 첨부하지 못했는데, 이는 이러한 모델들이 CD 기반 가상 미디어에 대해
UsbCd
와 같은 비표준 장치 문자열을 요구하기 때문입니다. 이번 업데이트를 통해 이제 프로비저닝에서 CD 기반 가상 미디어를 사용하여 프로비저닝된 SuperMicro 시스템에서UsbCd
를 덮어씁니다. (BZ#2009555) -
이전에는 Ironic에서 이러한 시스템의 BMC에서 URl 검증이 과도하게 제한되어 SuperMicro X11/X12 서버에 가상 미디어 이미지를 연결하지 못했습니다. 이번 업데이트를 통해 가상 미디어 이미지를 로컬 파일에서 지원하는 경우
filename
매개변수가 URL에서 제거되었습니다. 결과적으로 오브젝트 저장소에서 이미지를 지원하는 경우에도 매개 변수를 계속 전달합니다. (BZ#2011626) -
이전에는 시스템 다운러 이미지에서 사용하는
curl
유틸리티에서no_proxy
가 있는 CIDR(Classless inter-domain routing)을 지원하지 않았습니다. 따라서 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 다운로드할 때'noProxy'의 CIDR이 무시되었습니다. 이번 업데이트를 통해 적절한 경우curl
을 호출하기 전에 프록시가 환경에서 제거됩니다. 결과적으로 시스템 이미지를 다운로드할 때no_proxy
의 CIDR이 더 이상 무시되지 않습니다. (BZ#1990556) - 이전에는 OpenShift Container Platform의 가상 미디어 기반 배포가 iDRAC 하드웨어 유형에서 간헐적으로 실패하는 것으로 확인되었습니다. 이는 완료되지 않은 Lifecycle Controler 작업이 가상 미디어 구성 요청과 충돌할 때 발생했습니다. 이번 업데이트를 통해 배포 전에 iDRAC 하드웨어를 등록하면서 Lifecycle Controller 작업을 종료하여 가상 미디어 배포 오류가 수정되었습니다. (BZ#1988879)
-
이전에는 설치 구성 파일에 긴 형식의 IPv6 주소를 입력해야 했습니다(예:
2001:0db8:85a3:0000:0000:8a2e:0370:7334
). Ironic에서는 이 IP 주소와 일치하는 인터페이스를 찾을 수 없어 설치에 실패합니다. 이번 업데이트에서는 사용자가 제공하는 IPv6 주소가 짧은 양식 주소(예:2001:db8:85a3::8a2e:370:7334
)로 변환됩니다. 결과적으로 이제 설치가 성공적으로 수행됩니다. (BZ#2010698) - 이번 업데이트 이전에는 Redfish 시스템에 설정 URI가 있는 경우 Ironic 프로비저닝 서비스에서 항상 이 URI를 사용하여 부팅 관련 BIOS 설정을 변경합니다. 그러나 BMC(Baseboard Management Controller)에 설정 URI가 있지만 이 설정 URI를 사용하여 특정 BIOS 설정 변경을 지원하지 않는 경우 베어 메탈 프로비저닝이 실패합니다. OpenShift Container Platform 4.10 이상에서 시스템에 설정 URI가 있는 경우 Ironic에서 진행하기 전에 설정 URI를 사용하여 특정 BIOS 설정을 변경할 수 있는지 확인합니다. 그렇지 않으면 Ironic은 시스템 URI를 사용하여 변경 사항을 구현합니다. 이 추가 논리를 통해 Ironic에서 부팅 관련 BIOS 설정 변경 사항을 적용할 수 있으며 베어 메탈 프로비저닝이 성공할 수 있습니다. (OCPBUGS-6886)
빌드
이번 업데이트 이전에는 OpenShift Container Platform 4.7.x 또는 이전 버전에서 이미지 변경 트리거가 포함된 빌드 구성을 생성한 경우 이미지 변경 트리거가 지속적으로 트리거될 수 있습니다.
이 문제는 빌드의
BuildConfig
사양에서lastTriggeredImageID
필드를 사용 중단 및 제거하여 빌드를 인스턴스화하기 전에 이미지 변경 트리거 컨트롤러에서 해당 필드 확인을 중지했기 때문에 발생했습니다. OpenShift Container Platform 4.8에서는 이미지 변경 트리거 컨트롤러에서 확인하는 데 필요하지만 확인하지 않은 상태에 새 필드를 도입했습니다.이번 업데이트를 통해 이미지 변경 트리거 컨트롤러는 마지막 트리거 이미지 ID에 대한 사양 및 상태의 올바른 필드를 지속적으로 확인합니다. 이제 필요한 경우에만 빌드를 트리거합니다. (BZ#2004203)
- 이번 업데이트 이전에는 Red Hat 레지스트리 이름을 명시적으로 지정하는 데 필요한 빌드의 이미지 참조입니다. 이번 업데이트를 통해 이미지 참조에 레지스트리가 포함되어 있지 않은 경우 빌드에서 Red Hat 레지스트리 및 기타 잘 알려진 기타 레지스트리를 검색하여 이미지를 찾습니다. (BZ#2011293)
Jenkins
-
이번 업데이트 이전에는 OpenShift Jenkins 동기화 플러그인의 버전 1.0.48에서 OpenShift Jenkins Pipeline Build Strategy Build Config와 연결되지 않은 새 작업의 플러그인을 알릴 때
NullRuleerException
오류가 발생했습니다. 궁극적으로 이 오류는 들어오는 Jenkins 작업과 연결할BuildConfig
오브젝트가 없기 때문에 문제가 되지 않았습니다. 코어 Jenkins는 플러그인의 예외를 무시하고 다음 리스너로 이동했습니다. 그러나 Jenkins 로그에 긴 스택 추적이 나타나 사용자의 주의를 분산시켰습니다. 이번 업데이트를 통해 플러그인은 이 오류 및 후속 스택 추적을 방지하기 위해 적절한 검사를 통해 문제를 해결합니다. (BZ#2030692) 이번 업데이트 이전에는 OpenShift 동기화 Jenkins 플러그인의 버전 1.0.48의 성능 개선 사항이 Jenkins Kubernetes 플러그인 pod 템플릿에 매핑하려는
ConfigMap
및ImageStream
오브젝트에 대해 허용된 라벨을 잘못 지정했습니다. 결과적으로 플러그인은 더 이상jenkins-agent
라벨을 사용하여ConfigMap
및ImageStream
오브젝트에서 Pod 템플릿을 가져오지 않습니다.이번 업데이트에서는 플러그인이
ConfigMap
및jenkins-agent
레이블이 있는ImageStream
오브젝트에서 Pod 템플릿을 가져오도록 허용된 라벨 사양을 수정합니다. (2034839)
클라우드 컴퓨팅
- 이전 버전에서는 RHOSP(Red Hat OpenStack Platform)에서 머신 사양을 편집하면 OpenShift Container Platform에서 머신을 삭제하고 다시 생성할 수 있었습니다. 이로 인해 호스팅한 노드가 복구할 수 없었습니다. 이번 수정을 통해 생성 후 머신 사양에 대한 편집 사항이 무시됩니다. (BZ#1962066)
- 이전에는 RHOSP(Red Hat OpenStack Platform)에서 실행되는 클러스터에서 머신 오브젝트에 유동 IP 주소가 보고되지 않았습니다. 결과적으로 kubelet이 생성된 CSR(인증서 서명 요청)을 허용하지 않아 노드가 클러스터에 참여하지 않았습니다. 이제 모든 IP 주소가 머신 오브젝트에 대해 보고됩니다. (BZ#2022627)
- 이전에는 대기열을 다시 큐에 추가하기 전에 AWS 시스템이 업데이트되지 않았는지 확인합니다. 그 결과 AWS 시스템의 가상 머신이 제거되었지만 해당 오브젝트를 계속 사용할 수 있는 문제가 발생했습니다. 이 경우 AWS 머신은 무한 루프로 다시 큐에 추가되며 삭제하거나 업데이트할 수 없습니다. 이번 업데이트에서는 다시 큐에 추가하기 전에 AWS 시스템이 업데이트되지 않았는지 확인하는 데 사용된 검사를 복원합니다. 결과적으로 머신이 업데이트되면 더 이상 다시 큐에 대기하지 않습니다. (BZ#2007802)
- 이전에는 선택기를 수정하면 머신 세트가 관찰되는 시스템 목록이 변경되었습니다. 결과적으로 머신 세트가 이미 생성된 머신을 추적하지 못했기 때문에 누출이 발생할 수 있었습니다. 이번 업데이트에서는 생성 후 선택기를 변경할 수 없습니다. 결과적으로 머신 세트에 올바른 머신이 나열됩니다. (BZ#2005052)
-
이전 버전에서는 가상 머신 템플릿에 스냅샷이 있는 경우
linkedClone
작업을 잘못된 사용량으로 인해 디스크 크기가 잘못 선택되었습니다. 이번 업데이트를 통해 모든 상황에 대해 기본 복제 작업이fullClone
으로 변경됩니다.linkedClone
은 이제 사용자가 지정해야 합니다. (BZ#2001008) - 이전에는 CRD(사용자 정의 리소스 정의) 스키마 요구 사항에서 숫자 값을 허용하지 않았습니다. 결과적으로 업그레이드 중에 발생한 마샬링(Marshalling) 오류가 발생했습니다. 이번 업데이트에서는 문자열과 숫자 값을 모두 허용하도록 스키마 요구 사항이 수정되었습니다. 결과적으로 마샬링 오류는 더 이상 API 서버 변환에서 보고되지 않습니다. (BZ#1999425)
-
이전 버전에서는 Machine API Operator를 이동하거나 이름이 변경된 후 Pod가 배포된 경우 모니터링된 각 시스템에 대해
MachineNotYetDeleted
메트릭이 재설정되었습니다. 이번 업데이트에서는 소스 Pod 레이블을 무시하도록 메트릭 쿼리를 변경합니다. 그 결과MachineNotYetDeleted
지표가 Machine API Operator Pod의 이름이 변경된 시나리오에서 올바르게 경고됩니다. (BZ#1986237) - 이전에는 vSphere의 송신 IP가 kubelet 내에서 vSphere 클라우드 공급자에 의해 선택되었습니다. 이는 CSR(인증서 서명 요청) 승인자가 예상치 못한 일이었습니다. 결과적으로 송신 IP가 있는 노드에 CSR 갱신이 승인되지 않았습니다. 이번 업데이트를 통해 CSR 승인자가 송신 IP를 설명할 수 있습니다. 결과적으로 vSphere SDN 클러스터에서 송신 IP가 있는 노드는 이제 계속 작동하고 유효한 CSR 갱신을 갖습니다. (BZ#1860774)
- 이전에는 작업자 노드가 시작되지 않았으며 설치 프로그램이 디스크 이미지 기본값을 손상하고 GCP(Google Cloud Platform) SDK의 호환되지 않는 변경으로 인해 URL 이미지를 생성하지 못했습니다. 결과적으로 머신 컨트롤러에서 머신을 생성할 수 없었습니다. 이번 수정에서는 GCP SDK의 기본 경로를 변경하여 URL 이미지를 복구합니다. (BZ#2009111)
-
이전에는 vCenter의
powerOff
작업의 지연으로 인해 삭제 프로세스 중에 머신이 중단되었습니다. VMware는 시스템의 전원을 끄는 것으로 표시했지만 OpenShift Container Platform은 전원이 켜진 것으로 보고하여 삭제 프로세스 중에 시스템이 중단되었다고 보고했습니다. 이번 업데이트에서는 데이터베이스에서 삭제할 작업이 생성되기 전에 vSphere에서powerOff
작업 처리를 개선하여 삭제 프로세스 중에 머신이 정지되지 않습니다. (BZ#2011668) - OpenShift Container Platform을 설치하거나 업데이트한 후 메트릭 값에 마지막 CSR이 조정된 후 보류 중인 CSR 하나가 표시되었습니다. 이로 인해 보류중인 CSR이 없어야 하는 경우 하나의 보류 중인 CSR을 보고하는 메트릭이 생성되었습니다. 이번 수정을 통해 각 조정 루프가 끝날 때 메트릭을 업데이트하여 보류 중인 CSR 수가 승인 후 항상 유효한지 확인합니다. (BZ#2013528)
-
이전에는
cloud-provider
플래그가 빈 문자열로 설정된 경우 AWS에서 인증 정보를 확인했습니다. 인증 정보는 AWS 이외의 플랫폼에서도 메타데이터 서비스를 호출하여 확인되었습니다. 이로 인해 ECR 공급자 시작 시 대기 시간이 발생하고 AWS 이외의 AWS를 포함한 모든 플랫폼에 AWS 인증 정보 오류가 기록되었습니다. 이번 수정을 통해 인증 정보 확인에서 메타데이터 서비스에 대한 요청을 수행하지 못하도록 인증 정보 오류가 더 이상 기록되지 않습니다. (BZ#2015515) - 이전에는 Machine API에서 AWS가 API에서 VM 생성을 통신하기 전에 머신을 조정한 경우가 있었습니다. 그 결과 AWS에서 VM이 존재하지 않는다고 보고하고 Machine API가 실패한 것으로 간주했습니다. 이번 릴리스에서는 머신을 프로비저닝된 것으로 표시하기 전에 Machine API가 AWS API가 동기화될 때까지 기다립니다. (BZ#2025767)
- 이전에는 UPI 클러스터에서 동시에 생성된 대규모 노드의 경우 많은 CSR이 생성될 수 있었습니다. 그 결과 승인자가 100개 이상의 보류 중인 인증서 요청이 있을 때 승인자가 인증서 승인을 중지하기 때문에 인증서 갱신이 자동화되지 않았습니다. 이번 릴리스에서는 승인 마감을 계산할 때 기존 노드가 고려되고 UPI 클러스터는 대규모 새로 고침 요청이 있는 경우에도 자동화된 인증서 갱신의 이점을 누릴 수 있습니다. (BZ#2028019)
- 이전에는 Machine API 컨트롤러에 포함된 생성된 인스턴스 유형 목록이 최신 버전이 없었습니다. 이러한 인스턴스 유형 중 일부는 알려지지 않았으며 scale-from-zero 요구 사항에 맞게 주석을 달 수 없었습니다. 이번 릴리스에서는 생성된 목록이 최신 인스턴스 유형에 대한 지원을 포함하도록 업데이트됩니다. (BZ#2040376)
- 이전 버전에서는 AWS Machine API 컨트롤러에서 IO1 유형이 아닌 블록 장치에 대해 IOPS 값을 설정하지 않아 IOPS 필드가 무시되었습니다. 이번 릴리스에서는 지원되는 모든 블록 장치 유형에 IOPS가 설정되고 사용자는 머신에 연결된 블록 장치에 대해 IOPS를 설정할 수 있습니다. (BZ#2040504)
Cloud Credential Operator
-
이전 버전에서는 Azure 클러스터에서 수동 모드에서 Cloud Credential Operator를 사용할 때
Upgradeable
상태가False
로 설정되지 않았습니다. 다른 플랫폼에서는 이 동작이 다릅니다. 이번 릴리스에서는 수동 모드에서 Cloud Credential Operator를 사용하는 Azure 클러스터에Upgradeable
상태가False
로 설정되어 있습니다. (BZ#1976674) -
이전에는 Cloud Credential Operator에 의해 생성된 불필요한
controller-manager-service
서비스 리소스가 여전히 남아 있었습니다. 이번 릴리스에서는 Cluster Version Operator가 이를 정리합니다. (BZ#1977319) -
이전에는
CredentialsRequest
사용자 정의 리소스의 Cloud Credential Operator에 대한 로그 수준 설정 변경이 무시되었습니다. 이번 릴리스에서는CredentialsRequest
사용자 정의 리소스를 편집하여 로깅 상세 정보를 제어할 수 있습니다. (BZ#1991770) - 이전에는 AWS가 RHOSP(Red Hat OpenStack Platform)의 기본 시크릿 annotator인 경우 CCO(Cloud Credential Operator) Pod가 지속적인 오류로 다시 시작되었습니다. 이번 업데이트에서는 CCO Pod의 기본 설정이 수정되어 CCO Pod가 실패하지 않습니다. (BZ#1996624)
Cluster Version Operator
- 이전에는 매니페스트의 일부가 아닌 잘못된 마운트 요청으로 인해 Pod를 시작하지 못할 수 있었습니다. 이번 업데이트를 통해 CVO(Cluster Version Operator)는 매니페스트에 포함되지 않은 클러스터 내 리소스에서 볼륨 및 볼륨 마운트를 제거합니다. 이렇게 하면 Pod가 성공적으로 시작됩니다. (BZ#2002834)
- 이전에는 모니터링 인증서가 순환되면 CVO(Cluster Version Operator)에서 오류를 기록했으며 CVO Pod가 수동으로 재시작될 때까지 모니터링에서 메트릭을 쿼리할 수 없었습니다. 이번 업데이트를 통해 CVO는 인증서 파일을 모니터링하고 인증서 파일이 변경될 때마다 지표 연결을 자동으로 다시 생성합니다. (BZ#2027342)
콘솔 스토리지 플러그인
-
이전에는 PV(영구 볼륨)가 프로비저닝되고 용량이
0
TiB인 동안 로드 프롬프트가 표시되지 않아 혼란스러운 시나리오가 생성되었습니다. 이번 업데이트를 통해 PV가 계속 프로비저닝되거나 용량을 결정해야 하는 경우 사용자에게 세부 정보를 제공하는 로드 상태에 대한 로더가 추가됩니다. 또한 사용자에게 프로세스의 오류를 알려줍니다. (BZ#1928285) - 이전에는 특정 위치에서 문법이 정확하지 않고 번역가가 문맥을 해석하지 못하는 경우가 있었습니다. 이는 가독성에 부정적인 영향을 미쳤습니다. 이번 업데이트를 통해 다양한 위치의 문법이 수정되고 번역가를 위한 스토리지 클래스를 항목별로 정리하여 전체적인 가독성을 개선하였습니다. (BZ#1961391)
-
이전 버전에서는 블록 풀 페이지 내에서 풀을 누를 때 삭제 후에도 최종
Ready
단계가 지속되었습니다. 결과적으로 삭제 후에도 풀이Ready
상태에 있었습니다. 이번 업데이트에서는 사용자를 Pools 페이지로 리디렉션하고 보류 후 풀을 새로 고칩니다. (BZ#1981396)
DNS(Domain Name System)
-
이전에는 DNS Operator에서
spec.servers
를 사용하여 구성한 업스트림 확인자의 응답을 캐시하지 않았습니다. 이번 업데이트를 통해 DNS Operator는 모든 업스트림 서버의 응답을 캐시합니다. (BZ#2006803) -
이전에는 DNS Operator에서 사용자 정의 업스트림 리졸버의 서버 블록에서
prometheus
플러그인을 활성화하지 않았습니다. 결과적으로 CoreDNS는 업스트림 확인자에 대한 메트릭을 보고하지 않았으며 기본 서버 블록에 대한 메트릭만 보고했습니다. 이번 업데이트를 통해 모든 서버 블록에서prometheus
플러그인을 사용하도록 DNS Operator가 변경되었습니다. 이제 CoreDNS는 사용자 정의 업스트림 확인에 대한 Prometheus 메트릭을 보고합니다. (BZ#2020489) -
이전에는 512자보다 큰 응답을 제공한 업스트림 DNS로 인해 애플리케이션이 실패했습니다. 이는 DNS에 리포지토리를 확인할 수 없기 때문에 GitHub에서 리포지토리를 복제할 수 없기 때문에 발생했습니다. 이번 업데이트를 통해 GitHub의 이름 확인을 방지하기 위해 KNI CoreDNS의
bufsize
가 521로 설정됩니다. (BZ#1991067) -
DNS Operator가 피연산자를 조정할 때 Operator는 API에서 클러스터 DNS 서비스 오브젝트를 가져와서 Operator에서 서비스를 생성하거나 업데이트해야 하는지 확인합니다. 서비스가 이미 존재하는 경우 Operator는 업데이트가 필요한지 여부를 확인하는 Operator와 비교합니다. OpenShift Container Platform 4.9를 기반으로 하는 Kubernetes 1.22에서는 서비스를 위한 새로운
spec.internalTrafficPolicy
API 필드를 도입했습니다. Operator는 서비스를 생성할 때 이 필드를 비워 두지만 API는 이 필드의 기본값을 설정합니다. Operator는 이 기본값을 관찰하고 필드를 다시 빈 값으로 업데이트하려고 했습니다. 이로 인해 Operator의 업데이트 논리는 API가 서비스의 내부 트래픽 정책에 대해 설정한 기본값을 지속적으로 되돌리려고 했습니다. 이번 수정을 통해 서비스를 비교하여 업데이트가 필요한지 여부를 확인할 때 Operator는 이제spec.internalTrafficPolicy
의 빈 값과 기본값을 동일하게 처리합니다. 결과적으로 API가 서비스의spec.internalTrafficPolicy field
의 기본값을 설정하면 Operator에서 더 이상 클러스터 DNS 서비스를 업데이트하려고 시도하지 않습니다. (BZ#2002461) -
이전 버전에서는 DNS Operator에서
dnses.operator.openshift.io/default
오브젝트의spec.servers
필드에 있는 항목에 해당하는 CoreDNSCorefile
구성 맵의 서버 블록에 대한 캐시 플러그인을 활성화하지 않았습니다. 그 결과 CoreDNS는spec.servers
를 사용하여 구성된 업스트림 해석기의 응답을 캐시하지 않았습니다. 이 버그 수정을 통해 Operator가 기본 서버 블록에 대해 이미 구성한 매개변수와 동일한 매개변수를 사용하여 모든 서버 블록에 캐시 플러그인을 사용하도록 DNS Operator가 변경되었습니다. CoreDNS는 모든 업스트림 해석기의 응답을 캐시합니다. (BZ#2006803)
이미지 레지스트리
-
이전에는 내부적으로
\docker.io
가\registry-1.docker.io
에 대한 참조를 해석하여 인증 정보를 저장하는 데 사용되었습니다. 결과적으로\docker.io
이미지에 대한 인증 정보를 찾을 수 없었습니다. 이번 업데이트를 통해 자격 증명을 검색할 때\registry-1.docker.io
호스트 이름이\docker.io
로 변경되었습니다. 결과적으로 레지스트리에서\docker.io images
의 인증 정보를 올바르게 찾을 수 있습니다. (BZ#2024859) - 이전 버전에서는 이미지 정리기 작업이 실패 시 재시도하지 않았습니다. 결과적으로 단일 장애로 인해 다음에 실행될 때까지 Image Registry Operator의 성능이 저하될 수 있었습니다. 이번 수정을 통해 프루너(pruner)의 일시적인 문제로 인해 Image Registry Operator의 성능이 저하되지 않습니다. (BZ#2051692)
- 이전에는 Image Registry Operator가 정보자에서 오브젝트를 수정했습니다. 결과적으로 이러한 오브젝트는 정보 제공자에 의해 동시에 수정되어 경합 상태를 유발할 수 있었습니다. 이번 수정을 통해 컨트롤러 및 정보 제공자에게 오브젝트의 다른 복사본이 있으며 경쟁 조건이 없습니다. (BZ#2028030)
-
이전에는 Image Registry Operator의 구성 오브젝트 위치에 문제가 발생하여
TestAWSFinalizerDeleteS3Bucket
이 실패했습니다. 이번 업데이트를 통해 구성 오브젝트가 올바른 위치에 저장됩니다. 그 결과TestAWSFinalizerDeleteS3Bucket
을 실행할 때 Image Registry Operator에 더 이상 패닉 상태가 발생하지 않습니다. (BZ#2048443) -
이전 버전에서는 오류 처리로 인해
authentication required
시access denied
오류가 출력되었습니다. 이 버그로 인해 잘못된 오류 로그가 발생했습니다. Docker 배포 오류 처리를 통해 오류 출력이authentication required
에서access denied
로 변경되었습니다.access denied
오류가 더 정확한 오류 로그를 제공합니다. (BZ#1902456) - 이전에는 종료 요청 시 레지스트리가 즉시 종료되었습니다. 그 결과 라우터는 레지스트리 pod가 사라져 요청을 보낼 수 있음을 검색할 시간이 없었습니다. 이번 수정으로 Pod가 삭제되면 다른 구성 요소가 삭제를 검색할 수 있도록 몇 초 동안 활성 상태로 유지됩니다. 이제 라우터에서 업그레이드 중에 존재하지 않는 pod에 요청을 보내지 않으므로 더 이상 중단이 발생하지 않습니다. (BZ#1972827)
-
이전에는 사용 가능한 첫 번째 미러링 레지스트리에서 프록시된 레지스트리 응답을 제공했습니다. 미러 레지스트리를 사용할 수 있었지만 요청된 데이터가 없는 경우 pull-through는 필요한 데이터가 포함되어 있어도 다른 미러를 사용하려고 시도하지 않았습니다. 이번 수정을 통해 첫 번째 미러가
Not Found
로 응답한 경우 pull-through는 다른 미러 레지스트리를 시도합니다. 이제 미러 레지스트리에 데이터가 있는 경우 pull-through가 데이터를 검색할 수 있습니다. (BZ#2008539)
이미지 스트림
-
이전에는 이미지 정책 승인 플러그인이 배포 구성을 인식하지 못했습니다. 특히 상태 저장 세트가 업데이트될 수 있었습니다. 결과적으로
resolve-names
주석을 사용하면 배포 구성에서 이미지 스트림 참조가 해결되지 않은 상태로 유지됩니다. 이제 배포 구성 및 상태 저장 세트의 주석을 해결하도록 플러그인이 업데이트되었습니다. 결과적으로 이미지 스트림 태그는 생성 및 편집된 배포 구성에서 확인됩니다. (BZ#2000216) -
이전 버전에서는 글로벌 pull secret이 업데이트되면 기존 API 서버 pod pull secret이 업데이트되지 않았습니다. 이제 풀 시크릿의 마운트 지점이
/var/lib/kubelet/config.json
파일에서/var/lib/kubelet
디렉터리로 변경됩니다. 그 결과 업데이트된 풀 시크릿이 기존 API 서버 Pod에 표시됩니다. (BZ#1984592) - 이전에는 이미지 승인 플러그인이 배포 구성 템플릿 내에서 주석을 확인하지 않았습니다. 결과적으로 배포 구성 템플릿 내부의 주석은 복제본 컨트롤러에서 처리할 수 없었으며 무시됩니다. 이제 이미지 승인 플러그인이 배포 구성 템플릿을 분석합니다. 이번 수정을 통해 이미지 승인 플러그인은 배포 구성 및 템플릿에 대한 주석을 인식합니다. (BZ#2032589)
설치 프로그램
-
OpenShift Container Platform 베어 메탈 IPI 설치 프로그램은 이전에
install-config
의 호스트에 정의된 첫 번째 노드를master
역할로 필터링하지 않고 컨트롤 플레인 노드로 사용했습니다. 이제master
및worker
노드의 역할이 정의되면 인식됩니다. (BZ#2003113) - 이번 업데이트 이전에는 프로비저닝 네트워크 CIDR에 호스트 비트를 설정할 수 있었습니다. 이로 인해 프로비저닝 IP가 예상과 다르게 프로비저닝 네트워크의 다른 IP 주소와 충돌할 수 있었습니다. 이번 업데이트를 통해 검증에서는 프로비저닝 네트워크 CIDR에 호스트 비트를 포함할 수 없도록 합니다. 프로비저닝 네트워크 CIDR에 호스트 비트가 포함된 경우 설치 프로그램이 중지되고 오류 메시지를 기록합니다. (BZ#2006291)
- 이전에는 사전 진행 중 점검에서 RHOSP(Red Hat OpenStack Platform) 리소스 사용률을 고려하지 않았습니다. 그 결과 할당량이 아닌 사용률이 설치를 방해할 때 잘못된 오류 메시지와 함께 이러한 검사가 실패했습니다. 이제 사전 진행 중 점검에서 RHOSP 할당량 및 사용률을 모두 처리합니다. 할당량은 충분하지만 리소스가 충분하지 않은 경우 검사가 실패하고 오류 메시지가 올바르게 표시됩니다. (BZ#2001317)
- 이번 업데이트 이전에는 구성 파일에서 PVC를 생성할 때 oVirt Driver에서 ReadOnlyMany (ROX) 및 ReadWriteMany(RWX) 액세스 모드를 지정할 수 있었습니다. 이로 인해 드라이버가 공유 디스크를 지원하지 않고 이러한 액세스 모드를 지원할 수 없기 때문에 오류가 발생했습니다. 이번 업데이트를 통해 액세스 모드가 단일 노드 액세스로 제한되었습니다. PVC를 생성하고 오류 메시지를 기록할 때 시스템에서 ROX 또는 RWX를 지정하지 않도록 합니다. (BZ#1882983)
- 이전에는 Terraform 공급자의 디스크 업로드가 제대로 처리되지 않았습니다. 이로 인해 OpenShift Container Platform 설치 프로그램이 실패했습니다. 이번 업데이트를 통해 디스크 업로드 처리가 수정되었으며 디스크 업로드에 성공합니다. (BZ#1917893)
- 이전 버전에서는 크기가 특별한 Microsoft Azure 클러스터를 설치할 때 설치 프로그램에서 클러스터를 배포하기 위한 최소 리소스 요구 사항을 충족하는지 설치 프로그램에서 확인합니다. 이로 인해 설치 오류가 발생할 수 있었습니다. 이번 업데이트에서는 총 vCPU 수에서 사용 가능한 vCPU 수로 설치 프로그램을 변경하는지 확인합니다. 결과적으로 Operator에서 가상 머신 크기가 최소 리소스 요구 사항을 충족하지 않는 것을 알 수 있는 간결한 오류 메시지가 제공됩니다. (BZ#2025788)
- 이전에는 RHOSP(Red Hat OpenStack Platform)에 대한 RAM 검증에서 잘못된 단위를 사용하여 값을 확인했으며, 이로 인해 최소 RAM 요구 사항을 충족하지 않은 플레이버가 수락되었습니다. 이번 수정으로 RAM 검증은 이제 RAM이 충분하지 않은 플레이버를 거부합니다. (BZ#2009699)
- 이전에는 OpenShift Container Platform 컨트롤 플레인 노드에 예약 가능하고 RHOSP(Red Hat OpenStack Platform)에 배포될 때 Ingress 보안 그룹 규칙이 누락되었습니다. 이로 인해 RHOSP의 OpenShift Container Platform 배포가 전용 작업자가 없는 컴팩트 클러스터에 실패했습니다. 이번 수정에서는 컨트롤 플레인 노드를 예약할 수 있는 경우 RHOSP(Red Hat OpenStack Platform)에 Ingress 보안 그룹 규칙이 추가되었습니다. 이제 RHOSP에 컴팩트한 3노드 클러스터를 배포할 수 있습니다. (BZ#1955544)
- 이전 버전에서는 유효하지 않은 AWS 리전을 지정한 경우 설치 프로그램은 가용성 영역을 계속 시도하고 검증합니다. 이로 인해 설치 프로그램이 시간 초과되기 전에 60분 동안 응답하지 않게 되었습니다. 이제 설치 프로그램에서 가용성 영역보다 AWS 리전 및 서비스 끝점을 확인하여 설치 프로그램에서 오류를 보고하는 데 걸리는 시간을 줄입니다. (BZ#2019977)
- 이전에는 vCenter 호스트 이름이 숫자로 시작된 경우 VMware vSphere에 클러스터를 설치할 수 없었습니다. 설치 프로그램이 업데이트되었으며 더 이상 이 유형의 호스트 이름을 잘못된 것으로 처리하지 않습니다. 이제 vCenter 호스트 이름이 숫자로 시작될 때 클러스터가 성공적으로 배포됩니다. (BZ#2021607)
- 이전에는 Microsoft Azure에 클러스터를 배포할 때 사용자 지정 디스크 인스턴스 유형을 지정한 경우 클러스터가 배포되지 않을 수 있었습니다. 이로 인해 설치 프로그램에서 최소 리소스 요구 사항이 충족되었다고 잘못 결정되었기 때문입니다. 설치 프로그램이 업데이트되었으며 선택한 리전의 인스턴스 유형에 사용 가능한 vcpu 수가 최소 리소스 요구 사항을 충족하지 않는 경우 오류를 보고합니다. (BZ#2025788)
- 이전에는 AWS 클러스터를 배포할 때 사용자 지정 IAM 역할을 정의한 경우 클러스터를 제거한 후 부트스트랩 인스턴스 프로필을 수동으로 제거해야 할 수 있었습니다. 간헐적으로 설치 프로그램에서 부트스트랩 인스턴스 프로필을 제거하지 않았습니다. 설치 프로그램이 업데이트되었으며 클러스터가 제거될 때 모든 머신 인스턴스 프로필이 제거됩니다. (BZ#2028695)
- 이전에는 프로비저닝 네트워크 CIDR에 호스트 비트가 설정된 경우 기본 provisioningIP 값이 달랐습니다. 이로 인해 provisioningIP가 예상과는 다른 값이 생성되었습니다. 이러한 차이로 인해 provisioning 네트워크의 다른 IP 주소와 충돌했습니다. 이번 수정에서는 ProvisioningNetworkCIDR에 호스트 비트 세트가 없는지 확인하는 검증 사항이 추가되었습니다. 결과적으로 ProvisioningNetworkCIDR에 호스트 비트가 설정된 경우 설치 프로그램이 중지되고 검증 오류가 보고됩니다. (BZ#2006291)
-
이전에는 BMC 드라이버 IPMI가 보안 UEFI 부팅에 지원되지 않았습니다. 이로 인해 부팅에 실패했습니다. 이번 수정을 통해
UEFISecureBoot
모드가 베어 메탈 드라이버와 함께 사용되지 않도록 검증 검사가 추가되었습니다. 결과적으로 보안 UEFI 부팅이 성공적으로 수행됩니다. (BZ#2011893) - 이번 업데이트를 통해 Ignition 버전과 일치하도록 4.8 UPI 템플릿이 버전 3.1.0에서 3.2.0으로 업데이트되었습니다. (BZ#1949672)
-
이전 버전에서는 기본 레지스트리의 콘텐츠를 미러링하라는 메시지가 표시되면 OpenShift Container Platform 설치 프로그램이 검증 오류로 종료되어
imageContentSources
에 대한 잘못된install-config
파일 값이 수정되었습니다. 이번 업데이트를 통해 이제 설치 프로그램을 통해imageContentSources
값이 기본 레지스트리 이름을 지정할 수 있으며 기본 레지스트리 이름을 지정할 때 설치 프로그램이 더 이상 종료되지 않습니다. (BZ#1960378) -
이전에는 UPI ARM 템플릿이 생성된 VM(가상 머신) 인스턴스에 SSH 키를 연결했습니다. 그 결과 사용자가 제공한 SSH 키가
ed25519
유형인 경우 VM 생성이 실패합니다. 이번 업데이트를 통해 사용자가 제공한 SSH 키 유형에 관계없이 VM을 생성할 수 있습니다. (BZ#1968364) -
aws_vpc_dhcp_options_association
리소스를 성공적으로 생성하면 AWS에서 리소스가 존재하지 않는다고 보고할 수 있습니다. 결과적으로 AWS Terraform 공급자가 설치에 실패합니다. 이번 업데이트를 통해 AWS에서 리소스가 존재하는지 보고할 때까지 생성 후 일정 기간 동안aws_vpc_dhcp_options_association
리소스 쿼리를 재시도할 수 있습니다. 결과적으로aws_vpc_dhcp_options_association
리소스가 존재하지 않는 것으로 보고함에도 불구하고 설치에 성공합니다. (BZ#2032521) - 이전에는 로컬 영역이 활성화된 AWS에 OpenShift Container Platform을 설치할 때 설치 프로그램에서 가용성 영역이 아닌 로컬 영역에 일부 리소스를 생성할 수 있었습니다. 이로 인해 로드 밸런서가 로컬 영역에서 실행될 수 없기 때문에 설치 프로그램이 실패했습니다. 이번 수정을 통해 설치 프로그램은 로컬 영역을 무시하고 클러스터 구성 요소를 설치할 때 가용성 영역만 고려합니다. (BZ#1997059)
- 이전에는 구성 파일 생성을 완료하기 전에 부트스트랩 ignition 구성 파일을 Azure에 업로드할 수 있었습니다. 로컬 파일을 만들기 전에 업로드를 시작한 경우 설치에 실패합니다. 이번 수정으로 terraform은 먼저 로컬 복사본을 만드는 대신 Ignition 구성 파일을 Azure에 직접 업로드합니다. (BZ#2004313)
-
이전에는
cluster-bootstrap
및 Cluster Version Operator 구성 요소가 동일한 리소스에 대한 매니페스트를 Kubernetes API에 동시에 작성하려고 하면 경쟁 조건이 발생할 수 있었습니다. 이렇게 하면 기본 복사본으로Authentication
리소스를 덮어씁니다. 이로 인해 해당 리소스에 대한 사용자 정의가 제거될 수 있습니다. 이번 수정으로 Cluster Version Operator가 설치 프로그램에서 제공하는 매니페스트를 덮어쓰지 못했습니다. 이렇게 하면Authentication
리소스에 대한 사용자 지정 사용자 지정을 덮어쓰지 않습니다. (BZ#2008119) -
이전에는 AWS에 OpenShift Container Platform을 설치할 때 설치 프로그램에서
m5.large
인스턴스 유형을 사용하여 부트스트랩 시스템을 생성했습니다. 이로 인해 해당 인스턴스 유형을 사용할 수 없는 영역에서 설치에 실패했습니다. 이번 수정으로 부트스트랩 머신은 컨트롤 플레인 시스템과 동일한 인스턴스 유형을 사용합니다. (BZ#2016955) - 이전에는 AWS에 OpenShift Container Platform을 설치할 때 설치 프로그램에서 EC2 G 및 Intel Virtualization Technology (VT) 인스턴스를 인식하지 못하고 이를 X 인스턴스로 기본 설정했습니다. 이로 인해 이러한 인스턴스에 잘못된 인스턴스 할당량을 적용할 수 있었습니다. 이번 수정으로 설치 프로그램은 EC2 G 및 VT 인스턴스를 인식하고 올바른 인스턴스 할당량을 적용합니다. (BZ#2017874)
Kubernetes API 서버
Kubernetes 스케줄러
-
이번 업데이트 이전에는 현재 릴리스로 업그레이드해도
TaintandToleration
,NodeAffinity
및InterPodAffinity
매개변수에 대한 올바른 가중치가 설정되지 않았습니다. 이번 업데이트에서는TaintandToleration
의 가중치를3
으로,NodeAffinity
는2
,InterPodAffinity
를2
로 올바르게 설정하도록 문제를 해결합니다. (BZ#2039414) -
OpenShift Container Platform 4.10에서는 비보안 메트릭을 제공하기 위한 코드가
kube-scheduler
코드 베이스에서 제거됩니다. 이제 지표는 보안 서버를 통해서만 제공됩니다. 버그 수정 및 지원은 향후 라이프 사이클이 종료될 때 제공됩니다. 그 이후에는 새로운 기능 개선이 이루어지지 않습니다. (BZ#1889488)
Machine Config Operator
-
이전에는 MCO(Machine Config Operator)에서 OS(운영 체제) 변경 사항을 적용하기 전에 디스크에 보류 중인 구성 변경 사항을 저장했습니다. 그 결과 정전과 같은 상황에서 MCO는 다시 시작 시 OS 변경 사항이 이미 적용된 것으로 간주했으며
kargs
및kernel-rt
와 같은 변경 사항을 건너뛰었습니다. 이번 업데이트를 통해 OS 변경 사항을 적용한 후 디스크에 대한 구성 변경 사항이 저장됩니다. 이제 구성 애플리케이션 중에 전원이 손실된 경우 MCO는 다시 시작 시 설정 애플리케이션을 다시 시도해야 한다는 것을 알고 있습니다. (BZ#1916169) -
이전에는
baremetal-runtimecfg
프로젝트의 이전 버전의 Kubernetes 클라이언트 라이브러리에서 VIP 장애 조치 이후 클라이언트 연결을 시기 적절하게 닫을 수 없었습니다. 이로 인해 API를 사용하는 컨테이너 모니터링이 지연될 수 있습니다. 이번 업데이트를 통해 VIP 장애 조치 이후 클라이언트 연결을 적시에 종료할 수 있습니다. (BZ#1995021) -
이전 버전에서는 SSH 키를 업데이트할 때 MCO(Machine Config Operator)에서
authorized_keys
파일의 소유자와 그룹이root
로 변경되었습니다. 이번 업데이트에서는authorized_keys
파일을 업데이트할 때 MCO가core
를 소유자 및 그룹으로 유지할 수 있습니다. (BZ#1956739) -
이전 버전에서는
clone_slave_connection
함수에서 보낸 경고 메시지가 연결의 UUID만 저장하기위한new_uuid
변수에 잘못 저장되었습니다. 그 결과new_uuid
변수를 포함하는nmcli
명령이new_uuid
변수에 저장되는 잘못된 값으로 인해 실패했습니다. 이번 수정으로clone_slave_connection
함수 경고 메시지가stderr
로 리디렉션됩니다. 이제new_uuid
변수를 참조하는nmcli
명령이 실패하지 않습니다. (BZ#2022646) -
이전에는 이전 버전의 Kubernetes 클라이언트 라이브러리가
baremetal-runtimecfg
프로젝트에 표시되었습니다. 가상 IP(VIP)가 실패하면 클라이언트 연결이 시기 적절하게 종료되지 않을 수 있었습니다. 이로 인해 API에 대해 이야기하는 데 의존하는 컨테이너 모니터링이 지연될 수 있었습니다. 이번 수정으로 클라이언트 라이브러리가 업데이트되었습니다. 이제 VIP 장애 조치에서 예상대로 연결이 닫히고 과도한 기간 동안 모니터 컨테이너가 중단되지 않습니다. (BZ#1995021) - 이번 업데이트 이전에는 MCO(Machine Config Operator)에서 RHCOS(Red Hat Enterprise Linux CoreOS)에 적용하기 전에 디스크에 보류 중인 구성 변경 사항을 저장했습니다. 정전으로 인해 MCO가 구성 적용을 중단한 경우 MCO는 구성을 적용된 것으로 취급하고 변경 사항을 확인하지 않았습니다. 이 구성에 잘못된 변경 사항이 포함된 경우 이를 적용하지 못했습니다. 이번 업데이트를 통해 MCO는 적용된 후에만 디스크에 구성을 저장합니다. 이렇게 하면 MCO가 구성을 적용하는 동안 전원이 손실되면 다시 시작한 후 설정이 다시 적용됩니다. (BZ#1916169)
-
이번 업데이트 이전에는 MCO(Machine Config Operator)를 사용하여 SSH 키를 생성하거나 업데이트할 때
authorized_keys
파일의 소유자와 그룹을root
로 설정합니다. 이번 업데이트에서는 이러한 문제가 해결되었습니다. MCO가authorized_keys
파일을 생성하거나 업데이트할 때 파일의 소유자 및 그룹으로core
를 올바르게 설정하거나 유지합니다. (BZ#1956739) -
이전 버전에서는 SLAAC(상태 비저장 주소 자동 구성)를 사용하는 클러스터에서 Ironic
addr-gen-mode
매개변수가 OVNKubernetes 브리지에 유지되지 않았습니다. 결과적으로 브릿지를 만들 때 IPv6 주소가 변경될 수 있었습니다. 노드 IP 변경 사항이 지원되지 않으므로 이로 인해 클러스터가 중단되었습니다. 이번 수정에서는 브리지를 생성할 때addr-gen-mode
매개변수를 유지합니다. 이제 배포 프로세스 전체에서 IP 주소가 일관되게 유지됩니다. (BZ#1990625) -
이전 버전에서는 머신 구성에
spec.config.storage.files.contents.compression
매개변수가gzip
으로 설정된 압축 파일이 포함된 경우 MCD(Machine Config Daemon)에서 압축 파일을 추출하지 않고 디스크에 잘못 작성했습니다. 이번 수정으로 압축 매개 변수가gzip
으로 설정된 경우 MCD에서 압축 파일을 추출합니다. (BZ#1970218) -
이전에는
systemd
장치가 완전히 제거된 경우에만 정리되었습니다. 그 결과systemd
장치를 완전히 제거하지 않으면 마스크가 제거되지 않았기 때문에 시스템 구성을 사용하여systemd
장치를 마스킹 해제할 수 없었습니다. 이번 수정을 통해 시스템 구성에서systemd
장치를mask: true
로 구성하면 기존 마스크가 제거됩니다. 결과적으로systemd
장치는 이제 마스킹을 해제할 수 있습니다. (BZ#1966445)
관리 콘솔
-
이전에는 OperatorHub 카테고리 및 카드 링크에 유효한
href
속성이 포함되지 않았습니다. 결과적으로 OperatorHub 카테고리 및 카드 링크를 새 탭에서 열 수 없었습니다. 이번 업데이트에서는 OperatorHub 카테고리 및 카드 링크에 유효한href
속성이 추가되었습니다. 결과적으로 OperatorHub 및 해당 카드 링크를 새 탭에서 열 수 있습니다. (BZ#2013127) -
이전 버전에서는 Operand Details 페이지에서
status.conditions
속성의 conditions 테이블이 모든 다른 테이블보다 먼저 렌더링된 특수 케이스가 생성되었습니다. 결과적으로status.conditions
테이블이 설명자의 순서 규칙을 따르지 않아 사용자가 테이블 순서를 변경하려고 할 때 예기치 않은 동작이 발생했습니다. 이번 업데이트에서는status.conditions
의 특수한 경우를 제거하고, 해당 속성에 대한 설명자가 정의되지 않은 경우에만 기본적으로 렌더링할 수 있습니다. 따라서 해당 속성에 설명자가 정의되면status.condition
에 대한 테이블이 설명자 순서 지정 규칙에 따라 렌더링됩니다. (BZ#2014488) -
이전에는 리소스 세부 정보 페이지 메트릭 탭이 클러스터 범위 Thanos 끝점을 초과했습니다. 결과적으로 이 끝점에 대한 권한 부여가 없는 사용자는 모든 쿼리에 대한
401
응답을 수신하게 되었습니다. 이번 업데이트를 통해 Thanos 테넌시 끝점이 업데이트되고 중복 네임스페이스 쿼리 인수가 제거됩니다. 결과적으로 올바른 역할 기반 액세스 제어(RBAC) 권한이 있는 사용자는 리소스 세부 정보 페이지의 메트릭 탭에서 데이터를 볼 수 있습니다. (BZ#2015806) - 이전에는 Operator에서 기존 API 그룹에 API를 추가할 때 API 검색을 트리거하지 않았습니다. 그 결과 페이지를 새로 고칠 때까지 프런트 엔드에서 새 API를 볼 수 없었습니다. 이번 업데이트에서는Operator가 추가한 API를 페이지 새로 고침 없이 프런트 엔드에서 볼 수 있도록 합니다. (BZ#1815189)
- 이전에는 RHOSP(Red Hat OpenShift Cluster Manager)에서 컨트롤 플레인이 중국어 간체로 번역되지 않았습니다. 결과적으로 이름 지정은 OpenShift Container Platform 설명서와 다릅니다. 이번 업데이트에서는 Red Hat OpenShift Cluster Manager의 번역 문제가 해결되었습니다. (BZ#1982063)
-
이전에는 Red Hat OpenShift Cluster Manager에서 가상 테이블 필터링이 중단되었습니다. 결과적으로 모든 사용 가능한
nodes
가 검색 뒤에 나타나지 않았습니다. 이번 업데이트에는 Red Hat OpenShift Cluster Manager의 필터링 문제를 해결하는 새로운 가상 테이블 논리가 포함되어 있습니다. (BZ#1990255)
모니터링
이전 버전에서는 OpenShift Container Platform을 업그레이드하는 동안 동일한 노드에 두 개의 Prometheus Pod가 있거나 동일한 간격 동안 Pod가 재부팅되는 두 개의 노드가 있었기 때문에 Prometheus 서비스를 사용할 수 없었습니다. 이러한 상황은 Prometheus Pod에 노드 배치와 관련된 소프트 유사성 방지 규칙이 있고
PodDisruptionBudget
리소스가 프로비저닝되지 않았기 때문에 가능했습니다. 그 결과 메트릭이 수집되지 않았으며 일정 기간 동안 규칙이 평가되지 않았습니다.이 문제를 해결하기 위해 CVO(Cluster Monitoring Operator)에서 하드 유사성 방지 규칙을 설정하여 두 개의 Prometheus Pod가 다른 노드에 예약되도록 합니다. CMO는
PodDisruptionBudget
리소스를 프로비저닝하여 하나 이상의 Prometheus Pod가 항상 실행 중인지 확인합니다. 결과적으로 업그레이드 중에 노드가 순서대로 재부팅되어 하나 이상의 Prometheus Pod가 항상 실행되고 있는지 확인합니다. (BZ#1933847)이전에는 Thanos Ruler Pod가 포함된 노드에 중단이 발생했을 때 Thanos Ruler 서비스를 사용할 수 없었습니다. 이 상황은 Thanos Ruler Pod에 노드 배치와 관련된 소프트 유사성 방지 규칙만 있었기 때문에 발생했습니다. 그 결과 노드가 다시 온라인 상태가 될 때까지 사용자 정의 규칙이 평가되지 않았습니다.
이번 릴리스에서는 CVO(Cluster Monitoring Operator)에서 두 개의 Thanos Ruler Pod가 다른 노드에 예약되도록 하드 유사성 방지 규칙을 구성합니다. 결과적으로 단일 노드 중단으로 인해 사용자 정의 규칙 평가에 더 이상 차이가 발생하지 않습니다. (BZ#1955490)
이전 버전에서는 두 Prometheus Pod가 동일한 노드에 있고 해당 노드에 중단될 때 Prometheus 서비스를 사용할 수 없었습니다. 이 상황은 Prometheus Pod에 노드 배치와 관련된 소프트 유사성 방지 규칙만 있었기 때문에 발생했습니다. 그 결과 노드가 다시 온라인 상태가 될 때까지 메트릭이 수집되지 않았으며 규칙이 평가되지 않았습니다.
이번 릴리스에서는 두 개의 Prometheus Pod가 다른 노드에 예약되도록 Cluster Monitoring Operator에서 하드 유사성 방지 규칙을 구성합니다. 그 결과 Prometheus Pod가 다른 노드에 예약되고 단일 노드 중단에서 더 이상 모니터링에 격차가 발생하지 않습니다. (BZ#1949262)
-
이전 버전에서는 OpenShift Container Platform 패치 업그레이드 중에 3개의 Alertmanager Pod가 동일한 노드에 있거나 Alertmanager Pod를 실행하는 노드가 동시에 재부팅되었기 때문에 Alertmanager 서비스를 사용할 수 없게 되었습니다. 이 상황은 Alertmanager Pod에 노드 배치와 관련된 소프트 유사성 방지 규칙이 있고
PodDisruptionBudget
이 프로비저닝되지 않았기 때문에 가능했습니다. 이번 릴리스에서는 하드 유사성 방지 규칙 및PodDisruptionBudget
리소스를 활성화하여 Alertmanager 및 기타 모니터링 구성 요소에 대한 패치 업그레이드 중에 다운타임을 발생하지 않도록 합니다. (BZ#1955489) -
이전에는 파일 시스템 공간이 많은 Docker 이미지에 의해 점유되었을 때 false positive
NodeFilesystemSpaceFillingUp
경고가 트리거되었습니다. 이번 릴리스에서는NodeFilesystemSpaceFillingUp
경고를 발행하는 임계값이 사용 가능한 공간의 40%가 아니라 20%로 단축되어 false positive 경고가 발생하지 않습니다. (BZ#1987263) 이전 버전에서는 사용자 정의 모니터링이 활성화된 경우 Prometheus Operator 구성 요소에 대한 경고가
openshift-user-workload-monitoring
네임스페이스를 실행하는 Prometheus Operator에는 적용되지 않았습니다. 결과적으로openshift-user-workload-monitoring
네임스페이스를 관리하는 Prometheus Operator에 문제가 발생했을 때 경고가 실행되지 않습니다.이번 릴리스에서는
openshift-monitoring
및openshift-user-workload-monitoring
네임스페이스를 모두 모니터링하도록 경고가 수정되었습니다. 결과적으로 클러스터 관리자는 사용자 정의 모니터링을 관리하는 Prometheus Operator에 문제가 발생할 때 경고 알림을 받습니다. (BZ#2001566)이전 버전에서는
node-exporter
에이전트의 DaemonSet Pod 수가 클러스터의 노드 수와 일치하지 않으면CMO(Cluster Monitoring Operator)에서degraded
된 조건을 보고했습니다. 이 문제는 노드 중 하나가ready
상태에 있지 않은 경우 발생합니다.이번 릴리스에서는
node-exporter
에이전트의 DaemonSet Pod 수가 클러스터에서 준비된 노드 수보다 작은지 확인합니다. 이 프로세스에서는node-exporter
pod가 모든 활성 노드에서 실행되고 있는지 확인합니다. 그 결과 노드 중 하나가 준비 상태가 아닌 경우 CMO에서 성능이 저하된 조건을 보고하지 않습니다. (BZ#2004051)- 이번 릴리스에서는 TLS 인증서 관련 리소스가 존재하기 전에 모니터링 스택의 일부 Pod가 시작되어 실패와 재시작되는 문제가 해결되었습니다. (BZ#2016352)
-
이전 버전에서는 구성된 샘플 제한에 도달하여 보고 메트릭이 실패한 경우에도 지표 대상이 계속 웹 콘솔 UI에
Up
의 상태로 표시되었습니다. 지표 대상이 누락된 경우에도 웹 콘솔 UI에서 Up의 상태로 표시되었습니다. 이번 릴리스에서는 Prometheus가 보고 메트릭에 대한 샘플 제한 설정을 무시하므로 샘플 제한 설정과 관계없이 메트릭이 표시됩니다. (BZ#2034192)
네트워킹
- OpenShift Container Platform 4.8 이전 버전에서 OVN-Kubernetes 네트워크 제공자를 사용할 때 노드 라우팅 테이블이 라우팅 결정에 사용되었습니다. 최신 버전의 OpenShift Container Platform에서는 호스트 라우팅 테이블이 무시됩니다. 이번 릴리스에서는 트래픽 라우팅 결정에 호스트 커널 네트워킹 스택을 사용하거나 바이패스할지 여부를 지정할 수 있습니다. (BZ#1996108)
- 이전에는 프록시가 있는 제한된 설치에서 Kuryr를 사용할 때 RHOSP(Red Hat OpenStack Platform) API와의 통신을 허용하기 위해 Cluster Network Operator가 프록시를 사용하지 않았습니다. 이로 인해 클러스터 설치가 진행되지 않았습니다. 이번 업데이트를 통해 Cluster Network Operator가 프록시를 통해 RHOSP API와 통신할 수 있습니다. 결과적으로 이제 설치에 성공합니다. (BZ#1985486)
- 이번 업데이트 이전에는 SRIOV Webhook에서 RHOSP(Red Hat OpenStack Platform) 환경의 OpenShift Container Platform에서 네트워크 정책 생성을 차단했습니다. 이번 업데이트를 통해 SRIOV 웹 후크는 RHOSP 메타데이터를 읽고 검증하며 이제 네트워크 정책을 생성하는 데 사용할 수 있습니다. (BZ#2016334)
-
이전에는 SRIOV Operator에서
MachineConfig
풀 오브젝트를 일시 중지하지 않았기 때문에MachineConfig
오브젝트를 업데이트할 수 없었습니다. 이번 업데이트를 통해 SRIOV Operator는 재부팅이 필요한 구성을 실행하기 전에 관련 시스템 구성 풀을 일시 중지합니다. (BZ#2021151) -
이전에는 keepalived가 실행되어야 할 때 종료되는
keepalived
에 대한 타이밍 문제가 있었습니다. 이번 업데이트에서는 여러keepalived
명령이 단기간에 전송되지 않습니다. 결과적으로 타이밍 문제는 더 이상 문제가 되지 않으며keepalive
가 계속 실행됩니다. (BZ#2022050) - 이전에는 프록시가 있는 제한된 설치에서 Kuryr를 사용할 때 RHOSP(Red Hat OpenStack Platform) API와의 통신을 허용하기 위해 Cluster Networking Operator가 프록시를 사용하지 않았습니다. 이로 인해 클러스터 설치가 진행되지 않았습니다. 이번 업데이트를 통해 Cluster Network Operator가 프록시를 통해 RHOSP API와 통신할 수 있습니다. 결과적으로 이제 설치에 성공합니다. (BZ#1985486)
-
이전에는 Whereabouts CNI(Container Network Interface) 플러그인에서 제공하는 IP 주소와 보조 인터페이스를 사용하는 Pod가 IP 주소 소진으로 인해 컨테이너
Creating
상태가 될 수 있었습니다. 이제 Whereabouts는 이전에 추적되지 않은 재부팅과 같은 클러스터 이벤트에서 릴리스된 IP 주소를 올바르게 설명합니다. (BZ#1914053) - 이전 버전에서는 OpenShift SDN 클러스터 네트워크 공급자를 사용할 때 유휴 상태인 서비스가 유휴 상태 해제를 위해 점점 더 많은 CPU를 사용했습니다. 이번 릴리스에서는 kube-proxy의 유휴 코드가 서비스 유휴에 사용되는 CPU를 줄이기 위해 최적화되었습니다. (BZ#1966521)
- 이전에는 OVN-Kubernetes 클러스터 네트워크 공급자를 사용할 때 내부 구성 맵에 알 수 없는 필드가 있으면 클러스터 업그레이드 중에 OVN-Kubernetes Pod가 시작되지 않을 수 있었습니다. 이제 알 수 없는 필드가 있으면 실패가 아니라 경고가 발생합니다. 결과적으로 클러스터 업그레이드 중에 OVN-Kubernetes Pod가 성공적으로 시작됩니다. (BZ#1988440)
- 이전에는 SR-IOV Network Operator의 Webhook에서 OpenStack에 OpenShift 설치를 위한 네트워크 정책을 차단했습니다. SR-IOV 네트워크 정책을 생성할 수 없었습니다. 이번 업데이트에서는 Webhook가 수정되었습니다. 사용자는 OpenStack에 설치할 SR-IOV 네트워크 정책을 생성할 수 있습니다. (BZ#2016334)
-
이전에는 CRI-O 런타임 엔진에서
K8S_POD_UID
변수를 사용하여 Pod UID를 전달했습니다. 그러나 삭제된 Pod의 샌드박스에 대한 네트워킹을 설정하는 동시에 Pod를 삭제하고 다시 생성하면 이 방법으로 추가 메타데이터와 불필요한 처리가 발생했습니다. 이번 업데이트에서는 Multus에서 Pod UID를 처리하고 불필요한 메타데이터 처리를 방지합니다. (BZ#2017882) -
이전 버전에서는 단일 노드에 OpenShift를 배포할 때 SR-IOV Network Operator의 기본 설정으로 인해 사용자가 노드를 수정할 수 없었습니다. 기본적으로 구성 변경이 적용된 후 영향을 받는 노드가 드레인된 후 새 구성으로 다시 시작됩니다. 노드가 하나만 있는 경우 이 동작이 작동하지 않습니다. 이번 업데이트에서는 SR-IOV Network Operator를 단일 노드 배포에 설치하면 Operator가 구성을 변경하여
.spec.disableDrain
필드가true
로 설정됩니다. 사용자는 단일 노드 배포에서 구성 변경 사항을 성공적으로 적용할 수 있습니다. (BZ#2021151) - client-go 버전 1.20 및 이전 버전에서는 Kubernetes API에 대한 요청을 다시 시도하기에 충분한 기술이 없었습니다. 결과적으로 Kubernetes API에 대한 재시도가 충분하게 실행되지 않았습니다. 이번 업데이트에서는 client-go 1.22를 도입하여 문제를 해결합니다. (BZ#2052062)
노드
- 이전 버전에서는 CRI-O에서 관리하는 네트워크, IPC 및 UTS 네임스페이스 리소스가 Kubelet에서 중지된 Pod를 제거한 경우에만 해제되었습니다. 이번 업데이트를 통해 Pod가 중지될 때 Kubelet에서 이러한 리소스를 해제합니다. (BZ#2003193)
-
이전에는 작업자 노드에 로그인할 때
systemd-coredump
서비스 실패를 나타내는 메시지가 표시될 수 있었습니다. 이는 컨테이너에 대한system-systemd
네임스페이스가 불필요하기 때문에 발생했습니다. 이제 필터로 인해 이 네임스페이스가 워크플로우에 영향을 미치지 않습니다. (BZ#1978528) -
이전 버전에서는 클러스터를 다시 시작할 때 종료된 Pod의 상태가
Running
으로 재설정될 수 있었기 때문에 오류가 발생했습니다. 이 문제는 수정되어 종료된 모든 Pod가 종료되고 활성 상태의 Pod가 올바른 상태를 반영합니다. (BZ#1997478) - 이전 버전에서는 OpenShift Container Platform에서 특정 중지 신호가 무시되어 컨테이너의 서비스가 계속 실행되었습니다. 이제 신호 구문 분석 라이브러리를 업데이트하면 모든 정지 신호가 유지됩니다. (BZ#2000877)
- 이전 버전에서는 pod가 제거되었을 때 CRI-O에서 관리하는 Pod 네임스페이스(예: network, IPC, UTS)가 마운트 해제되지 않았습니다. 이로 인해 Open vSwitch CPU를 100%로 유도하여 Pod 대기 시간 및 기타 성능에 영향을 미쳤습니다. 이 문제는 해결되었으며 제거 시 Pod 네임스페이스를 마운트 해제합니다. (BZ#2003193)
OpenShift CLI(oc)
- 이전에는 클러스터에 설치된 CRD(사용자 정의 리소스 정의)의 수가 증가함에 따라 API 검색에 도달하는 요청이 클라이언트 코드 제한에 의해 제한되었습니다. 이제 제한 횟수와 QPS가 모두 향상되었으며 클라이언트 측 제한이 덜 자주 표시되어야 합니다. (BZ#2042059)
-
이전에는 일부 마이너 요청에 사용자 에이전트 문자열이 올바르게 설정되지 않아
oc
에 기본 Go 사용자 에이전트 문자열이 사용되었습니다. 이제 사용자 에이전트 문자열이 모든 미러 요청에 대해 올바르게 설정되고 예상되는oc
사용자 에이전트 문자열이 레지스트리에 전송됩니다. (BZ#1987257) -
이전에는
oc debug
가 Bash 쉘을 실행하려고 시도하여 Linux 기반 컨테이너를 대상으로 하는 것으로 간주했으며, Bash가 컨테이너에 없는 경우 Windows 컨테이너로 디버그하려고 했습니다.oc debug
명령에서는 Pod 선택기를 사용하여 컨테이너의 운영 체제를 확인하고 이제 Linux 및 Windows 기반 컨테이너에서 올바르게 작동합니다. (BZ#1990014) -
이전에는 여러
oc set
하위 명령에--dry-run
플래그가 제대로 작동하지 않아--dry-run=server
가 테스트 실행을 수행하지 않고 리소스에 대한 업데이트를 수행했습니다.--dry-run
플래그가 이제oc set
하위 명령에서 테스트 실행을 수행하기 위해 제대로 작동합니다. (BZ#2035393)
OpenShift 컨테이너
-
이전에는 SELinux를 사용하는 컨테이너가 누락된 정책으로 인해
/var/log/containers
로그 파일을 읽을 수 없었습니다. 이번 업데이트에서는 symlink를 통해 액세스하는 것을 포함하여/var/log
의 모든 로그 파일에 액세스할 수 있습니다. (BZ#2005997)
OpenShift Controller Manager
-
이전 버전에서는
openshift_apps_deploymentconfigs_last_failed_rollout_time
메트릭이namespace
레이블을exported_namespace
레이블 값으로 잘못 설정했습니다.openshift_apps_deploymentconfigs_last_failed_rollout_time
메트릭에 올바른namespace
레이블이 설정되어 있습니다. (BZ#2012770)
OLM(Operator Lifecycle Manager)
-
이번 업데이트 이전에는
marketplace-operator
의 기본 카탈로그 소스에서 테인트된 노드를 허용하지 않았으며CatalogSource
Pod에는 tolerations,nodeSelector
,priorityClassName
에 대한 기본 설정만 있었습니다. 이번 업데이트를 통해CatalogSource
사양에 Pod의 허용 오차,nodeSelector
,priorityClassName
을 덮어쓸 수 있는 선택적spec.grpcPodConfig
필드가 포함됩니다. (BZ#1927478) -
이번 업데이트 이전에는 OLM Operator를 다시 시작할 때
csv_suceeded
메트릭이 손실됩니다. 이번 업데이트를 통해 OLM Operator의 시작 논리가 시작될 때csv_succeeded
메트릭이 생성됩니다. (BZ#1927478) -
이번 업데이트 이전에는
oc adm catalog mirror
명령에서--max-icsp-size
플래그의 최소 및 최대 값을 설정하지 않았습니다. 결과적으로 이 필드는 0보다 작거나 너무 큰 값을 허용합니다. 이번 업데이트를 통해 값은 0보다 크고 250001보다 큰 크기로 제한됩니다. 이 범위를 벗어난 값은 유효성 검사에 실패합니다. (BZ#1972962) -
이번 업데이트 이전에는 번들 이미지에 파일 기반 카탈로그에 Operator 배포에 필요한 관련 이미지가 포함되어 있지 않았습니다. 이로 인해 CSV(ClusterServiceVersion)의
relatedImages
필드에 지정하지 않는 한 이미지가 연결이 끊긴 클러스터에 미러링되지 않았습니다. 이번 업데이트를 통해opm render
명령에서는 파일 기반 카탈로그 번들 이미지가 렌더링될 때 CSV Operator 이미지를relatedImages
파일에 추가합니다. CSV의relatedImages
필드에 나열되지 않은 경우에도 Operator 배포에 필요한 이미지가 연결 해제된 클러스터에 미러링됩니다. (BZ#2002075) -
이번 업데이트 이전에는 Operator가
skipRange
업데이트를 수행하는 데 최대 15분이 걸릴 수 있습니다. 이는 클러스터 관리자가openshift-operator-lifecycle-manager
네임스페이스에서catalog-operator
Pod를 삭제한 경우 해결할 수 있는 알려진 문제입니다. 이로 인해 Pod가 자동으로 다시 생성되고skipRange
업그레이드가 트리거됩니다. 이번 업데이트를 통해 OLM(Operator Lifecycle Manager)에서 더 이상 사용되지 않는 API 호출이 수정되었으며skipRange
업데이트가 즉시 트리거됩니다. (BZ#2002276) - 경우에 따라 OLM(Operator Lifecycle Manager)이 리스터(lister) 캐시에서 오브젝트를 수정한 동시에 클러스터의 업데이트 이벤트가 발생했습니다. 이로 인해 동시 맵 쓰기가 발생했습니다. 이번 수정을 통해 더 이상 리스터(lister) 캐시에서 검색된 오브젝트를 수정하지 않도록 OLM이 업데이트되었습니다. 대신 OLM은 적용 가능한 오브젝트의 사본을 수정합니다. 결과적으로 OLM에서 더 이상 동시 맵 쓰기가 발생하지 않습니다. (BZ#2003164)
-
이전 버전에서는 OLM(Operator Lifecycle Manager)에서 프록시를 통해서만 연결할 수 있는 카탈로그 소스 Pod에 대한 gRPC 연결을 설정할 수 없었습니다. 카탈로그 소스 Pod가 프록시 뒤에 있는 경우 OLM에서 프록시에 연결할 수 없어 호스팅된 Operator 콘텐츠를 설치할 수 없었습니다. 이번 버그 수정을 통해 OLM에서 gRPC 카탈로그 소스에 대한 연결을 설정하는 데 사용하는 프록시를 정의하는
GRPC_PROXY
환경 변수가 도입되었습니다. 결과적으로 gRPC 카탈로그 소스에 연결할 때 프록시를 사용하도록 OLM을 구성할 수 있습니다. (BZ#2011927) - 이전에는 건너뛰기된 번들이 동일한 패키지의 멤버인지 확인되지 않았습니다. 번들은 패키지를 건너뛸 수 있어 업그레이드 체인이 중단되었습니다. 이번 버그 수정을 통해 건너뛰는 번들이 동일한 패키지에 있는지 확인하는 검증 기능이 추가되었습니다. 결과적으로 번들이 다른 패키지의 번들을 건너뛸 수 없으며 그래프는 더 이상 패키지 간에 중단되지 않습니다. (BZ#2017327)
-
CatalogSource
오브젝트에서RegistryServiceStatus
필드는 OLM(Operator Lifecycle Manager)이 연결된 Pod와의 연결을 설정하는 데 사용하는 주소를 생성하는 데 사용되는 서비스 정보를 저장합니다.RegistryServiceStatus
필드가 nil이 아니며 서비스에 대한 네임스페이스, 이름 및 포트 정보가 없는 경우 연결된 Pod에 잘못된 이미지 또는 사양이 있을 때까지 OLM을 복구할 수 없습니다. 이 버그 수정을 통해 카탈로그 소스를 재구성할 때 OLM에서CatalogSource
오브젝트의RegistryServiceStatus
필드가 유효한지 확인하고 변경 사항을 반영하도록 해당 상태를 업데이트합니다. 또한 이 주소는status.GRPCConnectionState.Address
필드의 카탈로그 소스 상태에 저장됩니다. 주소가 변경되면 OLM은 이 필드를 업데이트하여 새 주소를 반영합니다. 결과적으로 카탈로그 소스의.status.connectionState.address
필드가 더 이상 nil이 아니어야 합니다. (BZ#2026343)
OpenShift API 서버
OpenShift 업데이트 서비스
RHCOS(Red Hat Enterprise Linux CoreOS)
- 이전 버전에서는 RHCOS 라이브 ISO에서 자체적으로 UEFI 부팅 항목을 추가할 때 기존 UEFI 부팅 항목 ID가 연속적이라고 가정하여 비 연속적인 부팅 항목 IDS가 있는 시스템에서 부팅할 때 UEFI 펌웨어에서 라이브 ISO가 실패했습니다. 이번 수정으로 RHCOS 라이브 ISO는 더 이상 자체적으로 UEFI 부팅 항목을 추가하지 않고 ISO가 성공적으로 부팅됩니다. (BZ#2006690)
- 사용자 제공 이미지가 이미 부팅되었는지 여부를 확인하기 위해 Ignition을 통해 시스템을 프로비저닝한 시기와 사용자 Ignition 구성이 제공되었는지를 설명하는 정보가 터미널 콘솔에 추가되었습니다. 이를 통해 Ignition이 필요할 때 실행되었는지 확인할 수 있습니다. (BZ#2016004)
- 이전에는 프로비저닝 중에 기존의 정적으로 키가 지정된 LUKS 볼륨을 재사용할 때 암호화 키가 디스크에 올바르게 기록되지 않았으며 "지속된 키 파일 누락" 오류와 함께 Ignition이 실패했습니다. 이번 수정을 통해 이제 Ignition은 재사용된 LUKS 볼륨의 키를 올바르게 작성하여 프로비저닝 중에 기존 정적으로 마운트된 LUKS 볼륨을 재사용할 수 있습니다. (BZ#2043296)
-
이전에는 RHCOS(Red Hat Enterprise Linux CoreOS) 노드를 4.6.17로 업그레이드하는 동안
ostree-finalize-staged.service
가 실패했습니다. 이 문제를 해결하기 위해 이제 sysroot 코드는/etc
에 있는 불규칙성 또는 비-symlink 파일을 무시합니다. (BZ#1945274) -
이전에는
initramfs
파일에 연결된 SCSI 장치의 by-id 심볼릭 링크에 대한 udev 규칙이 누락되었습니다. 이로 인해 이러한 심볼릭 링크를 참조하는 Ignition 구성 파일이 설치된 시스템을 부팅하지 못했습니다. 이번 업데이트를 통해 SCSI 규칙에 대한63-scsi-sg3_symlink.rules
가 dracut에 추가됩니다. (BZ#1990506) -
이전에는 베어 메탈 시스템에서
system-rfkill.service
와ostree-remount.service
간에 경쟁 상태가 발생했습니다. 결과적으로ostree-remount
서비스가 실패하고 부팅 프로세스 중에 노드 운영 체제가 충돌했습니다. 이번 업데이트를 통해 이제/sysroot/
디렉터리는 읽기 전용입니다. 결과적으로 이 문제는 더 이상 발생하지 않습니다. (BZ#1992618) - 이전에는 RHCOS(Red Hat Enterprise Linux CoreOS) 라이브 ISO 부팅에 UEFI 부팅 항목이 추가되어 TPM이 있는 시스템에서 재부팅하라는 메시지가 표시되었습니다. 이번 업데이트를 통해 RHCOS 라이브 ISO는 더 이상 UEFI 부팅 항목을 추가하지 않으므로 첫 번째 부팅 후 ISO가 재부팅을 시작하지 않습니다. (BZ#2004449)
Performance Addon Operator
-
spec.cpu.isolated
가PerformanceProfile
에 정의된 유일한 매개변수인 경우 spec.cpu.reserved' 플래그가 기본적으로 올바르게 설정되지 않을 수 있습니다.PerformanceProfile
에서spec.cpu.reserved
및spec.cpu.isolated
의 설정을 지정해야 합니다. 세트가 겹치지 않아야 하며 언급된 모든 CPU의 합계는 대상 풀의 작업자가 예상하는 모든 CPU를 포함해야 합니다. (BZ#1986681) -
이전에는 이미지에서
gather-sysinfo
바이너리가 누락된 경우oc adm must-gather
툴에서 노드 데이터를 수집하지 못했습니다. 이는 Dockerfile에서COPY
문으로 인해 발생했습니다. 이 문제를 방지하려면 필요한COPY
문을 Dockerfile에 추가하여 바이너리를 생성하고 복사해야 합니다. (BZ#2021036) - 이전에는 Performance Addon Operator가 CRI-O 캐시에서 사용 가능한지 확인하지 않고 레지스트리에서 해당 이미지를 다운로드했습니다. 결과적으로 Performance Addon Operator가 레지스트리에 연결할 수 없거나 다운로드 시간이 초과된 경우 시작하지 못했습니다. 이번 업데이트를 통해 Operator는 CRI-O 캐시에서 이미지를 가져올 수 없는 경우에만 레지스트리에서 이미지를 다운로드합니다. (BZ#2021202)
-
OpenShift Container Platform을 버전 4.10으로 업그레이드할 때 줄 시작 부분에서 시작되지 않는 조정된 프로필의 주석(
#comment
)으로 인해 구문 분석 오류가 발생합니다. Performance Addon Operator 문제는 OpenShift Container Platform과 동일한 수준(4.10)으로 업그레이드하여 해결할 수 있습니다. 주석 관련 오류는 행 시작 시 # 문자를 사용하여 모든 주석을 한 줄에 배치하여 작업할 수 있습니다. (BZ#2059934)
라우팅
- 이전 버전에서는 클러스터 관리자가 마지막 줄의 줄 바꿈 문자가 없는 기본 수신 인증서를 제공한 경우 OpenShift Container Platform 라우터에서 HAProxy에 대해 손상된 PEM 파일을 작성했습니다. 이제 입력에 줄 바꿈 문자가 없는 경우에도 유효한 PEM 파일을 작성합니다. (BZ#1894431)
-
이전 버전에서는 DNS 세그먼트의 결합된 이름과 네임스페이스가 63자 보다 큰 경로가 생성되었습니다. 이로 인해 업그레이드된 OpenShift Container Platform 버전과 통합되는 문제가 발생할 수 있습니다. 이제 주석에서 일치하지 않는 DNS 호스트 이름을 허용합니다.
AllowNonDNSCompliantHostAnnotation
이true
로 설정되면 일치하지 않는 DNS 호스트 이름 또는 63자 이상의 이름이 허용됩니다. (BZ#1964112) -
이전에는 클러스터의
ControlPlaneTopology
가External
로 설정된 경우 Cluster Ingress Operator에서 Ingress 컨트롤러에 대한 와일드카드 DNS 레코드를 생성하지 않았습니다.ControlPlaneTopology
가External
로 설정되고 Platform이 AWS인 Hypershift 클러스터에서는 Cluster Ingress Operator를 사용할 수 없습니다. 이번 업데이트에서는ControlPlaneTopology
가External
이고 플랫폼이 IBM Cloud인 경우 DNS 업데이트를 비활성화하는 것이 제한됩니다. 결과적으로 AWS에서 실행되는 Hypershift 클러스터에 대해 와일드카드 DNS 항목이 생성됩니다. (BZ#2011972) - 이전 버전에서는 Ingress Operator가 Azure Stack Hub IPI에서 클러스터 Ingress 라우터에 대한 와일드카드 DNS 레코드를 구성하지 못했으므로 클러스터 Ingress 라우터가 작동하지 않았습니다. 이번 수정으로 Ingress Operator는 구성된 ARM 끝점을 사용하여 Azure Stack Hub IPI에서 DNS를 구성합니다. 결과적으로 클러스터 Ingress 라우터가 제대로 작동합니다. (BZ#2032566)
-
이전에는 클러스터 전체 프록시 설정에서
noProxy
설정에 IPv6 주소를 허용하지 않았습니다. 결과적으로 IPv6 주소가 있는noProxy
가 있는 클러스터를 설치할 수 없었습니다. 이번 업데이트를 통해 Cluster Network Operator는 이제 클러스터 전체 프록시 리소스의noProxy
설정에 대한 IPv6 주소를 구문 분석할 수 있습니다. 결과적으로noProxy
설정에 대한 IPv6 주소를 제외할 수 있습니다. (BZ#1939435) -
OpenShift Container Platform 4.8 이전에는 IngressController API에
status.endpointPublishingStrategy.hostNetwork
및status.endpointPublishingStrategy.nodePort
필드 아래에 하위 필드가 없었습니다.spec.endpointPublishingStrategy.type
이HostNetwork
또는NodePortService
로 설정된 경우에도 이러한 필드는 null일 수 있습니다. OpenShift Container Platform 4.8에서는status.endpointPublishingStrategy.hostNetwork.protocol
및status.endpointPublishingStrategy.nodePort.protocol
하위 필드가 추가되었으며 Operator에서 "HostNetwork" 또는 "NodePortService"를 지정하는 IngressController를 승인하거나 재주문할 때 Ingress Operator에서 이러한 하위 필드의 기본값을 설정합니다. 그러나 이 버그로 인해 Operator는 이러한 사양 필드에 대한 업데이트를 무시하고spec.endpointPublishingStrategy.hostNetwork.protocol
또는spec.endpointPublishingStrategy.nodePort.protocol
을PROXY
로 업데이트하여 기존 IngressController에서 프록시 프로토콜을 활성화하지 못했습니다. 이 문제를 해결하기 위해 PROXY 프로토콜을 활성화하려면 IngressController를 삭제하고 다시 생성해야 했습니다. 이번 업데이트를 통해status.endpointPublishingStrategy.hostNetwork
및status.endpointPublishingStrategy.nodePort
가 null이고 IngressController 사양 필드에서HostNetwork
또는NodePortService
끝점 게시 전략 유형을 사용하여 프록시 프로토콜을 지정하는 경우 상태 필드를 올바르게 업데이트하도록 Ingress Operator가 변경되었습니다. 결과적으로spec.endpointPublishingStrategy.hostNetwork.protocol
또는spec.endpointPublishingStrategy.nodePort.protocol
을PROXY
로 설정하면 업그레이드된 클러스터에 올바르게 적용됩니다. (BZ#1997226)
샘플
-
이번 업데이트 이전에는 Cluster Samples Operator에
APIServerConflictError
오류가 발생하면 복구될 때까지sample-operator
를Degraded status
로 보고했습니다. 이 유형의 일시적인 오류는 업그레이드 중에 비정상적인 것은 아니지만 Operator 상태를 모니터링하는 관리자에게는 중요하지 않았습니다. 이번 업데이트를 통해 Operator에서 일시적인 오류가 발생하면Degraded status
상태로openshift-samples
를 표시하지 않고 API 서버에 다시 연결을 시도합니다. 일시적인Degraded status
로 전환이 더 이상 발생하지 않습니다. (BZ#1993840) 이번 업데이트 이전에는 클러스터 이미지 구성에서 허용되는 다양한 레지스트리 구성 옵션을 통해 Cluster Samples Operator가 이미지 스트림을 생성하지 못할 수 있습니다. 결과적으로 샘플 Operator가 degraded로 표시될 수 있으므로 일반적인 OpenShift Container Platform 설치 및 업그레이드 상태에 영향을 미쳤습니다.
다양한 상황에서 Cluster Samples Operator의 관리 상태는
Removed
로 전환할 수 있습니다. 이번 업데이트에서는 이미지 컨트롤러 구성 매개변수가 기본 이미지 레지스트리 또는samplesRegistry
설정에 지정된 이미지 레지스트리를 사용하여 이미지 스트림을 생성하지 못하는 경우가 포함됩니다. Operator 상태는 이제 클러스터 이미지 구성에서 샘플 이미지 스트림을 생성하지 않음을 나타냅니다. (BZ#2002368)
스토리지
- 이전 버전에서는 LSO(Local Storage Operator)에서 10초 지연의 누적으로 인해 고립된 PV(영구 볼륨)를 삭제하는 데 시간이 오래 걸렸습니다. 이번 업데이트에서는 LSO에서 10초 지연을 사용하지 않고 PV가 즉시 삭제되고 새 영구 볼륨 클레임에 로컬 디스크를 더 빨리 사용할 수 있습니다. (BZ#2001605)
- 이전에는 Manila 오류 처리가 Manila Operator 및 클러스터 성능이 저하되었습니다. 이제 클러스터를 다운그레이드하는 대신 Manila Operator가 비활성화되도록 오류가 치명적이 아닌 것으로 취급됩니다. (BZ#2001620)
- Cinder 사용 시와 같이 느린 클라우드 환경에서는 클러스터의 성능이 저하될 수 있습니다. 이제 OpenShift Container Platform은 느린 환경을 수용하므로 클러스터의 성능이 저하되지 않습니다. (BZ#2027685)
Telco Edge
-
생성된 정책의 ComplianceType이
mustonlyhave
인 있는 경우 OLM(Operator Lifecycle Manager)은 정책 엔진에서 CR의 '예상 (expected)' 상태를 복원하기 때문에 메타데이터에 대한 업데이트가 되돌려집니다. 결과적으로 OLM 및 정책 엔진은 충돌 시 CR의 메타데이터를 지속적으로 덮어씁니다. 그러면 CPU 사용량이 높아집니다. 이번 업데이트를 통해 OLM과 정책 엔진이 더 이상 충돌하지 않아 CPU 사용량이 줄어듭니다. (BZ#2009233) -
이전에는 기본 소스 CR에 필드가 없는 경우
PolicyGenTemplate
오버레이의 사용자 제공 필드가 생성된 매니페스트에 복사되지 않았습니다. 그 결과 일부 사용자 콘텐츠가 손실되었습니다. 모든 사용자가 제공한 모든 필드를 지원하도록policyGen
도구가 업데이트되었습니다. (BZ#2028881) - 이전에는 지원되지 않는 플랫폼에 설치할 때 DNS 조회 실패로 인해 Cluster Baremetal Operator가 계속 실패할 수 있었습니다. 이번 업데이트를 통해 지원되지 않는 플랫폼에 설치할 때 Operator는 비활성화된 상태로 유지됩니다. (BZ#2025458)
웹 콘솔(관리자 화면)
웹 콘솔 (개발자 화면)
- 이번 업데이트 이전에는 웹 콘솔의 개발자 화면에 있는 리소스에 해당 리소스에 대한 세부 정보에 대한 잘못된 링크가 있었습니다. 이번 업데이트에서는 이러한 문제가 해결되었습니다. 사용자가 리소스 세부 정보에 액세스할 수 있도록 유효한 링크를 생성합니다. (BZ#2000651)
-
이번 업데이트 이전에는 이름이 아닌 레이블별로
SinkBinding
양식의 제목만 지정할 수 있었습니다. 이번 업데이트를 통해 드롭다운 목록을 사용하여 제목을 이름 또는 레이블별로 지정할지 여부를 선택할 수 있습니다. (BZ#2002266) -
이번 업데이트 이전에는
opentekton-operators
네임스페이스에 Web Terminal Operator를 설치한 경우에만 웹 콘솔의 배너 헤드에서 웹 터미널 아이콘을 사용할 수 있었습니다. 이번 업데이트를 통해 Web Terminal Operator를 설치하는 네임스페이스와 관계없이 터미널 아이콘을 사용할 수 있습니다. (2006329) -
이번 업데이트 이전에는
ServiceBinding
CR(사용자 정의 리소스)을 정의하기 위해kind
속성 대신resource
속성을 사용한 경우 서비스 바인딩 커넥터가 토폴로지에 표시되지 않았습니다. 이번 업데이트에서는 CR의resource
속성을 읽고 토폴로지에 커넥터를 표시하여 문제를 해결합니다. (BZ#2013545) - 이번 업데이트 이전에는 이름 입력 필드에 복잡하고 재귀 정규식을 사용하여 사용자 입력을 검증했습니다. 이 정규식에서는 이름 검색이 매우 느리고 종종 오류가 발생했습니다. 이번 업데이트에서는 정규식을 최적화하고 재귀 일치를 방지하여 문제를 해결합니다. 이제 이름 검색 속도가 빠르고 오류가 발생하지 않습니다. (BZ#2014497)
- 이번 업데이트 이전에는 knative 플러그인에 의해 기여한 일부 확장에서 기능 플래그 gating이 누락되었습니다. 이 문제는 표시된 항목에는 영향을 미치지 않았지만 이러한 확장은 서버리스 Operator가 설치되지 않은 경우에도 불필요하게 실행되었습니다. 이번 업데이트에서는 확장 기능이 누락된 기능 플래그를 추가하여 문제를 해결합니다. 이제 확장이 불필요하게 실행되지 않습니다. (BZ#2016438)
-
이번 업데이트 이전에는 사용자 정의 리소스 정의 또는 Pod와 같은 리소스 세부 정보를 반복적으로 클릭하면 애플리케이션에 여러 코드 참조 오류가 발생하여
t is not a function
오류가 표시되지 않습니다. 이번 업데이트에서는 이러한 문제가 해결되었습니다. 오류가 발생하면 애플리케이션은 코드 참조를 확인하고 추가 오류를 올바르게 처리할 수 있도록 해결 상태를 저장합니다. 코드 참조 오류가 발생하면 애플리케이션이 더 이상 실패하지 않습니다. (BZ#2017130) - 이번 업데이트 이전에는 제한된 액세스 권한이 있는 사용자가 공유 네임스페이스의 구성 맵에 액세스할 수 없어 사용자 설정을 클러스터에 저장하고 다른 브라우저 또는 시스템에 로드할 수 없었습니다. 결과적으로 고정된 탐색 항목과 같은 사용자 기본 설정은 로컬 브라우저 스토리지에만 저장되었으며 여러 브라우저 간에 공유되지 않았습니다. 이번 업데이트에서는 웹 콘솔 Operator가 RBAC 규칙을 자동으로 생성하여 각 사용자가 공유 네임스페이스의 구성 맵에 이러한 설정을 저장하고 브라우저 간에 보다 쉽게 전환할 수 있도록 합니다. (BZ#2018234)
- 이번 업데이트 이전에는 토폴로지 보기에서 VM(가상 머신) 간 연결을 생성하려고 하면 "Error creating connection" 메시지와 함께 실패했습니다. 이 문제는 이 작업이 CRD(사용자 정의 리소스 정의)를 지원하지 않는 메서드에 의존했기 때문에 발생했습니다. 이번 업데이트에서는 CRD 지원을 추가하여 문제를 해결합니다. 이제 VM 간 연결을 생성할 수 있습니다. (BZ#2020904)
- 이번 업데이트 이전에는 PipelineRun 세부 정보의 작업 툴팁에 잘못된 정보가 표시되었습니다. 작업이 실행된 기간이 지난 후 경과된 시간이 표시됩니다. 예를 들어, 몇 초 전에 실행된 작업에 122시간이 표시되었습니다. 이번 업데이트를 통해 툴팁에 작업 기간이 표시됩니다. (BZ#2011368)