1.3. 새로운 기능 및 개선 사항

coreos-installer 프로그램으로 설치된 노드는 이전에 /boot/ignition/config.ign 파일에 설치 Ignition 구성을 유지했습니다. OpenShift Container Platform 4.9 설치 이미지부터 노드가 프로비저닝될 때 해당 파일이 제거됩니다. 이 변경 사항은 이전 bootimage를 계속 사용하므로 이전 OpenShift Container Platform 버전에 설치된 클러스터에는 영향을 미치지 않습니다.

RHCOS는 이제 OpenShift Container Platform 4.9에서 RHEL (Red Hat Enterprise Linux) 8.4 패키지를 사용합니다. 이러한 패키지는 NetworkManager 기능과 같은 최신 수정 사항, 기능 및 개선 사항 및 최신 하드웨어 지원 및 드라이버 업데이트를 제공합니다.

OpenShift Container Platform 4.9에서는 사용자 프로비저닝 인프라를 사용하여 Azure Stack Hub에 클러스터를 설치할 수 있도록 지원합니다.

배포 프로세스를 지원하기 위해 Red Hat에서 제공하는 ARM(Azure Resource Manager) 템플릿 샘플을 통합하거나 템플릿을 직접 만들 수 있습니다. 다른 방법을 통해 필요한 리소스를 자유롭게 만들 수도 있습니다. ARM 템플릿은 샘플 용으로 만 제공됩니다.

자세한 내용은 ARM 템플릿을 사용하여 Azure Stack Hub에 클러스터 설치를 참조하십시오.

업그레이드 프로세스 중에 클러스터의 노드를 일시적으로 사용할 수 없게 될 수 있습니다. 작업자 노드의 경우 시스템 상태 점검에서 이러한 노드를 비정상으로 식별하고 재부팅할 수 있습니다. 이러한 노드를 재부팅하지 않도록 OpenShift Container Platform 4.9에는 cluster.x-k8s.io/paused="" 주석이 도입되어 클러스터를 업데이트하기 전에 MachineHealthCheck 리소스를 일시 중지할 수 있습니다.

자세한 내용은 Pausing a MachineHealthCheck resource에서 참조하십시오.

Microsoft Azure용 OpenShift Container Platform 설치 프로그램은 이제 머신 CIDR 내에서 최대한 큰 서브넷을 생성합니다. 이를 통해 클러스터는 적절한 크기의 시스템 CIDR을 사용하여 클러스터의 노드 수를 수용할 수 있습니다.

OpenShift Container Platform 4.9에서는 AWS 중국 리전에 대한 지원이 도입되었습니다. 이제 cn-north-1 (Beijing) 및 cn-northwest-1 (Ningxia) 리전에 OpenShift Container Platform 클러스터를 설치하고 업데이트할 수 있습니다.

자세한 내용은 AWS 중국 리전에 클러스터 설치를 참조하십시오.

OpenShift Container Platform 4.9에서는 baremetal 네트워크에서 Virtual Media를 사용하여 provisioning 네트워크를 사용하여 배포한 설치 관리자 프로비저닝 클러스터를 확장할 수 있습니다. ProvisioningNetwork 구성 설정이 Managed로 설정된 경우 이 기능을 사용할 수 있습니다. 이 기능을 사용하려면 provisioning CR(사용자 정의 리소스)에서 virtualœViaExternalNetwork 구성 설정을 true로 설정해야 합니다. API VIP 주소를 사용하도록 머신 세트도 편집해야 합니다. 자세한 내용은 베어 메탈 네트워크에 가상 미디어를 사용하여 배포 준비에서 참조하십시오.

OpenShift Container Platform 4.9에서는 Kubernetes 1.22를 사용하며, 이에는 더 이상 사용되지 않는 많은 수의 v1beta1 API가 제거되어 있습니다.

OpenShift Container Platform 4.8.14에서는 OpenShift Container Platform 4.8에서 4.9로 클러스터를 업그레이드하기 전에 관리자가 수동으로 승인을 제공해야 한다는 요구 사항을 도입했습니다. 이는 OpenShift Container Platform 4.9로 업그레이드한 후에도 문제를 방지하기 위한 것입니다. 여기에서 제거된 API는 클러스터에서 실행 중인 워크로드, 툴 또는 기타 구성 요소에서 여전히 사용되고 있습니다. 관리자는 제거될 모든 API에 대해 클러스터를 평가하고 영향을 받는 구성 요소를 마이그레이션하여 적절한 새 API 버전을 사용해야 합니다. 이 작업이 완료되면 관리자는 관리자 승인을 제공할 수 있습니다.

모든 OpenShift Container Platform 4.8 클러스터에는 OpenShift Container Platform 4.9로 업그레이드하기 전에 이 관리자가 승인해야 합니다.

자세한 내용은 OpenShift Container Platform 4.9로 업데이트할 준비에서 참조하십시오.

OpenShift Container Platform 4.9에서는 PCI 통과를 사용하는 RHOSP(Red Hat OpenStack Platform) 배포에 대한 설치를 지원합니다.

OpenShift Container Platform 4.9에서는 etcd 3.5를 지원합니다. 클러스터를 업그레이드하기 전에 유효한 etcd 백업이 있는지 확인합니다. etcd 백업을 사용하면 업그레이드 실패가 발생할 경우 클러스터를 복원할 수 있습니다. OpenShift Container Platform 4.9에서는 etcd 업그레이드가 자동으로 수행됩니다. 클러스터의 버전 4.9로의 전환 상태에 따라 etcd 백업을 사용할 수 있습니다. 그러나 클러스터 업그레이드를 시작하기 전에 백업이 있는지 확인합니다.

OpenShift Container Platform 4.9에서는 설치 관리자 프로비저닝 인프라를 사용하여 IBM Cloud®에 클러스터를 설치할 수 있도록 지원합니다. 절차는 다음과 같은 차이점이 있지만 베어 메탈에서 설치 프로그램이 프로비저닝한 인프라와 거의 동일합니다.

자세한 내용은 IBM Cloud에 설치 프로그램 프로비저닝 클러스터 배포를 참조하십시오.

OpenShift Container Platform 4.9에서는 Fujitsu 하드웨어에 설치 관리자 프로비저닝 클러스터를 배포하고 Fujitsu iRMC(Integrated Remote Management Controller)를 사용하여 작업자 노드에 대한 BIOS 구성 지원을 추가합니다. 자세한 내용은 작업자 노드에 대한 BIOS 구성을 참조하십시오.

이번 업데이트를 통해 관리자는 이제 Node 페이지에서 노드 로그에 액세스할 수 있습니다. 노드 로그를 검토하려면 로그 탭을 클릭하여 개별 로그 파일과 저널 로그 단위 간에 전환할 수 있습니다.

이제 클러스터 대시보드의 클러스터 사용률 카드에서 노드 유형별로 필터링할 수 있습니다. 생성 시 추가 노드 유형이 목록에 표시됩니다.

이번 업데이트에서는 기본 프로젝트, 화면 및 토폴로지 뷰와 같은 설정을 사용자 지정하기 위해 사용자 환경 설정 페이지가 추가됩니다.

이번 업데이트를 통해 웹 콘솔 마스트 헤드의 프로젝트 드롭다운 메뉴에서 default projects를 숨길 수 있습니다. 검색 및 필터링 전에 default projects를 표시하도록 전환할 수 있습니다.

이번 업데이트를 통해 이제 웹 콘솔에 사용자 기본 설정을 추가할 수 있습니다. 사용자는 기본 화면, 프로젝트, 토폴로지 및 기타 기본 설정을 선택할 수 있습니다.

이제 OpenShift Container Platform의 감사 로깅 수준을 보다 세밀하게 제어할 수 있습니다. 사용자 지정 규칙을 사용하여 다른 그룹에 대해 다른 감사 정책 프로필(Default, WriteRequestBodies, AllRequestBodies, None)을 지정할 수 있습니다.

자세한 내용은 사용자 정의 규칙을 사용하여 감사 로그 정책 구성을 참조하십시오.

이제 None 감사 정책 프로필을 사용하여 OpenShift Container Platform의 감사 로깅을 비활성화할 수 있습니다.

자세한 내용은 감사 로깅 비활성화를 참조하십시오.

이제 내부 OAuth 서버의 URL을 사용자 지정할 수 있습니다. 자세한 내용은 내부 OAuth 서버 URL 사용자 지정을 참조하십시오.

OpenShift Container Platform 4.9에서는 NBDE 구성 시스템을 지속적으로 유지 관리하기 위한 새로운 절차를 제공합니다. NBDE를 사용하면 시스템을 다시 시작할 때 암호를 수동으로 입력하지 않고도 실제 및 가상 시스템에서 하드 드라이브의 root 볼륨을 암호화할 수 있습니다. 자세한 내용은 디스크 암호화 기술 정보를 참조하십시오.

OpenShift Container Platform 4.9에서는 etcd 인증서가 자동으로 교체되며 시스템에서 관리됩니다.

이제 Kubernetes API 서버 TLS 보안 프로파일 설정도 etcd에서 지원됩니다.

OpenShift Container Platform 4.9에서는 PTP에 다음 업데이트가 도입되었습니다.

자세한 내용은 linuxptp 서비스를 경계 클록으로 구성을 참조하십시오.

베어 메탈 클러스터에서 PTP 이벤트에 대한 빠른 이벤트 알림을 사용할 수 있습니다. PTP Operator는 구성된 모든 PTP 가능 네트워크 인터페이스에 대한 이벤트 알림을 생성합니다. 이벤트는 동일한 노드에서 실행되는 애플리케이션에 REST API를 통해 사용할 수 있습니다. 빠른 이벤트 알림은 AMQ Interconnect Operator에서 제공하는 AMQP(Advanced Message Queuing Protocol) 메시지 버스에서 전송합니다.

자세한 내용은 PTP 및 클럭 동기화 오류 이벤트 정보를 참조하십시오.

OVN-Kubernetes의 송신 IP 기능은 해당 네임스페이스에 여러 송신 IP 주소가 할당된 경우 지정된 네임스페이스의 노드 간에 네트워크 트래픽을 거의 균등하게 조정합니다. 각 IP 주소는 다른 노드에 있어야 합니다. 자세한 내용은 OVN-Kubernetes 프로젝트의 송신 IP 구성을 참조하십시오.

OpenShift Container Platform 4.9에서 DPDK(컨테이너 데이터 플레인 개발 키트)가 GA로 제공됩니다. 자세한 내용은 DPDK 및 RDMA 모드와 함께 VF(가상 기능) 사용을 참조하십시오.

SR-IOV는 Intel 및 Mellanox NIC의 Fast Datapath DPDK 애플리케이션과 함께 사용할 수 있도록 vhost-net을 지원합니다. SriovNetworkNodePolicy 리소스를 구성하여 이 기능을 활성화할 수 있습니다. 자세한 내용은 SR-IOV 네트워크 노드 구성 오브젝트를 참조하십시오.

단일 노드 클러스터는 SR-IOV 하드웨어 및 SR-IOV Network Operator를 지원합니다. SR-IOV 네트워크 장치를 구성하면 단일 노드가 재부팅되고 Operator의 disableDrain 필드를 구성해야 합니다. 자세한 내용은 SR-IOV Network Operator 구성을 참조하십시오.

OpenShift Container Platform 4.9에서는 Broadcom 및 Intel 하드웨어를 추가로 지원합니다.

자세한 내용은 지원되는 장치를 참조하십시오.

이 릴리스에서는 MetalLB Operator가 도입되었습니다. MetalLB Operator를 설치하고 구성한 후 MetalLB를 배포하여 베어 메탈 클러스터에서 서비스에 대한 기본 로드 밸런서 구현을 제공할 수 있습니다. 베어 메탈과 같은 기타 온프레미스 인프라도 유용할 수 있습니다.

Operator에는 사용자 정의 리소스 AddressPool이 도입되었습니다. MetalLB에서 서비스에 할당할 수 있는 IP 주소 범위를 사용하여 주소 풀을 구성합니다. LoadBalancer 유형의 서비스를 추가하면 MetalLB에서 풀의 IP 주소를 할당합니다.

이번 릴리스에서는 Red Hat은 계층 2 모드에서만 MetalLB 사용 방법을 지원합니다.

자세한 내용은 MetalLB 및 MetalLB Operator 정보를 참조하십시오.

CNI VRF 플러그인은 이전에 OpenShift Container Platform 4.7에서 기술 프리뷰 기능으로 소개되었으며 현재 OpenShift Container Platform 4.9에서 일반적으로 사용할 수 있습니다.

자세한 내용은 VRF에 보조 네트워크 할당을 참조하십시오.

이 릴리스에서는 Ingress 컨트롤러 tuningOptions 매개변수에 대한 6개의 시간 제한 구성이 도입되었습니다.

자세한 내용은 Ingress 컨트롤러 구성 매개변수를 참조하십시오.

spec.clientTLS를 설정하여 상호 TLS(mTLS) 인증을 사용하도록 Ingress 컨트롤러를 구성할 수 있습니다. clientTLS 필드에서는 클라이언트 인증서를 확인하기 위한 Ingress 컨트롤러의 구성을 지정합니다.

자세한 내용은 상호 TLS 인증 구성을 참조하십시오.

클러스터 관리자는 503, 404 또는 두 오류 페이지의 사용자 정의 HTTP 오류 코드 응답 페이지를 지정할 수 있습니다.

자세한 내용은 HAProxy 오류 코드 응답 페이지 사용자 지정을 참조하십시오.

OpenShift Container Platform 4.9에서 설치 관리자 프로비저닝 클러스터에 대한 provisioningNetworkInterface 구성 설정은 선택 사항입니다. provisioningNetworkInterface 구성 설정은 provisioning 네트워크에 사용되는 NIC 이름을 식별합니다 . OpenShift Container Platform 4.9에서는 Ironic에서 provisioning 네트워크에 연결된 NIC의 IP 주소를 식별하고 바인딩할 수 있도록 install-config.yml 파일에 bootMACAddress 구성 설정을 지정할 수도 있습니다. provisioning 사용자 정의 리소스에서 bootMACAddress 구성 설정을 대신 사용하도록 provisioningInterface 구성 설정을 생략할 수도 있습니다.

OpenShift Container Platform 4.9에서 DNS Operator managementState를 변경할 수 있습니다. DNS Operator의 managementState는 기본적으로 Managed로 설정되어 있으며 이는 DNS Operator가 리소스를 적극적으로 관리하고 있음을 의미합니다. Unmanaged로 변경할 수 있습니다. 이는 DNS Operator가 해당 리소스를 관리하지 않음을 의미합니다.

다음은 DNS Operator managementState를 변경하는 사용 사례입니다.

자세한 내용은 DNS Operator managementState 변경에서 참조하십시오.

RHOSP에서 실행되는 클러스터의 경우 로드 밸런싱을 위해 Octavia를 클라우드 공급자 옵션으로 구성할 수 있습니다.

자세한 내용은 클라우드 공급자 옵션 설정을 참조하십시오.

이번 릴리스에서는 HAProxy의 TLS 1.3 및 Modern 프로파일에 대한 Ingress 컨트롤러 지원이 추가되었습니다.

자세한 내용은 Ingress 컨트롤러 TLS 보안 프로필을 참조하십시오.

클러스터 관리자는 route.openshift.io/RequiredRouteAnnotations 라는 라우터에 대한 승인 플러그인을 추가하여 도메인별로 HTTP Strict Transport Security(HSTS) 확인을 구성할 수 있습니다. 클러스터 관리자가 HSTS를 적용하도록 이 플러그인을 구성하는 경우 클러스터 Ingress 구성의 글로벌 설정에 대해 확인된 규정 준수 HSTS 정책( ingresses.config.openshift.io/cluster )을 사용하여 새로 생성된 경로를 구성해야 합니다.

자세한 내용은 HTTP Strict Transport Security를 참조하십시오.

OpenShift Container Platform 4.9에서는 logEmptyRequests 및 HTTPEmptyRequestsPolicy 필드를 설정하여 빈 요청을 기록하거나 무시하도록 Ingress 컨트롤러를 구성할 수 있습니다.

자세한 내용은 Ingress 컨트롤러 구성 매개변수를 참조하십시오.

cluster-admin 역할을 사용하여 웹 콘솔에 로그인하면 이제 콘솔의 양식에서 클러스터의 모든 네임스페이스에 새 네트워크 정책을 생성할 수 있습니다. 이전에는 YAML에서 직접 수행할 수 있었습니다.

OpenShift Container Platform은 AWS EBS(Elastic Block Store)의 CSI(Container Storage Interface) 드라이버를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다. 이 기능은 이전에 OpenShift Container Platform 4.5에서 기술 프리뷰 기능으로 소개되었으며 현재 OpenShift Container Platform 4.9에서 일반적으로 사용 가능하며 활성화되어 있습니다.

자세한 내용은 AWS EBS CSI Driver Operator를 참조하십시오.

OpenShift Container Platform은 Azure Stack Hub 스토리지용 CSI 드라이버를 사용하여 PV를 프로비저닝할 수 있습니다. Azure Stack 포트폴리오의 일부인 Azure Stack Hub를 사용하면 온프레미스 환경에서 애플리케이션을 실행하고 데이터 센터에 Azure 서비스를 제공할 수 있습니다. 이 드라이버를 관리하는 Azure Stack Hub CSI Driver Operator는 4.9의 경우 새로 사용할 수 있으며 일반적으로 사용할 수 있습니다.

자세한 내용은 Azure Stack Hub CSI Driver Operator를 참조하십시오.

OpenShift Container Platform은 AWS EFS(Elastic File Service)용 CSI 드라이버를 사용하여 PV를 프로비저닝할 수 있습니다. 이 드라이버를 관리하는 AWS EFS CSI Driver Operator는 기술 프리뷰로 사용할 수 있습니다.

자세한 내용은 AWS EFS CSI Driver Operator에서 참조하십시오.

OpenShift Container Platform 4.8부터 동등한 CSI 드라이버로 인트리 볼륨 플러그인의 자동 마이그레이션을 기술 프리뷰 기능으로 사용할 수 있게 되었습니다. 이 기능은 이제 GCE PD(Google Compute Engine Persistent Disk) in-tree 플러그인에서 GCP(Google Cloud Platform) 영구 디스크 CSI 드라이버로 자동 마이그레이션을 지원합니다.

자세한 내용은 CSI 자동 마이그레이션을 참조하십시오.

OpenShift Container Platform 4.8부터 동등한 CSI 드라이버로 인트리 볼륨 플러그인의 자동 마이그레이션을 기술 프리뷰 기능으로 사용할 수 있게 되었습니다. 이 기능은 Azure Disk in-tree 플러그인에서 Azure Disk CSI 드라이버로 자동 마이그레이션을 지원합니다.

자세한 내용은 CSI 자동 마이그레이션을 참조하십시오.

vSphere CSI Operator Driver 스토리지 클래스에서 vSphere의 스토리지 정책을 사용합니다. OpenShift Container Platform은 클라우드 설정에 구성된 데이터 저장소를 대상으로 하는 스토리지 정책을 자동으로 생성합니다.

자세한 내용은 VMWare vSphere CSI Driver Operator에서 참조하십시오.

OpenShift Container Platform 4.9에서는 Local Storage Operator에 대한 다음과 같은 새로운 지표를 제공합니다.

자세한 내용은 로컬 볼륨을 사용한 영구 저장 장치를 참조하십시오.

OpenShift Container Platform 4.9에서는 oVirt CSI Driver에 크기 조정 기능을 추가하여 사용자가 기존 PVC(영구 볼륨 클레임)의 크기를 늘릴 수 있습니다. 이 기능을 사용하기 전에는 사용자가 크기가 증가된 새 PVC를 만들고 모든 콘텐츠를 이전 PV(영구 볼륨)에서 새 PV로 이동해야 했기 때문에 데이터가 손실될 수 있었습니다. 이제 사용자가 기존 PVC를 편집할 수 있으며 oVirt CSI 드라이버는 기본 oVirt 디스크의 크기를 조정합니다.

OpenShift Container Platform 4.9에서 통합 이미지 레지스트리는 사용자 프로비저닝 인프라를 사용하여 Microsoft Azure Stack Hub에 설치된 클러스터에 Azure Blob Storage를 사용합니다.

자세한 내용은 ARM 템플릿을 사용하여 Azure Stack Hub에 클러스터 설치를 참조하십시오.

OpenShift Container Platform 4.9부터 OLM(Operator Lifecycle Manager)은 Kubernetes 1.22를 지원합니다. 결과적으로 상당한 수의 v1beta1 API가 제거되고 v1로 업데이트되었습니다. 제거된 v1beta1 API에 의존하는 Operator는 OpenShift Container Platform 4.9에서 실행되지 않습니다. 클러스터 관리자는 클러스터를 OpenShift Container Platform 4.9로 업그레이드하기 전에 설치된 Operator 를 최신 채널로 업그레이드해야 합니다.

파일 기반 카탈로그는 OLM(Operator Lifecycle Manager) 카탈로그 형식의 최신 버전입니다. 형식은 일반 텍스트 기반(JSON 또는 YAML) 및 이전 버전의 선언적 구성 진화로 이제 더 이상 사용되지 않는 SQLite 데이터베이스 형식이며 이전 버전과 완전히 호환됩니다. 이 형식의 목표는 Operator 카탈로그 편집, 구성 가능성 및 확장성을 활성화하는 것입니다.

파일 기반 카탈로그 사양에 대한 자세한 내용은 Operator Framework 패키징 형식을 참조하십시오.

opm CLI를 사용하여 파일 기반 카탈로그 생성에 대한 지침은 사용자 정의 카탈로그 관리를 참조하십시오.

이제 OLM(Operator Lifecycle Manager)을 Single Node OpenShift(SNO) 클러스터에서 사용할 수 있으므로 셀프 서비스 Operator 설치가 가능합니다.

관리자는 이러한 문제를 성공적으로 디버깅하기 위해 다양한 하위 수준 API 또는 OLM(Operator Lifecycle Manager) Pod 로그 간의 상호 작용 프로세스를 이해할 필요가 없기 때문에 OpenShift Container Platform 4.9에서는 OLM의 다음과 같은 개선 사항이 도입되어 관리자에게 보다 이해하기 쉬운 오류 보고 및 메시지를 제공합니다.

클러스터 업그레이드를 방지하기 위해 Operator 설치가 지원되지 않거나 지속적인 업데이트 경로가 없는 경우 클러스터 업그레이드의 일부로 Operator 카탈로그의 인덱스 이미지 버전을 자동으로 변경할 수 있습니다.

olm.catalogImageTemplate 주석을 카탈로그 이미지 이름으로 설정하고 이미지 태그에 대한 템플릿을 구성할 때 Kubernetes 클러스터 버전 변수 중 하나 이상을 사용합니다.

자세한 내용은 사용자 정의 카탈로그 소스에 대한 이미지 템플릿을 참조하십시오.

OpenShift Container Platform 클러스터는 여러 노드를 사용하는 HA(고가용성) 모드로 구성하거나 단일 노드를 사용하는 비-HA 모드로 구성할 수 있습니다. 단일 노드 클러스터(SNO(Single Node OpenShift)라고도 하는 단일 노드 클러스터는 보다 보수적인 리소스 제약 조건이 있을 수 있습니다. 따라서 단일 노드 클러스터에 설치된 Operator가 적절하게 조정되고 제대로 실행되는 것이 중요합니다.

OpenShift Container Platform에 제공된 클러스터 고가용성 모드 API에 액세스하여 Operator 작성자는 Operator SDK를 사용하여 Operator가 HA 또는 비HA 모드 중 하나의 클러스터 인프라 토폴로지를 감지할 수 있습니다. 감지된 클러스터 토폴로지를 사용하여 Operator 및 관리하는 Operand 또는 워크로드 모두에 대해 리소스 요구 사항을 토폴로지에 가장 적합한 프로필로 자동 전환하는 사용자 정의 Operator 논리를 개발할 수 있습니다.

자세한 내용은 고가용성 또는 단일 노드 클러스터 감지 및 지원을 참조하십시오.

Operator 작성자는 이제 네트워크 프록시를 지원하는 Operator를 개발할 수 있습니다. 프록시가 지원되는 Operator는 환경 변수에 대한 Operator 배포를 검사하고 필요한 Operand에 변수를 전달합니다. 클러스터 관리자는 OLM(Operator Lifecycle Manager)에서 처리하는 환경 변수에 대한 프록시 지원을 구성합니다. 자세한 내용은 Go,Ansible 및 Helm을 사용하여 Operator 개발을 위한 Operator SDK 튜토리얼을 참조하십시오.

이제 bundle validate 하위 명령으로 Operator Framework 테스트 제품군을 사용하여 Kubernetes 1.22에서 제거된 API에 대한 번들 매니페스트를 확인할 수 있습니다.

예를 들면 다음과 같습니다.

$ operator-sdk bundle validate .<bundle_dir_or_image> \
  --select-optional suite=operatorframework \
  --optional-values=k8s-version=1.22

번들 매니페스트에 Kubernetes 1.22에서 제거된 API가 포함된 경우 명령에서 경고 메시지를 표시합니다. 경고 메시지에는 마이그레이션해야 하는 API와 Kubernetes API 마이그레이션 가이드에 대한 링크가 표시됩니다.

자세한 내용은 Kubernetes 1.22에서 제거된 베타 API 표 및 Operator SDK CLI 참조에서 확인하십시오.

이 릴리스에서는 이미지 레지스트리 설정에서 와일드카드 도메인을 레지스트리 소스로 사용할 수 있도록 지원합니다. 와일드카드 도메인(예: *.example.com )을 사용하면 각각 수동으로 입력하지 않고도 여러 하위 도메인에서 이미지를 푸시하고 가져오도록 클러스터를 설정할 수 있습니다. 자세한 내용은 이미지 컨트롤러 구성 매개 변수를 참조하십시오.

OpenShift Container Platform 4.9부터 컴퓨팅 머신에 RHEL (Red Hat Enterprise Linux) 8.4를 사용할 수 있습니다. 이전에는 컴퓨팅 머신에서 RHEL 8이 지원되지 않았습니다.

RHEL 7 컴퓨팅 머신을 RHEL 8로 업그레이드할 수 없습니다. 새 RHEL 8 호스트를 배포해야 하며 이전 RHEL 7 호스트를 제거해야 합니다.

이제 스케줄러 프로필을 사용하여 Pod를 예약할 수 있습니다. 이는 스케줄러 정책을 설정하는 대신 실행됩니다. 다음 스케줄러 프로필을 사용할 수 있습니다.

자세한 내용은 스케줄러 프로필을 사용하여 Pod 예약을 참조하십시오.

다음 Descheduler 프로필을 사용할 수 있습니다.

LifecycleAndUtilization 프로필에 대한 Pod 수명 값을 사용자 지정할 수도 있습니다.

자세한 내용은 Descheduler를 사용하여 Pod 제거를 참조하십시오.

Pod가 프라이빗 레지스트리에서 이미지를 가져올 수 있도록 docker/config.json 파일을 구성할 때 이제 각각 해당 레지스트리 경로와 관련된 인증 정보를 사용하여 동일한 레지스트리의 특정 리포지토리를 나열할 수 있습니다. 이전에는 지정된 레지스트리에서 하나의 리포지토리만 나열할 수 있었습니다. 이제 특정 네임스페이스로 레지스트리를 정의할 수도 있습니다.

노드 관련 지표 및 경고가 개선되어 노드의 안정성이 손상되는 시기를 미리 알 수 있습니다.

Poison Pill Operator에서 워치독 장치 사용으로 개선된 수정 기능을 제공합니다. 자세한 내용은 워치독 장치 정보를 참조하십시오.

Node Health Check Operator를 사용하여 NodeHealthCheck 컨트롤러를 배포할 수 있습니다. 컨트롤러는 비정상 노드를 식별하고 Poison Pill Operator를 사용하여 비정상 노드를 수정합니다.

모니터링 스택 구성 요소 및 종속 항목에 대한 업데이트에는 다음이 포함됩니다.

타사 Prometheus UI에 대한 링크는 OpenShift Container Platform 웹 콘솔의 Observe → Metrics 페이지에서 제거됩니다. openshift-monitoring 프로젝트의 네트워킹 경로 페이지로 이동하여 관리자 관점에서 웹 콘솔에서 Prometheus UI에 대한 경로에 계속 액세스할 수 있습니다.

기본 Grafana 대시보드를 실행하면 사용자 워크로드에서 리소스를 가져올 수 있으므로 Grafana 대시보드 배포를 비활성화할 수 있습니다.

이제 SRO(Special Resource Operator)를 사용하여 기존 OpenShift Container Platform 클러스터에서 커널 모듈 및 드라이버 배포를 관리할 수 있습니다. 현재 기술 프리뷰 기능입니다.

자세한 내용은 Special Resource Operator 정보를 참조하십시오.

Performance Addon Operator에서 구성한 kubelet 하위 구성 요소인 Memory Manager가 이제 다음 토폴로지 관리자 정책 중 하나로 구성된 노드에서 실행되는 모든 Pod에 대해 기본적으로 활성화됩니다.

OpenShift Container Platform 4.9에는 시스템 대기 시간을 측정하는 두 개의 추가 도구가 도입되었습니다.

자세한 내용은 대기 시간 테스트 실행을 참조하십시오.

OpenShift Container Platform 4.9의 클러스터 최대값 지침이 업데이트되었습니다.

해당 환경의 클러스터 한도를 추정하려면 OpenShift Container Platform Limit Calculator를 사용하십시오.

OpenShift Container Platform 4.9에서는 원격 사이트에서 베어 메탈 장비의 선언적 구성으로 새로운 에지 사이트를 프로비저닝할 수 있는 제로 터치 프로비저닝(ZTP)을 지원합니다. ZTP는 인프라 배포에 GitOps 배포 사례를 사용합니다. GitOps는 인프라 배포를 위한 프레임워크를 제공하기 위해 YAML 파일 및 기타 정의된 패턴과 같은 Git 리포지토리에 저장된 선언적 사양을 사용하여 이러한 작업을 수행합니다. 선언적 출력은 다중 사이트 배포를 위해 OCI(Open Cluster Manager)에서 활용됩니다. 자세한 내용은 대규모로 에지 사이트 프로비저닝을 참조하십시오.

OpenShift Container Platform 4.9에서 Insights Operator는 Red Hat OpenShift Cluster Manager에서 RHEL SCA(Simple Content Access) 인증서를 가져올 수 있습니다.

자세한 내용은 Insights Operator를 사용하여 RHEL Simple Content Access 인증서 가져오기를 참조하십시오.

OpenShift Container Platform 4.9에서 Insights Operator는 다음과 같은 추가 정보를 수집합니다.

Red Hat은 이러한 추가 정보를 사용하여 Insights Advisor에서 개선된 수정 단계를 제공할 수 있습니다.

이번 릴리스에서는 수동 모드에서 CCO(Cloud Credential Operator)를 구성하여 Microsoft Azure Stack Hub에 설치를 수행할 수 있습니다.

자세한 내용은 수동 모드 사용을 참조하십시오.