설치 개요

설치 프로그램을 사용하여 각 유형의 클러스터를 배포할 수 있습니다. 설치 프로그램은 부트스트랩, 컨트롤 플레인 및 컴퓨팅 머신의 Ignition 구성 파일과 같은 주요 자산을 생성합니다. 인프라를 올바르게 구성한 경우 세 가지 머신 구성으로 OpenShift Container Platform 클러스터를 시작할 수 있습니다.

OpenShift Container Platform 설치 프로그램은 일련의 대상 및 종속 항목을 사용하여 클러스터 설치를 관리합니다. 설치 프로그램에는 달성해야 할 대상 세트가 있으며 각 대상에는 종속 항목 세트가 있습니다. 각 대상은 자체 종속 항목에만 관련되므로 설치 프로그램은 최종 대상과 동시에 여러 대상을 실행 중인 클러스터가 되도록 할 수 있습니다. 설치 프로그램은 종속성을 충족하기 때문에 명령을 실행하여 다시 생성하는 대신 기존 구성 요소를 인식하고 사용합니다.

그림 1.1. OpenShift Container Platform 설치 대상 및 종속 항목

설치 후 각 클러스터 시스템은 운영 체제로 RHCOS (Red Hat Enterprise Linux CoreOS)를 사용합니다. RHCOS는 RHEL(Red Hat Enterprise Linux)의 변경 불가능한 컨테이너 호스트 버전이며 기본적으로 SELinux가 활성화된 RHEL 커널을 제공합니다. RHCOS에는 Kubernetes 노드 에이전트인 kubelet 과 Kubernetes에 최적화된 CRI-O 컨테이너 런타임이 포함됩니다.

OpenShift Container Platform 4.17 클러스터의 모든 컨트롤 플레인 시스템은 Ignition이라는 중요한 최초 부팅 프로비저닝 도구를 포함하는 RHCOS를 사용해야 합니다. 이 도구를 사용하면 클러스터가 머신을 구성할 수 있습니다. 운영 체제 업데이트는 OSTree 를 백엔드로 사용하여 Machine Config Operator에 의해 클러스터 전체에 배포되는 부팅 가능한 컨테이너 이미지로 제공됩니다. 실제 운영 체제 변경은 rpm-ostree 를 사용하여 각 머신에서 원자 작업으로 수행됩니다. 이러한 기술을 함께 사용하면 OpenShift Container Platform에서 전체 플랫폼을 최신 상태로 유지하는 인플레이스 업그레이드를 통해 클러스터의 다른 애플리케이션을 관리하는 것처럼 운영 체제를 관리할 수 있습니다. 이러한 내부 업데이트는 운영 팀의 부담을 줄일 수 있습니다.

모든 클러스터 머신의 운영 체제로 RHCOS를 사용하는 경우 클러스터가 운영 체제를 포함한 구성 요소 및 머신의 모든 측면을 관리합니다. 그러면 설치 프로그램 및 Machine Config Operator만 머신을 변경할 수 있습니다. 설치 프로그램에서는 Ignition 구성 파일을 사용하여 각 머신의 정확한 상태를 설정하고 Machine Config Operator는 설치 후 새 인증서 또는 키 적용과 같은 머신에 대한 추가 변경을 완료합니다.

용어집은 설치 콘텐츠와 관련된 일반적인 용어를 정의합니다. 설치 프로세스를 더 잘 이해하기 위해 다음 용어 목록을 읽으십시오.

지원 설치 관리자를 제외하고 OpenShift Container Platform 클러스터를 설치할 때 OpenShift Cluster Manager Hybrid Cloud Console의 적절한 클러스터 유형 페이지에서 설치 프로그램을 다운로드해야 합니다. 이 콘솔은 다음을 관리합니다.

OpenShift Container Platform 4.17에서 설치 프로그램은 자산 세트에서 일련의 파일 변환을 수행하는 Go 바이너리 파일입니다. 설치 프로그램과 상호 작용하는 방법은 설치 유형에 따라 다릅니다. 다음 설치 사용 사례를 고려하십시오.

설치 프로그램의 경우 프로그램은 설치 중에 install-config.yaml, Kubernetes 매니페스트 및 머신 유형에 대한 Ignition 구성 파일의 세 가지 파일 세트를 사용합니다.

설치 구성 파일은 Kubernetes 매니페스트로 변환된 다음 매니페스트가 Ignition 구성 파일로 래핑됩니다. 설치 프로그램은 이러한 Ignition 구성 파일을 사용하여 클러스터를 생성합니다.

설치 프로그램을 실행할 때 설치 구성 파일이 모두 정리되므로 다시 사용하려는 모든 구성 파일을 백업하십시오.

지원 설치 관리자를 사용한 설치 프로세스

지원 설치 관리자를 사용하여 설치하려면 웹 기반 사용자 인터페이스 또는 RESTful API를 사용하여 대화식으로 클러스터 구성을 생성해야 합니다. 지원 설치 관리자 사용자 인터페이스에서 필요한 값을 입력하라는 메시지를 표시하고 사용자 인터페이스 또는 API에서 변경하지 않는 한 나머지 매개변수에 대한 적절한 기본값을 제공합니다. 지원 설치 프로그램은 다운로드하여 클러스터 시스템을 부팅하는 데 사용하는 검색 이미지를 생성합니다. 이 이미지는 RHCOS 및 에이전트를 설치하고 에이전트가 프로비저닝을 처리합니다. 지원 설치 관리자를 사용하여 OpenShift Container Platform을 설치하고 Nutanix, vSphere 및 베어 메탈에서 전체 통합을 설치할 수 있습니다. 또한 통합 없이 다른 플랫폼에 지원 설치 프로그램을 사용하여 OpenShift Container Platform을 설치할 수 있습니다.

OpenShift Container Platform은 운영 체제 자체를 포함하여 클러스터의 모든 측면을 관리합니다. 각 머신은 결합하는 클러스터에서 호스팅되는 리소스를 참조하는 구성으로 부팅됩니다. 이 구성을 사용하면 업데이트가 적용될 때 클러스터가 자체적으로 관리될 수 있습니다.

가능한 경우 지원 설치 관리자 기능을 사용하여 에이전트 기반 설치 관리자를 다운로드하고 구성할 필요가 없습니다.

에이전트 기반 인프라를 사용하는 설치 프로세스

에이전트 기반 설치는 에이전트 기반 설치 관리자를 다운로드하여 설치해야 한다는 점을 제외하고 지원 설치 관리자를 사용하는 것과 유사합니다. 에이전트 기반 설치는 지원 설치 프로그램의 편의를 원하지만 연결이 끊긴 환경에 클러스터를 설치해야 하는 경우 유용합니다.

가능한 경우 에이전트 기반 설치 기능을 사용하여 부트스트랩 VM으로 프로비저너 시스템을 생성한 다음 클러스터 인프라를 프로비저닝 및 유지 관리할 필요가 없습니다.

설치 관리자가 프로비저닝한 인프라를 사용하는 설치 프로세스

기본 설치 유형에서는 설치 관리자 프로비저닝 인프라를 사용합니다. 기본적으로 설치 프로그램은 설치 마법사 역할을 하여 자체적으로 결정할 수 없는 값을 입력하라는 메시지를 표시하고 나머지 매개변수에 대한 적절한 기본값을 제공합니다. 고급 인프라 시나리오를 지원하도록 설치 프로세스를 사용자 정의할 수도 있습니다. 설치 프로그램은 클러스터의 기본 인프라를 프로비저닝합니다.

표준 클러스터 또는 사용자 정의된 클러스터를 설치할 수 있습니다. 표준 클러스터에서는 클러스터를 설치하는 데 필요한 최소 세부 정보를 제공합니다. 사용자 지정 클러스터를 사용하면 컨트롤 플레인에서 사용하는 머신 수, 클러스터가 배포하는 가상 머신 유형 또는 Kubernetes 서비스 네트워크의 CIDR 범위와 같은 플랫폼에 대한 세부 정보를 지정할 수 있습니다.

가능하면 이 기능을 사용하여 클러스터 인프라를 프로비저닝 및 유지보수하지 않아도 됩니다. 다른 모든 환경에서는 설치 프로그램을 사용하여 클러스터 인프라를 프로비저닝하는 데 필요한 자산을 생성합니다.

OpenShift Container Platform은 설치 프로그램에서 프로비저닝한 인프라 클러스터를 통해 운영 체제 자체를 포함하여 클러스터의 모든 측면을 관리합니다. 각 머신은 결합하는 클러스터에서 호스팅되는 리소스를 참조하는 구성으로 부팅됩니다. 이 구성을 사용하면 업데이트가 적용될 때 클러스터가 자체적으로 관리될 수 있습니다.

사용자 프로비저닝 인프라를 사용하는 설치 프로세스

제공하는 인프라에 OpenShift Container Platform도 설치할 수 있습니다. 설치 프로그램을 사용하여 클러스터 인프라를 프로비저닝하고 클러스터 인프라를 생성한 다음 제공한 인프라에 클러스터를 배포하는 데 필요한 자산을 생성합니다.

설치 프로그램이 프로비저닝한 인프라를 사용하지 않는 경우 클러스터 리소스를 직접 관리하고 유지보수해야 합니다. 다음 목록에서는 이러한 자체 관리 리소스 중 일부를 자세히 설명합니다.

클러스터가 사용자 프로비저닝 인프라를 사용하는 경우 RHEL 컴퓨팅 머신을 클러스터에 추가할 수 있습니다.

설치 프로세스 세부사항

클러스터가 프로비저닝되면 클러스터의 각 시스템에 클러스터에 대한 정보가 필요합니다. OpenShift Container Platform은 초기 구성 중에 임시 부트스트랩 머신을 사용하여 필요한 정보를 영구 컨트롤 플레인에 제공합니다. 임시 부트스트랩 머신은 클러스터 생성 방법을 설명하는 Ignition 구성 파일을 사용하여 부팅됩니다. 부트스트랩 시스템은 컨트롤 플레인을 구성하는 컨트롤 플레인 시스템을 생성합니다. 그런 다음 컨트롤 플레인 시스템에서는 작업자 머신이라고도 하는 컴퓨팅 머신을 만듭니다. 다음 그림은 이 프로세스를 보여줍니다.

그림 1.2. 부트스트랩, 컨트롤 플레인 및 컴퓨팅 시스템 생성

클러스터 머신이 초기화되면 부트스트랩 머신이 손상됩니다. 모든 클러스터에서는 부트스트랩 프로세스를 사용하여 클러스터를 초기화하지만, 클러스터의 인프라를 프로비저닝하는 경우 많은 단계를 수동으로 완료해야 합니다.

클러스터 부트스트랩에는 다음 단계가 포함됩니다.

이 부트스트랩 프로세스의 결과는 실행 중인 OpenShift Container Platform 클러스터입니다. 그런 다음 클러스터는 지원되는 환경에서 컴퓨팅 머신 생성을 포함하여 일상적인 작업에 필요한 나머지 구성 요소를 다운로드하고 구성합니다.

다음 설치 상태 점검이 성공하면 OpenShift Container Platform 설치가 완료됩니다.

설치가 완료되면 클러스터의 노드 상태를 계속 모니터링할 수 있습니다.

설치 범위

OpenShift Container Platform 설치 프로그램의 범위는 의도적으로 한정됩니다. 단순성과 성공을 보장하도록 설계되었습니다. 설치가 완료된 후 많은 추가 구성 작업을 완료할 수 있습니다.

OpenShift Local은 OpenShift Container Platform 클러스터 빌드를 시작할 수 있도록 빠른 애플리케이션 개발을 지원합니다. OpenShift Local은 로컬 컴퓨터에서 실행되어 설정 및 테스트를 단순화하고 컨테이너 기반 애플리케이션을 개발하는 데 필요한 모든 툴을 사용하여 클라우드 개발 환경을 로컬로 에뮬레이션하도록 설계되었습니다.

사용하는 프로그래밍 언어와 관계없이 OpenShift Local은 애플리케이션을 호스팅하고 서버 기반 인프라 없이도 로컬 PC에 사전 구성된 최소 Red Hat OpenShift Container Platform 클러스터를 제공합니다.

호스팅된 환경에서 OpenShift Local은 Linux, macOS 또는 Windows 10 이상을 실행하는 랩탑 또는 데스크탑에서 직접 마이크로서비스를 생성하고 이미지로 변환한 컨테이너에서 직접 실행할 수 있습니다.

OpenShift Local에 대한 자세한 내용은 Red Hat OpenShift 로컬 개요 를 참조하십시오.

OpenShift Container Platform을 직접 설치하고 관리하려면 다음 플랫폼에 설치할 수 있습니다.

온프레미스 하드웨어 및 클라우드 호스팅 서비스에 모두 OpenShift Container Platform 4 클러스터를 배포할 수 있지만 클러스터의 모든 시스템은 동일한 데이터 센터 또는 클라우드 호스팅 서비스에 있어야 합니다.

OpenShift Container Platform을 사용하지만 클러스터를 직접 관리하지 않으려면 여러 관리 서비스 옵션 중에서 선택할 수 있습니다. Red Hat에서 완전히 관리하는 클러스터를 원하는 경우 OpenShift Dedicated 를 사용할 수 있습니다. Azure, AWS, IBM Cloud® 또는 Google Cloud Platform에서 OpenShift를 관리형 서비스로 사용할 수도 있습니다. 관리 서비스에 대한 자세한 내용은 OpenShift 제품 페이지를 참조하십시오. 클라우드 가상 머신을 가상 베어 메탈으로 사용하여 OpenShift Container Platform 클러스터를 설치하는 경우 해당 클라우드 기반 스토리지가 지원되지 않습니다.

OpenShift Container Platform 3을 사용했으며 OpenShift Container Platform 4를 시도하려면 OpenShift Container Platform 4가 어떻게 다른지 이해해야 합니다. OpenShift Container Platform 4는 Kubernetes 애플리케이션과 플랫폼이 실행되는 운영 체제인 RHCOS(Red Hat Enterprise Linux CoreOS)를 함께 원활하게 패키지, 배포, 관리하는 Operator를 만듭니다. OpenShift Container Platform을 설치하기 위해 머신을 배포하고 운영 체제를 구성하는 대신 RHCOS 운영 체제는 OpenShift Container Platform 클러스터의 통합된 부분입니다. 클러스터 머신의 운영 체제를 배포하는 것은 OpenShift Container Platform의 설치 프로세스의 일부입니다. OpenShift Container Platform 3과 4의 차이점 을 참조하십시오.

OpenShift Container Platform 클러스터 설치 프로세스의 일부로 머신을 프로비저닝해야 하므로 OpenShift Container Platform 3 클러스터를 OpenShift Container Platform 4로 업그레이드할 수 없습니다. 대신 새로운 OpenShift Container Platform 4 클러스터를 생성하고 OpenShift Container Platform 3 워크로드를 마이그레이션해야 합니다. 마이그레이션에 대한 자세한 내용은 OpenShift Container Platform 3에서 4로 마이그레이션을 참조하십시오. OpenShift Container Platform 4로 마이그레이션해야 하므로 모든 유형의 프로덕션 클러스터 설치 프로세스를 사용하여 새 클러스터를 생성할 수 있습니다.

운영 체제는 OpenShift Container Platform에 통합되므로 OpenShift Container Platform용 설치 프로그램이 모든 인프라를 가동하도록 하는 것이 더 쉬워집니다. 이는 설치 관리자가 프로비저닝한 인프라 설치라고 합니다. 이 유형의 설치에서는 클러스터에 일부 기존 인프라를 제공할 수 있지만, 설치 프로그램은 클러스터가 처음에 필요한 모든 머신을 배포합니다.

AWS,Azure,Azure Stack Hub,GCP,Nutanix.에 대한 클러스터 또는 해당 기본 머신에 사용자 지정을 지정하지 않고 설치 관리자가 프로비저닝한 인프라 클러스터를 배포할 수 있습니다.

클러스터 머신의 인스턴스 유형과 같이 설치 관리자가 프로비저닝한 인프라 클러스터에 대한 기본 구성을 수행해야 하는 경우 AWS,Azure,GCP,Nutanix 에 대한 설치를 사용자 지정할 수 있습니다.

설치 관리자가 프로비저닝한 인프라 설치의 경우 AWS의 기존 VPC,Azure의 vNet 또는 GCP의 VPC 를 사용할 수 있습니다. AWS,Azure,GCP 의 클러스터가 사용자 환경의 기존 IP 주소 할당과 공존하고 기존 MTU 및 VXLAN 구성과 통합할 수 있도록 네트워킹 인프라의 부분을 재사용할 수도 있습니다. 이러한 클라우드에 기존 계정과 인증 정보가 있는 경우 다시 사용할 수 있지만 계정을 수정하여 OpenShift Container Platform 클러스터를 설치하는 데 필요한 권한이 있어야 할 수 있습니다.

설치 관리자 프로비저닝 인프라 방법을 사용하여 하드웨어에 vSphere 및 베어 메탈에 적절한 머신 인스턴스를 생성할 수 있습니다. 또한 vSphere 의 경우 설치 중에 추가 네트워크 매개변수를 사용자 지정할 수도 있습니다.

일부 설치 관리자 프로비저닝 인프라 설치(예: VMware vSphere 및 베어 메탈 플랫폼)의 경우 수신 가상 IP(VIP)에 도달하는 외부 트래픽은 기본 IngressController 복제본 간에 분산되지 않습니다. 기본 IngressController 라우터 성능을 초과하는 vSphere g 및 베어 메탈 설치 관리자 프로비저닝 인프라 설치의 경우 외부 로드 밸런서를 구성해야 합니다. 외부 로드 밸런서를 구성하면 여러 IngressController 복제본의 성능이 향상됩니다. 기본 IngressController 성능에 대한 자세한 내용은 Baseline Ingress Controller (router) 성능을 참조하십시오. 외부 로드 밸런서 구성에 대한 자세한 내용은 사용자 관리 로드 밸런서 구성을 참조하십시오.

광범위한 클라우드 인프라를 재사용하려면 사용자가 프로비저닝한 인프라 설치를 완료할 수 있습니다. 이러한 설치를 통해 설치 프로세스 중에 클러스터에 필요한 머신을 수동으로 배포합니다. AWS, Azure ,Azure Stack Hub 에서 사용자가 프로비저닝한 인프라 설치를 수행하는 경우, 제공된 템플릿을 사용하여 모든 필수 구성 요소를 유지할 수 있습니다. GCP에서 공유 VPC 를 재사용할 수도 있습니다. 그렇지 않으면 공급자와 무관한 설치 방법을 사용하여 다른 클라우드에 클러스터를 배포할 수 있습니다.

기존 하드웨어에서 사용자가 프로비저닝한 인프라 설치를 완료할 수도 있습니다. LPAR ,IBM Power, 또는 vSphere 에서는 RHOSP,IBM Z® 또는 IBM® LinuxONE , IBM Z® 및 IBM® LinuxONE을 사용하는 경우 특정 설치 지침을 사용하여 클러스터를 배포합니다. 다른 지원되는 하드웨어를 사용하는 경우 베어 메탈 설치 절차를 따르십시오. vSphere 및 베어 메탈 과 같은 일부 플랫폼의 경우 설치 중에 추가 네트워크 매개변수를 사용자 지정할 수도 있습니다.

사용자가 프로비저닝한 설치 메서드를 사용하는 경우 클러스터에 대한 프록시를 구성할 수 있습니다. 지침은 각 설치 절차에 포함됩니다.

퍼블릭 클라우드의 클러스터가 외부에서 끝점을 노출하지 못하도록 하려면 AWS,Azure 또는 GCP 에 설치 관리자 프로비저닝 인프라가 있는 프라이빗 클러스터를 배포할 수 있습니다.

연결이 끊긴 또는 제한된 네트워크 클러스터와 같은 인터넷에 대한 액세스가 제한된 클러스터를 설치해야 하는 경우 설치 패키지를 미러링하고 여기에서 클러스터를 설치할 수 있습니다. LPAR,IBM Power®, vSphere 또는 베어 메탈 의 제한된 네트워크에 대한 사용자 프로비저닝 인프라 설치에 대한 자세한 내용은RHEL KVM , IBM Z® 또는 IBM® LinuxONE을 사용하는 AWS,GCP, IBM Z® 또는 IBM® LinuxONE 의 사용자 프로비저닝 인프라에 대한 자세한 지침을 따르십시오. AWS,GCP,IBM Cloud®, Nutanix,RHOSP, vSphere 에 대한 자세한 지침에 따라 설치 관리자 프로비저닝 인프라를 사용하여 클러스터를 제한된 네트워크에 설치할 수도 있습니다.

AWS GovCloud 리전, AWS China 리전 또는 Azure 정부 리전에 클러스터를 배포해야 하는 경우 설치 관리자가 프로비저닝한 인프라 설치 중에 해당 사용자 지정 리전을 구성할 수 있습니다.

설치 중에 FIPS 140-2/140-3 검증 에 대해 NIST에 제출된 RHEL 암호화 라이브러리를 사용하도록 클러스터 머신을 구성할 수도 있습니다.

목적

Cluster Baremetal Operator는 baremetal 기능에 대한 기능을 제공합니다.

CNO(Cluster Baremetal Operator)는 베어 메탈 서버를 사용하여 OpenShift Container Platform 컴퓨팅 노드를 실행할 준비가 된 작업자 노드에 모든 구성 요소를 배포합니다. CBO를 사용하면 Bare Metal Operator(BMO) 및 Ironic 컨테이너로 구성된 metal3 배포가 OpenShift Container Platform 클러스터 내의 컨트롤 플레인 노드 중 하나에서 실행됩니다. CBO는 또한 조사하여 적절한 조치를 취하는 리소스에 대한 OpenShift Container Platform 업데이트를 수신 대기합니다.

베어 메탈 기능은 설치 관리자 프로비저닝 인프라를 사용하는 배포에 필요합니다. 베어 메탈 기능을 비활성화하면 이러한 배포에 예기치 않은 문제가 발생할 수 있습니다.

클러스터 관리자는 클러스터에 BareMetalHost 리소스가 없는 사용자 프로비저닝 인프라를 사용하여 설치하는 동안 베어 메탈 기능만 비활성화하는 것이 좋습니다.

목적

빌드 기능을 사용하면 빌드 API가 활성화됩니다. Build API는 Build 및 BuildConfig 오브젝트의 라이프사이클을 관리합니다.

목적

Cloud Controller Manager Operator는 CloudControllerManager 기능에 대한 기능을 제공합니다.

클러스터의 설치 구성(install-config.yaml) 파일에서 값을 확인하여 클러스터가 CloudControllerManager 기능 비활성화를 지원하는지 확인할 수 있습니다.

install-config.yaml 파일에서 platform 매개변수를 찾습니다.

Cloud Controller Manager Operator는 OpenShift Container Platform 상단에 배포된 클라우드 컨트롤러 관리자를 관리하고 업데이트합니다. Operator는 Kubebuilder 프레임워크 및 controller-runtime 라이브러리를 기반으로 합니다. CVO(Cluster Version Operator)를 통해 설치됩니다.

여기에는 다음 구성 요소가 포함됩니다.

기본적으로 Operator는 metrics 서비스를 통해 Prometheus 지표를 표시합니다.

목적

Cloud Credential Operator는 CloudCredential 기능에 대한 기능을 제공합니다.

CCO(Cloud Credential Operator)는 클라우드 공급자 인증 정보를 Kubernetes CRD(사용자 지정 리소스 정의)로 관리합니다. CCO는 CredentialsRequest CR(사용자 정의 리소스)에서 동기화되어 OpenShift Container Platform 구성 요소가 클러스터를 실행하는 데 필요한 특정 권한이 있는 클라우드 공급자 자격 증명을 요청할 수 있습니다.

install-config.yaml 파일에서 credentialsMode 매개변수에 다양한 값을 설정하면 CCO를 여러 모드에서 작동하도록 구성할 수 있습니다. 모드가 지정되지 않거나 credentialsMode 매개변수가 빈 문자열("")로 설정되면 CCO는 기본 모드에서 작동합니다.

목적

Cluster Image Registry Operator는 ImageRegistry 기능에 대한 기능을 제공합니다.

Cluster Image Registry Operator는 OpenShift 이미지 레지스트리의 단일 인스턴스를 관리합니다. 스토리지 생성을 포함하여 레지스트리의 모든 구성을 관리합니다.

처음 시작 시 Operator는 클러스터에서 탐지된 구성에 따라 기본 image-registry 리소스 인스턴스를 생성합니다. 이는 클라우드 공급자를 기반으로 사용할 클라우드 스토리지 유형을 나타냅니다.

완전한 image-registry 리소스를 정의하는 데 사용할 수 있는 정보가 충분하지 않으면 불완전한 리소스가 정의되고 Operator는 누락된 항목에 대한 정보를 사용하여 리소스 상태를 업데이트합니다.

Cluster Image Registry Operator는 openshift-image-registry 네임스페이스에서 실행되며 해당 위치의 레지스트리 인스턴스도 관리합니다. 레지스트리의 모든 설정 및 워크로드 리소스는 해당 네임 스페이스에 있습니다.

이미지 레지스트리를 클러스터의 사용자 인증 및 권한 부여 시스템에 통합하기 위해 클러스터의 각 서비스 계정에 대한 이미지 풀 시크릿이 생성됩니다.

ImageRegistry 기능을 비활성화하면 Telco 환경에서 OpenShift Container Platform의 전체 리소스 공간을 줄일 수 있습니다. 배포에 따라 필요하지 않은 경우 이 구성 요소를 비활성화할 수 있습니다.

프로젝트

cluster-image-registry-operator

목적

Cluster Storage Operator는 스토리지 기능에 대한 기능을 제공합니다.

Cluster Storage Operator는 OpenShift Container Platform 클러스터 수준 스토리지 기본값을 설정합니다. 이는 OpenShift Container Platform 클러스터에 기본 스토리지 클래스 가 있는지 확인합니다. 또한 클러스터가 다양한 스토리지 백엔드를 사용할 수 있는 CSI(Container Storage Interface) 드라이버를 설치합니다.

참고

목적

Console Operator는 콘솔 기능에 대한 기능을 제공합니다.

Console Operator에서 클러스터에 OpenShift Container Platform 웹 콘솔을 설치하고 유지 관리합니다. Console Operator는 기본적으로 설치되고 콘솔을 자동으로 유지 관리합니다.

목적

Cluster CSI Snapshot Controller Operator는 CSISnapshot 기능에 대한 기능을 제공합니다.

Cluster CSI Snapshot Controller Operator는 CSI Snapshot Controller를 설치하고 유지 관리합니다. CSI Snapshot Controller는 VolumeSnapshot CRD 오브젝트를 모니터링하고 볼륨 스냅샷의 생성 및 삭제 라이프사이클을 관리합니다.

목적

DeploymentConfig 기능은 DeploymentConfig API를 활성화하고 관리합니다.

목적

Ingress Operator는 Ingress 기능 기능을 제공합니다. Ingress 기능은 기본적으로 활성화되어 있습니다.

Ingress Operator는 OpenShift Container Platform 라우터를 구성하고 관리합니다.

프로젝트

openshift-ingress-operator

CRD

구성 오브젝트

참고

Ingress Operator는 openshift-ingress 프로젝트에서 라우터를 설정하고 라우터용 배포를 생성합니다.

$ oc get deployment -n openshift-ingress

Ingress Operator는 network/cluster 상태의 clusterNetwork[].cidr 을 사용하여 관리형 Ingress 컨트롤러(라우터)가 작동해야 하는 모드(IPv4, IPv6 또는 듀얼 스택)를 확인합니다. 예를 들어 clusterNetwork 에 v6 cidr 만 포함된 경우 Ingress 컨트롤러는 IPv6 전용 모드에서 작동합니다.

다음 예제에서는 클러스터 네트워크가 하나만 존재하고 네트워크가 IPv4 cidr 이므로 Ingress Operator에서 관리하는 Ingress 컨트롤러가 IPv4 전용 모드에서 실행됩니다.

$ oc get network/cluster -o jsonpath='{.status.clusterNetwork[*]}'

map[cidr:10.128.0.0/14 hostPrefix:23]

목적

Insights Operator는 Insights 기능에 대한 기능을 제공합니다.

Insights Operator는 OpenShift Container Platform 구성 데이터를 수집하여 Red Hat으로 보냅니다. 데이터는 클러스터가 노출될 수 있는 문제에 대한 사전 예방적 인사이트 권장 사항을 생성하는 데 사용됩니다. 이러한 통찰력은 console.redhat.com 에서 Insights Advisor를 통해 클러스터 관리자에게 전달됩니다.

참고

Insights Operator는 OpenShift Container Platform Telemetry를 보완합니다.

목적

machine-api-operator,cluster-autoscaler-operator 및 cluster-control-plane-machine-set-operator Operator는 MachineAPI 기능의 기능을 제공합니다. 사용자 프로비저닝 인프라가 있는 클러스터를 설치하는 경우에만 이 기능을 비활성화할 수 있습니다.

Machine API 기능은 클러스터의 모든 머신 구성 및 관리를 담당합니다. 설치 중에 Machine API 기능을 비활성화하는 경우 모든 머신 관련 작업을 수동으로 관리해야 합니다.

목적

Marketplace Operator는 Marketplace 기능에 대한 기능을 제공합니다.

Marketplace Operator는 클러스터에서 기본 OLM(Operator Lifecycle Manager) 카탈로그 세트를 사용하여 클러스터 외부 Operator를 클러스터에 가져오는 프로세스를 간소화합니다. Marketplace Operator가 설치되면 openshift-marketplace 네임스페이스를 생성합니다. OLM은 openshift-marketplace 네임스페이스에 설치된 카탈로그 소스를 클러스터의 모든 네임스페이스에 사용할 수 있도록 합니다.

Marketplace 기능을 비활성화하면 Marketplace Operator에서 openshift- marketplace 네임스페이스를 생성하지 않습니다. 카탈로그 소스는 클러스터에서 수동으로 구성 및 관리할 수 있지만 클러스터의 모든 네임스페이스에서 카탈로그를 사용할 수 있도록 OLM은 openshift-marketplace 네임스페이스에 따라 다릅니다. 시스템 또는 클러스터 관리자와 같이 openshift- 접두사가 있는 네임스페이스를 생성할 수 있는 승격된 권한이 있는 사용자는 openshift-marketplace 네임스페이스를 수동으로 생성할 수 있습니다.

Marketplace 기능을 활성화하면 Marketplace Operator를 구성하여 개별 카탈로그를 활성화하고 비활성화할 수 있습니다.

목적

Node Tuning Operator는 NodeTuning 기능에 대한 기능을 제공합니다.

Node Tuning Operator는 TuneD 데몬을 오케스트레이션하여 노드 수준 튜닝을 관리하고 Performance Profile 컨트롤러를 사용하여 대기 시간이 짧은 성능을 달성하는 데 도움이 됩니다. 대부분의 고성능 애플리케이션에는 일정 수준의 커널 튜닝이 필요합니다. Node Tuning Operator는 노드 수준 sysctls 사용자에게 통합 관리 인터페이스를 제공하며 사용자의 필요에 따라 지정되는 사용자 정의 튜닝을 추가할 수 있는 유연성을 제공합니다.

NodeTuning 기능을 비활성화하면 일부 기본 튜닝 설정이 control-plane 노드에 적용되지 않습니다. 이로 인해 900개가 넘는 노드 또는 900개가 넘는 대규모 클러스터의 확장성 및 성능이 제한될 수 있습니다.

목적

Cluster Samples Operator는 openshift-samples 기능에 대한 기능을 제공합니다.

Cluster Samples Operator는 openshift 네임스페이스에 저장된 샘플 이미지 스트림 및 템플릿을 관리합니다.

처음 시작 시 Operator는 기본 샘플 구성 리소스를 생성하여 이미지 스트림 및 템플릿을 생성하기 시작합니다. 구성 오브젝트는 키가 cluster이고 유형이 configs.samples인 클러스터 범위 지정 오브젝트입니다.

이미지 스트림은 registry.redhat.io의 이미지를 가리키는 RHCOS(Red Hat Enterprise Linux CoreOS) 기반 OpenShift Container Platform 이미지 스트림입니다. 마찬가지로 템플릿은 OpenShift Container Platform 템플릿으로 분류된 템플릿입니다.

샘플 기능을 비활성화하면 사용자가 제공하는 이미지 스트림, 샘플 및 템플릿에 액세스할 수 없습니다. 배포에 따라 필요하지 않은 경우 이 구성 요소를 비활성화해야 할 수 있습니다.

목적

OLM(Operator Lifecycle Manager)은 OpenShift Container Platform 클러스터에서 실행되는 Kubernetes 네이티브 애플리케이션(Operator) 및 관련 서비스의 라이프사이클을 설치, 업데이트, 관리하는 데 도움이 됩니다. Operator 프레임워크의 일부로, 효과적이고 자동화되었으며 확장 가능한 방식으로 Operator를 관리하도록 설계된 오픈 소스 툴킷입니다.

Operator에 다음 API가 필요한 경우 OperatorLifecycleManager 기능을 활성화해야 합니다.

etcd에 저장된 시크릿이 FIPS 검증 또는 진행중인 모듈 In Process 암호화를 사용하는지 확인하려면 FIPS 모드에서 노드를 부팅합니다. FIPS 모드에서 클러스터를 설치한 후 FIPS가 승인한 aes cbc 암호화 알고리즘을 사용하여 etcd 데이터를 암호화할 수 있습니다.

로컬 스토리지의 경우 RHEL 제공 디스크 암호화 또는 RHEL 제공 디스크 암호화를 사용하는 Container Native Storage를 사용합니다. RHEL 제공 디스크 암호화를 사용하는 볼륨에 모든 데이터를 저장하고 클러스터에 FIPS 모드를 활성화하면 미사용 데이터와 이동중인 데이터 또는 네트워크 데이터가 모두 FIPS 검증 또는 모듈 In Process 암호화로 보호됩니다. 노드 사용자 지정 에 설명된 대로 각 노드의 루트 파일 시스템을 암호화하도록 클러스터를 구성할 수 있습니다.

컨테이너가 FIPS 검증 또는 모듈 In Process 암호화 모듈을 사용하는 호스트에서 실행 중인지 확인하려면 CRI-O를 사용하여 런타임을 관리합니다.