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

RHCOS는 이제 OpenShift Container Platform 4.13에서 RHEL (Red Hat Enterprise Linux) 9.2 패키지를 사용합니다. 이를 통해 최신 수정 사항, 기능 및 향상된 기능은 물론 최신 하드웨어 지원 및 드라이버 업데이트를 받을 수 있습니다.

설치 관리자 프로비저닝 인프라(IPI)는 OpenShift Container Platform의 전체 스택 설치 및 설정을 제공합니다.

자세한 내용은 IBM Power Virtual Server에 설치 준비를 참조하십시오.

이 기능은 OpenShift Container Platform 4.12에서 기술 프리뷰로 소개되었으며 현재 OpenShift Container Platform 4.13에서 일반적으로 사용할 수 있습니다. IBM Secure Execution은 KVM 게스트의 메모리 경계를 보호하는 하드웨어 기능 강화입니다. IBM Secure Execution은 클러스터 워크로드에 대해 최고 수준의 격리 및 보안을 제공하며 IBM Secure Execution-ready QCOW2 부팅 이미지를 사용하여 활성화할 수 있습니다.

IBM Secure Execution을 사용하려면 호스트 머신의 호스트 키가 있어야 하며 Ignition 구성 파일에 지정해야 합니다. IBM Secure Execution은 LUKS 암호화를 사용하여 부팅 볼륨을 자동으로 암호화합니다.

자세한 내용은 IBM 보안 실행을 사용하여 RHCOS 설치를 참조하십시오.

console.redhat.com 에서 지원되는 설치 관리자 SaaS는 지원 설치 관리자 사용자 인터페이스 또는 REST API를 사용하여 IBM Power, IBM Z 및 IBM® LinuxONE 플랫폼에 OpenShift Container Platform 설치를 지원합니다. 통합을 통해 사용자는 단일 인터페이스에서 인프라를 관리할 수 있습니다. IBM Power, IBM Z 및 IBM® LinuxONE과 지원 설치 관리자 SaaS와의 통합을 활성화하는 몇 가지 추가 설치 단계가 있습니다.

자세한 내용은 지원 설치 관리자를 사용하여 온프레미스 클러스터 설치를 참조하십시오.

OpenShift Container Platform 4.13에는 이제 RHCOS에 lsof 명령이 포함되어 있습니다.

OpenShift Container Platform 4.13에서는 VMware vSphere 버전 8.0을 지원합니다. VMware vSphere 버전 7.0 업데이트 2에 OpenShift Container Platform 클러스터를 계속 설치할 수 있습니다.

OpenShift Container Platform 클러스터를 단일 VMware vCenter에서 실행되는 여러 vSphere 데이터 센터 또는 리전에 배포할 수 있습니다. 각 데이터 센터는 여러 클러스터 또는 영역을 실행할 수 있습니다. 이 설정을 사용하면 하드웨어 장애 또는 네트워크 중단으로 인해 클러스터가 실패할 위험이 줄어듭니다.

자세한 내용은 VMware vSphere 리전 및 영역 사용을 참조하십시오.

vSphere에서 OpenShift Container Platform용 설치 프로그램을 실행한 후 이제 기본 install-config.yaml 파일에 vcenters 및 failureDomains 필드가 포함되어 클러스터의 여러 데이터 센터, 리전 및 영역 정보를 지정할 수 있습니다. VMware vCenter에서 실행되는 단일 데이터 센터로 구성된 vSphere 환경에 OpenShift Container Platform 클러스터를 설치하려는 경우 이러한 필드를 비워 둘 수 있습니다.

자세한 내용은 VMware vCenter의 리전 및 영역 구성을 참조하십시오.

여러 서브넷을 지원하는 외부 로드 밸런서를 사용하도록 OpenShift Container Platform 클러스터를 구성할 수 있습니다. 여러 서브넷을 사용하는 경우 로드 밸런서 대상에서 사용하는 네트워크의 모든 IP 주소를 명시적으로 나열할 수 있습니다. 이 구성을 사용하면 로드 밸런서 대상을 재구성하지 않고 해당 네트워크 내에서 노드를 생성하고 삭제할 수 있으므로 유지 관리 오버헤드가 줄어들 수 있습니다.

자세한 내용은 외부 로드 밸런서 구성을 참조하십시오.

OpenShift Container Platform 4.13의 경우 사용자 프로비저닝 인프라를 사용하여 VMware vSphere에 클러스터를 설치하기 전에 가상 머신을 암호화할 수 있습니다.

자세한 내용은 가상 머신 암호화를 위한 요구 사항을참조하십시오.

OpenShift Container Platform 4.13부터 AWS(Amazon Web Services), Microsoft Azure, GCP(Google Cloud Platform) 및 VMware vSphere에서 3노드 클러스터 배포가 지원됩니다. 이 유형의 OpenShift Container Platform 클러스터는 컴퓨팅 머신 역할을 하는 세 개의 컨트롤 플레인 시스템으로 구성되므로 더 작고 리소스 효율이 높은 클러스터입니다.

자세한 내용은 AWS에 3-노드 클러스터설치, Azure에 3-노드 클러스터설치, GCP에 3-노드 클러스터 설치, vSphere에 3-노드 클러스터 설치를 참조하십시오.

기존 VPC(가상 프라이빗 클라우드)에 OpenShift Container Platform 클러스터를 배포하는 경우 networkResourceGroupName 매개변수를 사용하여 이러한 기존 리소스가 포함된 리소스 그룹의 이름을 지정할 수 있습니다. 이번 개선된 기능을 통해 기존 VPC 리소스 및 서브넷을 설치 프로그램이 프로비저닝하는 클러스터 리소스와 별도로 유지할 수 있습니다. 그런 다음 resourceGroupName 매개변수를 사용하여 설치 프로그램에서 프로비저닝한 모든 클러스터 리소스를 배포하는 데 사용할 수 있는 기존 리소스 그룹의 이름을 지정할 수 있습니다. resourceGroupName 이 정의되지 않은 경우 클러스터에 대한 새 리소스 그룹이 생성됩니다.

자세한 내용은 추가 IBM Cloud VPC 구성 매개변수를 참조하십시오.

OpenShift Container Platform 4.13에서는 사전 정의된 역할을 사용하는 대신 OpenShift Container Platform 클러스터를 설치하고 삭제하는 데 필요한 최소 권한을 포함하도록 사용자 정의 역할을 정의할 수 있습니다. 이러한 권한은 설치 관리자 프로비저닝 인프라 및 사용자 프로비저닝 인프라에서 사용할 수 있습니다.

OpenShift Container Platform 4.13에서는 리소스를 그룹화하고 리소스 액세스 및 비용을 관리하기 위해 Azure에서 태그를 구성할 수 있습니다. 태그에 대한 지원은 Azure Public Cloud에서 생성된 리소스와 OpenShift Container Platform 4.13에서 TP(기술 프리뷰)로만 사용할 수 있습니다. OpenShift Container Platform 클러스터 생성 중에 install-config.yaml 파일에서 Azure 리소스에 태그를 정의할 수 있습니다.

OpenShift Container Platform 4.13에서는 GCP(Google Cloud Platform)의 공유 VPC(Virtual Private Cloud)에 클러스터를 설치할 수 있습니다. 이 설치 방법은 다른 GCP 프로젝트와 VPC를 공유하도록 클러스터를 구성합니다. 공유 VPC를 사용하면 조직에서 공통 VPC 네트워크를 통해 여러 프로젝트의 리소스를 연결할 수 있습니다. 일반적인 VPC 네트워크는 내부 IP 주소를 사용하여 조직의 통신의 보안과 효율성을 높일 수 있습니다.

자세한 내용은 공유 VPC에 GCP의 클러스터 설치를 참조하십시오.

OpenShift Container Platform 4.13에서는 클러스터를 설치할 때 Shielded VMs를 사용할 수 있습니다. Shielded VM에는 보안 부팅, 펌웨어 및 무결성 모니터링, 루트킷 탐지 등 추가 보안 기능이 있습니다. 자세한 내용은 Enabling Shielded VMs and Google's documentation on Shielded VMs 에서 참조하십시오.

OpenShift Container Platform 4.13에서는 클러스터를 설치할 때 기밀성 VM을 사용할 수 있습니다. 기밀 VM은 처리되는 동안 데이터를 암호화합니다. 자세한 내용은 기밀 컴퓨팅에 대한 Google 문서를 참조하십시오. 서로 의존하지는 않지만 기밀 VM과 방패 VM을 동시에 활성화할 수 있습니다.

OpenShift Container Platform 4.13에서는 AWS VPC를 사용하는 클러스터의 설치 프로세스가 간소화됩니다. 이 릴리스에서는 AWS Local Zones에 최적화된 머신 풀인 엣지 풀도 도입되었습니다.

자세한 내용은 AWS 로컬 영역을 사용하여 클러스터 설치를 참조하십시오.

OpenShift Container Platform 4.13에서는 더 이상 사용되지 않는 여러 API를 제거한 Kubernetes 1.26을 사용합니다.

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

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

자세한 내용은 OpenShift Container Platform 4.13으로 업데이트 준비를 참조하십시오.

OpenShift Container Platform 4.13에서는 기본 제공 역할을 사용하는 대신 Microsoft Azure가 OpenShift Container Platform 클러스터를 설치하고 삭제하는 데 필요한 최소 권한을 포함하도록 사용자 정의 역할을 정의할 수 있습니다. 이러한 권한은 설치 관리자 프로비저닝 인프라 및 사용자 프로비저닝 인프라에서 사용할 수 있습니다.

OpenShift Container Platform 4.13에서는 oc adm upgrade --to-multi-arch 명령을 도입하여 단일 아키텍처 컴퓨팅 머신이 있는 클러스터를 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션할 수 있습니다. 다중 아키텍처의 매니페스트 목록에 있는 페이로드로 업데이트하면 혼합 아키텍처 컴퓨팅 머신을 클러스터에 추가할 수 있습니다.

vSphere 설치의 컨트롤 플레인 노드에서 실행하려면 VIP 주소가 필요한 경우 컨트롤 플레인 노드에서 독점적으로 실행되도록 ingressVIP 주소를 구성해야 합니다. 기본적으로 OpenShift Container Platform에서는 작업자 머신 구성 풀의 모든 노드가 ingressVIP 주소를 호스팅할 수 있습니다. vSphere 환경은 컨트롤 플레인 노드와 별도의 서브넷에 작업자 노드를 배포하므로 컨트롤 플레인 노드에서 독점적으로 실행되도록 ingressVIP 주소를 구성하면 별도의 서브넷에 작업자 노드를 배포하여 문제가 발생하지 않습니다. 자세한 내용은 vSphere의 컨트롤 플레인에서 실행되도록 네트워크 구성 요소 구성을 참조하십시오.

OpenShift Container Platform 4.13에서는 AWS(Amazon Web Services)에 단일 노드로 클러스터를 설치할 수 있습니다. 단일 노드에 설치하면 노드의 리소스 요구 사항이 증가합니다. 자세한 내용은 단일 노드에 클러스터 설치를 참조하십시오.

OpenShift Container Platform 4.13을 사용하면 Bare Metal Operator(BMO) 및 기타 메탈³ 구성 요소를 사용하여 기존 사용자 프로비저닝 인프라 클러스터에서 베어 메탈 호스트를 확장할 수 있습니다. 사용자 프로비저닝 클러스터에서 Bare Metal Operator를 사용하면 호스트의 관리 및 스케일링을 단순화하고 자동화할 수 있습니다.

BMO를 사용하면 BareMetalHost 오브젝트를 구성하여 호스트를 추가하거나 제거할 수 있습니다. BareMetalHost 오브젝트 인벤토리에 external Provisioned 로 등록하여 기존 호스트를 추적할 수도 있습니다.

BMO를 사용하여 사용자 프로비저닝 클러스터를 스케일링하는 방법에 대한 자세한 내용은 Bare Metal Operator가 있는 사용자 프로비저닝 클러스터 스케일링을 참조하십시오.

OpenShift Container Platform 4.13은 이제 64비트 ARM 아키텍처 기반 Azure 사용자 프로비저닝 설치에서 지원됩니다. 에이전트 기반 설치 프로그램은 이제 64비트 ARM 시스템에서도 지원됩니다. 인스턴스 가용성 및 설치 설명서에 대한 자세한 내용은 다른 플랫폼에 대해 지원되는 설치 방법을 참조하십시오.

OpenShift Jenkins 이미지는 이제 git-lfs 패키지를 지원합니다. 이 패키지를 사용하면 OpenShift Jenkins 이미지에서 200MB(MB)보다 큰 아티팩트를 사용할 수 있습니다.

oc-mirror 플러그인을 사용하여 디스크의 로컬 OCI Operator 카탈로그를 미러 레지스트리에 미러링할 수 있습니다. 이 기능은 이전에 OpenShift Container Platform 4.12에서 기술 프리뷰로 소개되었으며 현재 OpenShift Container Platform 4.13에서 일반적으로 사용할 수 있습니다.

이 릴리스에서는 로컬 OCI 카탈로그가 포함된 경우 다음 기능을 지원합니다.

자세한 내용은 로컬 OCI Operator 카탈로그 포함 을 참조하십시오.

RHOSP에서 여러 장애 도메인에 걸쳐 있는 클러스터를 배포할 수 있습니다. 대규모 배포의 경우 장애 도메인은 복원력과 성능을 향상시킵니다.

자세한 내용은 실패 도메인의 RHOSP 매개변수를 참조하십시오.

이제 기본 내부 로드 밸런서가 아닌 사용자 관리 로드 밸런서를 사용하여 RHOSP에 클러스터를 배포할 수 있습니다.

자세한 내용은 사용자 관리 로드 밸런서를 사용하여 OpenStack에 클러스터 설치 구성을 참조하십시오.

OpenShift Container Platform 4.13에서는 프로젝트 및 카테고리를 사용하여 Nutanix에 설치된 클러스터의 컴퓨팅 플레인 가상 머신을 구성할 수 있습니다. 프로젝트는 권한, 네트워크 및 기타 매개 변수를 관리하기 위한 사용자 역할의 논리 그룹을 정의합니다. 카테고리를 사용하여 공유 특성을 기반으로 가상 머신 그룹에 정책을 적용할 수 있습니다.

자세한 내용은 Nutanix에 클러스터 설치를 참조하십시오.

에이전트 기반 설치 관리자를 사용하여 OpenShift Container Platform 4.13을 설치하는 경우 콘솔 애플리케이션(텍스트 사용자 인터페이스 포함)은 설치 프로세스 초기에 가져오기 검사를 수행하여 현재 호스트가 구성된 릴리스 이미지를 검색할 수 있는지 확인합니다. 콘솔 애플리케이션은 사용자가 네트워크 구성을 직접 수정할 수 있도록 하여 문제 해결 문제를 지원합니다.

자세한 내용은 현재 설치 호스트가 릴리스 이미지를 가져올 수 있는지 확인을 참조하십시오.

다중 아키텍처 컴퓨팅 머신이 있는 OpenShift Container Platform 4.13 클러스터를 일반적으로 사용할 수 있습니다. Day 2 작업에서는 AWS 및 Azure 설치 관리자 프로비저닝 인프라에 다양한 아키텍처의 컴퓨팅 노드를 사용하여 클러스터를 생성할 수 있습니다. 베어 메탈에 사용자 프로비저닝 설치는 기술 프리뷰에 있습니다. 다중 아키텍처 컴퓨팅 머신을 사용하여 클러스터를 생성하는 방법에 대한 자세한 내용은 OpenShift Container Platform 클러스터에서 다중 아키텍처 컴퓨팅 머신 구성을 참조하십시오.

관리자는 VMware VSphere 인스턴스에서 실행되는 OpenShift Container Platform 클러스터에 대해 여러 장애 도메인을 지정할 수 있습니다. 즉, 데이터센터에 다양한 하드웨어 리소스 간에 주요 컨트롤 플레인과 워크로드 요소를 배포할 수 있습니다. 또한 여러 계층 2 네트워크 구성을 사용하도록 클러스터를 구성하여 노드 간 데이터 전송이 여러 네트워크에 걸쳐 확장될 수 있습니다.

자세한 내용은 VSphere에서 클러스터의 여러 장애 도메인 지정 을 참조하십시오.

이번 릴리스에서는 웹 콘솔의 개발자 화면에서 다음 작업을 수행할 수 있습니다.

OpenShift Container Platform 4.13에서 oc adm must-gather 명령에 --run-namespace 플래그를 사용할 수 있습니다. 이 플래그를 사용하여 must-gather 툴을 실행할 기존 네임스페이스를 지정할 수 있습니다.

자세한 내용은 must-gather 툴 정보를 참조하십시오.

OpenShift Container Platform 4.13에서는 새 oc CLI(명령줄 인터페이스) 플래그 --import-mode 가 다음 oc 명령에 추가되었습니다.

이 향상된 기능을 통해 사용자는 oc import-image 또는 oc tag 명령을 실행할 때 매니페스트 목록의 단일 하위 매니페스트 또는 모든 매니페스트를 가져오는 옵션을 제공하는 --import-mode 플래그를 Legacy 또는 PreserveOriginal 로 설정할 수 있습니다.

자세한 내용은 매니페스트 목록 작업을 참조하십시오.

OpenShift Container Platform 4.13에서 이미지에서 oc describe 를 실행하면 각 매니페스트의 os/arch 및 다이제스트가 반환됩니다.

OpenShift Container Platform 4.13에서는 이제 이미지 스트림에 나열된 매니페스트 이미지에 대한 지원을 일반적으로 사용할 수 있습니다.

OpenShift Container Platform에서 etcd 암호화를 활성화할 때 AES-GCM 암호화 유형이 지원됩니다. AES-GCM 암호화 유형의 암호화 키는 매주 순환됩니다.

자세한 내용은 지원되는 암호화 유형을 참조하십시오.

이번 업데이트를 통해 CloudEvent IPAddressPool 리소스의 IP 주소를 서비스, 네임스페이스 또는 둘 다에 할당할 수 있습니다. 이 기능은 IP 주소 풀에서 특정 서비스 및 네임스페이스에 IP 주소를 고정하기 위해 CloudEvent가 필요한 muti 테넌트 베어 메탈 환경에서 유용합니다. 많은 IP 주소 풀의 IP 주소를 서비스 및 네임스페이스에 할당할 수 있습니다. 그런 다음 이러한 IP 주소 풀의 우선 순위를 정의할 수 있으므로 CloudEvent에서 더 높은 우선순위 IP 주소 풀부터 시작하는 IP 주소를 할당할 수 있습니다.

IP 주소 풀의 IP 주소를 서비스 및 네임스페이스에 할당하는 방법에 대한 자세한 내용은 CloudEvent 주소 풀 구성을 참조하십시오.

이번 업데이트를 통해 다음 방법을 사용하여 두 개의 물리적 기능(PF)에서 2개의 VF(가상 기능)가 있는 본딩 인터페이스에 OpenShift Container Platform 클러스터를 배포할 수 있습니다.

듀얼 포트 NIC가 있는 노드에 OpenShift Container Platform을 설치하는 방법에 대한 자세한 내용은 SR-IOV 장치의 NIC 파티셔닝을 참조하십시오.

이번 릴리스에서는 DPDK(데이터 처리 장치) 모드에서 NIC(네트워크 인터페이스 컨트롤러) 모드로 BlueField-2 네트워크 장치를 전환할 수 있습니다.

자세한 내용은 BlueField-2를 DPU에서 NIC로 전환을 참조하십시오.

OpenShift Container Platform 4.13에서는 네트워크 카드의 MT2892 제품군 [ConnectX-6 Dx]에 대한 OvS Hardware Offload 지원이 추가되었습니다.

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

OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 OpenShift SDN 네트워크 플러그인으로 마이그레이션할 수 있습니다.

자세한 내용은 OpenShift SDN 네트워크 플러그인으로 마이그레이션을 참조하십시오.

OpenShift Container Platform 4.13은 CoreDNS를 1.10.1로 업데이트합니다. CoreDNS는 이제 원래 클라이언트 쿼리에 지정된 DNSSEC DO Bit을 사용합니다. 클라이언트가 DNSSEC를 요청하지 않는 경우 DNS 응답 UDP 패킷 크기가 줄어듭니다. 결과적으로 작은 패킷 크기로 인해 TCP 연결 재시도 및 전체 DNS 대역폭에 의해 DNS 잘림이 저하될 가능성이 줄어듭니다.

클러스터에 노드 추가를 지원하도록 클러스터 네트워크를 확장할 수 있습니다. 예를 들어 클러스터를 배포하고 10.128.0.0/19 를 클러스터 네트워크 범위와 23 의 호스트 접두사로 지정한 경우 16개의 노드로 제한됩니다. 클러스터의 CIDR 마스크를 /14 로 변경하여 이를 510 노드로 확장할 수 있습니다. 자세한 내용은 클러스터 네트워크 범위 구성을 참조하십시오.

설치 관리자 프로비저닝 vSphere 클러스터에서는 IPv4가 있는 듀얼 스택 네트워킹을 기본 IP 제품군으로, IPv6를 보조 주소 제품군으로 사용할 수 있습니다. 자세한 내용은 네트워크 구성 매개변수를 참조하십시오.

베어 메탈에 클러스터를 설치하는 동안 듀얼 스택 클러스터에서 IPv6를 기본 IP 주소 제품군으로 구성할 수 있습니다. 새 클러스터를 설치할 때 이 기능을 활성화하려면 머신 네트워크, 클러스터 네트워크, 서비스 네트워크, API VIP 및 ingress VIP의 IPv4 주소 제품군 앞에 IPv6 주소 제품군을 지정합니다.

자세한 내용은 다음 소스를 참조하십시오.

이번 릴리스에서는 Red Hat OpenShift Networking OVN-Kubernetes 네트워크 플러그인을 통해 Pod에 대한 보조 네트워크 인터페이스를 구성할 수 있습니다. 보조 네트워크로 OVN-Kubernetes는 계층 2(스위스) 토폴로지 네트워크를 지원합니다. 이는 기술 프리뷰 기능으로 사용할 수 있습니다.

보조 네트워크로 OVN-Kubernetes에 대한 자세한 내용은 OVN-Kubernetes 추가 네트워크 의 구성을 참조하십시오.

OpenShift Container Platform 4.13에서 nodeSelector 가 OVN-Kubernetes 네트워크 플러그인의 송신 방화벽 대상 사양에 추가되었습니다. 이 기능을 사용하면 하나 이상의 노드에 레이블을 추가할 수 있으며 선택한 노드의 IP 주소가 관련 규칙에 포함됩니다. 자세한 내용은 EgressFirewall에 대한 nodeSelector 예제를 참조하십시오.

이제 RHOSP에서 실행되고 Kuryr를 OVN-Kubernetes로 사용하는 클러스터를 마이그레이션할 수 있습니다.

자세한 내용은 Kuryr 네트워크 플러그인에서 OVN-Kubernetes 네트워크 플러그인으로 마이그레이션을 참조하십시오.

RHOSP에서 실행되고 OVN-Kubernetes를 사용하는 클러스터의 경우 예약 포트에 유동 IP 주소를 수동으로 다시 할당할 필요가 없습니다. 예약 포트가 한 노드에서 제거되고 다른 포트에서 다시 생성되는 경우 이제 재할당이 자동으로 수행됩니다.

OpenShift Container Platform 4.13에서는 다음과 같은 SR-IOV 장치에 대한 지원이 추가되었습니다.

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

이번 업데이트를 통해 AWS의 기본 인증 정보 요청이 수정되어 KMS(Key Management Service)에서 고객 관리 키를 다시 암호화할 수 있습니다. 수동 모드를 사용하도록 구성된 CCO(Cloud Credential Operator)가 있는 클러스터의 경우 관리자는 키 정책에 kms:ReEncrypt* 권한을 추가하여 이러한 변경 사항을 수동으로 적용해야 합니다. 다른 관리자는 이 변경의 영향을 받지 않습니다. (OCPBUGS-5410)

OpenShift Container Platform 4.13에서는 IPv4 및 IPv6 네트워크 환경에서 LVM 스토리지가 이중 스택에서 지원됩니다. 자세한 내용은 듀얼 스택 클러스터 네트워크로 변환을 참조하십시오.

OpenShift Container Platform 4.13에서는 GitOps ZTP를 통해 LVM(Logical Volume Manager Storage)을 추가하고 구성할 수 있습니다. 자세한 내용은 PolicyGenTemplate CR 및 LVM Storage를 사용하여 LVM 스토리지 구성 을 참조하십시오.

OpenShift Container Platform 4.13에서는 연결이 끊긴 환경에 LVM 스토리지를 설치할 수 있습니다. 자세한 내용은 연결이 끊긴 환경에서 LVM 스토리지 설치를 참조하십시오.

사용자 관리 암호화 기능을 사용하면 설치 중에 OpenShift Container Platform 노드 루트 볼륨을 암호화하는 키를 제공하고 모든 관리 스토리지 클래스에서 이 키를 사용하여 프로비저닝된 스토리지 볼륨을 암호화할 수 있습니다. 이를 통해 플랫폼의 기본 계정 키가 아닌 선택한 키로 스토리지 볼륨을 암호화할 수 있습니다.

이 기능은 다음 스토리지 유형을 지원합니다.

CSI(Container Storage Interface) 드라이버는 노드가 비정상적으로 중단될 때 볼륨을 자동으로 분리할 수 있습니다. 비정상적인 노드 종료가 발생하면 노드에 서비스 부족 테인트를 수동으로 추가하여 볼륨에서 자동으로 노드에서 분리할 수 있습니다. 이 기능은 기술 프리뷰 상태에서 지원됩니다.

자세한 내용은 비정상적인 노드 종료 후 CSI 볼륨 분리를 참조하십시오.

vSphere에서 실행되는 OpenShift Container Platform에서 VM(가상 머신) 및 영구 볼륨(PV)을 암호화할 수 있습니다.

자세한 내용은 vSphere 영구 디스크 암호화를 참조하십시오.

OpenShift Container Platform 4.12에는 다양한 영역 및 지역에 vSphere용 OpenShift Container Platform을 배포하는 기능이 도입되어 여러 컴퓨팅 클러스터에 배포할 수 있으므로 단일 장애 지점을 방지할 수 있습니다. OpenShift Container Platform 4.13에서는 여러 데이터센터를 통해 배포하고 설치 또는 설치 후 생성된 장애 도메인을 사용하여 토폴로지를 설정할 수 있도록 지원합니다.

자세한 내용은 vSphere CSI 토폴로지 에서 참조하십시오.

OpenShift Container Platform 4.13에서는 둘 이상의 기본 스토리지 클래스를 생성할 수 있습니다. 이 기능을 사용하면 기본값으로 정의된 두 번째 스토리지 클래스를 생성할 수 있으므로 기본 스토리지 클래스를 쉽게 변경할 수 있습니다. 그런 다음 이전 기본 스토리지 클래스에서 기본 상태를 제거하기 전에 두 개의 기본 스토리지 클래스가 일시적으로 있습니다. 짧은 시간 동안 기본 스토리지 클래스가 여러 개 있을 수 있지만 결국 하나의 기본 스토리지 클래스만 있는지 확인해야 합니다.

자세한 내용은 기본 스토리지 클래스 변경 및 다중 기본 스토리지 클래스 변경을 참조하십시오.

OpenShift Container Platform 4.13에서는 ClusterCSIDriver 오브젝트에 spec.storageClassState 필드를 도입하여 OpenShift Container Platform에서 생성한 기본 스토리지 클래스를 관리하여 여러 가지 목표를 수행할 수 있습니다.

자세한 내용은 Managing the default storage class 를 참조하십시오.

이전 버전에서는 기본 스토리지 클래스가 없는 경우 기본 스토리지 클래스를 요청한 PVC(영구 볼륨 클레임)는 수동으로 삭제하고 다시 생성하지 않는 한 기본 스토리지 클래스를 무기한 보류 상태로 남아 있었습니다. OpenShift Container Platform은 이제 이러한 PVC에 기본 스토리지 클래스를 소급적으로 할당하여 해당 PVC가 보류 중 상태로 유지되지 않도록 할 수 있습니다. 이 기능을 활성화하면 기본 스토리지 클래스가 생성되거나 기존 스토리지 클래스 중 하나가 기본값으로 선언된 후 이전에 설정된 PVC가 기본 스토리지 클래스에 할당됩니다.

이 기능은 기술 프리뷰 상태에서 지원됩니다.

자세한 내용은 Absent 기본 스토리지 클래스 를 참조하십시오.

OpenShift Container Platform은 IBM Power Virtual Server Block Storage의 CSI(Container Storage Interface) 드라이버를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다.

자세한 내용은 IBM Power Virtual Server Block CSI Driver Operator 에서 참조하십시오.

CSI(Container Storage Interface) 인라인 임시 볼륨은 OpenShift Container Platform 4.5에서 기술 프리뷰 기능으로 도입되었으므로 pod가 배포되고 Pod가 제거될 때 인라인 임시 볼륨을 생성하는 Pod 사양을 정의할 수 있습니다. 이 기능은 이제 일반적으로 사용할 수 있습니다.

이 기능은 지원되는 CSI(Container Storage Interface) 드라이버에서만 사용할 수 있습니다.

이 기능에는 CSI 볼륨 승인 플러그인이 포함되어 있습니다. 이 플러그인은 Pod 승인 시 CSI 임시 볼륨을 프로비저닝할 수 있는 개별 CSI 드라이버를 사용할 수 있는 메커니즘을 제공합니다. 관리자 또는 배포는 CSIDriver 오브젝트에 csi-ephemeral-volume-profile 레이블을 추가할 수 있으며 레이블은 Admission 플러그인에 의해 검사되고 시행, 경고 및 감사 결정에 사용됩니다.

자세한 내용은 CSI 인라인 임시 볼륨을 참조하십시오.

OpenShift Container Platform 4.8부터는 동등한 CSI(Container Storage Interface) 드라이버로 인트리 볼륨 플러그인에 대한 자동 마이그레이션을 기술 프리뷰 기능으로 사용할 수 있게 되었습니다. 이 기능은 OpenShift Container Platform 4.10에서 Azure File에 대한 지원이 제공되었습니다. OpenShift Container Platform 4.13에서는 이제 일반적으로 사용 가능한 Azure File에 대한 자동 마이그레이션을 지원합니다. Azure File의 CSI 마이그레이션은 기본적으로 활성화되어 있으며 관리자가 수행할 필요가 없습니다.

이 기능은 인트리 오브젝트를 해당 CSI 표현으로 자동 변환하므로 사용자에게 완전히 투명해야 합니다. 변환된 오브젝트는 디스크에 저장되지 않으며 사용자 데이터는 마이그레이션되지 않습니다.

in-tree 스토리지 플러그인을 참조하는 스토리지 클래스는 계속 작동하지만 기본 스토리지 클래스를 CSI 스토리지 클래스로 전환하는 것이 좋습니다.

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

이 기능은 인트리 오브젝트를 해당 CSI 표현으로 자동 변환하므로 사용자에게 완전히 투명해야 합니다. in-tree 스토리지 플러그인을 참조하는 스토리지 클래스는 계속 작동하지만 기본 스토리지 클래스를 CSI 스토리지 클래스로 전환하는 것이 좋습니다.

OpenShift Container Platform 4.8부터는 동등한 CSI(Container Storage Interface) 드라이버로 인트리 볼륨 플러그인에 대한 자동 마이그레이션을 기술 프리뷰 기능으로 사용할 수 있게 되었습니다. vSphere에 대한 지원은 OpenShift Container Platform 4.10에서 이 기능을 통해 제공되었습니다. OpenShift Container Platform 4.13에서는 일반적으로 사용 가능한 vSphere에 대한 자동 마이그레이션을 지원합니다.

OpenShift Container Platform 4.13 이상을 새로 설치하는 경우 자동 마이그레이션이 기본적으로 활성화됩니다. 그러나 OpenShift Container Platform 4.12 또는 이전 버전에서 4.13으로 업데이트할 때 vSphere에 대한 자동 CSI 마이그레이션은 옵트인하는 경우에만 수행됩니다. 마이그레이션에 옵트인하기 전에 표시된 결과를 신중하게 검토합니다.

다음 조건이 모두 true인 경우 OpenShift Container Platform 4.12에서 4.13으로, 4.13에서 4.14로 업데이트가 차단됩니다.

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

계정 간 지원을 통해 하나의 AWS(Amazon Web Services) 계정에 OpenShift Container Platform 클러스터를 사용하고 AWS EBS(Elastic File System) CSI(Container Storage Interface) 드라이버를 사용하여 다른 AWS 계정에 파일 시스템을 마운트할 수 있습니다.

자세한 내용은 AWS EFS CSI cross account support 에서 참조하십시오.

이 기능을 사용하면 OpenShift Container Platform에서 볼륨이 마운트될 때 Pod의 FSGroup을 CSI(Container Storage Interface) 드라이버에 제공할 수 있습니다. Microsoft Azure File CSI 드라이버는 이 기능에 따라 다릅니다.

OpenShift Container Platform 4.13은 일반적으로 사용 가능한 NFS(Network File System)를 사용하는 CSI(Azure File Container Storage Interface) Driver Operator를 지원합니다.

자세한 내용은 NFS 지원을 참조하십시오.

OpenShift Container Platform 4.13에서는 다음 OpenShift CLI (oc) 명령을 실행하여 시스템에 설치할 수 있는 Operator 버전 및 채널을 찾을 수 있습니다.

$ oc describe packagemanifests <operator_name> -n <catalog_namespace>

다음 명령을 실행하여 Operator 버전 및 채널 정보의 출력 형식을 지정할 수 있습니다.

$ oc get packagemanifests <operator_name> -n <catalog_namespace> -o <output_format>

자세한 내용은 특정 버전의 Operator 설치를 참조하십시오.

OLM(Operator Lifecycle Manager)의 기본 동작은 Operator 설치 중에 단순화를 제공하는 것입니다. 그러나 이러한 동작으로 인해 특히 다중 테넌트 클러스터에서 유연성이 부족할 수 있습니다.

다중 테넌트 클러스터에서 Operator 관리에 대한 지침 및 권장 솔루션이 다음 주제를 사용하여 추가되었습니다.

OLM(Operator Lifecycle Manager)은 동일한 네임스페이스에 설치된 OLM 관리 Operator를 처리합니다. 즉 서브스크립션 리소스는 관련 Operator와 동일한 네임스페이스에 배치됩니다. OLM은 실제로 관련이 없는 경우에도 버전 및 업데이트 정책과 같은 상태를 업데이트할 때 해당 상태를 고려합니다.

Operator 공동 배치 및 사용자 지정 네임스페이스를 사용하는 대체 절차에 대한 지침이 다음 주제와 함께 추가되었습니다.

클러스터에서 CSV(클러스터 서비스 버전)가 비활성화되어 있는 경우 OpenShift Container Platform 웹 콘솔이 더 나은 Operator 검색을 제공하도록 업데이트되었습니다.

클러스터 관리자가 CSV를 복사할 수 없는 경우 CSV가 실제로 모든 네임스페이스에 복사되지 않더라도 일반 사용자를 위해 모든 네임스페이스의 openshift 네임스페이스에서 CSV 복사를 표시하도록 웹 콘솔을 수정합니다. 이를 통해 일반 사용자는 네임스페이스에서 이러한 Operator의 세부 정보를 확인하고 전역적으로 설치된 Operator가 제공하는 CR(사용자 정의 리소스)을 생성할 수 있습니다.

자세한 내용은 복사된 CSV 비활성화를 참조하십시오.

이번 릴리스에서는 Operator 작성자가 Operator가 실행되는 제안된 네임스페이스에 기본 노드 선택기를 설정할 수 있습니다. 제안된 네임스페이스는 CSV( ClusterServiceVersion )에 포함된 YAML의 네임스페이스 매니페스트를 사용하여 생성됩니다. OperatorHub를 사용하여 클러스터에 Operator를 추가하면 웹 콘솔은 설치 프로세스 중에 클러스터 관리자에게 제안된 네임스페이스를 자동으로 채웁니다.

자세한 내용은 기본 노드 선택기로 제안된 네임스페이스 설정을 참조하십시오.

NodeTuning 클러스터 기능을 사용하여 NFD(Node Tuning Operator)를 활성화/비활성화할 수 있습니다. 클러스터 설치 시 비활성화된 경우 나중에 다시 활성화할 수 있습니다. 자세한 내용은 Node Tuning 기능을 참조하십시오.

자세한 내용은 Control Plane Machine Set Operator 시작하기를 참조하십시오.

이제 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지 계층을 일반적으로 사용할 수 있습니다. 이 기능을 사용하면 추가 이미지를 기본 이미지에 계층화하여 기본 RHCOS 이미지의 기능을 확장할 수 있습니다.

자세한 내용은 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지 계층 지정을 참조하십시오.

RHCOS(Red Hat Enterprise Linux CoreOS) 이미지 계층을 사용하여 RHEL(Red Hat Enterprise Linux) 및 타사 패키지를 클러스터 노드에 추가할 수 있습니다.

자세한 내용은 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지 계층 지정을 참조하십시오.

이제 RHCOS 코어 사용자의 암호를 생성할 수 있습니다. SSH 또는 oc debug node 명령을 사용하여 노드에 액세스할 수 없는 경우 이 암호를 사용하면 core 사용자를 사용하여 클라우드 공급자 직렬 콘솔 또는 베어 메탈 BMC(Baseboard Controller manager)를 통해 노드에 액세스할 수 있습니다.

자세한 내용은 노드 액세스의 코어 사용자 암호 변경을 참조하십시오.

이제 다이제스트 사양 외에도 이미지 태그를 사용하여 미러링된 레지스트리에서 이미지를 가져올 수 있습니다. 이러한 변경을 수행하기 위해 ImageContentSourcePolicy (ICSP) 오브젝트가 더 이상 사용되지 않습니다. 이제 다이제스트 사양 또는 ImageTagMirrorSet (ITMS) 오브젝트를 사용하여 이미지 태그를 사용하여 이미지를 가져오도록 ImageDigestMirrorSet (IDMS) 오브젝트를 사용할 수 있습니다.

ICSP 오브젝트를 생성하는 데 사용한 기존 YAML 파일이 있는 경우 oc adm migrate icsp 명령을 사용하여 해당 파일을 IDMS YAML 파일로 변환할 수 있습니다.

이러한 새 오브젝트에 대한 자세한 내용은 이미지 레지스트리 저장소 미러링 구성을 참조하십시오.

기존 ICSP YAML 파일을 IDMS YAML 파일로 변환하는 방법에 대한 자세한 내용은 이미지 레지스트리 저장소 미러링을 위한 ICSP (ICSP) 파일 변환을 참조하십시오.

이제 OpenShift Container Platform 4.13에서 crun 하위 수준 컨테이너 런타임을 일반적으로 사용할 수 있습니다. GA 버전에는 새로운 기능이 없습니다.

이제 OpenShift Container Platform 4.13에서 Linux Control Group 버전 2(cgroup v2)를 일반적으로 사용할 수 있습니다. GA 버전에는 새로운 기능이 없습니다.

이번 릴리스에서는 PDB(Pod 중단 예산)에 대한 비정상적인 Pod 제거 정책을 기술 프리뷰 기능으로 지정할 수 있습니다. 이는 노드를 드레이닝하는 동안 애플리케이션의 오작동을 제거하는 데 도움이 될 수 있습니다.

이 기술 프리뷰 기능을 사용하려면 TechPreviewNoUpgrade 기능 세트를 활성화해야 합니다.

자세한 내용은 비정상 Pod에 대한 제거 정책 지정을 참조하십시오.

이전에는 Machine Health Checks가 자체 대응하거나 Self Node Remediation 공급자를 사용할 수 있었습니다. 이번 릴리스에서는 베어 메탈 클러스터에서 새 Metal3 수정 공급자도 지원됩니다.

자세한 내용은 베어 메탈의 전원 기반 업데이트 적용 정보를 참조하십시오.

이 릴리스에는 스택 구성 요소 및 종속 항목을 모니터링하기 위한 다음 버전 업데이트가 포함되어 있습니다.

이번 릴리스에서는 코어 플랫폼 모니터링 및 사용자 정의 프로젝트의 Alertmanager 구성에 보안을 추가할 수 있습니다. Alertmanager가 경고를 보낼 수 있도록 수신자로 인증해야 하는 경우 수신자에 대한 인증 자격 증명이 포함된 보안을 사용하도록 Alertmanager를 구성할 수 있습니다.

이번 릴리스에서는 다음 node-exporter 수집기에 대해 CMO(Cluster Monitoring Operator) 구성 맵 설정을 사용자 지정할 수 있습니다. 다음 node-exporter 수집기는 선택 사항이며 활성화 또는 비활성화할 수 있습니다.

OpenShift Container Platform 웹 콘솔에서 노드 역할을 기반으로 노드 관련 모니터링 대시보드에서 데이터를 필터링할 수 있습니다. 작업자 노드와 같은 특정 역할의 노드에 대해서만 대시보드 데이터를 표시하려면 이 새 필터를 사용하여 관련 노드 역할을 빠르게 선택할 수 있습니다.

이 릴리스에서는 기본 플랫폼 모니터링에 대한 기술 프리뷰 기능을 도입하여 관리자가 기본 메트릭 데이터 또는 최소 양의 메트릭 데이터를 수집하도록 메트릭 수집 프로필을 설정할 수 있습니다. 최소 프로필을 활성화하면 경고와 같은 기본 모니터링 기능이 계속 작동하지만 Prometheus에 필요한 CPU 및 메모리 리소스가 감소합니다.

NUMA 리소스 Operator를 사용한 NUMA 인식 예약은 이전에 OpenShift Container Platform 4.10에서 기술 프리뷰로 도입되었으며 이제 OpenShift Container Platform 4.13에서 일반적으로 사용할 수 있습니다.

NUMA 리소스 Operator는 클러스터에서 사용 가능한 NUMA 영역에 대한 전체 이미지를 기반으로 워크로드에 대한 스케줄링을 결정하는 NUMA 인식 보조 스케줄러를 배포합니다. 이렇게 향상된 NUMA 인식 스케줄링을 통해 대기 시간에 민감한 워크로드를 단일 NUMA 영역에서 처리하여 효율성과 성능을 극대화합니다.

이번 업데이트에서는 다음 기능이 추가되었습니다.

자세한 내용은 NUMA 인식 워크로드 스케줄링을 참조하십시오.

이번 업데이트 이전에는 단일 노드 OpenShift 클러스터에만 워크로드 파티셔닝이 지원되었습니다. 이제 3-노드 컴팩트 클러스터 및 표준 클러스터의 워크로드 파티셔닝을 구성할 수도 있습니다. 워크로드 파티셔닝을 사용하여 예약된 CPU 세트에서 실행되도록 OpenShift Container Platform 서비스, 클러스터 관리 워크로드 및 인프라 Pod를 분리합니다.

자세한 내용은 워크로드 파티셔닝을 참조하십시오.

OpenShift Container Platform 4.12에는 중요 및 중요하지 않은 워크로드의 전원 상태를 설정하는 기능이 도입되었습니다. OpenShift Container Platform 4.13에서는 GitOps ZTP를 사용하여 전원 상태를 구성할 수 있습니다.

기능에 대한 자세한 내용은 PolicyGenTemplates CR을 사용하여 전원 상태 구성을 참조하십시오.

이번 릴리스에서는 GitOps ZTP와 함께 사용할 수 있는 두 가지 새로운 토폴로지 라이프사이클 관리자(TALM) 기능이 추가되었습니다.

자세한 내용은 컨테이너 이미지 사전 캐시 필터 사용을 참조하십시오.

HTTP는 이제 PTP 및 베어 메탈 이벤트 인프라에서 기본 전송입니다. AMQ Interconnect는 2024년 6월 30일부터 EOL(End of Life)입니다.

자세한 내용은 PTP 빠른 이벤트 알림 프레임워크 정보를 참조하십시오.

이제 PTP Operator를 사용하여 Intel E810 웨스트 포트 채널 NIC를 PTP 오브 마스터 시계로 구성할 수 있습니다. PTP 무지 마스터 시계는 시스템 클럭 및 네트워크 시간 동기화에 ts2phc (시간 스탬프 2 물리적 시계)를 사용합니다.

자세한 내용은 Configuring linuxptp services as a breakingmaster clock 에서 참조하십시오.

기본 컨테이너 런타임으로 crun을 구성하는 ContainerRuntimeConfig CR은 GitOps ZTP ztp-site-generate 컨테이너에 추가되었습니다.

GitOps ZTP를 사용하여 설치하는 클러스터에서 최적의 성능을 위해 단일 노드 OpenShift의 컨트롤 플레인 및 작업자 노드에 대해 crun을, 추가 Day 0 설치 매니페스트 CR과 함께 3노드 OpenShift 및 표준 클러스터에 대해 crun을 활성화합니다.

자세한 내용은 Configuring crun as the default container runtime 에서 참조하십시오.

이제 OpenShift Container Platform 설명서에서 제공되는 이점 및 작동 방식 등 etcd에 대한 개요를 확인할 수 있습니다. Kubernetes의 기본 데이터 저장소인 etcd는 etcd Operator를 통해 OpenShift Container Platform의 클러스터 구성 및 관리에 대한 안정적인 접근 방식을 제공합니다. 자세한 내용은 etcd의 개요 를 참조하십시오.

OpenShift Container Platform 설명서에는 호스트된 컨트롤 플레인 전용 섹션이 포함되어 있습니다. 이 섹션에는 호스팅된 클러스터 구성 및 관리에 대한 정보 및 기능 개요가 있습니다. 자세한 내용은 호스팅 컨트롤 플레인 을 참조하십시오.

OpenShift Container Platform 설명서에 호스트 컨트롤 플레인 업데이트에 대한 정보가 포함되어 있습니다. 호스트된 컨트롤 플레인을 업데이트하려면 호스팅 클러스터 및 노드 풀을 업데이트해야 합니다. 자세한 내용은 호스팅된 컨트롤 플레인 업데이트를 참조하십시오.