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

OpenShift Container Platform 4.10에는 이제 시작 가이드가 포함되어 있습니다. OpenShift Container Platform 시작하기에서는 기본 용어를 정의하고 개발자와 관리자를 위한 역할 기반 다음 단계를 제공합니다.

튜토리얼은 웹 콘솔과 OpenShift CLI(oc) 인터페이스를 통해 신규 사용자를 안내합니다. 신규 사용자는 시작하기를 통해 다음 작업을 수행할 수 있습니다.

자세한 내용은 OpenShift Container Platform 시작하기를 참조하십시오.

coreos-installer 유틸리티에는 라이브 ISO 및 PXE 이미지에서 RHCOS를 설치할 때 보다 유연한 사용자 지정을 위해 iso customize 및 pxe customize 하위 명령이 있습니다.

여기에는 사용자 정의 인증 기관 또는 자체 서명된 인증서를 사용하는 HTTPS 서버에서 Ignition 구성을 가져오도록 설치를 사용자 지정할 수 있습니다.

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

OpenShift Container Platform 4.10 설치 프로그램은 AWS에 설치할 때 새로운 기본 구성 요소 유형을 사용합니다. 설치 프로그램은 기본적으로 다음 구성 요소를 사용합니다.

이전에는 사용자가 베어 메탈 설치 관리자 프로비저닝 인프라에 OpenShift Container Platform을 설치할 때 Ironic 서버와 통신하도록 고정 IP 또는 vLAN과 같은 사용자 지정 네트워크 인터페이스를 구성할 위치가 없었습니다.

베어 메탈에서만 Day 1 설치를 구성할 때 사용자는 이제 install-config.yaml 파일에서 API를 사용하여 네트워크 구성(networkConfig)을 사용자 지정할 수 있습니다. 이 구성은 설치 및 프로비저닝 프로세스 중에 설정되며 호스트당 정적 IP 설정 등 고급 옵션을 포함합니다.

OpenShift Container Platform 4.10은 이제 ARM 기반 AWS EC2 및 베어 메탈 플랫폼에서 지원됩니다. 인스턴스 가용성 및 설치 문서는 다른 플랫폼에 지원되는 설치 방법에서 확인할 수 있습니다.

ARM의 OpenShift Container Platform에서 지원되는 기능은 다음과 같습니다.

다음 Operator는 ARM의 OpenShift Container Platform에서 지원됩니다.

OpenShift Container Platform 4.10에서는 기술 프리뷰의 설치 관리자 프로비저닝 인프라를 사용하여 IBM Cloud에 클러스터를 설치할 수 있도록 지원합니다.

IPI를 사용하는 IBM Cloud에는 다음과 같은 제한 사항이 적용됩니다.

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

OpenShift Container Platform 4.10에서는 설치 관리자 프로비저닝 인프라를 사용하여 클러스터를 설치할 때 씬 프로비저닝된 디스크를 지원합니다. 디스크를 thin, thick, 또는 eagerZeroedThick으로 프로비저닝할 수 있습니다. VMware vSphere의 디스크 프로비저닝 모드에 대한 자세한 내용은 설치 구성 매개 변수를 참조하십시오.

이제 AWS GovCloud 리전에서 RHCOS(Red Hat Enterprise Linux CoreOS) AMI(Amazon Machine Images)를 사용할 수 있습니다. 이러한 AMI의 가용성은 더 이상 클러스터를 배포하기 위해 사용자 지정 RHCOS AMI를 업로드하지 않아도 되므로 설치 프로세스가 향상됩니다.

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

OpenShift Container Platform 4.10부터 기존 IAM 역할로 클러스터를 구성하면 설치 프로그램에서 클러스터를 배포할 때 더 이상 shared 태그를 역할에 추가하지 않습니다. 이 기능 향상을 통해 사용자 지정 IAM 역할을 사용하려고 하지만 보안 정책으로 인해 shared 태그 사용이 금지된 조직에 대한 설치 프로세스가 향상되었습니다.

vSphere에서 실행되는 클러스터에 CSI 드라이버를 설치하려면 다음 구성 요소가 설치되어 있어야 합니다.

위의 버전보다 이전 버전의 구성 요소는 계속 지원되지만 더 이상 사용되지 않습니다. 이러한 버전은 여전히 완전히 지원되지만 OpenShift Container Platform 버전 4.11에는 vSphere 가상 하드웨어 버전 15 이상이 필요합니다.

OpenShift Container Platform 4.10에는 기술 프리뷰의 설치 관리자 프로비저닝 인프라를 사용하여 RuntimeClass Cloud에 클러스터를 설치할 수 있는 기능이 도입되었습니다. 이러한 유형의 설치를 통해 설치 프로그램이 프로비저닝하고 클러스터가 유지보수하는 인프라에 클러스터를 배포할 수 있습니다.

OpenShift Container Platform 4.10에서는 설치 관리자 프로비저닝 인프라를 사용하여 Azure Stack Hub에 클러스터를 설치할 수 있도록 지원합니다. 이러한 유형의 설치를 통해 설치 프로그램이 프로비저닝하고 클러스터가 유지보수하는 인프라에 클러스터를 배포할 수 있습니다.

자세한 내용은 설치 관리자 프로비저닝 인프라를 사용하여 Azure Stack Hub에 클러스터 설치를 참조하십시오.

OpenShift Container Platform 4.10은 OpenShift Update Service에서 제공하는 조건부 업데이트 경로 사용을 지원합니다. 조건부 업데이트 경로는 확인된 위험 및 해당 위험이 클러스터에 적용되는 조건을 전달합니다. 웹 콘솔의 관리자 (Administrator) 모드에서는 클러스터가 알려진 위험과 일치하지 않는 권장되는 업그레이드 경로만 제공합니다. 그러나 OpenShift CLI(oc) 4.10 이상에서는 OpenShift Container Platform 4.10 클러스터에 대한 추가 업그레이드 경로를 표시하는 데 사용할 수 있습니다. 문서 참조를 비롯한 관련 위험 정보는 경로와 함께 표시됩니다. 관리자는 참조 자료를 검토하고 지원되는 업그레이드(더 이상 권장되지 않음)를 수행할 수 있습니다.

자세한 내용은 조건부 업데이트 및 조건부 업그레이드 경로에 따라 업데이트를 참조하십시오.

이번 릴리스에서는 oc-mirror OpenShift CLI(oc) 플러그인이 기술 프리뷰로 도입되었습니다. oc-mirror 플러그인을 사용하여 연결이 끊긴 환경의 이미지를 미러링할 수 있습니다.

자세한 내용은 oc-mirror 플러그인을 사용하여 연결이 끊긴 설치의 이미지 미러링을 참조하십시오.

이제 OVS-DPDK(Data Plane Development Kit) 네트워크를 사용하여 Open vSwitch에서 컴퓨팅 머신이 실행되는 RHOSP(Red Hat OpenStack Platform)에 클러스터를 설치할 수 있습니다. 이러한 머신에서 실행되는 워크로드는 OVS-DPDK의 성능 및 대기 시간 개선의 이점을 얻을 수 있습니다.

자세한 내용은 DPDK 연결 컴퓨팅 머신을 지원하는 RHOSP에 클러스터 설치를 참조하십시오.

RHOSP에 클러스터를 설치할 때 컴퓨팅 머신 선호도를 선택할 수 있습니다. 기본적으로 컴퓨팅 머신은 soft-anti-affinity 서버 정책을 사용하여 배포되지만 anti-affinity 또는 soft-affinity 정책을 선택할 수도 있습니다.

OpenShift Container Platform 4.10부터 OpenShift 콘솔 동적 플러그인을 생성하는 기능을 기술 프리뷰 기능으로 사용할 수 있습니다. 이 기능을 사용하여 다음을 포함하여 런타임 시 인터페이스를 사용자 지정할 수 있습니다.

동적 플러그인에 대한 자세한 내용은 OpenShift Container Platform 웹 콘솔에 동적 플러그인 추가를 참조하십시오.

이번 업데이트를 통해 웹 콘솔에서 디버그 터미널을 볼 수 있습니다. Pod에 CrashLoopBackOff 상태에 있는 컨테이너가 있는 경우 디버그 Pod를 시작할 수 있습니다. 터미널 인터페이스가 표시되고 크래시 루프 컨테이너를 디버깅하는 데 사용할 수 있습니다.

또한 Pod 상태 팝업 창에서 Pod 세부 정보 페이지의 로그 및 이벤트 탭에 대한 링크를 제공합니다.

이번 업데이트를 통해 사용자 환경 설정 페이지에서 워크로드 알림을 사용자 지정할 수 있습니다. 알림 탭의 사용자 워크로드 알림을 사용하여 클러스터 개요 페이지 또는 드로어에 표시되는 사용자 워크로드 알림을 숨길 수 있습니다.

이번 업데이트를 통해 관리자 이외의 사용자는 이제 프로젝트 개요,ResourceQuotas, API Explorer 페이지에서 AppliedClusterResourceQuota의 사용량을 보고 사용할 수 있는 클러스터 범위 할당량을 결정할 수 있습니다. 또한 AppliedClusterResourceQuota 세부 정보는 이제 검색 페이지에서 확인할 수 있습니다.

OpenShift Container Platform을 사용하면 개요 세부 정보 카드의 클러스터 설정, 클러스터 설정, 모달 정보에서 클러스터에 대한 지원 수준 정보를 볼 수 있으며 클러스터가 지원되지 않는 경우 알림 창에 알림을 추가할 수 있습니다. 개요 페이지에서 SLA(서비스 수준 계약)에 따라 서브스크립션 설정을 관리할 수 있습니다.

여러 IP 주소 제품군을 사용하는 서비스를 생성할 때 Service 오브젝트 정의에서 ipFamilyPolicy: PreferDualStack 또는 ipFamilyPolicy: RequireDualStack을 명시적으로 지정해야 합니다. 이번 변경으로 인해 이전 릴리스의 OpenShift Container Platform과 역호환이 중단됩니다.

자세한 내용은 BZ#2045576에서 참조하십시오.

클러스터 설치 후 OpenShift SDN 클러스터 네트워크 공급자 또는 OVN-Kubernetes 클러스터 네트워크 공급자를 사용하는 경우 하드웨어 MTU 및 클러스터 네트워크 MTU 값을 변경할 수 있습니다. 클러스터 전체에서 MTU를 변경하는 것은 중단되므로 각 노드를 여러 번 재부팅해야 합니다. 자세한 내용은 클러스터 네트워크 MTU 변경을 참조하십시오.

OVN-Kubernetes CNI 네트워크 공급자는 송신 트래픽이 노드 게이트웨이로 전송되는 방법을 구성하는 지원을 추가합니다. 기본적으로 송신 트래픽은 클러스터를 종료하기 위해 OVN에서 처리되며 트래픽은 커널 라우팅 테이블의 특수 경로의 영향을 받지 않습니다.

이번 개선된 기능에는 gatewayConfig.routingViaHost 필드가 추가되었습니다. 이번 업데이트를 통해 런타임 시 필드를 설치 후 활동으로 설정할 수 있으며 true로 설정되면 송신 트래픽이 Pod에서 호스트 네트워킹 스택으로 전송됩니다. 이번 업데이트에서는 커널 라우팅 테이블에 수동으로 구성된 경로를 사용하는 고도의 전문 설치 및 애플리케이션에 도움이 됩니다.

이번 개선된 기능을 통해 Open vSwitch 하드웨어 오프로드 기능과 상호 작용합니다. 이번 업데이트를 통해 gatewayConfig.routingViaHost 필드가 true로 설정되면 송신 트래픽이 호스트 네트워킹 스택에서 처리되므로 오프로드의 성능 이점을 받지 않습니다.

구성 정보는 OVN-Kubernetes CNI 클러스터 네트워크 공급자에 대한 구성을 참조하십시오.

이제 클러스터에 다음 지표를 사용할 수 있습니다. sdn_controller로 시작하는 지표 이름은 OpenShift SDN CNI 네트워크 공급자에 고유합니다. ovn으로 시작하는 지표 이름은 OVN-Kubernetes CNI 네트워크 공급자에 고유합니다.

4.10 릴리스에 대해 ovnkube_master_resource_update_total 메트릭이 제거됩니다.

OpenShift Container Platform 웹 콘솔에서 네트워크 정책 기능을 사용하는 경우 정책의 영향을 받는 Pod가 나열됩니다. 이러한 정책 섹션의 결합된 네임스페이스 및 Pod 선택기가 수정됨에 따라 목록이 변경됩니다.

영향을 받는 Pod 목록에는 사용자가 액세스할 수 있는 Pod만 포함됩니다.

oc adm must-gather 명령은 네트워크 패킷 캡처 수집을 간소화하는 방식으로 향상되었습니다.

이전 버전에서는 oc adm must-gather 가 단일 디버그 Pod만 시작할 수 있었습니다. 이번 개선된 기능을 통해 여러 노드에서 동시에 디버그 Pod를 시작할 수 있습니다.

향상된 기능을 사용하여 네트워크 통신 문제 해결을 단순화하기 위해 여러 노드에서 패킷 캡처를 실행할 수 있습니다. 새로운 --node-selector 인수는 패킷 캡처를 수집하는 노드를 식별하는 방법을 제공합니다.

자세한 내용은 네트워크 추적 방법 및 호스트 네트워크 추적 수집을 참조하십시오.

Pod 수준의 본딩은 고가용성과 처리량이 필요한 Pod 내부의 워크로드를 활성화하는 데 중요합니다. Pod 수준 본딩을 사용하면 커널 모드 인터페이스에서 여러 개의 SR-IOV(root I/O Virtualization) 가상 기능 인터페이스에서 본딩 인터페이스를 생성할 수 있습니다. SR-IOV 가상 기능은 Pod에 전달되고 커널 드라이버에 연결됩니다.

Pod 수준 본딩이 필요한 시나리오에는 다양한 물리적 기능의 여러 SR-IOV 가상 함수에서 본딩 인터페이스 생성이 포함됩니다. 호스트에서 두 가지 물리적 함수에서 본딩 인터페이스를 생성하여 Pod 수준에서 고가용성을 실현할 수 있습니다.

클러스터 관리자는 하나 이상의 송신 IP 주소를 네임스페이스와 연결할 수 있습니다. 송신 IP 주소를 사용하면 클러스터를 나가는 특정 네임스페이스의 트래픽과 일관된 소스 IP 주소가 연결됩니다.

OVN-Kubernetes 및 OpenShift SDN 클러스터 네트워크 공급자의 경우 다음 퍼블릭 클라우드 공급자에서 송신 IP 주소를 구성할 수 있습니다.

자세한 내용은 클러스터 네트워크 공급자에 대한 해당 문서를 참조하십시오.

OpenShift SDN 클러스터 네트워크 공급자를 사용하는 경우 ipBlock 및 ipBlock.except을 사용하여 네트워크 정책에서 송신 규칙을 사용할 수 있습니다. NetworkPolicy 오브젝트의 egress 배열에 송신 정책을 정의합니다.

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

이번 개선된 기능에는 특정 MIME 유형에 대해 HAProxy Ingress 컨트롤러에서 글로벌 HTTP 트래픽 압축을 구성하는 기능이 추가되었습니다. 이번 업데이트에서는 압축 가능한 라우팅 트래픽이 많은 경우 수신 워크로드를 gzip으로 압축할 수 있습니다.

자세한 내용은 라우터 압축 사용을 참조하십시오.

클러스터 관리자는 이제 기본 도메인에 대해 구성된 서버를 통해 DNS 이름 확인을 허용하도록 DNS 서버를 구성할 수 있습니다. DNS 전달 구성에는 /etc/resolv.conf 파일과 업스트림 DNS 서버에 지정된 기본 서버가 모두 있을 수 있습니다.

자세한 내용은 DNS 전달 사용을 참조하십시오.

이번 개선된 기능에는 Operator의 로그 수준을 개별적으로 또는 클러스터 전체에 수동으로 변경할 수 있는 기능이 추가되었습니다.

자세한 내용은 CoreDNS 로그 수준 설정을 참조하십시오.

Ingress 컨트롤러의 syslog 메시지의 최대 길이를 480에서 4096바이트 사이의 값으로 설정할 수 있습니다.

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

이제 DNS Operator를 통해 CoreDNS 전달 정책을 설정할 수 있습니다. 기본값은 Random이며 값을 RoundRobin 또는 Sequential으로 설정할 수도 있습니다.

자세한 내용은 DNS 전달 사용을 참조하십시오.

이제 호환되는 베어 메탈 노드에서 데이터 처리 성능을 높이기 위해 Open vSwitch 하드웨어 오프로드를 구성할 수 있습니다. 하드웨어 오프로드는 CPU에서 데이터 처리 작업을 제거하고 네트워크 인터페이스 컨트롤러의 전용 데이터 처리 장치로 전송하는 데이터를 처리하는 방법입니다. 이 기능의 이점은 더 빠른 데이터 처리, CPU 워크로드 감소 및 컴퓨팅 비용을 절감할 수 있습니다.

자세한 내용은 하드웨어 오프로드 구성을 참조하십시오.

이제 AWS, Azure 및 GCP와 같은 클라우드 공급자에서 Red Hat External DNS Operator를 사용하여 DNS 레코드를 생성할 수 있습니다. OperatorHub를 사용하여 외부 DNS Operator를 설치할 수 있습니다. 매개변수를 사용하여 필요에 따라 ExternalDNS를 구성할 수 있습니다.

자세한 내용은 외부 DNS Operator 이해를 참조하십시오.

클러스터 관리자는 OpenShift Container Platform의 Internal 및 External 간에 로드 밸런서 범위를 변경하기 위해 Ingress 컨트롤러 끝점 게시 전략을 구성할 수 있습니다.

자세한 내용은 Ingress 컨트롤러 끝점 게시 전략을 참조하십시오.

RHOSP(Red Hat OpenStack Platform)에서 실행되는 클러스터의 경우 OVS(Open vSwitch) 하드웨어 오프로드를 활성화할 수 있습니다.

자세한 내용은 OVS 하드웨어 오프로드 활성화를 참조하십시오.

RHOSP에서 실행되는 클러스터의 경우 Kuryr는 이제 Pod 네트워크에 하나 이상의 Pod가 있는 네임스페이스에 대한 Neutron 네트워크와 서브넷만 생성합니다. 또한 Pod 네트워크의 Pod가 네임스페이스에 생성된 후 네임스페이스의 풀이 채워집니다.

이제 distributed compute node (DCN) 구성을 사용하는 RHOSP(Red Hat OpenStack Platform) 배포에 클러스터를 배포할 수 있습니다. 이 배포 구성에는 몇 가지 제한 사항이 있습니다.

RHOSP에서 실행되는 클러스터는 이제 클라우드 공급자 OpenStack을 사용할 수 있습니다. 이 기능은 TechPreviewNoUpgrade 기능 세트의 일부로 사용할 수 있습니다.

OpenShift Container Platform에서는 호스트 인터페이스를 구성하기 위해 NMState YAML 구성을 사용하는 설치 관리자 프로비저닝 클러스터에 대한 networkConfig 구성 설정을 제공합니다. 설치 프로그램에서 제공하는 설치 중에 networkConfig 구성 설정과 NMState YAML 구성을 install-config.yaml 파일에 추가할 수 있습니다. 또한 Bare Metal Operator를 사용할 때 networkConfig 구성 설정과 NMState YAML 구성을 베어 메탈 호스트 리소스에 추가할 수 있습니다.

networkConfig 구성 설정의 가장 일반적인 사용 사례는 설치 중에 또는 클러스터를 확장하는 동안 호스트의 네트워크 인터페이스에 고정 IP 주소를 설정하는 것입니다.

자세한 내용은 install-config.yaml 파일에서 호스트 네트워크 인터페이스 구성을 참조하십시오.

이제 PtpConfig 프로필에 여러 네트워크 인터페이스를 지정하여 RAN vDU 애플리케이션을 실행하는 노드가 Precision Time Protocol Telecom Boundary Clock(PTP T-BC) 역할을 할 수 있습니다. 경계 클럭으로 구성된 인터페이스는 PTP 빠른 이벤트도 지원합니다.

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

Intel 800-Series Columbiaville NIC는 이제 경계 클럭 또는 일반 클럭으로 구성된 인터페이스에서 완전히 지원됩니다. Columbiaville NIC는 다음 구성에서 지원됩니다.

자세한 내용은 PTP 장치 구성을 참조하십시오.

OpenShift Container Platform은 이제 베어 메탈, IBM Power, IBM Z 및 LinuxONE 설치를 위한 Kubernetes NMState Operator를 제공합니다. Kubernetes NMState Operator는 다른 모든 플랫폼의 기술 프리뷰입니다. 자세한 내용은 Kubernetes NMState Operator 정보를 참조하십시오.

Mellanox MT2892 카드에 SR-IOV 지원을 사용할 수 있습니다.

관리자는 Network Observability Operator를 설치하여 콘솔에서 OpenShift Container Platform 클러스터의 네트워크 트래픽을 확인할 수 있습니다. 다른 그래픽 표현에서 네트워크 트래픽 데이터를 보고 모니터링할 수 있습니다. Network Observability Operator는 eBPF 기술을 사용하여 네트워크 흐름을 생성합니다. 네트워크 흐름은 OpenShift Container Platform 정보로 보강되고 로키에 저장됩니다. 자세한 문제 해결 및 분석을 위해 네트워크 트래픽 정보를 사용할 수 있습니다.

Network Observability Operator는 4.12 버전의 OpenShift Container Platform의 GA(General Availability) 상태이며 OpenShift Container Platform 4.10에서도 지원됩니다.

자세한 내용은 Network Observability 을 참조하십시오.

이 릴리스에는 MetalLB 및 MetalLB Operator에 대한 다음과 같은 개선 사항이 포함되어 있습니다.

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

OpenShift Container Platform은 HostFirmware>-< 및 FirmwareSchema 리소스를 지원합니다. 베어 메탈 호스트에 OpenShift Container Platform을 배포할 때 프로비저닝 전이나 후에 호스트를 변경해야 하는 경우가 있습니다. 여기에는 호스트의 펌웨어 및 BIOS 세부 정보 검사가 포함될 수 있습니다. Bare Metal Operator(BMO)와 함께 사용할 수 있는 두 가지 새로운 리소스가 있습니다.

자세한 내용은 베어 메탈 구성을 참조하십시오.

OpenShift Container Platform은 AliCloud Disk의 CSI(Container Storage Interface) 드라이버를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다. 이 드라이버를 관리하는 AliCloud Disk Driver Operator는 일반적으로 사용 가능하며 OpenShift Container Platform 4.10에서 기본적으로 활성화됩니다.

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

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

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

OpenShift Container Platform은 IBM Virtual Private Cloud(VPC) 블록용 CSI(Container Storage Interface) 드라이버를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다. 이 드라이버를 관리하는 IBM VPC Block Driver Operator는 일반적으로 사용 가능하며 OpenShift Container Platform 4.10에서 기본적으로 활성화됩니다.

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

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

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

vSphere CSI Driver Operator를 설치하려면 다음이 필요합니다.

이전 조건이 충족되지 않더라도 클러스터는 계속 업그레이드되지만 지원되는 vSphere CSI Operator 드라이버를 사용하려면 이러한 조건을 충족하는 것이 좋습니다.

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

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

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

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

OpenShift Container Platform 4.8부터 동등한 CSI(Container Storage Interface) 드라이버로 in-tree 볼륨 플러그인에 대한 자동 마이그레이션이 기술 프리뷰 기능으로 사용 가능하게 되었습니다. 이 기능은 Azure File CSI 드라이버로 Azure File in-tree 플러그인에 대한 자동 마이그레이션을 지원합니다.

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

OpenShift Container Platform 4.8부터 동등한 CSI(Container Storage Interface) 드라이버로 in-tree 볼륨 플러그인에 대한 자동 마이그레이션이 기술 프리뷰 기능으로 사용 가능하게 되었습니다. 이 기능은 vSphere CSI 드라이버로 vSphere in-tree 플러그인에 대한 자동 마이그레이션을 지원합니다.

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

스토리지 볼륨에 많은 파일이 포함된 경우(약 1,000,000개 이상) Pod가 타임아웃될 수 있습니다.

OpenShift Container Platform 4.10에는 fsGroup 및 fsGroupChangePolicy를 사용하여 스토리지 볼륨에 대한 재귀 권한 변경을 건너뛸 수 있는 기능이 도입되어 Pod 시간 초과 문제를 방지할 수 있습니다.

자세한 내용은 fsGroup을 사용하여 Pod 시간 초과 감소를 참조하십시오.

OLM(Operator Lifecycle Manager)에서 Operator를 설치하면 Operator가 조사하도록 구성된 모든 네임스페이스에서 CSV(클러스터 서비스 버전)의 단순화된 사본이 생성됩니다. 이러한 CSV는 복사된 CSV라고 하며 지정된 네임스페이스에서 리소스 이벤트를 적극적으로 조정하는 컨트롤러를 식별합니다.

대규모 클러스터에서는 수백 개 또는 수천 개의 복사된 Operator가 있는 대규모 클러스터에서는 OLM의 메모리 사용량, 클러스터 etcd 제한 및 네트워킹 대역폭과 같은 리소스가 지원되지 않는 리소스를 사용할 수 있습니다. 이러한 대규모 클러스터를 지원하기 위해 클러스터 관리자는 AllNamespaces 모드로 설치된 Operator에 대해 복사된 CSV를 비활성화할 수 있습니다.

자세한 내용은 Operator Lifecycle Manager 기능 구성을 참조하십시오.

특정 종속성 요구 사항이 있는 Operator는 이제 복잡한 제약 조건 또는 요구 사항 표현식을 사용할 수 있습니다. 새 olm.constraint 번들 속성에는 종속성 제약 조건 정보가 포함되어 있습니다. 메시지 필드를 사용하면 Operator 작성자가 특정 제약 조건을 사용한 이유에 대한 높은 수준의 세부 정보를 전달할 수 있습니다.

자세한 내용은 Operator Lifecycle Manager 종속성 확인을 참조하십시오.

Operator 카탈로그를 포함한 OLM(Operator Lifecycle Manager) 구성 요소는 이제 Hypershift 관리 컨트롤 플레인에서 완전히 실행될 수 있습니다. 이 기능은 작업자 노드의 테넌트에 비용이 발생하지 않습니다.

이전에는 기본 Operator 카탈로그에서 ARM을 지원하지 않습니다. 이번 개선된 기능을 통해 OLM(Operator Lifecycle Manager)은 ARM 클러스터에 기본 Operator 카탈로그를 추가합니다. 결과적으로 OperatorHub에는 ARM을 지원하는 Operator에 대한 콘텐츠가 기본적으로 포함되어 있습니다. (BZ#1996928)

Operator SDK의 표준 Helm 기반 Operator 지원은 Operator 완성 모델의 Auto Pilot 기능(level V)에 도달한 Go 기반 및 Ansible 기반 Operator 지원에 비해 기능이 제한되어 있습니다.

OpenShift Container Platform 4.10부터 기술 프리뷰 기능으로 부터 Operator SDK에는 Go API를 통해 기존 Helm 기반 지원 기능을 개선할 수 있는 하이브리드 Helm Operator가 포함되어 있습니다. Operator 작성자는 Helm 차트로 시작하는 Operator 프로젝트를 생성한 다음 Go 언어의 Helm 조정기에 고급 이벤트 기반 논리를 추가할 수 있습니다. 작성자는 Go를 사용하여 동일한 프로젝트에 새 API 및 사용자 지정 리소스 정의(CRD)를 계속 추가할 수 있습니다.

자세한 내용은 하이브리드 Helm Operator에 대한 Operator SDK 튜토리얼을 참조하십시오.

Operator 작성자는 Operator SDK에서 Ansible 기반 Operator 지원을 사용하여 사용자 정의 지표를 노출하고 Kubernetes 이벤트를 발송하며 더 나은 로깅을 제공할 수 있습니다.

자세한 내용은 Ansible 기반 Operator에 대한 사용자 정의 지표 노출을 참조하십시오.

operator-lib 정리 유틸리티를 사용하면 Go 기반 Operator가 클러스터에 남아 있고 리소스를 사용할 수 있는 작업 또는 Pod와 같은 오브젝트를 정리할 수 있습니다. 유틸리티에는 Go 기반 Operator의 일반적인 정리 전략이 포함됩니다. Operator 작성자는 유틸리티를 사용하여 사용자 정의 후크 및 전략을 생성할 수도 있습니다.

정리 유틸리티에 대한 자세한 내용은 Go 기반 Operator의 오브젝트 정리 유틸리티를 참조하십시오.

이번 개선된 기능을 통해 Operator SDK는 OLM(Operator Lifecycle Manager)을 사용하여 연결이 끊긴 환경에서 작동하는 번들에 Operator 프로젝트를 패키징할 수 있습니다. Operator 작성자는 make bundle 명령을 실행하고 USE_IMAGE_DIGESTS를 true로 설정하여 Operator 이미지 참조를 태그가 아닌 다이제스트로 자동으로 업데이트할 수 있습니다. 명령을 사용하려면 환경 변수를 사용하여 하드 코딩된 관련 이미지 참조를 교체해야 합니다.

연결이 끊긴 환경을 위해 Operator를 개발하는 방법에 대한 자세한 내용은 제한된 네트워크 환경에서 Operator 활성화를 참조하십시오.

이번 개선된 기능을 통해 Azure에서 실행되는 머신 세트를 생성하여 임시 OS 디스크에 머신을 배포할 수 있습니다. 임시 OS 디스크는 원격 Azure Storage가 아닌 로컬 VM 용량을 사용합니다.

자세한 내용은 임시 OS 디스크에 머신을 배포하는 머신 세트를 참조하십시오.

이번 릴리스에서는 Machine API를 사용하여 Microsoft Azure VM에 Accelerated Networking을 활성화할 수 있습니다. 가속 네트워킹은 단일 루트 I/O 가상화(SR-IOV)를 사용하여 VM에 더 직접적인 전환 경로를 제공합니다.

자세한 내용은 Microsoft Azure VM용 Accelerated Networking을 참조하십시오.

이번 릴리스에서는 여러 가용성 영역이 없는 글로벌 Azure 리전에서 가용성 세트를 사용하여 고가용성을 보장할 수 있습니다.

GCP(Google Cloud Platform) Compute Engine을 사용하면 사용자가 VM 인스턴스에 GPU를 추가할 수 있습니다. GPU 리소스에 액세스할 수 있는 워크로드는 이 기능이 활성화된 컴퓨팅 머신에서 더 효과적으로 수행할 수 있습니다. 이번 릴리스에서는 Machine API를 사용하여 인스턴스에 사용할 지원되는 GPU를 정의할 수 있습니다.

자세한 내용은 머신 세트의 GPU 지원 활성화를 참조하십시오.

이번 개선된 기능을 통해 ClusterAutoscaler 리소스 정의에 노드 사용률 임계값을 지정할 수 있습니다. 이 임계값은 불필요한 노드를 삭제할 수 있는 노드 사용률 수준을 나타냅니다.

자세한 내용은 클러스터 자동 스케일러 정보를 참조하십시오.

이번 개선된 기능을 통해 MCD(Machine Config Daemon)는 이제 노드 부팅 외에도 시스템 구성에 지정된 파일에 대해 파일 시스템 쓰기 이벤트가 발생하고 새 시스템 구성이 적용되기 전에 구성 드리프트에 대해 노드를 검사합니다. 이전에는 MCD에서 노드 부팅 시 구성 드리프트만 확인했습니다. 이는 관리자가 문제를 해결할 수 있을 때까지 구성 드리프트로 인한 문제를 방지할 만큼 노드 재부팅이 자주 발생하지 않기 때문에 변경되었습니다.

노드의 디스크상의 상태가 머신 구성에 구성된 것과 다른 경우 구성 드리프트가 발생합니다. MCO(Machine Config Operator)는 MCD를 사용하여 구성 드리프트의 노드를 확인하고, 탐지된 경우 해당 노드와 MCP(Machine config pool)를 degraded로 설정합니다.

구성 드리프트에 대한 자세한 내용은 구성 드리프트 감지 이해를 참조하십시오.

이제 클러스터의 특정 노드에서 Linux 제어 그룹 버전 2 (cgroups v2)를 활성화할 수 있습니다. cgroups v2를 활성화하는 OpenShift Container Platform 프로세스는 모든 cgroups 버전 1 컨트롤러 및 계층을 비활성화합니다. OpenShift Container Platform cgroups 버전 2 기능은 개발자 프리뷰에 있으며 현재 Red Hat에서 지원하지 않습니다. 자세한 내용은 Linux 제어 그룹 버전 2(cgroups v2) 활성화를 참조하십시오.

노드별로 OpenShift Container Platform 워크로드에 대한 스왑 메모리 사용을 활성화할 수 있습니다. 자세한 내용은 노드에서 스왑 메모리 사용량 활성화를 참조하십시오.

Node Maintenance Operator (NMO)는 나머지 클러스터에서 노드를 차단하고 노드의 모든 Pod를 드레이닝합니다. 노드를 유지보수 모드에 배치하면 머신 관련 문제를 조사하거나 기본 머신에서 작업을 수행할 수 있으므로 노드에 오류가 발생할 수 있습니다. 이것은 NMO의 독립형 버전입니다. OpenShift Virtualization을 설치한 경우 번들로 제공되는 NMO를 사용해야 합니다.

Node Health Check Operator는 다음과 같은 새로운 개선 사항을 제공합니다.

Poison Pill Operator는 NodeDeletion 을 기본 수정 전략으로 사용합니다. NodeDeletion 수정 전략에서는 node 오브젝트를 제거합니다.

OpenShift Container Platform 4.10에서 Poison Pill Operator에는 ResourceDeletion 이라는 새로운 수정 전략이 도입되었습니다. ResourceDeletion 수정 전략에서는 node 오브젝트가 아닌 노드의 Pod 및 관련 볼륨 연결을 제거합니다. 이 전략은 워크로드를 더 빨리 복구하는 데 도움이 됩니다.

서비스 중단 없이 하나의 RHOSP 호스트에서 다른 RHOSP 호스트로 컨트롤 플레인 노드를 마이그레이션할 수 있습니다.

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

OpenShift Container Platform 웹 콘솔의 새 메트릭 대상 페이지에는 기본 OpenShift Container Platform 프로젝트 및 사용자 정의 프로젝트의 대상이 표시됩니다. 이 페이지를 사용하여 현재 스크래핑을 대상으로 하는 끝점을 보고, 검색하고, 필터링할 수 있으므로 문제를 식별하고 해결하는 데 도움이 됩니다.

이번 릴리스에서는 모든 모니터링 구성 요소가 메트릭 수집에 대해 Bearer Token 정적 인증이 아닌 상호 TLS 인증을 사용하도록 구성됩니다. TLS 인증은 Kubernetes API 중단에 더 탄력적이며 Kubernetes API의 로드를 줄입니다.

이번 릴리스에서는 Cluster Monitoring Operator 구성 요소에서 글로벌 OpenShift Container Platform tlsSecurityProfile 설정을 준수합니다. 다음 구성 요소 및 서비스에서 TLS 보안 프로필을 사용합니다.

사용자 정의 모니터링이 활성화된 경우 다음 Pod에서 프로필을 사용합니다.

이번 릴리스에서는 다음 모니터링 구성 요소에 대해 하드 방지 규칙 및 Pod 중단 예산을 활성화하여 패치 업그레이드 중에 다운타임을 줄일 수 있습니다.

사용자 정의 모니터링을 활성화한 경우 다음 구성 요소도 이러한 규칙과 예산을 사용합니다.

이 릴리스에는 관리자가 사용자 정의 프로젝트 모니터링을 위해 경고 라우팅을 활성화할 수 있는 기술 프리뷰 기능이 도입되었습니다. 그러면 사용자가 사용자 정의 프로젝트에 대한 경고 라우팅을 추가하고 구성할 수 있습니다.

OpenShift Container Platform 경로에서 타사 Alertmanager 웹 사용자 인터페이스에 대한 액세스가 제거되었습니다.

타사 Grafana 웹 사용자 인터페이스에 대한 액세스는 더 이상 사용되지 않으며 향후 OpenShift Container Platform 릴리스에서 제거됩니다.

SRO(Special Resource Operator)에서 SRO 사용자 정의 리소스 및 오브젝트의 상태를 확인하는 데 도움이 되는 메트릭을 노출합니다. 자세한 내용은 Prometheus Special Resource Operator 메트릭을 참조하십시오.

SRO(Special Resource Operator)에 oc explain을 사용하면 SRO CRD(사용자 정의 리소스 정의)에 대한 온라인 문서가 제공됩니다. 이번 개선된 기능을 통해 CRD 필드에 대한 세부 정보가 개선되었습니다. (BZ#2031875)

이제 Node Tuning Operator (NTO) 메트릭이 Telemetry에 추가되었습니다. Telemetry에서 수집한 데이터 표시 절차에 따라 Telemetry에서 수집한 모든 메트릭을 확인합니다.

NFD(Node Feature Discovery) Topology Updater는 작업자 노드에서 할당된 리소스를 검사하는 데몬입니다. 이 노드는 영역별로 새 Pod에 할당할 수 있는 리소스를 차지하며, 여기서 영역이 NUMA(Non-Uniform Memory Access) 노드일 수 있습니다. 자세한 내용은 NFD Topology Updater 사용을 참조하십시오.

OpenShift Container Platform의 하이퍼 스레딩 인식 CPU 관리자 정책을 추가 튜닝 없이도 사용할 수 있습니다. 필요한 경우 클러스터 관리자가 이 기능을 활성화할 수 있습니다. 하이퍼스레드는 하드웨어에서 논리 프로세서로 추상화됩니다. 하이퍼 스레딩을 사용하면 단일 물리적 프로세서가 두 개의 고체중 높은 스레드(processes)를 동시에 실행하여 프로세서 리소스를 동적으로 공유할 수 있습니다.

기본 OpenShift Container Platform 스케줄러는 컴퓨팅 노드의 개별 NUMA(Non-Uniform Memory Access) 영역을 볼 수 없습니다. 이로 인해 대기 시간에 민감한 워크로드의 일시적인 스케줄링이 발생할 수 있습니다. NUMA 인식 보조 스케줄러를 배포하는 새 NUMA 리소스 Operator를 사용할 수 있습니다. NUMA 인식 보조 스케줄러는 클러스터에서 사용 가능한 NUMA 영역에 대한 전체 이미지를 기반으로 워크로드를 예약합니다. 이렇게 하면 대기 시간에 민감한 워크로드를 단일 NUMA 영역에서 처리하여 효율성 및 성능을 극대화할 수 있습니다.

자세한 내용은 NUMA 인식 스케줄링 정보를 참조하십시오.

이제 필터를 사용하여 zero touch provisioning (ZTP) GitOps 파이프라인의 설치 단계에서 사용할 다른 CR을 포함하거나 제외하도록 site Config CR을 사용자 지정할 수 있습니다. 자세한 내용은 site Config 필터를 사용하여 사용자 정의 리소스 필터링을 참조하십시오.

RAN vDU 애플리케이션을 실행하는 노드에서는 이전 버전에서 OpenShift Container Platform 4.10으로 업데이트하는 경우 chronyd 를 비활성화해야 합니다. chronyd 를 비활성화하려면 TunedPerformancePatch.yaml 파일의 .spec.profile.data 아래의 [service] 섹션에 다음 행을 추가합니다. TunedPerformancePatch.yaml 파일은 PolicyGenTemplate CR 그룹에서 참조됩니다.

[service]
service.chronyd=stop,disable

자세한 내용은 vDU 애플리케이션을 실행하도록 권장 클러스터 구성 입니다.

이번 릴리스에서는 기술 프리뷰 플래그 --replica-sets가 oc adm prune deployment 명령에 도입되었습니다. 기본적으로 복제 컨트롤러는 oc adm prune deployments 명령을 사용하여 정리됩니다. --replica-sets를 true로 설정하면 복제 세트도 정리 프로세스에 포함됩니다.

자세한 내용은 배포 리소스 정리를 참조하십시오.

OpenShift Container Platform 4.10에서 Insights Operator는 기본적으로 Red Hat OpenShift Cluster Manager에서 간단한 콘텐츠 액세스 인증서를 가져올 수 있습니다.

자세한 내용은 Insights Operator를 사용하여 간단한 콘텐츠 액세스 인증서 가져오기를 참조하십시오.

Red Hat으로 전송되는 데이터 양을 줄이기 위해 Insights Operator는 특정 조건이 충족되는 경우에만 정보를 수집합니다. 예를 들어 Insights Operator는 Alertmanager가 경고 알림을 전송하지 못하는 경우에만 Alertmanager 로그를 수집합니다.

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

Red Hat은 이러한 추가 정보를 통해 OpenShift Container Platform 기능을 개선하고 Insights Advisor 권장 사항을 향상시킵니다.

이번 릴리스에서는 사용자 로그인 시 OpenID Connect 공급자의 그룹 멤버십을 OpenShift Container Platform으로 동기화하는 기능이 추가되었습니다. OpenShift Container Platform OpenID Connect ID 공급자 구성에서 groups 클레임을 구성하여 이를 활성화할 수 있습니다.

자세한 내용은 샘플 OpenID Connect CR을 참조하십시오.

Okta 및 Ping Identity OpenID Connect(OIDC) 공급자는 이제 OpenShift Container Platform에서 테스트하고 지원됩니다.

OIDC 공급자의 전체 목록은 지원되는 OIDC 공급자를 참조하십시오.

이전 버전에서는 레지스트리 구성을 사용한 oc 명령(예: oc registry login 또는 oc image 명령)은 Docker 구성 위치에서 인증 정보를 가져옵니다. OpenShift Container Platform 4.10에서 레지스트리 항목을 기본 Docker 구성 위치에 찾을 수 없는 경우 oc 명령은 Podman 구성 위치에서 인증 정보를 가져옵니다. 우선 순위를 지정하려면 REGISTRY_AUTH_PREFERENCE 환경 변수를 사용하여 docker 또는 podman 으로 기본 설정을 설정할 수 있습니다.

사용자에게는 기존 --registry-config CLI 플래그 대신 사용되는 REGISTRY_AUTH_FILE 환경 변수를 사용할 수 있는 옵션도 있습니다. REGISTRY_AUTH_FILE 환경 변수는 podman과도 호환됩니다.

이제 CCO(Cloud Credential Operator) 유틸리티 ccoctl을 사용하여 Google Cloud Platform Workload Identity를 사용하도록 CCO를 구성할 수 있습니다. CCO가 GCP Workload Identity를 사용하도록 구성된 경우 클러스터 내 구성 요소는 단기적이고 제한된 권한 보안 인증 정보를 사용하여 IAM 서비스 계정을 구성 요소에 가장할 수 있습니다.

자세한 내용은 GCP 워크로드 ID에서 수동 모드 사용을 참조하십시오.