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

OpenShift Container Platform 4.12 부팅 이미지에서 설치된 RHCOS(Red Hat Enterprise Linux CoreOS) 노드는 이제 플랫폼별 기본 콘솔을 사용합니다. 클라우드 플랫폼의 기본 콘솔은 해당 클라우드 공급자가 예상하는 특정 시스템 콘솔에 해당합니다. VMware 및 OpenStack 이미지는 이제 기본 그래픽 콘솔과 보조 직렬 콘솔을 사용합니다. 다른 베어 메탈 설치에서는 기본적으로 그래픽 콘솔만 사용하고 직렬 콘솔을 활성화하지 않습니다. coreos-installer 에서 수행되는 설치는 기존 기본값을 재정의하고 직렬 콘솔을 활성화할 수 있습니다.

기존 노드는 영향을 받지 않습니다. 기존 클러스터의 새 노드는 클러스터를 설치하는 데 원래 사용된 부팅 이미지에서 일반적으로 설치되므로 영향을 받지 않을 수 있습니다.

직렬 콘솔을 활성화하는 방법에 대한 자세한 내용은 다음 문서를 참조하십시오.

OpenShift Container Platform에서는 IBM Z 및 LinuxONE(s390x 아키텍처)에서 IBM Secure Execution 용 RHCOS(Red Hat Enterprise Linux CoreOS) 노드 구성을 기술 프리뷰 기능으로 지원합니다. IBM Secure Execution은 KVM 게스트의 메모리 경계를 보호하는 하드웨어 개선 사항입니다. IBM Secure Execution은 클러스터 워크로드에 대해 최고 수준의 격리 및 보안을 제공하며 IBM Secure Executionready QCOW2 부팅 이미지를 사용하여 활성화할 수 있습니다.

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

자세한 내용은 IBM Secure Execution를 사용하여 RHCOS 설치를 참조하십시오.

RHCOS는 OpenShift Container Platform 4.12에서 RHEL (Red Hat Enterprise Linux) 8.6 패키지를 사용합니다. 이를 통해 최신 수정 사항, 기능 및 향상된 기능은 물론 최신 하드웨어 지원 및 드라이버 업데이트를 받을 수 있습니다. OpenShift Container Platform 4.10은 라이프사이클 전체에서 RHEL 8.4 EUS 패키지를 계속 사용하는 EUS (Extended Update Support) 릴리스입니다.

console.redhat.com 에서 지원되는 설치 관리자 SaaS는 지원 설치 관리자 사용자 인터페이스 또는 REST API를 사용하여 Machine API 통합을 통해 Nutanix 플랫폼에 OpenShift Container Platform 설치를 지원합니다. Nutanix Prism 사용자는 통합을 통해 단일 인터페이스에서 인프라를 관리하고 자동 스케일링을 가능하게 합니다. 지원 설치 관리자 SaaS와 Nutanix 통합을 활성화하는 몇 가지 추가 설치 단계가 있습니다. 자세한 내용은 지원 설치 관리자 설명서를 참조하십시오.

OpenShift Container Platform 4.12부터 설치 중에 NLB(Network Load Balancer) 또는 Classic을 AWS에서 영구 로드 밸런서 유형으로 지정할 수 있습니다. 이후 Ingress 컨트롤러가 삭제되면 설치 중에 설정된 로드 밸런서 유형이 유지됩니다.

자세한 내용은 네트워크 사용자 지정으로 AWS에 클러스터 설치를 참조하십시오.

이번 업데이트를 통해 설치 관리자 프로비저닝 인프라가 있는 기존 VPC에 OpenShift Container Platform을 설치하여 작업자 노드를 로컬 영역 서브넷으로 확장할 수 있습니다. 설치 프로그램은 NoSchedule 테인트를 사용하여 사용자 애플리케이션에 특별히 지정된 AWS 네트워크의 에지에 작업자 노드를 프로비저닝합니다. 로컬 영역 위치에 배포된 애플리케이션은 일반 사용자에게 짧은 대기 시간을 제공합니다.

자세한 내용은 AWS Local Zones를 사용하여 클러스터 설치를 참조하십시오.

OpenShift Container Platform은 이제 GCP Marketplace에서 사용할 수 있습니다. GCP Marketplace 이미지를 사용하여 OpenShift Container Platform을 설치하면 GCP를 통해 사용량별로(시간별로) 청구되는 자체 관리 클러스터 배포를 생성할 수 있지만 Red Hat에서 직접 지원합니다.

설치 관리자 프로비저닝 인프라를 사용하는 방법에 대한 자세한 내용은 GCP Marketplace 이미지 사용을 참조하십시오. 사용자 프로비저닝 인프라를 사용하는 방법에 대한 자세한 내용은 GCP에서 추가 작업자 머신 생성 을 참조하십시오.

이제 설치 프로그램에서 GCP 및 Azure의 부트스트랩 및 컨트롤 플레인 호스트에서 직렬 콘솔 로그를 수집합니다. 이 로그 데이터는 표준 부트스트랩 로그 번들에 추가됩니다.

자세한 내용은 설치 문제 해결을 참조하십시오.

IBM Cloud VPC는 이제 OpenShift Container Platform 4.12에서 일반적으로 사용할 수 있습니다.

클러스터 설치에 대한 자세한 내용은 IBM Cloud VPC에 설치 준비를 참조하십시오.

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

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

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

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

OpenShift Container Platform 4.12부터 설치 프로세스의 일부로 설정된 기능을 활성화할 수 있습니다. 기능 세트는 기본적으로 활성화되어 있지 않은 OpenShift Container Platform 기능 컬렉션입니다.

설치 중에 기능 세트를 활성화하는 방법에 대한 자세한 내용은 기능 게이트를 사용하여 OpenShift Container Platform 기능 활성화 를 참조하십시오.

OpenShift Container Platform 4.12가 ARM 아키텍처 기반 Azure 설치 관리자 프로비저닝 인프라에서 지원됩니다. AWS Graviton 3 프로세서는 이제 클러스터 배포에서 사용할 수 있으며 OpenShift Container Platform 4.11에서도 지원됩니다. 인스턴스 가용성 및 설치 설명서에 대한 자세한 내용은 다른 플랫폼의 지원 설치 방법을참조하십시오.

이제 Docker v2 형식 대신 oc-mirror CLI 플러그인을 사용하여 OCI 형식으로 파일 기반 카탈로그 Operator 이미지를 미러링할 수 있습니다. 이제 기술 프리뷰 로 사용할 수 있습니다.

자세한 내용은 OCI 형식의 파일 기반 카탈로그 Operator 이미지 미러링을 참조하십시오.

OpenShift Container Platform 4.12에서는 GCP의 클러스터를 공유 VPC에 기술 프리뷰 로 설치할 수 있습니다. 이 설치 방법에서는 클러스터는 다른 GCP 프로젝트의 VPC를 사용하도록 구성되어 있습니다. 공유 VPC를 통해 조직은 여러 프로젝트의 리소스를 공통 VPC 네트워크로 연결할 수 있습니다. 해당 네트워크의 내부 IP 주소를 사용하여 조직 내에서 안전하고 효율적으로 통신할 수 있습니다.

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

이번 업데이트를 통해 provisioning 네트워크 없이 베어 메탈 설치에서 프록시 서버를 통해 Ironic API 서비스에 액세스할 수 있습니다. 이 프록시 서버는 Ironic API 서비스에 일관된 IP 주소를 제공합니다. metal3-ironic 이 포함된 Metal3 pod가 다른 pod로 재배치되는 경우 일관된 프록시 주소는 Ironic API 서비스와의 지속적인 통신을 보장합니다.

OpenShift Container Platform 4.12에서는 서비스 계정이 연결된 가상 머신을 사용하여 GCP에 클러스터를 설치할 수 있습니다. 이를 통해 서비스 계정 JSON 파일을 사용할 필요 없이 설치를 수행할 수 있습니다.

자세한 내용은 GCP 서비스 계정 생성을 참조하십시오.

OpenShift Container Platform 4.12에서 propagateUserTags 매개변수는 Operator가 생성한 AWS 리소스 태그에 지정된 사용자 태그를 포함하도록 클러스터 내에서 Operator를 지시하는 플래그입니다.

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

이전 버전의 OpenShift Container Platform에서 Ironic 컨테이너 이미지는 Red Hat Enterprise Linux (RHEL) 8을 기본 이미지로 사용했습니다. OpenShift Container Platform 4.12에서 Ironic 컨테이너 이미지는 RHEL 9를 기본 이미지로 사용합니다. RHEL 9 기본 이미지는 Ironic 구성 요소에서 CentOS Stream 9, Python 3.8, 및 Python 3.9에 대한 지원이 추가되었습니다.

Ironic 프로비저닝 서비스에 대한 자세한 내용은 베어 메탈에 설치 프로그램 프로비저닝 클러스터 배포를 참조하십시오.

OpenShift Container Platform 4.12에서는 RHOSP(Red Hat OpenStack Platform)에서 실행되는 클러스터는 기존 OpenStack 클라우드 공급자에서 외부 CCO(Cloud Controller Manager)로 전환됩니다. 이러한 변경은 클라우드 컨트롤러 관리자를 사용하여 구현된 외부 클라우드 공급자로 인트리(in-tree)에서 외부 클라우드 공급자로 Kubernetes의 이동을 따릅니다.

자세한 내용은 The OpenStack Cloud Controller Manager 에서 참조하십시오.

OpenShift Container Platform 4.12에서 DCN(Distributed Compute Node) 아키텍처가 있는 RHOSP(Red Hat OpenStack Platform) 클라우드에 클러스터 배포가 검증되었습니다. 이러한 배포에 대한 참조 아키텍처가 곧 제공됩니다.

이 배포 유형에 대한 간략한 개요는 OpenStack을 사용하여 에지에서 클러스터 배포 블로그 게시물을 참조하십시오.

OpenShift Container Platform 4.12는 이제 기술 프리뷰 로 AWS Outposts 플랫폼에서 지원됩니다. AWS Outposts를 사용하면 엣지 기반 작업자 노드를 배포하는 동시에 컨트롤 플레인 노드에 AWS 리전을 사용할 수 있습니다. 자세한 내용은 AWS Outposts에서 원격 작업자를 사용하여 AWS에 클러스터 설치를 참조하십시오.

에이전트 기반 설치에서는 두 가지 입력 모드를 지원합니다.

기본 모드를 사용하면 install-config.yaml 파일을 구성하고 agent- config.yaml 파일에서 에이전트 기반 특정 설정을 지정할 수 있습니다. 자세한 내용은 에이전트 기반 OpenShift Container Platform 설치 관리자 정보를 참조하십시오.

에이전트 기반 OpenShift Container Platform 설치 관리자는 FIPS(Federal Information Processing Standards) 호환 모드에서 OpenShift Container Platform 클러스터를 지원합니다. install-config.yaml 파일에서 fips 필드 값을 True 로 설정해야 합니다. 자세한 내용은 FIPS 컴플라이언스 정보를 참조하십시오.

연결이 끊긴 환경에서 에이전트 기반 설치를 수행할 수 있습니다. 연결이 끊긴 환경에서 사용되는 이미지를 생성하려면 install-config.yaml 파일의 imageContentSources 섹션에 ZTP 매니페스트를 사용하는 경우 미러 정보 또는 registries.conf 파일이 포함되어야 합니다. 이러한 파일에서 사용할 실제 구성 설정은 oc adm release mirror 또는 oc mirror 명령으로 제공됩니다. 자세한 내용은 연결이 끊긴 설치 미러링 이해를 참조하십시오.

이미지 세트 구성을 생성할 때 graph: true 필드를 추가하여 graph-data 이미지를 미러 레지스트리로 빌드하고 푸시할 수 있습니다. graph-data 이미지는 OSUS(OpenShift Update Service)를 생성하는 데 필요합니다. graph: true 필드도 UpdateService 사용자 정의 리소스 매니페스트를 생성합니다. oc CLI(명령줄 인터페이스)는 UpdateService 사용자 정의 리소스 매니페스트를 사용하여 OSUS를 생성할 수 있습니다.

다음 IP 주소 구성을 사용하여 에이전트 ISO 이미지를 생성할 수 있습니다.

자세한 내용은 듀얼 및 단일 IP 스택 클러스터를 참조하십시오.

Kubernetes Operator용 멀티 클러스터 엔진을 설치하고 에이전트 기반 OpenShift Container Platform 설치 프로그램으로 hub 클러스터를 배포할 수 있습니다. 자세한 내용은 Kubernetes Operator의 다중 클러스터 엔진에 대한 에이전트 기반 설치된 클러스터 준비를 참조하십시오.

에이전트 기반 OpenShift Container Platform Installer는 다음에서 검증을 수행합니다.

자세한 내용은 설치 검증을 참조하십시오.

에이전트 기반 OpenShift Container Platform 설치 관리자를 사용하면 에이전트 ISO 이미지를 생성하기 전에 모든 호스트에 대해 IPv4, IPv6 또는 듀얼 스택(IPv4 및 IPv6)에 대한 고정 IP 주소를 구성할 수 있습니다. ZTP 매니페스트를 사용하는 경우 agent-config.yaml 파일의 hosts 섹션 또는 NMStateConfig.yaml 파일에서 정적 주소를 추가할 수 있습니다. NMState 상태 예제에 설명된 대로 주소 구성은 NMState의 구문 규칙을 따라야 합니다.

자세한 내용은 네트워킹 정보를 참조하십시오.

에이전트 기반 OpenShift Container Platform 설치 관리자를 사용하면 설치 구성을 정의하고 모든 노드에 대한 ISO를 생성한 다음 생성된 ISO로 대상 시스템을 부팅하여 설치 해제할 수 있습니다. 자세한 내용은 에이전트 기반 OpenShift Container Platform 설치 프로그램을 사용하여 OpenShift Container Platform 클러스터 설치를 참조하십시오.

에이전트 기반 설치에서 호스트 이름, NMState 형식으로 네트워크 구성, 루트 장치 팁 및 역할을 구성할 수 있습니다.

자세한 내용은 루트 장치 팁 정보를 참조하십시오.

에이전트 기반 OpenShift Container Platform 설치 관리자를 사용하면 DHCP를 사용하여 모든 노드에 대한 네트워킹을 구성하기 위해 시스템 중 하나 이상이 수신할 IP를 알고 있는 환경에 배포할 수 있습니다. 이 IP는 모든 노드가 회의 지점으로 사용하려면 이 IP가 필요합니다. 자세한 내용은 DHCP 를 참조하십시오.

연결이 끊겼거나 제한된 네트워크 클러스터의 경우와 같이 환경에 인터넷 액세스가 제한되면 Nutanix에 클러스터를 설치할 수 있습니다. 이 유형의 설치를 통해 OpenShift Container Platform 이미지 레지스트리의 내용을 미러링하고 설치 미디어를 포함하는 레지스트리를 생성합니다. 인터넷과 폐쇄 네트워크에 모두 액세스할 수 있는 미러 호스트에 레지스트리를 생성할 수 있습니다.

자세한 내용은 제한된 네트워크 의 Nutanix에 클러스터 설치를 참조하십시오.

vSphere에서 실행되는 클러스터에 CSI 드라이버를 설치하려면 다음 요구 사항을 충족해야 합니다.

위의 버전보다 이전 버전의 구성 요소는 계속 지원되지만 더 이상 사용되지 않습니다. 이러한 버전은 여전히 완전히 지원되지만 OpenShift Container Platform 버전 4.12에는 vSphere 가상 하드웨어 버전 15 이상이 필요합니다. 자세한 내용은 사용 중단 및 제거된 기능을 참조하십시오.

위의 요구 사항을 충족하지 못하면 OpenShift Container Platform이 OpenShift Container Platform 4.13 이상으로 업그레이드할 수 없습니다.

다음과 같은 새로운 클러스터 기능이 추가되었습니다.

사전 정의된 새로운 클러스터 기능 세트 v4.12 가 추가되었습니다. 여기에는 v4.11 의 모든 기능과 현재 릴리스와 함께 추가된 새로운 기능이 포함됩니다.

자세한 내용은 link: 클러스터 기능 활성화를 참조하십시오.

다중 아키텍처 컴퓨팅 머신이 있는 OpenShift Container Platform 4.12에서는 이미지 스트림에 나열된 매니페스트를 지원합니다. 매니페스트 목록 이미지에 대한 자세한 내용은 OpenShift Container Platform 클러스터에서 다중 아키텍처 컴퓨팅 머신 구성을 참조하십시오.

다중 아키텍처 컴퓨팅 머신이 있는 클러스터에서 Operator의 Subscription 오브젝트의 노드 유사성을 재정의하여 Operator에서 지원하는 아키텍처를 사용하여 노드에 Pod를 예약할 수 있습니다. 자세한 내용은 노드 유사성을 사용하여 Operator가 설치된 위치를 제어하는 것을 참조하십시오.

이 릴리스에서는 웹 콘솔의 관리자 화면에 대한 여러 업데이트가 있습니다.

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

Krew를 사용하여 OpenShift CLI(oc)에 대한 플러그인을 설치 및 관리할 수 있습니다. 이제 기술 프리뷰 로 사용할 수 있습니다.

자세한 내용은 Krew를 사용하여 CLI 플러그인 관리를 참조하십시오.

이제 OpenShift Container Platform 4.12 이상에서 SPO(Security Profiles Operator)를 사용할 수 있습니다.

SPO는 보안 컴퓨팅(seccomp) 프로필 및 SELinux 프로필을 사용자 정의 리소스로 정의하고 지정된 네임스페이스의 모든 노드에 프로필을 동기화하는 방법을 제공합니다.

자세한 내용은 Security Profiles Operator 개요 를 참조하십시오.

지원되는 설치 프로그램은 베어 메탈의 API VIP 및 Ingress VIP에 대한 이중 스택 네트워킹을 사용하는 OpenShift Container Platform 4.12 이상 버전의 설치를 지원합니다. 이 지원에서는 IP 주소 목록을 가져올 수 있는 api_vips 및 ingress_vips 의 두 가지 새로운 구성 설정을 도입합니다. 레거시 설정인 api_vip 및 ingress_vip 도 OpenShift Container Platform 4.12에서 설정해야 합니다. 그러나 하나의 IP 주소만 사용하므로 API VIP에 듀얼 스택 네트워킹을 구성할 때 IPv4 주소를 설정해야 하며, Ingress VIP에 대한 듀얼 스택 네트워킹을 레거시 api_vip 및 ingress_vip 구성 설정으로 설정해야 합니다.

듀얼 스택 네트워킹을 사용하는 경우 API VIP 주소와 Ingress VIP 주소는 기본 IP 주소 제품군이어야 합니다. 현재 Red Hat은 IPv6를 사용한 듀얼 스택 VIP 또는 듀얼 스택 네트워킹을 기본 IP 주소 제품군으로 지원하지 않습니다. 그러나 Red Hat은 IPv4를 기본 IP 주소 제품군으로 사용한 듀얼 스택 네트워킹을 지원합니다. 따라서 IPv6 항목 앞에 IPv4 항목을 배치해야 합니다. 자세한 내용은 지원 설치 관리자 설명서를 참조하십시오.

Red Hat OpenShift Networking은 Kubernetes CNI 플러그인 이상으로 Kubernetes 네트워킹을 하나 또는 여러 하이브리드 클러스터의 네트워크 트래픽을 관리하는 데 필요한 고급 네트워킹 관련 기능을 사용하여 Kubernetes 네트워킹을 확장하는 기능, 플러그인 및 고급 네트워킹 기능의 에코시스템입니다. 이 네트워킹 기능 에코시스템은 수신, 송신, 로드 밸런싱, 고성능 처리량, 보안 및 클러스터 간 트래픽 관리를 통합하며, 자연적인 복잡성을 줄이기 위해 역할 기반 관찰 도구를 제공합니다.

자세한 내용은 네트워킹 정보를 참조하십시오.

새 클러스터를 설치할 때 OVN-Kubernetes 네트워크 플러그인은 기본 네트워킹 플러그인입니다. 이전 버전의 OpenShift Container Platform에서 OpenShift SDN은 기본 네트워킹 플러그인으로 유지됩니다.

OVN-Kubernetes 네트워크 플러그인에는 다음을 포함하여 OpenShift SDN보다 다양한 기능이 포함되어 있습니다.

OpenShift Container Platform 4.12의 이전 버전과 비교하면 OpenShift Container Platform 4.12의 확장성, 성능 및 안정성도 크게 향상되었습니다.

OpenShift SDN 네트워크 플러그인을 사용하는 경우 다음 사항에 유의하십시오.

OpenShift SDN과의 기능 비교 매트릭스를 포함한 OVN-Kubernetes 에 대한 자세한 내용은 OVN-Kubernetes 네트워크 플러그인 정보를 참조하십시오.

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

이번 업데이트에서는 새로운 상태 비저장 Ingress Node Firewall Operator가 도입되었습니다. 노드 수준에서 방화벽 규칙을 구성할 수 있습니다. 자세한 내용은 Ingress Node Firewall Operator 를 참조하십시오.

이제 OVN-Kubernetes 네트워크 플러그인에 다음 메트릭을 사용할 수 있습니다.

다음 메트릭이 제거되었습니다.

OpenShift Container Platform 4.12부터 설치 관리자 프로비저닝 인프라를 사용하여 단일 vCenter 설치에서 여러 vCenter 데이터센터와 여러 vCenter 클러스터를 구성하는 기능을 이제 기술 프리뷰 기능으로 사용할 수 있습니다. vCenter 태그를 사용하면 vCenter 데이터 센터와 컴퓨팅 클러스터를 openshift-regions 및 openshift-zones와 연결할 수 있습니다. 이러한 연결을 통해 애플리케이션 워크로드가 특정 위치 및 장애 도메인과 연관될 수 있도록 실패 도메인을 정의합니다.

OpenShift Container Platform 4.12부터 VMware vSphere 인스턴스에서 Kubernetes NMState Operator를 사용하여 DNS 서버 또는 검색 도메인, VLAN, 브리지 및 인터페이스 본딩과 같은 네트워킹 설정을 구성할 수 있습니다.

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

OpenShift Container Platform 4.12부터 OpenStack 인스턴스에서 Kubernetes NMState Operator를 사용하여 DNS 서버 또는 검색 도메인, VLAN, 브리지 및 인터페이스 본딩과 같은 네트워킹 설정을 구성할 수 있습니다.

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

OpenShift Container Platform 4.12에서 External DNS Operator는 AzureDNS의 ExternalDNS 와일드카드 TXT 레코드 형식을 수정합니다. 외부 DNS Operator는 별표를 ExternalDNS 와일드카드 TXT 레코드로 바꿉니다. 충돌이 발생할 수 있으므로 ExternalDNS 와일드카드 A 및 CNAME 레코드가 남아 있는 하위 도메인이 있으면 안 됩니다.

OpenShift Container Platform 4.12용 ExternalDNS 의 업스트림 버전은 v0.13.1입니다.

OpenShift Container Platform 4.12에서 Cluster Ingress Operator는 route_metrics_controller_routes_per_shard 라는 새 지표를 내보냅니다. 지표의 shard_name 레이블은 shard의 이름을 지정합니다. 이 메트릭은 각 shard에서 허용하는 총 경로 수를 제공합니다.

다음 지표는 Telemetry를 통해 전송됩니다.

OpenShift Container Platform 4.12에서 AWS Load Balancer 컨트롤러는 여러 일치에 대해 Kubernetes Ingress 사양을 구현합니다. Ingress 내의 여러 경로가 요청과 일치하면 가장 긴 일치 경로가 우선합니다. 두 경로가 여전히 일치하는 경우 경로 유형이 정확한 경로가 있는 경로가 접두사 경로 유형보다 우선합니다.

AWS Load Balancer Operator는 EnableIPTargetType 기능 게이트를 false 로 설정합니다. AWS Load Balancer 컨트롤러는 대상 유형 IP에 대한 서비스 및 수신 리소스에 대한 지원을 비활성화 합니다.

OpenShift Container Platform 4.12의 업스트림 버전은 v2.4.4입니다.

OpenShift Container Platform Custom Metrics Autoscaler Operator를 사용하여 사용 가능한 작업자 노드 수와 같이 배포된 클러스터의 메트릭을 기반으로 기본 Ingress 컨트롤러를 동적으로 확장할 수 있습니다. Custom Metrics Autoscaler는 기술 프리뷰 기능으로 사용할 수 있습니다.

자세한 내용은 Ingress 컨트롤러 자동 확장을 참조하십시오.

OpenShift Container Platform 4.12에서 maxConnections 설정의 기본값은 이제 50000입니다. 이전에는 OpenShift Container Platform 4.11부터 maxConnections 설정의 기본값이ECDHE이었습니다.

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

자동 DNS 관리를 중지하고 수동 DNS 관리를 시작하도록 Ingress 컨트롤러를 구성할 수 있습니다. dnsManagementPolicy 매개변수를 설정하여 자동 또는 수동 DNS 관리를 지정합니다.

자세한 내용은 DNS를 수동으로 관리하도록 Ingress 컨트롤러 구성 을 참조하십시오.

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

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

OpenShift Container Platform 4.12에는 다음 장치에 대한 OvS Hardware Offload 지원이 추가되었습니다.

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

OpenShift Container Platform 4.12에서는 SR-IOV 장치에 대한 다중 네트워크 정책 구성을 지원합니다.

이제 SR-IOV 추가 네트워크에 대한 다중 네트워크를 구성할 수 있습니다. SR-IOV 추가 네트워크는 기술 프리뷰 기능이며 커널 네트워크 인터페이스 카드(NIC)에서만 지원됩니다.

자세한 내용은 다중 네트워크 정책 구성을 참조하십시오.

Ingress 컨트롤러를 삭제하지 않고 AWS Classic Load Balancer(CLB)와 AWS NLB(Network Load Balancer)를 전환하도록 Ingress 컨트롤러를 업데이트할 수 있습니다.

자세한 내용은 AWS에서 수신 클러스터 트래픽 구성을 참조하십시오.

SR-IOV(Single Root I/O Virtualization) CNI 플러그인으로 생성된 Pod는 IP 주소 관리 CNI 플러그인이 IP를 할당하여 이제 IPv6 비호주 서블러 알림 및/또는 IPv4 비정상적인 주소 확인 프로토콜을 기본적으로 네트워크에 보냅니다. 이번 개선된 기능을 통해 특정 IP의 새 Pod MAC 주소 호스트에 올바른 정보로 ARP/NDP 캐시를 새로 고치도록 알립니다.

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

CoreDNS에서 캐시하는 DNS 쿼리가 성공하고 실패한 TTL(Time-to-live) 기간을 구성할 수 있습니다.

자세한 내용은 CoreDNS 캐시 튜닝을 참조하십시오.

이전에는 OVN-Kubernetes가 내부적으로 사용하는 서브넷은 IPv4의 경우 100.64.0.0/16 이고 IPv6의 경우 fd98::/48 은 수정할 수 없었습니다. 이러한 서브넷이 인프라의 기존 서브넷과 겹치는 경우 인스턴스를 지원하기 위해 이러한 내부 서브넷을 변경하여 중복을 방지할 수 있습니다.

자세한 내용은 Cluster Network Operator 설정 오브젝트를참조하십시오.

OpenShift Container Platform과 함께 제공되는 RHOSP에서는 이제 Egress IP 주소의 자동 첨부 및 분리를 지원합니다. 여러 네임스페이스에 있는 하나 이상의 Pod의 트래픽은 클러스터 외부의 서비스에 일관된 소스 IP 주소를 갖습니다. 이 지원은 OpenShift SDN 및 OVN-Kubernetes에 기본 네트워크 공급자로 적용됩니다.

OpenShift SDN 네트워크 플러그인에서 OVN-Kubernetes 네트워크 플러그인으로 마이그레이션하려는 경우 다음 기능에 대한 구성이 OVN-Kubernetes에서 작동하도록 자동으로 변환됩니다.

OVN-Kubernetes로의 마이그레이션이 작동하는 방법에 대한 자세한 내용은 OpenShift SDN 클러스터 네트워크 공급자에서 마이그레이션을 참조하십시오.

OVN-Kubernetes 네트워크 플러그인의 경우 송신 방화벽은 네트워크 정책 감사 로깅이 사용하는 것과 동일한 메커니즘을 사용하여 감사 로깅을 지원합니다. 자세한 내용은 송신 방화벽 및 네트워크 정책 규칙에 대한 로깅 을 참조하십시오.

이번 업데이트를 통해 BGP 모드에서는 노드 선택기를 사용하여 특정 IP 주소 풀을 사용하여 노드 서브 세트에서 MetalLB 서비스를 알릴 수 있습니다. 이 기능은 OpenShift Container Platform 4.11에서 기술 프리뷰 기능으로 소개되었으며 현재 BGP 모드의 경우 OpenShift Container Platform 4.12에서만 사용할 수 있습니다. L2 모드는 기술 프리뷰 기능으로 유지됩니다.

자세한 내용은 노드 하위 집합의 IP 주소 풀을 참조하십시오.

이번 업데이트에서는 MetalLB에 대한 추가 배포 사양을 제공합니다. 사용자 지정 리소스를 사용하여 MetalLB를 배포하는 경우 이러한 추가 배포 사양을 사용하여 MetalLB 발표자 및 컨트롤러 Pod가 클러스터에서 배포 및 실행되는 방법을 관리할 수 있습니다. 예를 들어 MetalLB 배포 사양을 사용하여 MetalLB Pod가 배포된 위치를 관리하고, MetalLB pod에 대한 CPU 제한을 정의하고, 런타임 클래스를 MetalLB Pod에 할당할 수 있습니다.

MetalLB의 배포 사양에 대한 자세한 내용은 MetalLB의 배포 사양을 참조하십시오.

이전에는 클러스터 호스트의 nodeip-configuration 서비스에서 기본 경로가 사용된 인터페이스에서 IP 주소를 선택했습니다. 여러 경로가 있는 경우 서비스는 가장 낮은 메트릭 값이 있는 경로를 선택합니다. 결과적으로 네트워크 트래픽이 잘못된 인터페이스에서 분산될 수 있었습니다.

OpenShift Container Platform 4.12에서는 새 인터페이스가 nodeip-configuration 서비스에 추가되어 사용자가 힌트 파일을 생성할 수 있습니다. 힌트 파일에는 기본 IP 선택 논리를 재정의하고 서브넷 NODEIP_HINT 변수에서 특정 노드 IP 주소를 선택하는 NODEIP_HINT 변수인 NODEIP_HINT 변수가 포함되어 있습니다. NODEIP_HINT 변수를 사용하면 사용자가 사용되는 IP 주소를 지정하여 네트워크 트래픽이 올바른 인터페이스에서 배포되도록 할 수 있습니다.

자세한 내용은 선택 사항: 기본 노드 IP 선택 논리 덮어쓰기를 참조하십시오.

OpenShift Container Platform 4.12에서 CoreDNS는 다음과 같은 변경 사항이 포함된 버전 1.10.0을 사용합니다.

이번 업데이트를 통해 클러스터 관리자는 HAProxy가 경로 및 엔드포인트 업데이트에 대한 응답으로 구성을 덜 자주 다시 로드하도록 다시 로드 간격을 구성할 수 있습니다. 기본 최소 HAProxy 재로드 간격은 5초입니다.

자세한 내용은 HAProxy 재로드 간격 구성을 참조하십시오.

Network Observability Operator는 OpenShift Container Platform 마이너 버전 릴리스 스트림과 별도로 업데이트를 릴리스합니다. 업데이트는 현재 지원되는 모든 OpenShift Container Platform 4 버전에서 지원되는 단일 롤링 스트림을 통해 제공됩니다. Network Observability Operator의 새로운 기능, 개선 사항 및 버그 수정에 대한 정보는 Network Observability 릴리스 노트 에서 확인할 수 있습니다.

이제 RHOSP에서 실행되는 클러스터에서 보조 네트워크 인터페이스의 IPv6가 지원됩니다.

자세한 내용은 RHOSP의 Pod에 대한 IPv6 연결 활성화를 참조하십시오.

외부 OpenStack 클라우드 공급자로 전환하여 UDP는 해당 플랫폼에서 실행되는 클러스터의 LoadBalancer 서비스에 대해 지원됩니다.

호스팅 서비스 클러스터를 구성하고 배포한 경우 이제 호스팅 클러스터에 대한 SR-IOV Operator를 배포할 수 있습니다. 자세한 내용은 호스팅 컨트롤 플레인에 대한 SR-IOV Operator 배포를 참조하십시오.

이번 업데이트를 통해 설치 관리자가 프로비저닝한 인프라 클러스터에서 install-config.yaml 파일의 ingressVIP 및 apiVIP 구성 설정이 더 이상 사용되지 않습니다. 대신 ingressVIPs 및 apiVIPs 구성 설정을 사용합니다. 이러한 설정은 Ingress VIP 및 API VIP 서비스를 사용하여 클러스터에 대한 IPv4 및 IPv6 액세스가 필요한 베어 메탈의 애플리케이션에 대해 이중 스택 네트워킹을 지원합니다. ingressVIPs 및 apiVIPs 구성 설정은 목록 형식을 사용하여 IPv4 주소, IPv6 주소 또는 두 IP 주소 형식을 지정합니다. 목록의 순서는 각 서비스의 기본 및 보조 VIP 주소를 나타냅니다. 듀얼 스택 네트워킹을 사용하는 경우 기본 IP 주소는 IPv4 네트워크에서 있어야 합니다.

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

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

이전에는 클러스터 설치 중에 OVN-Kubernetes 네트워크 플러그인 을 사용하는 클러스터의 경우 클러스터가 Windows 노드를 지원하도록 하이브리드 네트워킹을 활성화할 수 있었습니다. 이제 설치 후 하이브리드 네트워킹을 활성화할 수 있습니다. 자세한 내용은 하이브리드 네트워킹 구성을 참조하십시오.

Service 오브젝트의 Network API의 ServiceSpec 구성 요소는 사용자가 서비스에 생성하는 특성을 설명합니다. ServiceSpec 구성 요소 내의 allocateLoadBalancerNodePorts 속성이 OpenShift Container Platform 4.12.28 릴리스에서 지원됩니다. allocateLoadBalancer NodePorts 속성은 LoadBalancer 유형의 서비스에 NodePort가 자동으로 할당될지 여부를 정의합니다.

자세한 내용은 Network API ServiceSpec 오브젝트를참조하십시오.

OpenShift Container Platform은 GCP(Google Compute Platform) 파일 저장소의 CSI(Container Storage Interface) 드라이버를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다. 이 드라이버를 관리하는 GCP Filestore CSI Driver Operator는 기술 프리뷰로 사용할 수 있습니다.

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

OpenShift Container Platform 4.8부터 동등한 CSI(Container Storage Interface) 드라이버로 in-tree 볼륨 플러그인에 대한 자동 마이그레이션이 기술 프리뷰 기능으로 사용 가능하게 되었습니다. AWS(Amazon Web Services) EBS(Elastic Block Storage)에 대한 지원은 OpenShift Container Platform 4.8에서 이 기능을 통해 제공되며 OpenShift Container Platform 4.12에서는 AWS EBS에 대한 자동 마이그레이션을 사용할 수 있습니다. AWS EBS의 CSI 마이그레이션은 기본적으로 활성화되어 있으며 관리자가 작업을 수행하지 않아도 됩니다.

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

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

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

OpenShift Container Platform 4.8부터 동등한 CSI(Container Storage Interface) 드라이버로 in-tree 볼륨 플러그인에 대한 자동 마이그레이션이 기술 프리뷰 기능으로 사용 가능하게 되었습니다. OpenShift Container Platform 4.9의 이 기능에 GCP PD(Google Compute Engine Persistent Disk)에 대한 지원이 제공되었으며 OpenShift Container Platform 4.12는 이제 일반적으로 사용 가능한 GCP PD에 대한 자동 마이그레이션을 지원합니다. 이제 GCP PD의 CSI 마이그레이션이 기본적으로 활성화되어 관리자가 수행할 필요가 없습니다.

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

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

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

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

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

이 새로운 기능은 CSIStorageCapacity 오브젝트를 사용하여 현재 사용 가능한 스토리지 용량을 노출하고 늦은 바인딩과 함께 CSI(Container Storage Interface) 볼륨을 사용하는 Pod 예약을 향상시킵니다. 현재 이 기능을 지원하는 유일한 OpenShift Container Platform 스토리지 유형은 OpenShift Data Foundation입니다.

OpenShift Container Platform은 vSphere용 OpenShift Container Platform을 다른 영역 및 리전에 배포할 수 있는 기능을 제공하므로 여러 컴퓨팅 클러스터에 배포할 수 있으므로 단일 장애 지점을 방지할 수 있습니다.

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

이제 로컬 임시 스토리지 리소스 관리 기능을 일반적으로 사용할 수 있습니다. 이 기능을 사용하면 요청 및 제한을 지정하여 로컬 임시 스토리지를 관리할 수 있습니다.

자세한 내용은 임시 스토리지 관리를 참조하십시오.

볼륨 팝업기에서는 데이터 소스 를 사용하여 미리 채워진 볼륨을 생성할 수 있습니다.

볼륨 채우기는 현재 활성화되어 있으며 기술 프리뷰 기능으로 지원됩니다. 그러나 OpenShift Container Platform에는 볼륨 팝업기가 제공되지 않습니다.

자세한 내용은 볼륨 팝업기를 참조하십시오.

OpenShift Container Platform 4.12의 경우 VMWare vSphere Container Storage Interface(CSI) Driver Operator에는 다음과 같은 최소 구성 요소가 설치되어 있어야 합니다.

타사 CSI 드라이버가 클러스터에 있는 경우 OpenShift Container Platform은 이를 덮어쓰지 않습니다. 타사 CSI 드라이버가 있으면 OpenShift Container Platform이 OpenShift Container Platform 4.13 이상으로 업그레이드되지 않습니다.

자세한 내용은 VMware vSphere CSI Driver Operator 요구 사항을 참조하십시오.

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

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

OpenShift Container Platform 4.12부터 OLM(Operator Lifecycle Manager)은 플랫폼 Operator 유형을 기술 프리뷰 기능으로 도입합니다. 플랫폼 Operator 메커니즘은 OpenShift Container Platform 4.12에서 도입된 RukPak 구성 요소의 리소스에 의존하여 콘텐츠를 소싱하고 관리합니다.

Platform Operator는 OpenShift Container Platform 클러스터의 Day 0 작업 중 또는 이후에 설치할 수 있고 클러스터의 라이프사이클에 참여할 수 있는 OLM 기반 Operator입니다. 클러스터 관리자는 플랫폼 Operator를 사용하여 요구 사항 및 사용 사례에 맞게 OpenShift Container Platform 설치를 추가로 사용자 지정할 수 있습니다.

플랫폼 Operator에 대한 자세한 내용은 플랫폼 Operator 관리를 참조하십시오. RukPak 및 해당 리소스에 대한 자세한 내용은 Operator Framework 패키징 형식을 참조하십시오.

기본적으로 Operator를 설치할 때 OpenShift Container Platform은 작업자 노드 중 하나에 무작위로 Operator Pod를 설치합니다.

OpenShift Container Platform 4.12에서는 Operator의 Subscription 오브젝트에 유사성 제약 조건을 추가하여 Operator Pod 설치 위치를 제어할 수 있습니다.

자세한 내용은 Operator가 설치된 위치 제어를 참조하십시오.

OpenShift Container Platform 4.12에서는 Operator가 openshift- 접두사가 있는 사용자 생성 네임스페이스에 설치된 경우 기본적으로 Pod 보안 승인 동기화가 활성화됩니다. CSV(클러스터 서비스 버전)가 네임스페이스에 생성된 후 동기화가 활성화됩니다. 동기화된 레이블은 네임스페이스에서 서비스 계정의 권한을 상속합니다.

자세한 내용은 Pod 보안 표준을 사용한 보안 컨텍스트 제약 조건 동기화 를 참조하십시오.

run bundle 및 bundle-upgrade 하위 명령에서 --security-context-config 플래그를 사용하여 카탈로그 Pod의 보안 컨텍스트를 구성할 수 있습니다. 플래그를 사용하면 seccomp 프로필이 Pod 보안 승인을 준수할 수 있습니다. 플래그는 제한 및 레거시 의 값을 허용합니다. 값을 지정하지 않으면 seccomp 프로필은 기본적으로 restricted 로 설정됩니다. 제한된 권한으로 카탈로그 Pod를 실행할 수 없는 경우 다음 예와 같이 플래그를 legacy 로 설정합니다.

$ operator-sdk run bundle \
  --security-context-config=legacy

이제 bundle validate 하위 명령과 함께 Operator Framework Framework 테스트 모음을 사용하여 Kubernetes 1.25에서 제거된 더 이상 사용되지 않는 API의 번들 매니페스트를 확인할 수 있습니다.

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

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

Operator에서 Kubernetes 1.25에서 제거된 API를 사용할 수 있는 권한을 요청하는 경우 명령에서 경고 메시지를 표시합니다.

Kubernetes 1.25에서 제거된 API 버전이 CSV(클러스터 서비스 버전)에 포함된 경우 명령에 오류 메시지가 표시됩니다.

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

OpenShift Container Platform 4.12에는 컨트롤 플레인 머신 세트가 도입되었습니다. 컨트롤 플레인 머신 세트는 컴퓨팅 머신에 제공하는 컴퓨팅 머신 세트와 유사한 컨트롤 플레인 시스템에 관리 기능을 제공합니다. 자세한 내용은 컨트롤 플레인 시스템 관리를 참조하십시오.

OpenShift Container Platform에서는 ClusterAutoscaler 사용자 정의 리소스에서 logVerbosity 매개변수를 설정하여 클러스터 자동 스케일러의 로그 수준 세부 정보 표시 수준을 설정할 수 있습니다. 자세한 내용은 ClusterAutoscaler 리소스 정의를 참조하십시오.

OpenShift Container Platform에서는 머신 세트가 생성하는 Azure 머신에서 부팅 진단 활성화를 지원합니다. 자세한 내용은 컴퓨팅 머신 또는 컨트롤 플레인 머신 의 "Azure 부팅 진단 활성화"를 참조하십시오.

RHCOS(Red Hat Enterprise Linux CoreOS) 이미지 계층 지정을 사용하면 기본 RHCOS 이미지 상단에 새 이미지를 추가할 수 있습니다. 이 계층화는 기본 RHCOS 이미지를 수정하지 않습니다. 대신 모든 RHCOS 기능을 포함하는 사용자 정의 계층 이미지를 생성하고 클러스터의 특정 노드에 기능을 추가합니다.

현재 RHCOS 이미지 계층화에서는 Red Hat Hotfix 정책을 기반으로 Customer Experience and Engagement(CEE)를 사용하여 RHCOS 이미지 상단에서 Hotfix 패키지를 확보하고 적용할 수 있습니다. RHCOS 이미지 계층 지정을 사용하여 Libreswan 또는 numactl과 같은 타사 소프트웨어 패키지를 통합할 수 있는 향후 릴리스에 계획되어 있습니다.

자세한 내용은 RHCOS 이미지 계층 지정을 참조하십시오.

OpenShift Container Platform에서는 이제 기본 인터페이스별 안전한 sysctl 업데이트를 지원합니다.

사전 정의된 목록에서 sysctl 을 추가하거나 제거할 수 있습니다. sysctl 을 추가하면 모든 노드에 설정할 수 있습니다. 인터페이스별 안전한 sysctl 목록을 업데이트하는 것은 기술 프리뷰 기능입니다.

자세한 내용은 인터페이스별 안전한 sysctl 목록 업데이트를 참조하십시오.

cron 작업 일정의 시간대 설정은 이제 기술 프리뷰 로 제공됩니다. 시간대를 지정하지 않으면 Kubernetes 컨트롤러 관리자는 해당 로컬 시간대에 상대적인 일정을 해석합니다.

자세한 내용은 cron 작업 생성 을 참조하십시오.

Linux Control Group 버전 2( cgroup v2)에 대한 OpenShift Container Platform 지원은 기술 프리뷰로 승격되었습니다. cgroup v2는 커널 제어 그룹 의 다음 버전입니다. cgroup v2는 통합 계층, 더 안전한 하위 트리 위임, pressure Stall Information 과 같은 새로운 기능을 포함하여 여러 개선 사항을 제공합니다. 자세한 내용은 Linux Control Group version 2 (cgroup v2) 활성화를 참조하십시오.

OpenShift Container Platform은 이제 기술 프리뷰에서 crun 컨테이너 런타임을 지원합니다. ContainerRuntimeConfig 사용자 지정 리소스(CR)를 사용하여 필요에 따라 crun 컨테이너 런타임과 기본 컨테이너 런타임 간에 전환할 수 있습니다. 자세한 내용은 컨테이너 엔진 및 컨테이너 런타임 정보를 참조하십시오.

OpenShift Container Platform에서는 Self Node Remediation Operator를 통한 컨트롤 플레인 펜싱을 지원합니다. 노드 장애가 발생하는 경우 작업자 노드와 컨트롤 플레인 노드에서 모두 수정 전략을 실행할 수 있습니다. 자세한 내용은 Workload Availability for Red Hat OpenShift 설명서를 참조하십시오.

OpenShift Container Platform에서는 Node Health Check Operator에서 컨트롤 플레인 펜싱을 지원합니다. 노드 장애가 발생하는 경우 작업자 노드와 컨트롤 플레인 노드에서 모두 수정 전략을 실행할 수 있습니다. 자세한 내용은 Workload Availability for Red Hat OpenShift 설명서를 참조하십시오.

이제 Node Health Check Operator에 Node Health Checks 관리를 위한 웹 콘솔 플러그인도 포함됩니다. 자세한 내용은 Workload Availability for Red Hat OpenShift 설명서를 참조하십시오.

Node Health Check Operator의 최신 버전을 설치하거나 업데이트하려면 stable 서브스크립션 채널을 사용합니다. 자세한 내용은 Workload Availability for Red Hat OpenShift 설명서를 참조하십시오.

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

OpenShift Container Platform Pod가 여러 가용성 영역에 배포되는 경우 Pod 토폴로지 분배 제약 조건을 사용하여 Prometheus, Thanos Ruler 및 Alertmanager Pod가 네트워크 토폴로지에 분배되는 방법을 제어할 수 있습니다.

여러 자동 스케일링 요청에서 데이터 일관성을 개선하도록 Prometheus Adapter(PA)에 대한 선택적 kubelet 서비스 모니터를 구성할 수 있습니다. 이 서비스 모니터를 사용하면 PA로 동시에 전송된 두 쿼리가 PA에 의해 실행되는 기본 PromQL 쿼리가 다른 Prometheus 서버에 있을 수 있으므로 다른 결과가 발생할 수 있습니다.

이번 릴리스에서는 추가 키를 보유하도록 Alertmanager 보안을 구성하고 Alertmanager 구성이 이러한 키(예: 템플릿, TLS 인증서 또는 토큰)를 참조하는 경우, 구성 설정에서 상대 경로가 아닌 절대 경로를 사용하여 이러한 키를 가리켜야 합니다. 이러한 키는 /etc/alertmanager/config 디렉터리에서 사용할 수 있습니다. 이전 버전의 OpenShift Container Platform에서는 Alertmanager 구성 파일이 키와 동일한 디렉터리에 있었기 때문에 구성의 상대 경로를 사용하여 이러한 키를 가리킬 수 있습니다.

기본적으로 클러스터 수준에서 systemd 서비스는 가상 네트워크 인터페이스에 대해 Receive Packettektonering (RPS) 마스크를 설정합니다. RPS 마스크는 성능 프로필에 정의된 예약된 CPU 목록에 따라 가상 네트워크 인터페이스의 요청을 중단합니다. 컨테이너 수준에서 CRI-O 후크 스크립트는 모든 가상 네트워크 장치에 대한 RPS 마스크도 설정합니다.

이번 업데이트를 통해 성능 프로필에서 spec.workloadHints.realTime 을 False 로 설정하면 시스템에서 RPS 마스크를 설정하는 systemd 서비스와 CRI-O 후크 스크립트도 비활성화합니다. RPS는 일반적으로 대기 시간이 짧고 실시간 워크로드가 필요한 사용 사례와 관련이 있기 때문에 이러한 RPS 함수를 비활성화합니다.

spec.workloadHints.realTime 을 False 로 설정하는 경우에도 RPS 기능을 유지하려면 Red Hat Knowledgebase 솔루션 Performance addons operator 의 RPS 설정 섹션을 참조하십시오.

워크로드 힌트 구성에 대한 자세한 내용은 워크로드 힌트 이해를 참조하십시오.

이제 tuned 프로필에서 기본적으로 fs.aio-max-nr sysctl 값을 정의하여 기본 노드 프로필의 비동기 I/O 성능을 개선합니다.

최신 커널 기능 및 옵션을 사용하도록 짧은 대기 시간 튜닝이 업데이트되었습니다. 2117780 의 수정 사항에는 CPU당 새로운 kthread,ktimers 가 도입되었습니다. 이 스레드는 적절한 CPU 코어에 고정되어야 합니다. 이번 업데이트를 통해 기능적인 변경 사항은 없습니다. 워크로드 격리는 동일합니다. 자세한 내용은ECDHE 2450을 참조하십시오.

OpenShift Container Platform 4.12에서는 C 상태 및 OS 제어 P-상태를 활성화하여 중요하거나 중요하지 않은 워크로드에 다양한 전원을 사용할 수 있습니다. 새로운 perPodPowerManagement 워크로드 힌트와 cpu-c-states.crio.io 및 cpu- freq-governor.crio.io CRI- O 주석을 통해 구성을 적용할 수 있습니다. 이 기능에 대한 자세한 내용은 Power-ECDHE Configuration을 참조하십시오.

OpenShift Container Platform 4.11에서는 단일 노드 OpenShift 클러스터에 작업자 노드를 수동으로 추가할 수 있는 기능이 도입되었습니다. 이 기능은 이제 GitOps ZTP에서도 사용할 수 있습니다.

자세한 내용은 GitOps ZTP를 사용하여 단일 노드 OpenShift 클러스터에 작업자 노드 추가를 참조하십시오.

OpenShift Container Platform 4.12에서는 seamless-precaching-cli 툴을 사용하여 배당의 서버에서 OpenShift Container Platform 및 Operator 이미지를 사전 캐시한 다음 사전 캐시된 서버를 배포 사이트에 포함할 수 있습니다. loading-precaching-cli 툴에 대한 자세한 내용은 단일 노드 OpenShift 배포의 이미지 사전 캐싱 을 참조하십시오.

OpenShift Container Platform 4.12에서는 GitOps ZTP 워크플로에서 loading-precaching-cli 툴을 사용할 수 있습니다. 자세한 내용은 단일 노드 OpenShift 배포용 이미지 사전 캐싱을 참조하십시오.

Node Tuning Operator를 사용하여 호스트 클러스터에서 노드의 OS 수준 튜닝을 구성할 수 있습니다. 노드 튜닝을 구성하려면 Tuned 오브젝트가 포함된 관리 클러스터에 구성 맵을 생성하고 노드 풀에 해당 구성 맵을 참조할 수 있습니다. Tuned 오브젝트에서 definied된 튜닝 구성은 노드 풀의 노드에 적용됩니다. 자세한 내용은 호스팅된 클러스터에서 노드 튜닝 구성을 참조하십시오.

KMM(커널 모듈 관리) Operator는 SAR(Special Resource Operator)를 대체합니다. KMM에는 연결된 환경에만 다음 기능이 포함되어 있습니다.

인터넷에 액세스할 수 있는 환경의 hub 및 spoke 배포의 경우 hub 클러스터에 배포된 KMM(커널 모듈 관리) Operator를 사용하여 필요한 커널 모듈의 배포를 하나 이상의 관리형 클러스터에 관리할 수 있습니다.

topology Aware Lifecycle Manager (TALM)에서 보다 자세한 상태 정보 및 메시지와 재설계된 조건을 제공합니다. ClusterLabelSelector 필드를 사용하여 업데이트를 위해 클러스터를 선택할 때 유연성을 높일 수 있습니다. 시간 초과 설정을 사용하여 클러스터에 대한 업데이트가 실패하는 경우(예: 실패한 클러스터를 건너뛰고 다른 클러스터를 계속 업그레이드하거나 모든 클러스터에 대한 정책 수정을 중지하는 등) 발생하는 상황을 확인할 수 있습니다. 자세한 내용은 클러스터 업데이트에 대한 토폴로지 Aware Lifecycle Manager를 참조하십시오.

캡슐화는 모든 Kubernetes별 마운트 지점을 대체 네임스페이스로 이동하여 기본 네임스페이스의 많은 마운트 지점의 가시성 및 성능 영향을 줄이는 프로세스입니다. 이전 버전에서는 GitOps ZTP를 사용하여 설치된 DU(Distributed Unit)를 위해 OpenShift Container Platform에 마운트 네임스페이스 캡슐화가 투명하게 배포되었습니다. OpenShift Container Platform v4.12에서 이 기능은 이제 구성 가능한 옵션으로 제공됩니다.

표준 호스트 운영 체제는 systemd를 사용하여 모든 마운트 네임스페이스(표준 Linux 마운트와 Kubernetes가 작동하는 데 사용하는 수많은 마운트)를 지속적으로 검사합니다. Kubelet 및 CRI-O의 현재 구현은 모든 컨테이너 및 Kubelet 마운트 지점에 최상위 네임스페이스를 사용합니다. 프라이빗 네임스페이스에서 이러한 컨테이너별 마운트 지점을 캡슐화하면 systemd 오버헤드가 줄어들고 CPU 성능이 향상됩니다. 캡슐화는 권한이 없는 사용자가 검사에서 안전한 위치에 Kubernetes별 마운트 지점을 저장하여 보안을 개선할 수도 있습니다.

자세한 내용은 마운트 네임스페이스 캡슐화를 사용하여 CPU 사용량 최적화 를 참조하십시오.

GitOps ZTP로 배포하는 단일 노드 OpenShift 클러스터에서 워크로드 파티셔닝 CPU 세트를 구성할 수 있습니다. 이렇게 하려면 site Config CR(사용자 정의 리소스)의 cpuset 필드와 PolicyGenTemplate CR의 reserved 필드를 사용하여 클러스터 관리 CPU 리소스를 지정합니다. cpuset 에 설정한 값은 워크로드 파티셔닝을 위한 클러스터 PerformanceProfile CR .spec.cpu.reserved 필드에 설정된 값과 일치해야 합니다.

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

RHACM(Red Hat Advanced Cluster Management) 및 TALM( Topology Aware Lifecycle Manager)을 사용하여 Hub 템플릿 기능을 GitOps ZTP와 함께 사용할 수 있습니다. Hub-side 클러스터 템플릿을 사용하면 similiar 구성이 있지만 값이 다른 여러 클러스터에 대해 별도의 정책을 생성할 필요가 없습니다. 자세한 내용은 PolicyGenTemplate CR에서 hub 템플릿 사용을 참조하십시오.

RHACM은 siteConfig CR을 사용하여 ArgoCD의 1일 차 관리 클러스터 설치 CR을 생성합니다. 각 ArgoCD 애플리케이션은 최대 300개의 site Config CR을 관리할 수 있습니다. 자세한 내용은 ArgoCD를 사용하여 허브 클러스터 구성 을 참조하십시오.

GitOps ZTP v4.11+에서는 PolicyGenTemplate CR(사용자 정의 리소스)에서 기본 정책 준수 평가 시간 초과 값을 사용할 수 있습니다. 이 값은 RHACM이 적용된 클러스터 정책을 다시 평가하기 전에 관련 ConfigurationPolicy CR의 상태가 정책 준수 또는 비준수 상태에 있을 수 있는 기간을 지정합니다.

선택적으로 PolicyGenTemplate CR의 모든 정책에 대한 기본 평가 간격을 덮어쓸 수 있습니다.

자세한 내용은 PolicyGenTemplate CR에 대한 정책 준수 평가 시간 초과 구성을 참조하십시오.

지원 설치 프로그램은 현재 다음과 같은 OpenShift Container Platform 플랫폼을 지원합니다.

단일 노드 OpenShift는 VSphere 를 지원하지 않습니다.

이 릴리스에서는 hub 클러스터를 구성할 때 인증되지 않은 레지스트리를 사용할 수 있습니다. 인증이 필요하지 않은 레지스트리는 AgentServiceConfig 리소스의 spec.unauthenticatedRegistries 에 나열됩니다. 이 목록의 레지스트리는 설명된 클러스터 설치에 사용된 풀 시크릿에 항목이 필요하지 않습니다. assisted-service 는 설치에 사용되는 모든 이미지 레지스트리에 대한 인증 정보가 포함되어 있는지 확인하여 풀 시크릿을 검증합니다.

자세한 내용은 인증되지 않은 레지스트리를 사용하도록 hub 클러스터 구성을 참조하십시오.

GitOps ZTP를 사용하여 연결 해제된 설치의 경우 OpenShift Container Platform 버전 4.11 또는 이전 버전을 통합 흐름이 활성화된 대화 상자에 배포하는 경우 기본 Ironic 에이전트 이미지를 로컬 이미지 리포지토리에 미러링해야 합니다. 기본 Ironic 에이전트 이미지는 다음과 같습니다.

이미지 미러링에 대한 자세한 내용은 OpenShift Container Platform 이미지 저장소 미러링을 참조하십시오.

OpenShift Container Platform은 이제 GitOps ZTP 배포에서 Discovery ISO에 대한 커널 인수 지정을 지원합니다. 수동 및 자동화된 GitOps ZTP 배포 모두에서 Discovery ISO는 관리 베어 메탈 호스트의 OpenShift Container Platform 설치 프로세스의 일부입니다. 이제 InfraEnv 리소스를 편집하여 Discovery ISO에 대한 커널 인수를 지정할 수 있습니다. 이는 특정 환경 요구 사항이 있는 클러스터 설치에 유용합니다. 예를 들어 rd.net.timeout.carrier 커널 인수를 정의하여 정적 네트워킹을 위한 클러스터를 구성할 수 있습니다.

커널 인수를 지정하는 방법에 대한 자세한 내용은 GitOps ZTP 를 사용하여 Discovery ISO에 대한 커널 인수 구성 및 GitOps ZTP 를 사용하여 수동으로 설치를 위해 Discovery ISO에 대한 커널 인수 구성을 참조하십시오.

이번 업데이트를 통해 AMD64 및 AArch64 CPU 아키텍처 둘 다 사용하는 호스트를 지원하는 이기종 클러스터라고도 하는 OpenShift Container Platform 혼합 아키텍처 클러스터를 생성할 수 있습니다. RHACM(Red Hat Advanced Cluster Management)에서 관리하는 허브 클러스터에서 이기종 발표 클러스터를 배포할 수 있습니다. 이기종 발표 클러스터를 생성하려면 배포된 AMD64 클러스터에 AArch64 작업자 노드를 추가합니다.

배포된 AMD64 클러스터에 AArch64 작업자 노드를 추가하려면 InfraEnv CR(사용자 정의 리소스)을 사용하여 AArch64 아키텍처, 다중 아키텍처 릴리스 이미지 및 노드에 필요한 운영 체제를 지정할 수 있습니다. 그런 다음 Assisted Installer API 및 InfraEnv CR을 사용하여 AArch64 작업자 노드를 AMD64 클러스터에 프로비저닝할 수 있습니다.

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

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

OpenShift Container Platform 4.12에서 활성 Insights 권장 사항은 이제 사용자에게 경고로 표시됩니다. Alertmanager를 사용하여 이러한 경고를 보고 구성할 수 있습니다.

OpenShift Container Platform 4.12에서 Insights Operator에서 다음 메트릭을 수집합니다.

이제 RHOSP(Red Hat OpenStack Platform)에서 실행되는 클러스터의 clouds.yaml 파일에 애플리케이션 인증 정보를 지정할 수 있습니다. 애플리케이션 자격 증명은 구성 파일에 사용자 계정 세부 정보를 포함하는 대안입니다. 예를 들어 사용자 계정 세부 정보가 포함된 clouds.yaml 파일의 다음 섹션을 참조하십시오.

clouds:
    openstack:
        auth:
            auth_url: https://127.0.0.1:13000
            password: thepassword
            project_domain_name: Default
            project_name: theprojectname
            user_domain_name: Default
            username: theusername
        region_name: regionOne

해당 섹션을 애플리케이션 인증 정보를 사용하는 것과 비교합니다.

clouds:
    openstack:
        auth:
            auth_url: https://127.0.0.1:13000
            application_credential_id: '5dc185489adc4b0f854532e1af81ffe0'
            application_credential_secret: 'PDCTKans2bPBbaEqBLiT_IajG8e5J_nJB4kvQHjaAy6ufhod0Zl0NkNoBzjn_bWSYzk587ieIGSlT11c4pVehA'
        auth_type: "v3applicationcredential"
        region_name: regionOne

클러스터와 함께 애플리케이션 인증 정보를 RHOSP 관리자로 사용하려면 인증 정보를 생성합니다. 그런 다음 클러스터를 설치할 때 clouds.yaml 파일에서 사용하십시오. 또는 clouds.yaml 파일을 생성하여 기존 클러스터로 순환할 수 있습니다.

OpenShift Container Platform에서 호스팅 컨트롤 플레인의 API인 hypershift.openshift.io API의 기본 버전은 이제 v1beta1입니다. 현재 기존 클러스터의 경우 alpha에서 beta로의 이동은 지원되지 않습니다.

OpenShift Container Platform의 각 메이저, 마이너 또는 패치 버전 릴리스와 함께 HyperShift Operator가 릴리스됩니다. HyperShift CLI(명령줄 인터페이스)는 각 HyperShift Operator 릴리스의 일부로 릴리스됩니다.

HostedCluster 및 NodePool API 리소스는 API의 베타 버전에서 사용할 수 있으며 OpenShift Container Platform 및 Kubernetes 와 유사한 정책을 따릅니다.

OpenShift Container Platform에서 호스트 컨트롤 플레인을 사용하는 경우 etcd 스냅샷을 작성하고 이를 나중에 검색할 수 있는 위치에 업로드하여 etcd를 백업 및 복원할 수 있습니다(예: S3 버킷). 나중에 필요한 경우 스냅샷을 복원할 수 있습니다. 자세한 내용은 호스팅된 클러스터에서 etcd 백업 및 복원을 참조하십시오.

호스팅된 클러스터의 재해 복구가 필요한 경우 호스팅된 클러스터를 AWS 내의 동일한 리전으로 복구할 수 있습니다. 자세한 내용은 AWS 리전 내에서 호스팅되는 클러스터에 대한 재해 복구 에서 참조하십시오.