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

이번 릴리스에서는 외부 OpenID Connect(OIDC) ID 공급자와 직접 통합을 활성화하여 인증을 위한 토큰을 발행할 수 있습니다. 이렇게 하면 기본 제공 OAuth 서버를 무시하고 외부 ID 공급자를 직접 사용합니다.

외부 OIDC 공급자와 직접 통합하면 기본 제공 OAuth 서버의 기능에 의해 제한되는 대신 선호하는 OIDC 공급자의 고급 기능을 활용할 수 있습니다. 조직은 단일 인터페이스에서 사용자와 그룹을 관리하는 동시에 여러 클러스터와 하이브리드 환경에서 인증을 간소화할 수 있습니다. 기존 툴 및 솔루션과 통합할 수도 있습니다.

직접 인증은 기술 프리뷰 기능으로 사용할 수 있습니다.

자세한 내용은 외부 OIDC ID 공급자로 직접 인증 활성화를 참조하십시오.

OpenShift Container Platform 4.19에서 ServiceAccountTokenNodeBinding 기능이 기본적으로 활성화되어 업스트림 Kubernetes 동작과 일치합니다. 이 기능을 사용하면 기존 바인딩 옵션 외에도 서비스 계정 토큰을 노드 오브젝트에 직접 바인딩할 수 있습니다. 이러한 변경으로 인해 바인딩된 노드가 삭제될 때 자동 토큰 무효화를 통한 보안 강화와 다른 노드의 토큰 재생 공격에 대한 보호가 향상됩니다.

이 릴리스에는 OpenShift Container Platform의 etcd 에 대한 모든 기존 문서를 통합하는 etcd 섹션이 포함되어 있습니다. 자세한 내용은 etcd 개요를 참조하십시오.

OpenShift Container Platform 4.19에는 이전 릴리스의 시작하기 가이드 대신 자습서 가이드가 포함되어 있습니다. 기존 튜토리얼이 새로 고쳐지고 안내서는 이제 실습 튜토리얼 콘텐츠에만 중점을 둡니다. 또한 Red Hat 전체의 OpenShift Container Platform에 대한 기타 권장 실습 학습 리소스도 제공합니다.

자세한 내용은 튜토리얼을 참조하십시오.

이제 PolicyGenerator 리소스 및 RHACM(Red Hat Advanced Cluster Management)을 사용하여 GitOps ZTP가 있는 관리 클러스터의 정책을 배포할 수 있습니다. PolicyGenerator API는 Open Cluster Management 표준의 일부이며 일반적인 방식으로 리소스 패치를 제공하며 PolicyGenTemplate API에서는 사용할 수 없습니다. PolicyGenTemplate 리소스를 사용하여 정책을 관리하고 배포할 예정인 OpenShift Container Platform 릴리스에서는 더 이상 사용되지 않습니다.

자세한 내용은 PolicyGenerator 리소스를 사용하여 관리되는 클러스터 정책 구성 을 참조하십시오.

클러스터의 인프라 비용을 줄이는 동시에 고가용성(HA)을 유지하기 위해 두 개의 제어 평면 노드와 하나의 로컬 아비터 노드로 OpenShift Container Platform 클러스터를 구성할 수 있습니다. 이 구성은 베어메탈 설치에만 지원됩니다.

로컬 중재자 노드는 제어 평면 정족수 결정에 참여하는 비용이 저렴하고 동일한 위치에 있는 머신입니다. 표준 제어 평면 노드와 달리, 중재자 노드는 전체 제어 평면 서비스 세트를 실행하지 않습니다. 이 구성을 사용하면 3개 대신 완전히 프로비저닝된 2개의 제어 평면 노드만으로 클러스터의 HA를 유지할 수 있습니다.

이 기능을 활성화하려면 install-config.yaml 파일에서 Arbiter 머신 풀을 정의하고 TechPreviewNoUpgrade 기능 세트를 활성화해야 합니다. 자세한 내용은 로컬 중재자 노드 구성을 참조하세요.

이 릴리스에서는 구성 변경으로 인해 재부팅이 필요한 경우(예: 지연된 튜닝 변경) 스포크 클러스터 전체에서 재부팅을 조정하기 위해 Topology Aware Lifecycle Manager(TALM)에서 적용할 수 있는 ZTP 참조에 재부팅 정책이 추가되었습니다. 재부팅 정책이 적용되면 TALM은 선택된 클러스터의 대상 MachineConfigPool 개체에 있는 모든 노드를 재부팅합니다.

개별적으로 변경한 후 노드를 재부팅하는 대신, 정책을 통해 모든 구성 업데이트를 적용한 다음 단일의 조정된 재부팅을 트리거할 수 있습니다.

자세한 내용은 구성 변경에 대한 재부팅 조정을 참조하세요.

이 릴리스에서는 확장 프로그램을 설치하려고 할 때 Operator Controller가 설치 프로세스의 테스트 실행을 수행합니다. 이 연습 실행은 지정된 서비스 계정에 번들에 의해 정의된 역할과 바인딩에 대한 필수 역할 기반 액세스 제어(RBAC) 규칙이 있는지 확인합니다.

서비스 계정에 필요한 RBAC 규칙이 없으면 실제 설치가 진행되기 전에 사전 검사가 실패하고 보고서가 생성됩니다.

자세한 내용은 클러스터 확장에 대한 사전 권한 확인(기술 미리 보기)을 참조하세요.

이 릴리스를 사용하면 registry+v1 Operator 번들의 기술 미리 보기 기능으로 OwnNamespace 또는 SingleNamespace 설치 모드를 사용하여 특정 네임스페이스에 확장을 배포할 수 있습니다.

자세한 내용은 특정 네임스페이스에 클러스터 확장 배포(기술 미리 보기)를 참조하세요.

RHOSP 17.1의 호스팅 제어 평면은 이제 기술 미리 보기로 지원됩니다.

자세한 내용은 OpenStack에 호스팅된 제어 평면 배포를 참조하세요.

OpenShift Container Platform 4.18에서 Insights Operator는 Red Hat이 컨테이너의 워크로드를 더 잘 이해할 수 있도록 Insights 런타임 추출기 워크로드 데이터 수집 기능을 기술 프리뷰 기능으로 도입했습니다. 이제 4.19 버전에서 이 기능을 일반적으로 사용할 수 있습니다. Insights 런타임 추출기 기능은 런타임 워크로드 데이터를 수집하여 Red Hat으로 전송합니다.

OpenShift Container Platform 4.19에서 설치 프로그램은 Terraform 대신 Cluster API를 사용하여 IBM Cloud에 설치하는 동안 클러스터 인프라를 프로비저닝합니다.

이제 말레이시아( ap-southeast-5 ) 및 태국( ap-southeast-7 ) 지역의 Amazon Web Services(AWS)에 OpenShift Container Platform 클러스터를 설치할 수 있습니다.

자세한 내용은 지원되는 Amazon Web Services(AWS) 지역을 참조하세요.

OpenShift Container Platform 4.19에서 설치 프로그램은 Terraform 대신 Cluster API를 사용하여 Microsoft Azure Stack Hub에 설치 관리자가 프로비저닝한 인프라 설치 중에 클러스터를 프로비저닝합니다.

64비트 x86 아키텍처를 기반으로 하는 머신 유형에 대한 추가 Microsoft Azure 인스턴스 유형은 OpenShift Container Platform 4.19에서 테스트되었습니다.

Dxv6 머신 시리즈의 경우 다음 인스턴스 유형이 테스트되었습니다.

Lsv4 및 Lasv4 머신 시리즈의 경우 다음 인스턴스 유형이 테스트되었습니다.

ND 및 NV 머신 시리즈의 경우 다음 인스턴스 유형이 테스트되었습니다.

자세한 내용은 Azure에 대한 테스트된 인스턴스 유형 및 Azure 설명서 (Microsoft 설명서)를 참조하세요.

2025년 9월 30일 Microsoft Azure의 모든 새 VM(가상 머신)에 대한 기본 아웃 바운드 액세스 연결이 중단됩니다. 보안을 강화하기 위해 Azure는 인터넷에 대한 기본 액세스 권한이 꺼져 있는 보안 기반 모델로 이동하고 있습니다. 그러나 OpenShift Container Platform에 대한 구성 변경이 필요하지 않습니다. 기본적으로 설치 프로그램은 로드 밸런서에 대한 아웃 바운드 규칙을 생성합니다.

자세한 내용은 Azure 업데이트 (Microsoft 문서), Azure의 아웃바운드 연결 방법 (Microsoft 문서) 및 Azure에 클러스터를 설치 준비를 참조하십시오.

이 릴리스를 사용하면 GCP에서 추가적인 기밀 컴퓨팅 플랫폼을 사용할 수 있습니다. 설치 전에 install-config.yaml 파일에서 활성화하거나 설치 후에 머신 세트와 제어 평면 머신 세트를 사용하여 구성할 수 있는 새로운 지원 플랫폼은 다음과 같습니다.

자세한 내용은 Google Cloud Platform의 설치 구성 매개변수 , 머신 세트(제어 평면)를 사용하여 기밀 VM 구성 , 머신 세트(컴퓨팅)를 사용하여 기밀 VM 구성을 참조하세요.

이번 릴리스에서는 기본 클러스터 프로비저닝 DNS 솔루션 대신 사용자 프로비저닝 DNS(Domain Name Server)를 활성화할 수 있습니다. 예를 들어 조직의 보안 정책은 Google Cloud DNS와 같은 퍼블릭 DNS 서비스 사용을 허용하지 않을 수 있습니다. API 및 Ingress 서버의 IP 주소에 대해서만 DNS를 관리할 수 있습니다. 이 기능을 사용하는 경우 api.<cluster_name>.<base_domain>. 및 *.apps.<cluster_name>.<base_domain >. . .에 대한 레코드를 포함하는 자체 DNS 솔루션을 제공해야 합니다. 사용자 제공 DNS를 활성화하는 기능은 기술 미리 보기 기능으로 제공됩니다.

자세한 내용은 사용자 관리 DNS 활성화를 참조하십시오.

이번 릴리스에서는 여러 스토리지 디스크가 있는 VMware vSphere에 기술 프리뷰 기능으로 클러스터를 설치할 수 있습니다. 이러한 추가 디스크를 etcd 스토리지와 같은 클러스터 내의 특수 기능에 할당할 수 있습니다.

자세한 내용은 선택적 vSphere 구성 매개변수를 참조하십시오.

이번 릴리스에서는 Microsoft Azure에 클러스터를 설치할 때 부팅 진단 컬렉션을 활성화할 수 있습니다. 부팅 진단은 VM 부팅 실패를 식별하는 VM(가상 머신)의 디버깅 기능입니다. 컴퓨팅 머신, 컨트롤 플레인 시스템 또는 모든 시스템의 install-config.yaml 파일에서 bootDiagnostics 매개변수를 설정할 수 있습니다.

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

OpenShift Container Platform 4.19에서는 더 이상 사용되지 않는 몇 가지 API를 제거한 Kubernetes 1.32를 사용합니다.

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

모든 OpenShift Container Platform 4.18 클러스터에는 OpenShift Container Platform 4.19로 업데이트하기 전에 이 관리자의 승인이 필요합니다.

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

이 릴리스를 사용하면 OpenShift Container Platform 장애 도메인을 VMware vSphere 호스트 그룹에 매핑할 수 있습니다. 이를 통해 vSphere 확장 클러스터 구성이 제공하는 고가용성을 활용할 수 있습니다. 이 기능은 OpenShift Container Platform 4.19의 기술 미리 보기로 제공됩니다.

설치 시 호스트 그룹을 구성하는 방법에 대한 자세한 내용은 VMware vSphere 호스트 그룹 활성화를 참조하세요.

기존 클러스터에 대한 호스트 그룹 구성에 대한 자세한 내용은 vSphere에서 클러스터에 대한 여러 호스트 그룹 지정을 참조하세요.

이 릴리스를 통해 이제 에이전트 기반 설치 프로그램을 사용하여 Nutanix에 클러스터를 설치할 수 있습니다. 에이전트 기반 설치 프로그램을 사용하여 Nutanix에 클러스터를 설치하려면 install-config.yaml 파일에서 플랫폼 매개변수를 nutanix 로 설정해야 합니다.

자세한 내용은 에이전트 기반 설치 프로그램 설명서의 필수 구성 매개변수를 참조하세요.

RHCOS(Red Hat Enterprise Linux CoreOS) 이미지 계층 지정을 OpenShift의 이미지 모드 라고 합니다. 이러한 변경의 일부로 클러스터 내 계층 지정 은 이제 클러스터 의 이미지 모드에서 호출되고 클러스터 외부 계층 지정 은 이제 클러스터 외부 이미지 모드입니다.

업데이트된 부팅 이미지 기능을 이제 부팅 이미지 관리 라고 합니다.

이전에는 on-cluster 계층화라고 하는 OpenShift의 이미지 모드는 이제 GA(일반 사용 가능)입니다. GA 프로모션과 함께 다음 변경 사항이 도입되었습니다.

이전에 업데이트된 부팅 이미지라고 하는 부팅 이미지 관리 기능이 이제 GCP(Google Cloud Platform) 및 AWS(Amazon Web Services) 클러스터에서 기본 동작입니다. 따라서 OpenShift Container Platform 4.19로 업데이트한 후 클러스터의 부팅 이미지가 4.19 버전으로 자동 업데이트됩니다. 후속 업데이트를 통해 MCO(Machine Config Operator)는 클러스터의 부팅 이미지를 다시 업데이트합니다. 부팅 이미지는 머신 세트와 연결되며 새 노드를 확장할 때 사용됩니다. 업데이트 후 생성하는 새 노드는 새 버전을 기반으로 합니다. 현재 노드는 이 기능의 영향을 받지 않습니다.

4.19로 업그레이드하기 전에 이 기본 동작을 옵트아웃하거나 진행하기 전에 이러한 변경 사항을 승인해야 합니다. 자세한 내용은 부팅 이미지 관리 비활성화를 참조하십시오.

설치 프로그램에서 생성한 MCS(Machine Config Server) CA 번들은 이제 openshift-machine-config-operator 네임스페이스의 machine-config-server-ca 구성 맵에 저장됩니다. 번들은 이전에 kube-system 네임스페이스 의 root-ca configmap에 저장되었습니다. root-ca configmap은 OpenShift Container Platform 4.19로 업데이트되는 클러스터에서 더 이상 사용되지 않습니다. 이러한 변경으로 인해 이 CA 번들은 MCO(Machine Config Operator)에서 관리합니다.

MCS 서명 키는 openshift-machine-config-operator 네임스페이스의 machine-config-server-ca 시크릿에 저장됩니다.

MCS CA 및 MCS 인증서는 10년 동안 유효하며 약 8년 후에 MCO에 의해 자동으로 순환됩니다. OpenShift Container Platform 4.19로 업데이트되면 CA 서명 키가 없습니다. 결과적으로 MCO 인증서 컨트롤러가 시작될 때 CA 번들이 즉시 만료된 것으로 간주됩니다. 이 만료로 인해 클러스터가 10세가 아니더라도 즉각적인 인증서 교체가 발생합니다. 이 시점에서 다음 교체는 표준 8 년 동안 수행됩니다.

MCO 인증서에 대한 자세한 내용은 Machine Config Operator 인증서를 참조하십시오.

이 릴리스에서는 기술 미리 보기 기능으로 지원되는 플랫폼에서 클러스터 API와 머신 API 간에 일부 리소스를 마이그레이션할 수 있습니다. 자세한 내용은 머신 API 리소스를 클러스터 API 리소스로 마이그레이션을 참조하세요.

이 기능을 지원하기 위해 OpenShift Container Platform Cluster API 설명서에는 이제 베어 메탈 및 Amazon Web Services 클러스터에 대한 추가 구성 세부 정보가 포함되었습니다.

이번 릴리스에서는 컨트롤 플레인 머신 세트로 생성된 머신의 머신 이름 접두사를 사용자 지정할 수 있습니다. 이 기능은 ControlPlaneMachineSet 사용자 정의 리소스의 spec.machineNamePrefix 매개변수를 수정하여 활성화됩니다.

자세한 내용은 컨트롤 플레인 시스템 이름에 사용자 정의 접두사 추가를 참조하십시오.

이 릴리스를 사용하면 Amazon Web Services 클러스터에서 온디맨드 용량 예약 및 ML을 위한 용량 블록을 포함한 용량 예약을 사용하는 머신을 배포할 수 있습니다.

이러한 기능은 컴퓨팅 및 제어 평면 머신 세트를 사용하여 구성할 수 있습니다.

이 릴리스에서는 기술 미리 보기 기능으로 vSphere 클러스터의 가상 머신(VM) 컨트롤러에 최대 29개의 디스크를 추가할 수 있습니다. 이 기능은 컴퓨팅 및 제어 평면 머신 세트에서 사용할 수 있습니다.

이 릴리스에는 클러스터 내 모니터링 스택 구성 요소 및 종속성에 대한 다음 버전 업데이트가 포함되어 있습니다.

이 릴리스에서는 Prometheus 구성 요소에 대한 주요 업데이트가 도입되어 v2에서 v3로 전환됩니다. 모니터링 스택과 기타 핵심 구성 요소에는 원활한 업그레이드를 보장하기 위한 모든 필수 조정 사항이 포함되어 있습니다. 하지만 일부 사용자 관리 구성에는 수정이 필요할 수 있습니다. 주요 변경 사항은 다음과 같습니다.

Prometheus v2와 v3 사이의 변경 사항에 대한 자세한 내용은 Prometheus 3.0 마이그레이션 가이드를 참조하세요.

OpenShift Container Platform 4.13에서는 기본 플랫폼 모니터링에 대한 메트릭 수집 프로필을 설정하여 기본 양의 메트릭 데이터 또는 최소한의 양의 메트릭 데이터를 수집하는 기능을 도입했습니다. OpenShift Container Platform 4.19에서는 메트릭 수집 프로필이 이제 일반적으로 사용 가능합니다.

자세한 내용은 메트릭 수집 프로필 정보 및 메트릭 수집 프로필 선택을 참조하세요.

이 릴리스에서는 외부 Alertmanager 인스턴스가 통신을 위해 클러스터 전체 HTTP 프록시 설정을 사용합니다. 클러스터 모니터링 운영자(CMO)는 클러스터 전체 프록시 설정을 읽고 Alertmanager 엔드포인트에 적합한 프록시 URL을 구성합니다.

이번 릴리스에서는 OpenShift Container Platform 4.18에 도입된 엄격한 검증이 개선되었습니다. 이제 오류 메시지에서 영향을 받는 필드를 명확하게 식별하고, 유효성 검사에서 대소문자를 구분하여 구성을 더욱 정확하고 일관되게 보장합니다.

자세한 내용은 ( OCPBUGS-42671 ) 및 ( OCPBUGS-54516 )을 참조하세요.

이번 릴리스에서는 타사 인증서 관리 솔루션을 사용하여 OpenShift Container Platform 경로를 구성하여 경로 API의 .spec.tls.externalCertificate 필드를 사용할 수 있습니다. 이를 통해 시크릿을 통해 외부 관리형 TLS 인증서를 참조하고 수동 인증서 관리를 제거하여 프로세스를 간소화할 수 있습니다. 외부 관리형 인증서를 사용하면 오류를 줄이고 더 원활한 인증서 업데이트 프로세스를 보장하며 OpenShift 라우터에서 갱신된 인증서를 신속하게 제공할 수 있습니다. 자세한 내용은 외부 관리 인증서를 사용하여 경로 생성 을 참조하십시오.

이번 릴리스에서는 게이트웨이 API 리소스를 사용하여 수신 클러스터 트래픽 관리 지원이 일반적으로 사용 가능합니다. 게이트웨이 API는 표준화된 오픈 소스 에코시스템을 사용하는 OpenShift Container Platform 클러스터에 대해 전송 계층 L4 및 애플리케이션 계층 L7 내에 강력한 네트워킹 솔루션을 제공합니다.

자세한 내용은 OpenShift Container Platform 네트워킹을 사용한 게이트웨이 API 를 참조하십시오.

이번 릴리스에서는 OpenShift Container Platform에서 게이트웨이 API CRD의 라이프사이클을 관리합니다. 즉, Ingress Operator는 필요한 리소스 버전 관리 및 관리를 처리합니다. 이전 OpenShift Container Platform 버전에서 생성된 모든 게이트웨이 API 리소스는 Ingress Operator에 필요한 사양을 준수하도록 다시 생성하고 재배포해야 합니다.

자세한 내용은 Ingress Operator의 게이트웨이 API 관리 연속 준비를 참조하십시오.

OpenShift Container Platform 4.19은 Red Hat OpenShift Service Mesh를 버전 3.0.2로 업데이트하고 게이트웨이 API를 버전 1.2.1로 업데이트합니다. 자세한 내용은 Service Mesh 3.0.0 릴리스 노트 및 게이트웨이 API 1.2.1 변경 로그 를 참조하십시오.

클러스터가 실행되는 인프라에서 Open vSwitch(OVS) balance-slb 모드를 활성화하여 두 개 이상의 물리적 인터페이스가 네트워크 트래픽을 공유할 수 있습니다. 자세한 내용은 클러스터에 OVS balance-slb 모드 활성화를 참조하세요.

이 릴리스를 사용하면 AWS에 OpenShift Container Platform 클러스터를 설치할 때 로드 밸런서를 할당하여 배포를 사용자 지정할 수 있습니다. 이 기능은 최적의 트래픽 분산, 높은 애플리케이션 가용성, 중단 없는 서비스 및 네트워크 분할을 보장합니다.

자세한 내용은 AWS의 설치 구성 매개변수 및 특정 서브넷에 로드 밸런서 할당을 참조하세요.

이번 릴리스에서는 듀얼 포트 NIC(네트워크 인터페이스 컨트롤러)를 사용하여 PTP(Precision Time Protocol) 일반 클록의 중복성을 개선할 수 있습니다. 일반 클록에 대한 이중 포트 NIC 구성에서 기술 프리뷰로 사용할 수 있습니다. 하나의 포트가 실패하면 대기 포트가 처리되어 PTP 타이밍 동기화를 유지합니다.

자세한 내용은 이중 포트 NIC를 사용하여 PTP 일반 클록의 중복성 개선을 참조하십시오.

이제 SriovOperatorConfig 개체에서 featureGates.resourceInjectorMatchCondition 기능을 활성화하여 네트워크 리소스 인젝터 웹훅의 범위를 제한할 수 있습니다. 이 기능을 활성화하면 웹훅은 보조 네트워크 주석 k8s.v1.cni.cncf.io/networks가 있는 포드에만 적용됩니다.

이 기능을 비활성화하면 웹후크의 failurePolicy가 기본적으로 Ignore 로 설정됩니다. 이 구성을 사용하면 웹훅을 사용할 수 없는 경우 필요한 리소스 주입 없이 SR-IOV 네트워크를 요청하는 포드가 배포될 수 있습니다. 이 기능이 활성화되어 있고 웹훅을 사용할 수 없는 경우, 주석이 없는 포드는 계속 배포되므로 다른 작업 부하가 불필요하게 중단되는 것을 방지할 수 있습니다.

자세한 내용은 네트워크 리소스 인젝터 정보를 참조하세요.

이번 릴리스에서는 OpenShift Container Platform에 DPDK(Data Processing Unit) Operator가 도입되어 DPU 장치를 관리할 수 있습니다. DPU Operator는 DPU를 사용하여 컴퓨팅 노드의 구성 요소를 관리하여 네트워킹, 스토리지 및 보안과 같은 데이터 워크로드를 오프로드할 수 있습니다. 이로 인해 클러스터 성능이 향상되고 대기 시간이 단축되고 보안이 강화되어 더 효율적인 인프라에 기여할 수 있습니다. 자세한 내용은 DPU 및 DPU Operator 정보를 참조하십시오.

이제 관리자는 ClusterUserDefinedNetwork 사용자 지정 리소스를 사용하여 Localnet 토폴로지에 보조 네트워크를 배포할 수 있습니다. 이 기능을 사용하면 localnet 네트워크에 연결된 Pod 및 가상 머신이 물리적 네트워크로 송신할 수 있습니다. 자세한 내용은 Localnet 토폴로지의 ClusterUserDefinedNetwork CR 생성을 참조하십시오.

Linux 브리지 네트워크 연결 정의(NAD)에 대해 포트 격리를 활성화하여 동일한 VLAN(가상 LAN)에서 실행되는 VM(가상 LAN) 또는 Pod가 서로 독립적으로 작동할 수 있도록 할 수 있습니다. 자세한 내용은 Linux 브리지의 포트 격리 활성화를 참조하십시오.

Whereabouts의 성능을 개선하기 위해 특히 클러스터의 노드가 많은 양의 Pod를 실행하는 경우 빠른 IP 주소 관리(IPAM) 기능을 활성화할 수 있습니다. Fast IPAM 기능은 Whereabouts 컨트롤러에서 관리하는 nodeslicepools 를 사용하여 노드의 IP 주소 할당을 최적화합니다. 자세한 내용은 Whereabouts IPAM CNI 플러그인의 Fast IPAM 구성 을 참조하십시오.

이번 릴리스에서는 OpenShift Container Platform에서 번호가 지정되지 않은 BGP 피어링이 도입되었습니다. 기술 프리뷰 기능으로 사용 가능한 BGP 피어 사용자 정의 리소스의 spec.interface 필드를 사용하여 번호가 지정되지 않은 BGP 피어링을 구성할 수 있습니다.

외부 DNS 서버에 연결할 수 없는 연결이 끊긴 환경에서는 NMState CRD(사용자 정의 리소스 정의)에 사용자 정의 DNS 호스트 이름을 지정하여 Kubernetes NMState Operator 상태 프로브 문제를 해결할 수 있습니다. 자세한 내용은 DNS 연결 문제를 해결하기 위해 사용자 정의 DNS 호스트 이름 생성 을 참조하십시오.

이번 릴리스에서는 PTP 이벤트 REST API v1 및 이벤트 소비자 애플리케이션 사이드카 지원이 제거됩니다.

대신 O-RAN 호환 PTP 이벤트 REST API v2를 사용해야 합니다.

자세한 내용은 REST API v2를 사용하여 PTP 이벤트 소비자 애플리케이션 개발을 참조하십시오.

이제 ARM 아키텍처에서 실행되는 클러스터에 SR-IOV 네트워크 운영자를 배포할 수 있습니다. (OCPBUGS-56271)

클러스터에 대해 RouteExternalCertificate 기능 게이트를 활성화한 경우 이전에 삭제한 비밀을 다시 추가할 수 있습니다. (OCPBUGS-33958)

OpenShift Container Platform 4.16에서 더 이상 사용되지 않는 cgroup v1은 더 이상 지원되지 않으며 OpenShift Container Platform에서 제거되었습니다. 클러스터에서 cgroup v1을 사용하는 경우 OpenShift Container Platform 4.19로 업그레이드하기 전에 cgroup v2를 구성해야 합니다. 이제 모든 워크로드가 cgroup v2와 호환되어야 합니다.

클러스터에서 cgroup v2를 구성하는 방법에 대한 자세한 내용은 OpenShift Container Platform 버전 4.18 설명서의 Linux cgroup 구성을 참조하세요.

cgroup v2에 대한 자세한 내용은 Red Hat OpenShift 워크로드 (Red Hat 블로그)의 Linux cgroup 버전 2 및 Red Hat Enterprise Linux 9 변경 사항 정보를 참조하십시오.

OpenShift Container Platform 4.19부터 oc-mirror 플러그인 v2는 컨테이너 이미지에 대한 공동 서명 태그 기반 서명의 미러링과 검증을 지원합니다.

다음은 Operator 프로젝트의 기본 이미지이며, OpenShift Container Platform 4.19와의 호환성을 위해 업데이트되었습니다. 이러한 기본 이미지의 런타임 기능 및 구성 API는 버그 수정 및 CVE 문제를 해결하는 데 지원됩니다.

자세한 내용은 OpenShift Container Platform 4.19 이상(Red Hat Knowledgebase)의 기존 Ansible 또는 Helm 기반 Operator 프로젝트의 기본 이미지 업데이트를 참조하십시오.

OpenShift Container Platform 4.19에서는 베어 메탈을 서비스로 사용(BMaaS)하여 OpenShift Container Platform이 아닌 노드를 배포할 수 있습니다. BMaaS 노드는 컨테이너화나 가상화에 적합하지 않은 워크로드를 실행할 수 있습니다. 예를 들어, 직접적인 하드웨어 액세스가 필요하거나 고성능 컴퓨팅 작업을 수행하거나 레거시 애플리케이션이며 클러스터와 독립적으로 작동하는 애플리케이션과 같은 워크로드는 BMaaS를 사용하여 배포하는 데 적합합니다.

자세한 내용은 베어메탈을 서비스로 사용하기를 참조하세요.

RHCOS는 OpenShift Container Platform 4.19에서 RHEL (Red Hat Enterprise Linux) 9.6 패키지를 사용합니다. 이러한 패키지를 사용하면 OpenShift Container Platform 인스턴스에 최신 수정 사항, 기능, 개선 사항, 하드웨어 지원 및 드라이버 업데이트가 제공됩니다.

이번 업데이트를 통해 더 큰 커널 페이지 크기를 지정하여 실시간 커널이 비활성화된 ARM 인프라 노드의 메모리 집약적인 고성능 워크로드의 성능을 향상시킬 수 있습니다. 자세한 내용은 커널 페이지 크기 구성을 참조하십시오.

이 릴리스에는 클러스터 비교 플러그인에 대한 다음과 같은 사용성 및 기능 업데이트가 포함되어 있습니다.

사용 가능한 템플릿 함수의 전체 목록은 참조 템플릿 함수를 참조하세요.

이번 업데이트를 통해 성능 프로필을 적용하여 호스트된 컨트롤 플레인에서 노드를 조정할 수 있습니다. 자세한 내용은 호스팅된 컨트롤 플레인의 성능 프로필 생성 을 참조하십시오.

이번 릴리스에서는 컨트롤 플레인에서 TLS 1.3을 지원합니다. 이제 컨트롤 플레인에 Modern TLS 보안 프로필을 사용할 수 있습니다.

자세한 내용은 컨트롤 플레인의 TLS 보안 프로필 구성을 참조하십시오.

이번 릴리스에서는 보안 저장소 공급자가 연결이 끊긴 클러스터에서 Secrets Store CSI 드라이버를 사용하여 지원합니다.

자세한 내용은 연결이 끊긴 환경 지원을 참조하십시오.

교차 구독 지원을 사용하면 Azure File Container Storage Interface(CSI) 드라이버를 사용하여 하나의 Azure 구독에 OpenShift Container Platform 클러스터를 두고 다른 Azure 구독에 Azure 파일 공유를 마운트할 수 있습니다. 구독은 동일한 테넌트에 있어야 합니다.

이 기능은 일반적으로 OpenShift Container Platform 4.19에서 사용할 수 있습니다.

자세한 내용은 AWS EFS CSI 교차 계정 지원을 참조하세요.

볼륨 속성 클래스는 관리자가 제공하는 저장소 "클래스"를 설명할 수 있는 방법을 제공합니다. 다양한 클래스는 다양한 서비스 품질 수준에 해당할 수 있습니다.

OpenShift Container Platform 4.19의 볼륨 속성 클래스는 AWS Elastic Block Storage(EBS) 및 Google Cloud Platform(GCP) 영구 디스크(PD) 컨테이너 스토리지 인터페이스(CSI)에서만 사용할 수 있습니다.

영구 볼륨 클레임(PVC)에 볼륨 속성 클래스를 적용할 수 있습니다. 클러스터에서 새로운 볼륨 속성 클래스를 사용할 수 있게 되면 필요한 경우 PVC를 새로운 볼륨 속성 클래스로 업데이트할 수 있습니다.

볼륨 속성 클래스에는 해당 클래스에 속한 볼륨을 설명하는 매개변수가 있습니다. 매개변수를 생략하면 볼륨 프로비저닝 시 기본값이 사용됩니다. 사용자가 매개변수가 생략된 다른 볼륨 속성 클래스로 PVC를 적용하는 경우 CSI 드라이버 구현에 따라 매개변수의 기본값이 사용될 수 있습니다. 자세한 내용은 관련 CSI 드라이버 문서를 참조하세요.

볼륨 속성 클래스는 기술 미리 보기 상태의 OpenShift Container Platform 4.19에서 사용할 수 있습니다.

자세한 내용은 볼륨 속성 클래스를 참조하세요.

OpenShift Container Platform 4.19에서는 지속적인 볼륨 클레임 사용량을 확인하는 새로운 명령이 도입되었습니다. 이 기능은 기술 미리보기 상태입니다.

자세한 내용은 PVC 사용 통계 보기를 참조하세요.

이전에는 기본 스토리지 공급자가 지원하지 않는 크기로 영구 볼륨 클레임(PVC)을 확장할 수 있었습니다. 이 경우, 확장 컨트롤러는 일반적으로 볼륨을 확장하기 위해 끝없이 시도하지만 계속 실패합니다.

이 새로운 기능을 사용하면 PVC에 대한 크기 조정 값을 복구하고 다른 크기 조정 값을 제공할 수 있습니다. 일반적으로 OpenShift Container Platform 4.19에서는 복구 크기 조정 기능이 지원됩니다.

볼륨 크기 조정에 대한 자세한 내용은 영구 볼륨 확장을 참조하세요.

볼륨 크기 조정 시 복구에 대한 자세한 내용은 볼륨 확장 시 오류 복구를 참조하세요.

이전에는 트리 내에서 CSI(Container Storage Interface)로 마이그레이션된 VMware vSphere 영구 볼륨의 크기를 조정할 수 없었습니다. OpenShift Container Platform 4.19에서는 마이그레이션된 볼륨의 크기 조정이 지원됩니다. 이 기능은 일반적으로 이용 가능합니다.

볼륨 크기 조정에 대한 자세한 내용은 영구 볼륨 확장을 참조하세요.

클러스터 관리자는 2일차 작업으로 VMWare vSphere Container Storage Interface(CSI) 드라이버를 비활성화하여 vSphere CSI 드라이버가 vSphere 설정과 상호 작용하지 않도록 할 수 있습니다.

이 기능은 기술 미리 보기 상태의 OpenShift Container Platform 4.17에서 도입되었습니다. 이 기능은 이제 OpenShift Container Platform 4.19에서 일반적으로 사용 가능하게 지원됩니다.

자세한 내용은 vSphere에서 스토리지 비활성화 및 활성화를 참조하세요.

VMware vSphere 버전 7의 경우 OpenShift Container Platform은 노드당 최대 볼륨 수를 59개로 제한합니다.

하지만 OpenShift Container Platform 4.19 for vSphere 버전 8 이상을 사용하면 노드당 허용되는 볼륨 수를 최대 255개까지 늘릴 수 있습니다. 그렇지 않으면 기본값은 59로 유지됩니다.

이 기능은 기술 미리보기 상태입니다.

자세한 내용은 vSphere에 대한 노드당 최대 볼륨 증가를 참조하세요.

현재 데이터스토어의 공간이 부족하거나 성능이 더 뛰어난 데이터스토어로 이동하려는 경우 VMware vSphere Cloud Native Storage(CNS) 볼륨을 데이터스토어 간에 마이그레이션할 수 있습니다. 이는 첨부된 볼륨과 분리된 볼륨 모두에 적용됩니다.

OpenShift Container Platform은 이제 vCenter UI를 사용하여 CNS 볼륨 마이그레이션을 완벽하게 지원합니다. 마이그레이션된 볼륨은 예상대로 작동해야 하며 작동하지 않는 영구 볼륨이 생성되어서는 안 됩니다. CNS 볼륨은 포드에서 사용 중에도 마이그레이션될 수 있습니다.

이 기능은 OpenShift Container Platform 4.17에서 개발 미리 보기로 도입되었지만 이제 4.19에서 완벽하게 지원됩니다.

데이터스토어 간에 CNS 볼륨을 마이그레이션하려면 VMware vSphere 8.0.2 이상 또는 vSphere 7.0 업데이트 3o 이상이 필요합니다.

자세한 내용은 vSphere용 데이터스토어 간 CNS 볼륨 마이그레이션을 참조하세요.

기본적으로 Filestore 인스턴스는 동일한 Google Cloud 프로젝트와 가상 사설 클라우드(VPC) 네트워크를 공유하는 모든 클라이언트에 루트 수준의 읽기/쓰기 액세스 권한을 부여합니다. 네트워크 파일 시스템(NFS) 내보내기 옵션을 사용하면 이러한 액세스를 특정 IP 범위와 Filestore 인스턴스의 특정 사용자/그룹 ID로 제한할 수 있습니다. 스토리지 클래스를 생성할 때 nfs-export-options-on-create 매개변수를 사용하여 이러한 옵션을 설정할 수 있습니다.

NFS 내보내기 옵션은 OpenShift Container Platform 4.19에서 일반적으로 사용 가능합니다.

자세한 내용은 NFS 내보내기 옵션을 참조하세요.

웹 콘솔은 이제 Patternfly 6을 사용합니다. 웹 콘솔에서 Patternfly 4에 대한 지원이 더 이상 제공되지 않습니다.

이번 릴리스에서는 웹 콘솔에 대한 다음과 같은 업데이트도 도입되었습니다. 이제 다음 작업을 수행할 수 있습니다.