2장. 정책 및 서비스 정의
2.1. OpenShift Dedicated 서비스 정의
2.1.1. 계정 관리
2.1.1.1. 청구 옵션
고객은 OSD(OpenShift Dedicated)의 연간 서브스크립션을 구입하거나 클라우드 마켓플레이스를 통해 온디맨드로 사용할 수 있는 옵션이 있습니다. 고객은 고객 클라우드 서브스크립션(CCS)이라는 자체 클라우드 인프라 계정을 가져오거나 Red Hat이 소유한 클라우드 공급자 계정에 배포할 수 있습니다. 아래 표에서는 청구 및 지원되는 배포 옵션에 대한 추가 정보를 제공합니다.
| OSD 서브스크립션 유형 | 클라우드 인프라 계정 | 청구됨 |
|---|---|---|
| Red Hat을 통한 연간 고정 용량 서브스크립션 | Red Hat 클라우드 계정 | OSD 서브스크립션 및 클라우드 인프라 모두에 사용되는 Red Hat |
| 고객의 클라우드 계정 | OSD 서브스크립션 사용을 위해 Red Hat 클라우드 인프라 사용을 위한 클라우드 공급자 | |
| Google Cloud Marketplace를 통한 온디맨드 사용 기반 사용 | 고객의 Google Cloud 계정 | 클라우드 인프라 및 Red Hat OSD 서브스크립션 모두를 위한 Google Cloud |
| Red Hat Marketplace를 통한 온디맨드 사용량 기반 사용 | 고객의 클라우드 계정 | OSD 서브스크립션 사용을 위해 Red Hat 클라우드 인프라 사용을 위한 클라우드 공급자 |
CSS(Customer Cloud Subscription)라고 하는 자체 클라우드 인프라 계정을 사용하는 고객은 클라우드 인프라 비용을 줄이기 위해 예약된 인스턴스(RI) 컴퓨팅 인스턴스를 사전 구매하거나 제공해야 합니다.
다음을 포함하여 OpenShift Dedicated 클러스터에 대한 추가 리소스를 구입할 수 있습니다.
- 추가 노드 ( 머신 풀을 사용하여 다른 유형 및 크기일 수 있음)
- Middleware(JBoss EAP, JBoss Fuse 등) - 특정 미들웨어 구성 요소에 따른 추가 가격
- 500GB 단위로의 추가 저장 공간(표준만 해당, 100GB 포함)
- 추가 12TiB 네트워크 I/O (표준 12TB 포함)
- 서비스용 로드 밸런서는 4 번들에서 사용할 수 있습니다. HTTP/SNI 트래픽 또는 비표준 포트(표준 전용)를 활성화합니다.
2.1.1.2. 클러스터 셀프 서비스
고객은 필요한 서브스크립션을 이미 구매한 경우 OpenShift Cluster Manager 에서 클러스터를 생성, 확장 및 삭제할 수 있습니다.
Red Hat OpenShift Cluster Manager에서 사용 가능한 작업은 클러스터 내에서 직접 수행할 수 없습니다. 이로 인해 모든 작업이 자동으로 되돌아가는 것을 포함하여 불리한 영향을 미칠 수 있습니다.
2.1.1.3. 클라우드 공급자
OpenShift Dedicated는 다음 클라우드 공급자에서 OpenShift Container Platform 클러스터를 관리형 서비스로 제공합니다.
- AWS(Amazon Web Services)
- GCP(Google Cloud Platform)
2.1.1.4. 인스턴스 유형
단일 가용성 영역 클러스터에는 단일 가용성 영역에 배포된 고객 클라우드 서브스크립션(CCS) 클러스터에 최소 2개의 작업자 노드가 필요합니다. 표준 클러스터에는 최소 4개의 작업자 노드가 필요합니다. 이 4개의 작업자 노드는 기본 서브스크립션에 포함되어 있습니다.
여러 가용성 영역 클러스터에는 각각 3개의 가용성 영역에 배포된 고객 클라우드 서브스크립션(CCS) 클러스터에 최소 3개의 작업자 노드가 필요합니다. 표준 클러스터에는 최소 9개의 작업자 노드가 필요합니다. 이 9개의 작업자 노드는 기본 서브스크립션에 포함되어 있으며 적절한 노드 배포를 유지하려면 추가 노드를 3의 다중에서 구입해야 합니다.
단일 OpenShift Dedicated 머신 풀 내의 모든 작업자 노드는 동일한 유형과 크기여야 합니다. 그러나 OpenShift Dedicated 클러스터 내의 여러 머신 풀의 작업자 노드는 다양한 유형과 크기일 수 있습니다.
컨트롤 플레인 및 인프라 노드도 Red Hat에서 제공합니다. etcd 및 API 관련 워크로드를 처리하는 컨트롤 플레인 노드가 3개 이상 있습니다. 메트릭, 라우팅, 웹 콘솔 및 기타 워크로드를 처리하는 인프라 노드가 두 개 이상 있습니다. 컨트롤 플레인 및 인프라 노드에서 워크로드를 실행하지 않아야 합니다. 실행하려는 워크로드는 작업자 노드에 배포해야 합니다. 작업자 노드에 배포해야 하는 Red Hat 워크로드에 대한 자세한 내용은 아래 Red Hat Operator 지원 섹션을 참조하십시오.
약 1 vCPU 코어 및 1GiB의 메모리는 각 작업자 노드에 예약되며 할당 가능한 리소스에서 제거됩니다. 이는 기본 플랫폼에서 요구하는 프로세스를 실행하는 데 필요합니다. 여기에는 udev, kubelet, 컨테이너 런타임 등과 같은 시스템 데몬과 커널 예약 계정이 포함됩니다. 감사 로그 집계, 지표 수집, DNS, 이미지 레지스트리, SDN 등과 같은 OpenShift Container Platform 코어 시스템은 클러스터의 안정성과 유지 관리를 위해 추가 할당 가능한 리소스를 사용할 수 있습니다. 소비되는 추가 리소스는 사용량에 따라 다를 수 있습니다.
OpenShift Dedicated 4.11부터 기본 Pod당 PID 제한은 4096 입니다. 이 PID 제한을 활성화하려면 OpenShift Dedicated 클러스터를 이 버전 이상으로 업그레이드해야 합니다. 4.11 이전 버전을 실행하는 OpenShift Dedicated 클러스터는 기본 PID 제한을 1024 로 제한합니다.
OpenShift Dedicated 클러스터에서는 Pod별 PID 제한을 구성할 수 없습니다.
추가 리소스
2.1.1.5. Customer Cloud Subscription 클러스터의 AWS 인스턴스 유형
OpenShift Dedicated는 AWS에서 다음과 같은 작업자 노드 인스턴스 유형 및 크기를 제공합니다.
예 2.1. 일반 목적
- m5.metal (96ovn vCPU, 384GiB)
- m5.xlarge (4 vCPU, 16GiB)
- m5.2xlarge (8 vCPU, 32GiB)
- m5.4xlarge (16 vCPU, 64GiB)
- m5.8xlarge(32 vCPU, 128GiB)
- m5.12xlarge(48 vCPU, 192GiB)
- m5.16xlarge(64 vCPU, 256GiB)
- m5.24xlarge (96 vCPU, 384GiB)
- m5a.xlarge (4 vCPU, 16GiB)
- m5a.2xlarge (8 vCPU, 32GiB)
- m5a.4xlarge (16 vCPU, 64GiB)
- m5a.8xlarge(32 vCPU, 128GiB)
- m5a.12xlarge(48 vCPU, 192GiB)
- m5a.16xlarge(64 vCPU, 256GiB)
- m5a.24xlarge (96 vCPU, 384GiB)
- m5ad.xlarge (4 vCPU, 16GiB)
- m5ad.2xlarge (8 vCPU, 32GiB)
- m5ad.4xlarge (16 vCPU, 64GiB)
- m5ad.8xlarge(32 vCPU, 128GiB)
- m5ad.12xlarge (48 vCPU, 192GiB)
- m5ad.16xlarge (64 vCPU, 256GiB)
- m5ad.24xlarge (96 vCPU, 384GiB)
- m5d.metal (96ovn vCPU, 384GiB)
- m5d.xlarge (4 vCPU, 16GiB)
- m5d.2xlarge (8 vCPU, 32GiB)
- m5d.4xlarge (16 vCPU, 64GiB)
- m5d.8xlarge(32 vCPU, 128GiB)
- m5d.12xlarge(48 vCPU, 192GiB)
- m5d.16xlarge(64 vCPU, 256GiB)
- m5d.24xlarge(96 vCPU, 384GiB)
- m5n.metal (96 vCPU, 384GiB)
- m5n.xlarge (4 vCPU, 16GiB)
- m5n.2xlarge (8 vCPU, 32GiB)
- m5n.4xlarge (16 vCPU, 64GiB)
- m5n.8xlarge(32 vCPU, 128GiB)
- m5n.12xlarge(48 vCPU, 192GiB)
- m5n.16xlarge(64 vCPU, 256GiB)
- m5n.24xlarge (96 vCPU, 384GiB)
- m5dn.metal (96 vCPU, 384GiB)
- m5dn.xlarge (4 vCPU, 16GiB)
- m5dn.2xlarge (8 vCPU, 32GiB)
- m5dn.4xlarge (16 vCPU, 64GiB)
- m5dn.8xlarge(32 vCPU, 128GiB)
- m5dn.12xlarge(48 vCPU, 192GiB)
- m5dn.16xlarge(64 vCPU, 256GiB)
- m5dn.24xlarge (96 vCPU, 384GiB)
- m5zn.metal (48 vCPU, 192GiB)
- m5zn.xlarge (4 vCPU, 16GiB)
- m5zn.2xlarge (8 vCPU, 32GiB)
- m5zn.3xlarge (12 vCPU, 48GiB)
- m5zn.6xlarge (24 vCPU, 96GiB)
- m5zn.12xlarge (48 vCPU, 192GiB)
- m6a.xlarge (4 vCPU, 16GiB)
- m6a.2xlarge (8 vCPU, 32GiB)
- m6a.4xlarge (16 vCPU, 64GiB)
- m6a.8xlarge(32 vCPU, 128GiB)
- m6a.12xlarge(48 vCPU, 192GiB)
- m6a.16xlarge(64 vCPU, 256GiB)
- m6a.24xlarge (96 vCPU, 384GiB)
- m6a.32xlarge(128 vCPU, 512GiB)
- m6a.48xlarge(192 vCPU, 768GiB)
- m6i.metal (128 vCPU, 512GiB)
- m6i.xlarge (4 vCPU, 16GiB)
- m6i.2xlarge (8 vCPU, 32GiB)
- m6i.4xlarge (16 vCPU, 64GiB)
- m6i.8xlarge(32 vCPU, 128GiB)
- m6i.12xlarge (48 vCPU, 192GiB)
- m6i.16xlarge(64 vCPU, 256GiB)
- m6i.24xlarge (96 vCPU, 384GiB)
- m6i.32xlarge(128 vCPU, 512GiB)
- m6id.xlarge (4 vCPU, 16GiB)
- m6id.2xlarge (8 vCPU, 32GiB)
- m6id.4xlarge (16 vCPU, 64GiB)
- m6id.8xlarge(32 vCPU, 128GiB)
- m6id.12xlarge (48 vCPU, 192GiB)
- m6id.16xlarge (64 vCPU, 256GiB)
- m6id.24xlarge (96 vCPU, 384GiB)
- m6id.32xlarge(128 vCPU, 512GiB)
- m7i.xlarge (4 vCPU, 16GiB)
- m7i.2xlarge (8 vCPU, 32GiB)
- m7i.4xlarge (16 vCPU, 64GiB)
- m7i.8xlarge(32 vCPU, 128GiB)
- m7i.12xlarge (48 vCPU, 192GiB)
- m7i.16xlarge (64 vCPU, 256GiB)
- m7i.24xlarge (96 vCPU, 384GiB)
- m7i.48xlarge (192 vCPU, 768GiB)
- m7i.metal-24xl (96 vCPU, 384GiB)
- m7i.metal-48xl (192 vCPU, 768GiB)
- m7i-flex.xlarge (4 vCPU, 16GiB)
- m7i-flex.2xlarge (8 vCPU, 32GiB)
- m7i-flex.4xlarge (16 vCPU, 64GiB)
- m7i-flex.8xlarge(32 vCPU, 128GiB)
- m7a.xlarge (4 vCPU, 16GiB)
- m7a.2xlarge (8 vCPU, 32GiB)
- m7a.4xlarge (16 vCPU, 64GiB)
- m7a.8xlarge(32 vCPU, 128GiB)
- m7a.12xlarge (48 vCPU, 192GiB)
- m7a.16xlarge (64 vCPU, 256GiB)
- m7a.24xlarge (96 vCPU, 384GiB)
- m7a.32xlarge(128 vCPU, 512GiB)
- m7a.48xlarge (192 vCPU, 768GiB)
- m7a.metal-48xl (192 vCPU, 768GiB)
이러한 인스턴스 유형은 48개의 물리적 코어에서 96개의 논리 프로세서를 제공합니다. 두 개의 물리적 Intel 소켓이 있는 단일 서버에서 실행됩니다.
예 2.2. Burstable 일반 목적
- t3.xlarge (4 vCPU, 16GiB)
- t3.2xlarge (8 vCPU, 32GiB)
- t3a.xlarge (4 vCPU, 16GiB)
- t3a.2xlarge (8 vCPU, 32GiB)
예 2.3. 메모리 집약적
- x1.16xlarge(64 vCPU, 976GiB)
- X1.32xlarge(128 vCPU, 1952GiB)
- X1e.xlarge (4 vCPU, 122GiB)
- X1e.2xlarge (8 vCPU, 244GiB)
- X1e.4xlarge (16 vCPU, 488GiB)
- X1e.8xlarge(32 vCPU, 976GiB)
- X1e.16xlarge(64 vCPU, 1,952GiB)
- X1e.32xlarge(128 vCPU, 3,904GiB)
- x2idn.16xlarge (64 vCPU, 1024GiB)
- X2idn.24xlarge (96 vCPU, 1536GiB)
- x2idn.32xlarge(128 vCPU, 2048GiB)
- x2iedn.xlarge (4 vCPU, 128GiB)
- X2iedn.2xlarge (8 vCPU, 256GiB)
- X2iedn.4xlarge (16 vCPU, 512GiB)
- X2iedn.8xlarge(32 vCPU, 1024GiB)
- x2iedn.16xlarge (64 vCPU, 2048GiB)
- X2iedn.24xlarge (96 vCPU, 3072GiB)
- x2iedn.32xlarge(128 vCPU, 4096GiB)
- X2iezn.2xlarge (8 vCPU, 256GiB)
- X2iezn.4xlarge (16vCPU, 512GiB)
- X2iezn.6xlarge (24vCPU, 768GiB)
- X2iezn.8xlarge(32vCPU, 1,024GiB)
- X2iezn.12xlarge (48vCPU, 1,536GiB)
- x2idn.metal(128vCPU, 2,048GiB)
- x2iedn.metal (128vCPU, 4,096GiB)
- x2iezn.metal (48 vCPU, 1,536GiB)
예 2.4. 최적화된 메모리
- r4.xlarge (4 vCPU, 30.5GiB)
- r4.2xlarge (8 vCPU, 61GiB)
- r4.4xlarge (16 vCPU, 122GiB)
- r4.8xlarge(32 vCPU, 244GiB)
- r4.16xlarge(64 vCPU, 488GiB)
- r5.metal (96ECDHE vCPU, 768GiB)
- r5.xlarge (4 vCPU, 32GiB)
- r5.2xlarge (8 vCPU, 64GiB)
- r5.4xlarge (16 vCPU, 128GiB)
- r5.8xlarge(32 vCPU, 256GiB)
- r5.12xlarge (48 vCPU, 384GiB)
- r5.16xlarge(64 vCPU, 512GiB)
- r5.24xlarge (96 vCPU, 768GiB)
- r5a.xlarge (4 vCPU, 32GiB)
- r5a.2xlarge (8 vCPU, 64GiB)
- r5a.4xlarge (16 vCPU, 128GiB)
- r5a.8xlarge(32 vCPU, 256GiB)
- r5a.12xlarge(48 vCPU, 384GiB)
- r5a.16xlarge(64 vCPU, 512GiB)
- r5a.24xlarge(96 vCPU, 768GiB)
- r5ad.xlarge (4 vCPU, 32GiB)
- r5ad.2xlarge (8 vCPU, 64GiB)
- r5ad.4xlarge (16 vCPU, 128GiB)
- r5ad.8xlarge(32 vCPU, 256GiB)
- r5ad.12xlarge(48 vCPU, 384GiB)
- r5ad.16xlarge(64 vCPU, 512GiB)
- r5ad.24xlarge (96 vCPU, 768GiB)
- r5d.metal (96ECDHE vCPU, 768GiB)
- r5d.xlarge (4 vCPU, 32GiB)
- r5d.2xlarge (8 vCPU, 64GiB)
- r5d.4xlarge (16 vCPU, 128GiB)
- r5d.8xlarge(32 vCPU, 256GiB)
- r5d.12xlarge(48 vCPU, 384GiB)
- r5d.16xlarge(64 vCPU, 512GiB)
- r5d.24xlarge(96 vCPU, 768GiB)
- r5n.metal (96 vCPU, 768GiB)
- r5n.xlarge (4 vCPU, 32GiB)
- r5n.2xlarge (8 vCPU, 64GiB)
- r5n.4xlarge (16 vCPU, 128GiB)
- r5n.8xlarge(32 vCPU, 256GiB)
- r5n.12xlarge(48 vCPU, 384GiB)
- r5n.16xlarge(64 vCPU, 512GiB)
- r5n.24xlarge (96 vCPU, 768GiB)
- r5dn.metal (96 vCPU, 768GiB)
- r5dn.xlarge (4 vCPU, 32GiB)
- r5dn.2xlarge (8 vCPU, 64GiB)
- r5dn.4xlarge (16 vCPU, 128GiB)
- r5dn.8xlarge(32 vCPU, 256GiB)
- r5dn.12xlarge(48 vCPU, 384GiB)
- r5dn.16xlarge(64 vCPU, 512GiB)
- r5dn.24xlarge (96 vCPU, 768GiB)
- r6a.xlarge (4 vCPU, 32GiB)
- r6a.2xlarge (8 vCPU, 64GiB)
- r6a.4xlarge (16 vCPU, 128GiB)
- r6a.8xlarge(32 vCPU, 256GiB)
- r6a.12xlarge(48 vCPU, 384GiB)
- r6a.16xlarge(64 vCPU, 512GiB)
- r6a.24xlarge (96 vCPU, 768GiB)
- r6a.32xlarge(128 vCPU, 1,024GiB)
- r6a.48xlarge(192 vCPU, 1,536GiB)
- r6i.metal (128 vCPU, 1,024GiB)
- r6i.xlarge (4 vCPU, 32GiB)
- r6i.2xlarge (8 vCPU, 64GiB)
- r6i.4xlarge (16 vCPU, 128GiB)
- r6i.8xlarge(32 vCPU, 256GiB)
- r6i.12xlarge(48 vCPU, 384GiB)
- r6i.16xlarge(64 vCPU, 512GiB)
- r6i.24xlarge (96 vCPU, 768GiB)
- r6i.32xlarge(128 vCPU, 1,024GiB)
- r6id.xlarge (4 vCPU, 32GiB)
- r6id.2xlarge (8 vCPU, 64GiB)
- r6id.4xlarge (16 vCPU, 128GiB)
- r6id.8xlarge(32 vCPU, 256GiB)
- r6id.12xlarge (48 vCPU, 384GiB)
- r6id.16xlarge (64 vCPU, 512GiB)
- r6id.24xlarge (96 vCPU, 768GiB)
- r6id.32xlarge(128 vCPU, 1,024GiB)
- z1d.metal (48ECDHE vCPU, 384GiB)
- z1d.xlarge (4 vCPU, 32GiB)
- z1d.2xlarge (8 vCPU, 64GiB)
- z1d.3xlarge (12 vCPU, 96GiB)
- z1d.6xlarge (24 vCPU, 192GiB)
- z1d.12xlarge(48 vCPU, 384GiB)
- r7a.xlarge (4 vCPU, 32GiB)
- r7a.2xlarge (8 vCPU, 64GiB)
- r7a.4xlarge (16 vCPU, 128GiB)
- r7a.8xlarge(32 vCPU, 256GiB)
- r7a.12xlarge (48 vCPU, 384GiB)
- r7a.16xlarge (64 vCPU, 512GiB)
- r7a.24xlarge (96 vCPU, 768GiB)
- r7a.32xlarge(128 vCPU, 1024GiB)
- r7a.48xlarge(192 vCPU, 1536GiB)
- r7a.metal-48xl (192 vCPU, 1536 GiB)
- r7i.xlarge (4 vCPU, 32GiB)
- r7i.2xlarge (8 vCPU, 64GiB)
- r7i.4xlarge (16 vCPU, 128GiB)
- r7i.8xlarge(32 vCPU, 256GiB)
- r7i.12xlarge (48 vCPU, 384GiB)
- r7i.16xlarge (64 vCPU, 512GiB)
- r7i.24xlarge (96 vCPU, 768GiB)
- r7i.metal-24xl (96 vCPU, 768 GiB)
- r7iz.xlarge (4 vCPU, 32GiB)
- r7iz.2xlarge (8 vCPU, 64GiB)
- r7iz.4xlarge (16 vCPU, 128GiB)
- r7iz.8xlarge(32 vCPU, 256GiB)
- r7iz.12xlarge (48 vCPU, 384GiB)
- r7iz.16xlarge (64 vCPU, 512GiB)
- r7iz.32xlarge(128 vCPU, 1024GiB)
- r7iz.metal-16xl (64 vCPU, 512GiB)
- r7iz.metal-32xl (128 vCPU, 1024GiB)
이러한 인스턴스 유형은 48개의 물리적 코어에서 96개의 논리 프로세서를 제공합니다. 두 개의 물리적 Intel 소켓이 있는 단일 서버에서 실행됩니다.
이 인스턴스 유형은 24개의 물리적 코어에서 48개의 논리 프로세서를 제공합니다.
예 2.5. 가속화된 컴퓨팅
- p3.2xlarge (8 vCPU, 61GiB)
- p3.8xlarge(32 vCPU, 244GiB)
- p3.16xlarge(64 vCPU, 488GiB)
- p3dn.24xlarge (96 vCPU, 768GiB)
- p4d.24xlarge(96 vCPU, 1,152GiB)
- p4de.24xlarge (96 vCPU, 1,152GiB)
- p5.48xlarge(192 vCPU, 2,048GiB)
- g4ad.xlarge (4 vCPU, 16GiB)
- g4ad.2xlarge (8 vCPU, 32GiB)
- g4ad.4xlarge (16 vCPU, 64GiB)
- g4ad.8xlarge(32 vCPU, 128GiB)
- g4ad.16xlarge (64 vCPU, 256GiB)
- g4dn.xlarge (4 vCPU, 16GiB)
- g4dn.2xlarge (8 vCPU, 32GiB)
- g4dn.4xlarge (16 vCPU, 64GiB)
- g4dn.8xlarge(32 vCPU, 128GiB)
- g4dn.12xlarge(48 vCPU, 192GiB)
- g4dn.16xlarge(64 vCPU, 256GiB)
- g4dn.metal (96 vCPU, 384GiB)
- g5.xlarge (4 vCPU, 16GiB)
- g5.2xlarge (8 vCPU, 32GiB)
- g5.4xlarge (16 vCPU, 64GiB)
- g5.8xlarge(32 vCPU, 128GiB)
- g5.16xlarge(64 vCPU, 256GiB)
- g5.12xlarge(48 vCPU, 192GiB)
- g5.24xlarge(96 vCPU, 384GiB)
- g5.48xlarge(192 vCPU, 768GiB)
- dl1.24xlarge (96 vCPU, 768GiB)
ECDHE Intel specific; Nvidia의 적용을 받지 않음
AWS에서는 GPU 인스턴스 유형 소프트웨어 스택에 대한 지원이 제공됩니다. AWS 서비스 할당량이 원하는 GPU 인스턴스 유형을 수용할 수 있는지 확인합니다.
예 2.6. 컴퓨팅 최적화
- c5.metal (96 vCPU, 192GiB)
- c5.xlarge (4 vCPU, 8GiB)
- c5.2xlarge (8 vCPU, 16GiB)
- c5.4xlarge (16 vCPU, 32GiB)
- c5.9xlarge(36 vCPU, 72GiB)
- c5.12xlarge(48 vCPU, 96GiB)
- c5.18xlarge (72 vCPU, 144GiB)
- c5.24xlarge (96 vCPU, 192GiB)
- c5d.metal (96 vCPU, 192GiB)
- c5d.xlarge (4 vCPU, 8GiB)
- c5d.2xlarge (8 vCPU, 16GiB)
- c5d.4xlarge (16 vCPU, 32GiB)
- c5d.9xlarge(36 vCPU, 72GiB)
- c5d.12xlarge(48 vCPU, 96GiB)
- c5d.18xlarge(72 vCPU, 144GiB)
- c5d.24xlarge (96 vCPU, 192GiB)
- c5a.xlarge (4 vCPU, 8GiB)
- c5a.2xlarge (8 vCPU, 16GiB)
- c5a.4xlarge (16 vCPU, 32GiB)
- c5a.8xlarge(32 vCPU, 64GiB)
- c5a.12xlarge(48 vCPU, 96GiB)
- c5a.16xlarge(64 vCPU, 128GiB)
- c5a.24xlarge (96 vCPU, 192GiB)
- c5ad.xlarge (4 vCPU, 8GiB)
- c5ad.2xlarge (8 vCPU, 16GiB)
- c5ad.4xlarge (16 vCPU, 32GiB)
- c5ad.8xlarge(32 vCPU, 64GiB)
- c5ad.12xlarge(48 vCPU, 96GiB)
- c5ad.16xlarge (64 vCPU, 128GiB)
- c5ad.24xlarge (96 vCPU, 192GiB)
- c5n.metal (72 vCPU, 192GiB)
- c5n.xlarge (4 vCPU, 10.5GiB)
- c5n.2xlarge (8 vCPU, 21GiB)
- c5n.4xlarge (16 vCPU, 42GiB)
- c5n.9xlarge(36 vCPU, 96GiB)
- c5n.18xlarge (72 vCPU, 192GiB)
- c6a.xlarge (4 vCPU, 8GiB)
- c6a.2xlarge (8 vCPU, 16GiB)
- c6a.4xlarge (16 vCPU, 32GiB)
- c6a.8xlarge(32 vCPU, 64GiB)
- c6a.12xlarge(48 vCPU, 96GiB)
- c6a.16xlarge(64 vCPU, 128GiB)
- c6a.24xlarge (96 vCPU, 192GiB)
- c6a.32xlarge(128 vCPU, 256GiB)
- c6a.48xlarge(192 vCPU, 384GiB)
- c6i.metal (128 vCPU, 256GiB)
- c6i.xlarge (4 vCPU, 8GiB)
- c6i.2xlarge (8 vCPU, 16GiB)
- c6i.4xlarge (16 vCPU, 32GiB)
- c6i.8xlarge(32 vCPU, 64GiB)
- c6i.12xlarge (48 vCPU, 96GiB)
- c6i.16xlarge (64 vCPU, 128GiB)
- c6i.24xlarge (96 vCPU, 192GiB)
- c6i.32xlarge(128 vCPU, 256GiB)
- c6id.xlarge (4 vCPU, 8GiB)
- c6id.2xlarge (8 vCPU, 16GiB)
- c6id.4xlarge (16 vCPU, 32GiB)
- c6id.8xlarge(32 vCPU, 64GiB)
- c6id.12xlarge (48 vCPU, 96GiB)
- c6id.16xlarge (64 vCPU, 128GiB)
- c6id.24xlarge (96 vCPU, 192GiB)
- c6id.32xlarge(128 vCPU, 256GiB)
- c7a.xlarge (4 vCPU, 8GiB)
- c7a.2xlarge (8 vCPU, 16GiB)
- c7a.4xlarge (16 vCPU, 32GiB)
- c7a.8xlarge(32 vCPU, 64GiB)
- c7a.12xlarge (48 vCPU, 96GiB)
- c7a.16xlarge (64 vCPU, 128GiB)
- c7a.24xlarge (96 vCPU, 192GiB)
- c7a.32xlarge(128 vCPU, 256GiB)
- c7a.48xlarge(192 vCPU, 384GiB)
- c7a.metal-48xl (192 vCPU, 384 GiB)
- c7i.xlarge (4 vCPU, 8GiB)
- c7i.2xlarge (8 vCPU, 16GiB)
- c7i.4xlarge (16 vCPU, 32GiB)
- c7i.8xlarge(32 vCPU, 64GiB)
- c7i.12xlarge (48 vCPU, 96GiB)
- c7i.16xlarge (64 vCPU, 128GiB)
- c7i.24xlarge (96 vCPU, 192GiB)
- c7i.48xlarge(192 vCPU, 384GiB)
- c7i.metal-24xl (96 vCPU, 192 GiB)
- c7i.metal-48xl (192 vCPU, 384 GiB)
- hpc6a.48xlarge (96 vCPU, 384GiB)
- hpc6id.32xlarge (64 vCPU, 1024GiB)
- hpc7a.12xlarge (24 vCPU, 768GiB)
- hpc7a.24xlarge (48 vCPU, 768GiB)
- hpc7a.48xlarge (96 vCPU, 768GiB)
- hpc7a.96xlarge (192 vCPU, 768GiB)
예 2.7. 최적화된 스토리지
- i3.metal (72ECDHE vCPU, 512GiB)
- i3.xlarge (4 vCPU, 30.5GiB)
- i3.2xlarge (8 vCPU, 61GiB)
- i3.4xlarge (16 vCPU, 122GiB)
- i3.8xlarge(32 vCPU, 244GiB)
- i3.16xlarge(64 vCPU, 488GiB)
- i3en.metal (96 vCPU, 768GiB)
- i3en.xlarge (4 vCPU, 32GiB)
- i3en.2xlarge (8 vCPU, 64GiB)
- i3en.3xlarge (12 vCPU, 96GiB)
- i3en.6xlarge (24 vCPU, 192GiB)
- i3en.12xlarge(48 vCPU, 384GiB)
- i3en.24xlarge (96 vCPU, 768GiB)
- i4i.xlarge (4 vCPU, 32GiB)
- i4i.2xlarge (8 vCPU, 64GiB)
- i4i.4xlarge (16 vCPU, 128GiB)
- i4i.8xlarge(32 vCPU, 256GiB)
- i4i.12xlarge (48 vCPU, 384GiB)
- i4i.16xlarge (64 vCPU, 512GiB)
- i4i.24xlarge (96 vCPU, 768GiB)
- i4i.32xlarge(128 vCPU, 1024GiB)
- i4i.metal(128 vCPU, 1024GiB)
이 인스턴스 유형은 36 개의 물리적 코어에서 72 개의 논리 프로세서를 제공합니다.
가상 인스턴스 유형은 ".metal" 인스턴스 유형보다 더 빨리 초기화됩니다.
예 2.8. 높은 메모리
- U-3tb1.56xlarge (224 vCPU, 3,072GiB)
- U-6tb1.56xlarge (224 vCPU, 6,144GiB)
- U-6tb1.112xlarge (448 vCPU, 6,144GiB)
- U-6tb1.metal (448 vCPU, 6,144GiB)
- U-9tb1.112xlarge (448 vCPU, 9,216GiB)
- U-9tb1.metal (448 vCPU, 9,216GiB)
- U-12tb1.112xlarge (448 vCPU, 12,288GiB)
- U-12tb1.metal (448 vCPU, 12,288GiB)
- U-18tb1.metal (448 vCPU, 18,432GiB)
- U-24tb1.metal (448 vCPU, 24,576GiB)
추가 리소스
2.1.1.6. 표준 클러스터의 AWS 인스턴스 유형
OpenShift Dedicated는 AWS에서 다음과 같은 작업자 노드 유형 및 크기를 제공합니다.
예 2.9. 일반 목적
- m5.xlarge (4 vCPU, 16GiB)
- m5.2xlarge (8 vCPU, 32GiB)
- m5.4xlarge (16 vCPU, 64GiB)
예 2.10. 메모리 최적화
- r5.xlarge (4 vCPU, 32GiB)
- r5.2xlarge (8 vCPU, 64GiB)
- r5.4xlarge (16 vCPU, 128GiB)
예 2.11. compute- optimization
- c5.2xlarge (8 vCPU, 16GiB)
- c5.4xlarge (16 vCPU, 32GiB)
2.1.1.7. Google Cloud 컴퓨팅 유형
OpenShift Dedicated는 다른 클라우드 인스턴스 유형과 동일한 공통 CPU 및 메모리 용량을 가지도록 선택한 Google Cloud에서 다음과 같은 작업자 노드 유형과 크기를 제공합니다.
e2 및 a2 컴퓨팅 유형은 CCS에서만 사용할 수 있습니다.
예 2.12. 일반 목적
- Custom-4-16384 (4 vCPU, 16GiB)
- Custom-8-32768 (8 vCPU, 32GiB)
- custom-16-65536 (16 vCPU, 64GiB)
- custom-32-131072(32 vCPU, 128GiB)
- custom-48-199608 (48 vCPU, 192GiB)
- custom-64-262144 (64 vCPU, 256GiB)
- custom-96-393216 (96 vCPU, 384GiB)
- e2-standard-4 (4 vCPU, 16GiB)
- n2-standard-4 (4 vCPU, 16GiB)
- e2-standard-8 (8 vCPU, 32GiB)
- n2-standard-8 (8 vCPU, 32GiB)
- e2-standard-16 (16 vCPU, 64GiB)
- n2-standard-16 (16 vCPU, 64GiB)
- e2-standard-32(32 vCPU, 128GiB)
- n2-standard-32(32 vCPU, 128GiB)
- n2-standard-48 (48 vCPU, 192GiB)
- n2-standard-64 (64 vCPU, 256GiB)
- n2-standard-80 (80 vCPU, 320GiB)
- n2-standard-96 (96 vCPU, 384GiB)
- n2-standard-128(128 vCPU, 512GiB)
예 2.13. 메모리 최적화
- custom-4-32768-ext (4 vCPU, 32GiB)
- custom-8-65536-ext (8 vCPU, 64GiB)
- custom-16-131072-ext (16 vCPU, 128GiB)
- e2-highmem-4 (4 vCPU, 32GiB)
- e2-highmem-8 (8 vCPU, 64GiB)
- e2-highmem-16 (16 vCPU, 128GiB)
- n2-highmem-4 ( vCPU, 32GiB)
- n2-highmem-8 (8 vCPU, 64GiB)
- n2-highmem-16 (16 vCPU, 128GiB)
- n2-highmem-32(32 vCPU, 256GiB)
- n2-highmem-48 (48 vCPU, 384GiB)
- n2-highmem-64 (64 vCPU, 512GiB)
- n2-highmem-80 (80 vCPU, 640GiB)
- n2-highmem-96 (96 vCPU, 768GiB)
- n2-highmem-128(128 vCPU, 864GiB)
예 2.14. compute- optimization
- Custom-8-16384 (8 vCPU, 16GiB)
- custom-16-32768(16 vCPU, 32GiB)
- custom-36-73728 (36 vCPU, 72GiB)
- custom-48-98304 (48 vCPU, 96GiB)
- custom-72-147456 (72 vCPU, 144GiB)
- custom-96-196608 (96 vCPU, 192GiB)
- c2-standard-4 (4 vCPU, 16GiB)
- c2-standard-8 (8 vCPU, 32GiB)
- c2-standard-16 (16 vCPU, 64GiB)
- c2-standard-30 (30 vCPU, 120GiB)
- c2-standard-60 (60 vCPU, 240GiB)
- e2-highcpu-8 (8 vCPU, 8GiB)
- e2-highcpu-16 (16 vCPU, 16GiB)
- e2-highcpu-32(32 vCPU, 32GiB)
- n2-highcpu-8 (8 vCPU, 8GiB)
- n2-highcpu-16 (16 vCPU, 16GiB)
- n2-highcpu-32(32 vCPU, 32GiB)
- n2-highcpu-48 (48 vCPU, 48GiB)
- n2-highcpu-64 (64 vCPU, 64GiB)
- n2-highcpu-80 (80 vCPU, 80GiB)
- n2-highcpu-96 (96 vCPU, 96GiB)
예 2.15. 가속화된 컴퓨팅
- a2-highgpu-1g (12 vCPU, 85GiB)
- A2-highgpu-2g (24 vCPU,170 GiB)
- a2-highgpu-4g (48 vCPU, 340GiB)
- a2-highgpu-8g (96 vCPU, 680GiB)
- a2-megagpu-16g (96 vCPU, 1.33 TiB)
- a2-ultragpu-1g (12 vCPU,170 GiB)
- a2-ultragpu-2g (24 vCPU, 340GiB)
- a2-ultragpu-4g (48 vCPU, 680GiB)
- a2-ultragpu-8g (96 vCPU, 1360GiB)
2.1.1.8. 지역 및 가용성 영역
다음 리전은 OpenShift Container Platform 4에서 지원되며 OpenShift Dedicated에서 지원됩니다.
2.1.1.8.1. AWS 리전 및 가용성 영역
다음 AWS 리전은 OpenShift Container Platform 4에서 지원되며 OpenShift Dedicated에서 지원됩니다.
- af-south-1 (AWS opt-in 필요)
- ap-east-1 (홍콩, AWS 옵트인 필요)
- ap-northeast-1(도쿄)
- ap-northeast-2(서울)
- ap-northeast-3 (오사카)
- ap-south-1(뭄바이)
- ap-south-2 (Hyderabad, AWS opt-in 필요)
- ap-southeast-1(싱가포르)
- ap-southeast-2(시드니)
- ap-southeast-3 (AWS 옵트인 필요)
- ap-southeast-4 (Melbourne, AWS 옵트인 필요)
- ca-central-1 (캐나다)
- eu-central-1(프랑크푸르트)
- eu-central-2(Zurich, AWS 옵트인 필요)
- eu-north-1(스톡홀름)
- eu-south-1 (AWS 옵트인 필요)
- eu-south-2 (스페인, AWS 옵트인 필요)
- eu-west-1(아일랜드)
- eu-west-2(런던)
- eu-west-3(파리)
- me-central-1(UAE, AWS 옵트인 필요)
- me-south-1 (Bahrain, AWS opt-in 필요)
- sa-east-1(상파울루)
- us-east-1(버지니아 북부)
- us-east-2(오하이오)
- us-west-1(캘리포니아 북부)
- us-west-2(오레곤)
2.1.1.8.2. Google Cloud 리전 및 가용성 영역
현재 지원되는 Google Cloud 리전은 다음과 같습니다.
- asia-east1, Changhua County, Taiwan
- asia-east2, Hong Kong
- asia-northeast1, Tokyo, Japan
- asia-northeast2, Osaka, Japan
- asia-south1, Mumbai, India
- asia-south2, Delhi, India
- asia-southeast1, 싱가포르의 Jurong West
- australia-southeast1, Sydney, Australia
- australia-southeast2, 멜버른, 호주
- europe-north1, Hamina, Finland
- europe-west1, St. Ghislain, Belgium
- europe-west2, London, England, UK
- europe-west3, Frankfurt, Germany
- europe-west4, Eemshaven, Netherlands
- europe-west6, Zürich, Switzerland
- europe-west8, Milan, 이탈리아
- europe-west12, Turin, Italy
- europe-southwest1, Madrid, Spain
- northamerica-northeast1, Montréal, Québec, Canada
- southamerica-east1, Osasco (Sawo Paulo), 브라질
- southamerica-west1, Santiago, Chile
- us-central1, Council Bluffs, Iowa, USA
- us-east1, Moncks Corner, South Carolina, USA
- us-east4, Ashburn, Northern Virginia, USA
- us-west1, The Dalles, Oregon, USA
- us-west2, Los Angeles, California, USA
- me-central1, Doha, Qatar
- me-central2, Dammam, Saudi Arabia
다중 AZ 클러스터는 가용성 영역이 3개 이상인 리전에만 배포할 수 있습니다( AWS 및 Google Cloud참조).
각 새로운 OpenShift Dedicated 클러스터는 단일 리전의 전용 VPC(Virtual Private Cloud) 내에 설치되며, 옵션은 단일 가용성 영역(Single-AZ) 또는 여러 가용 영역(Multi-AZ)에 배포할 수 있습니다. 이를 통해 클러스터 수준 네트워크 및 리소스 분리를 제공하고 VPN 연결 및 VPC 피어링과 같은 클라우드 공급자 VPC 설정을 활성화합니다. 영구 볼륨은 클라우드 블록 스토리지에서 지원되며 프로비저닝되는 가용성 영역에 따라 다릅니다. 영구 볼륨은 예약할 수 없는 Pod를 방지하기 위해 연결된 Pod 리소스가 특정 가용성 영역에 할당될 때까지 볼륨에 바인딩되지 않습니다. 가용성 영역별 리소스는 동일한 가용성 영역의 리소스에서만 사용할 수 있습니다.
클러스터를 배포한 후에는 리전 및 단일 또는 다중 가용성 영역 선택 사항을 변경할 수 없습니다.
2.1.1.9. SLA(서비스 수준 계약)
서비스 자체에 대한 SLA는 Red Hat Enterprise Agreement 부록 4 (Online Subscription Services)의 부록 4 에 정의되어 있습니다.
2.1.1.10. 제한된 지원 상태
클러스터가 제한된 지원 상태로 전환되면 Red Hat은 더 이상 클러스터를 적극적으로 모니터링하지 않으며 SLA는 더 이상 적용되지 않으며 SLA에 대해 요청된 자립이 거부됩니다. 이는 더 이상 제품 지원이 없다는 의미는 아닙니다. 일부 경우 위반 요인을 수정하면 클러스터가 완전히 지원되는 상태로 돌아갈 수 있습니다. 그러나 다른 경우에는 클러스터를 삭제하고 다시 생성해야 할 수도 있습니다.
다음 시나리오를 포함하여 여러 가지 이유로 클러스터가 제한된 지원 상태로 전환될 수 있습니다.
- 라이프 사이클 종료일 전에 클러스터를 지원되는 버전으로 업그레이드하지 않는 경우
Red Hat은 라이프 사이클 종료일 이후 버전에 대해 런타임 또는 SLA를 보장하지 않습니다. 지속적인 지원을 받으려면 종료일 이전에 클러스터를 지원되는 버전으로 업그레이드하십시오. 라이프 사이클 종료일 이전에 클러스터를 업그레이드하지 않으면 클러스터가 지원되는 버전으로 업그레이드될 때까지 제한된 지원 상태로 전환됩니다.
Red Hat은 지원되지 않는 버전에서 지원되는 버전으로 업그레이드하기 위해 상업적으로 합리적인 지원을 제공합니다. 그러나 지원되는 업그레이드 경로를 더 이상 사용할 수 없는 경우 새 클러스터를 생성하고 워크로드를 마이그레이션해야 할 수 있습니다.
- 기본 OpenShift Dedicated 구성 요소 또는 Red Hat에서 설치 및 관리하는 기타 구성 요소를 제거하거나 교체하는 경우
- 클러스터 관리자 권한을 사용한 경우 Red Hat은 인프라 서비스, 서비스 가용성 또는 데이터 손실에 영향을 미치는 사용자 또는 사용자의 권한이 있는 사용자의 조치에 대해 책임을 지지 않습니다. Red Hat에서 이러한 작업을 감지하면 클러스터가 제한된 지원 상태로 전환될 수 있습니다. Red Hat은 상태 변경을 알리며 클러스터를 삭제하고 다시 생성해야 할 수 있는 수정 단계를 탐색할 수 있는 조치를 되돌리거나 지원 케이스를 생성해야 합니다.
클러스터가 제한된 지원 상태로 전환되거나 추가 지원이 필요한 특정 작업에 대한 질문이 있는 경우 지원 티켓을 엽니다.
2.1.1.11. 지원
OpenShift Dedicated에는 Red Hat 고객 포털을 사용하여 액세스할 수 있는 Red Hat 프리미엄 지원이 포함되어 있습니다.
OpenShift Dedicated에 대한 지원 관련 사항에 대한 자세한 내용은 지원 범위 페이지를 참조하십시오.
지원 응답 시간은 OpenShift Dedicated SLA 를 참조하십시오.
2.1.2. 로깅
OpenShift Dedicated는 AWS(Amazon Cloud Logging) 또는 GCP(Google Cloud Logging)에 대한 선택적 통합 로그 전달 기능을 제공합니다.
자세한 내용은 로그 수집 및 전달 정보를 참조하십시오.
2.1.2.1. 클러스터 감사 로깅
통합이 활성화된 경우 AWS의 Amazon Cloud Logging 또는 GCP의 Google Cloud Logging을 통해 클러스터 감사 로그를 사용할 수 있습니다. 통합이 활성화되지 않은 경우 지원 케이스를 열어 감사 로그를 요청할 수 있습니다. 감사 로그 요청은 21 일을 초과하지 않는 날짜 및 시간 범위를 지정해야 합니다. 감사 로그를 요청할 때 고객은 감사 로그의 크기가 하루에 최대GB임을 알고 있어야 합니다.
2.1.2.2. 애플리케이션 로깅
STDOUT 으로 전송된 애플리케이션 로그는 설치된 경우 클러스터 로깅 스택을 통해 AWS의 Amazon Cloud Logging 또는 Google Cloud Logging(Google Cloud Logging)으로 전달됩니다.
2.1.3. 모니터링
2.1.3.1. 클러스터 메트릭
OpenShift Dedicated 클러스터에는 CPU, 메모리 및 네트워크 기반 메트릭을 포함한 클러스터 모니터링을 위한 통합된 Prometheus/Grafana 스택이 제공됩니다. 웹 콘솔을 통해 액세스할 수 있으며 Grafana 대시보드를 통해 클러스터 수준 상태 및 용량/사용을 볼 수도 있습니다. 이러한 메트릭을 사용하면 OpenShift Dedicated 사용자가 제공하는 CPU 또는 메모리 메트릭을 기반으로 수평 Pod 자동 스케일링을 수행할 수 있습니다.
2.1.3.2. 클러스터 알림
클러스터 알림은 클러스터의 상태, 상태 또는 성능에 대한 메시지입니다.
클러스터 알림은 Red Hat site Reliability Engineering(SRE)이 관리형 클러스터의 상태에 대해 귀하와 통신하는 기본 방법입니다. SRE는 클러스터 알림을 사용하여 클러스터 문제를 해결하거나 방지하기 위해 작업을 수행하도록 요청할 수도 있습니다.
클러스터 소유자 및 관리자는 클러스터가 정상 상태로 유지되고 지원되는지 확인하기 위해 클러스터 알림을 정기적으로 검토하고 조치를 취해야 합니다.
클러스터의 클러스터 기록 탭에서 Red Hat Hybrid Cloud Console에서 클러스터 알림을 볼 수 있습니다. 기본적으로 클러스터 소유자만 이메일로 클러스터 알림을 수신합니다. 다른 사용자가 클러스터 알림 이메일을 수신해야 하는 경우 각 사용자를 클러스터에 대한 알림 연락처로 추가합니다.
2.1.4. 네트워킹
2.1.4.1. 애플리케이션용 사용자 정의 도메인
OpenShift Dedicated 4.14부터 Custom Domain Operator는 더 이상 사용되지 않습니다. OpenShift Dedicated 4.14 이상에서 Ingress를 관리하려면 Ingress Operator를 사용합니다. OpenShift Dedicated 4.13 및 이전 버전에서는 기능이 변경되지 않습니다.
경로에 사용자 지정 호스트 이름을 사용하려면 CNAME(정규 이름) 레코드를 생성하여 DNS 공급자를 업데이트해야 합니다. CNAME 레코드는 OpenShift 표준 라우터 호스트 이름을 사용자 정의 도메인에 매핑해야 합니다. 경로를 생성한 후 OpenShift 정식 라우터 호스트 이름은 경로 세부 정보 페이지에 표시됩니다. 또는 와일드카드 CNAME 레코드를 한 번 생성하여 지정된 호스트 이름의 모든 하위 도메인을 클러스터의 라우터로 라우팅할 수 있습니다.
2.1.4.2. 클러스터 서비스의 사용자 정의 도메인
사용자 정의 도메인 및 하위 도메인은 플랫폼 서비스 경로(예: API 또는 웹 콘솔 경로 또는 기본 애플리케이션 경로)에는 사용할 수 없습니다.
2.1.4.3. 도메인 검증 인증서
OpenShift Dedicated에는 클러스터의 내부 및 외부 서비스 모두에 필요한 TLS 보안 인증서가 포함되어 있습니다. 외부 경로의 경우 각 클러스터에 제공 및 설치된 두 개의 별도의 TLS 와일드카드 인증서가 있습니다. 하나는 웹 콘솔과 라우팅 기본 호스트 이름, API 끝점에 대한 두 번째 인증서입니다. Let's Encrypt 는 인증서에 사용되는 인증 기관입니다. 클러스터 내의 경로(예: 내부 API 끝점 )는 클러스터의 내장 인증 기관에서 서명한 TLS 인증서를 사용하며 TLS 인증서를 신뢰하기 위해 모든 Pod에서 CA 번들을 사용할 수 있어야 합니다.
2.1.4.4. 빌드를 위한 사용자 정의 인증 기관
OpenShift Dedicated에서는 이미지 레지스트리에서 이미지를 가져올 때 빌드에서 신뢰하는 사용자 정의 인증 기관 사용을 지원합니다.
2.1.4.5. 로드 밸런서
OpenShift Dedicated는 최대 5개의 로드 밸런서를 사용합니다.
- 클러스터 내부이고 내부 클러스터 통신을 위해 트래픽의 균형을 조정하는 데 사용되는 내부 컨트롤 플레인 로드 밸런서입니다.
- OpenShift Container Platform 및 Kubernetes API에 액세스하는 데 사용되는 외부 컨트롤 플레인 로드 밸런서입니다. 이 로드 밸런서는 Red Hat OpenShift Cluster Manager에서 비활성화할 수 있습니다. 이 로드 밸런서가 비활성화된 경우 Red Hat은 내부 제어 로드 밸런서를 가리키도록 API DNS를 재구성합니다.
- Red Hat에서 클러스터 관리용으로 예약한 Red Hat의 외부 컨트롤 플레인 로드 밸런서입니다. 액세스는 엄격하게 제어되며 허용되는 bastion 호스트에서만 통신이 가능합니다.
-
URL의
앱에표시된 기본 애플리케이션 로드 밸런서인 기본 라우터/수신 로드 밸런서입니다. 기본 로드 밸런서는 인터넷을 통해 공개적으로 액세스하거나 기존 개인 연결을 통해 비공개로만 액세스하도록 OpenShift Cluster Manager에서 구성할 수 있습니다. 클러스터의 모든 애플리케이션 경로는 로깅 UI, 지표 API 및 레지스트리와 같은 클러스터 서비스를 포함하여 기본 라우터 로드 밸런서에 노출됩니다. -
선택 사항: URL의
apps2에 표시된 보조 애플리케이션 로드 밸런서인 보조 라우터/수신 로드 밸런서입니다. 보조 로드 밸런서는 인터넷을 통해 공개적으로 액세스하거나 기존 개인 연결을 통해 비공개로만 액세스하도록 OpenShift Cluster Manager에서 구성할 수 있습니다. 이 라우터 로드 밸런서에 대해 'Label match'가 구성된 경우 이 레이블과 일치하는 애플리케이션 경로만 이 라우터 로드 밸런서에 노출됩니다. 그렇지 않으면 모든 애플리케이션 경로도 이 라우터 로드 밸런서에 노출됩니다. - 선택 사항: HTTP/SNI 트래픽 또는 비표준 포트 사용과 같은 고급 인그레스 기능을 활성화하기 위해 OpenShift Dedicated에서 실행되는 서비스에 매핑될 수 있는 서비스의 로드 밸런서입니다. 이는 표준 클러스터의 경우 4 그룹에서 구입하거나 CCS(Customer Cloud Subscription) 클러스터에 비용을 부과하지 않고 프로비저닝할 수 있지만 각 AWS 계정에는 각 클러스터 내에서 사용할 수 있는 Classic Load Balancer의 수를 제한하는 할당량이 있습니다.
2.1.4.6. 네트워크 사용량
표준 OpenShift Dedicated 클러스터의 경우 네트워크 사용량은 인바운드, VPC 피어링, VPN 및 AZ 트래픽 간의 데이터 전송을 기반으로 측정됩니다. 표준 OpenShift Dedicated 기본 클러스터에서 12TB의 네트워크 I/O가 제공됩니다. 추가 네트워크 I/O는 12TB 단위로 구매할 수 있습니다. CCS OpenShift Dedicated 클러스터의 경우 네트워크 사용량은 모니터링되지 않으며 클라우드 공급자가 직접 청구합니다.
2.1.4.7. 클러스터 인그레스
프로젝트 관리자는 IP 허용 목록을 통한 수신 제어를 포함하여 다양한 용도로 경로 주석을 추가할 수 있습니다.
ovs-networkpolicy 플러그인을 활용하는 NetworkPolicy 오브젝트를 사용하여 Ingress 정책을 변경할 수도 있습니다. 이를 통해 동일한 클러스터의 Pod와 동일한 네임스페이스에도 Pod 수준을 포함하여 수신 네트워크 정책을 완전히 제어할 수 있습니다.
모든 클러스터 Ingress 트래픽은 정의된 로드 밸런서를 통과합니다. 클라우드 구성에 의해 모든 노드에 대한 직접 액세스가 차단됩니다.
2.1.4.8. 클러스터 송신
EgressNetworkPolicy 오브젝트를 통한 Pod 송신 트래픽 제어를 사용하여 OpenShift Dedicated에서 아웃바운드 트래픽을 방지하거나 제한할 수 있습니다.
컨트롤 플레인 및 인프라 노드의 공용 아웃바운드 트래픽이 필요하며 클러스터 이미지 보안 및 클러스터 모니터링을 유지 관리하는 데 필요합니다. 이렇게 하려면 0.0.0.0/0 경로가 인터넷 게이트웨이에만 속해야 합니다. 이 범위를 프라이빗 연결을 통해 라우팅할 수 없습니다.
OpenShift Dedicated 클러스터는 NAT 게이트웨이를 사용하여 클러스터를 나가는 모든 공용 아웃바운드 트래픽에 대한 공용 고정 IP를 제공합니다. 클러스터가 배포된 각 서브넷은 별도의 NAT 게이트웨이를 수신합니다. 여러 가용성 영역이 있는 AWS에 배포된 클러스터의 경우 클러스터 송신 트래픽에 대해 최대 3개의 고유한 고정 IP 주소가 존재할 수 있습니다. 가용성 영역 토폴로지에 관계없이 Google Cloud에 배포된 클러스터의 경우 작업자 노드 송신 트래픽에 대한 고정 IP 주소가 1개입니다. 클러스터 내부에 남아 있거나 공용 인터넷으로 나가지 않는 트래픽은 NAT 게이트웨이를 통과하지 않으며 트래픽이 시작된 노드에 속하는 소스 IP 주소를 갖습니다. 노드 IP 주소는 동적이므로 고객은 개인 리소스에 액세스할 때 개별 IP 주소를 허용 목록에 사용하지 않아야 합니다.
고객은 클러스터에서 Pod를 실행한 다음 외부 서비스를 쿼리하여 공용 고정 IP 주소를 확인할 수 있습니다. 예를 들면 다음과 같습니다.
$ oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bin/nslookup -type=a myip.opendns.com resolver1.opendns.com | grep -E 'Address: [0-9.]+'"
2.1.4.9. 클라우드 네트워크 구성
OpenShift Dedicated를 사용하면 여러 클라우드 공급자 관리형 기술을 통해 프라이빗 네트워크 연결을 구성할 수 있습니다.
- VPN 연결
- AWS VPC 피어링
- AWS Transit Gateway
- AWS Direct Connect
- Google Cloud VPC 네트워크 피어링
- Google Cloud Classic VPN
- Google Cloud HA VPN
Red Hat SREs는 사설 네트워크 연결을 모니터링하지 않습니다. 이러한 연결을 모니터링하는 것은 고객의 책임입니다.
2.1.4.10. DNS 전달
프라이빗 클라우드 네트워크 구성이 있는 OpenShift Dedicated 클러스터의 경우 고객은 명시적으로 제공된 도메인에 대해 쿼리해야 하는 프라이빗 연결에서 사용할 수 있는 내부 DNS 서버를 지정할 수 있습니다.
2.1.4.11. 네트워크 검증
네트워크 확인 검사는 기존 VPC(Virtual Private Cloud)에 OpenShift Dedicated 클러스터를 배포하거나 클러스터에 새로 추가된 서브넷을 사용하여 추가 머신 풀을 생성할 때 자동으로 실행됩니다. 이 검사에서는 네트워크 구성을 검증하고 오류를 강조 표시하므로 배포 전에 구성 문제를 해결할 수 있습니다.
네트워크 확인 검사를 수동으로 실행하여 기존 클러스터의 구성을 검증할 수도 있습니다.
추가 리소스
- 네트워크 확인 검사에 대한 자세한 내용은 네트워크 확인을 참조하십시오.
2.1.5. 스토리지
2.1.5.1. encrypted-at-rest OS/node 스토리지
컨트롤 플레인 노드는 encrypted-at-rest-EBS 스토리지를 사용합니다.
2.1.5.2. encrypted-at-rest PV
PV(영구 볼륨)에 사용되는 EBS 볼륨은 기본적으로 암호화된 볼륨입니다.
2.1.5.3. 블록 스토리지(RWO)
PV(영구 볼륨)는 AWS EBS 및 Google Cloud 영구 디스크 블록 스토리지에서 지원합니다. 이 블록 스토리지는 RWO(ReadWriteOnce) 액세스 모드를 사용합니다. 표준 OpenShift Dedicated 기본 클러스터에서 PV에 100GB의 블록 스토리지가 제공되며 애플리케이션 요청에 따라 동적으로 프로비저닝 및 재활용됩니다. 추가 영구 스토리지는 500GB 단위로 구매할 수 있습니다.
PV는 한 번에 단일 노드에만 연결할 수 있으며 프로비저닝된 가용성 영역과 관련이 있지만 가용성 영역의 모든 노드에 연결할 수 있습니다.
각 클라우드 공급자에는 단일 노드에 연결할 수 있는 PV 수에 대한 자체 제한이 있습니다. 자세한 내용은 AWS 인스턴스 유형 제한 또는 Google Cloud Platform 사용자 정의 머신 유형을 참조하십시오.
2.1.6. 플랫폼
2.1.6.1. 클러스터 백업 정책
고객은 애플리케이션 및 애플리케이션 데이터에 대한 백업 계획을 가지고 있어야 합니다.
애플리케이션 및 애플리케이션 데이터 백업은 OpenShift Dedicated 서비스의 일부가 아닙니다. 각 OpenShift Dedicated 클러스터의 모든 Kubernetes 오브젝트는 클러스터가 작동하지 않는 경우 신속하게 복구할 수 있도록 백업됩니다.
백업은 클러스터와 동일한 계정에 있는 보안 개체 스토리지(Multi-AZ) 버킷에 저장됩니다. Red Hat Enterprise Linux CoreOS는 OpenShift Container Platform 클러스터에서 완전히 관리되고 노드의 루트 볼륨에 저장해서는 안되므로 노드 루트 볼륨이 백업되지 않습니다.
다음 표에서는 백업 빈도를 보여줍니다.
| 구성 요소 | 스냅샷 빈도 | 보존 | 참고 |
|---|---|---|---|
| 전체 오브젝트 저장소 백업 | 매일 0100 UTC | 7일 | 이는 모든 Kubernetes 오브젝트의 전체 백업입니다. 이 백업 일정에는 PV(영구 볼륨)가 백업되지 않습니다. |
| 전체 오브젝트 저장소 백업 | weekly on Mondays at 0200 UTC | 30일 | 이는 모든 Kubernetes 오브젝트의 전체 백업입니다. 이 백업 일정에는 PV가 백업되지 않습니다. |
| 전체 오브젝트 저장소 백업 | 시간 경과 후 17분 | 24시간 | 이는 모든 Kubernetes 오브젝트의 전체 백업입니다. 이 백업 일정에는 PV가 백업되지 않습니다. |
2.1.6.2. 자동 확장
노드 자동 스케일링은 OpenShift Dedicated에서 사용할 수 있습니다. 클러스터에서 노드 자동 스케일링에 대한 자세한 내용은 클러스터에서 노드 자동 스케일링 정보를 참조하십시오.
2.1.6.3. 데몬 세트
고객은 OpenShift Dedicated에서 DaemonSet을 생성하고 실행할 수 있습니다. DaemonSets를 작업자 노드에서만 실행하도록 제한하려면 다음 nodeSelector를 사용합니다.
...
spec:
nodeSelector:
role: worker
...2.1.6.4. 다중 가용성 영역
여러 가용성 영역 클러스터에서 제어 노드는 가용성 영역에 분산되어 있으며 각 가용성 영역에는 세 개 이상의 작업자 노드가 필요합니다.
2.1.6.5. 노드 라벨
사용자 정의 노드 레이블은 노드 생성 중에 Red Hat에서 생성하며 현재 OpenShift Dedicated 클러스터에서 변경할 수 없습니다.
2.1.6.6. OpenShift 버전
OpenShift Dedicated는 서비스로 실행되며 최신 OpenShift Container Platform 버전으로 최신 상태로 유지됩니다.
2.1.6.7. 업그레이드
업그레이드 정책 및 절차에 대한 자세한 내용은 OpenShift Dedicated 라이프 사이클 을 참조하십시오.
2.1.6.8. Windows 컨테이너
현재 OpenShift Dedicated에서는 Windows 컨테이너를 사용할 수 없습니다.
2.1.6.9. 컨테이너 엔진
OpenShift Dedicated는 OpenShift 4에서 실행되며 사용 가능한 유일한 컨테이너 엔진으로 CRI-O 를 사용합니다.
2.1.6.10. 운영 체제
OpenShift Dedicated는 OpenShift 4에서 실행되며 모든 컨트롤 플레인 및 작업자 노드의 운영 체제로 Red Hat Enterprise Linux CoreOS를 사용합니다.
2.1.6.11. Red Hat Operator 지원
일반적으로 Red Hat 워크로드는 Operator Hub를 통해 제공되는 Red Hat 제공 Operator를 참조합니다. Red Hat 워크로드는 Red Hat SRE 팀에서 관리하지 않으며 작업자 노드에 배포해야 합니다. 이러한 Operator에는 추가 Red Hat 서브스크립션이 필요할 수 있으며 추가 클라우드 인프라 비용이 발생할 수 있습니다. Red Hat에서 제공하는 Operator의 예는 다음과 같습니다.
- Red Hat Quay
- Red Hat Advanced Cluster Management
- Red Hat Advanced Cluster Security
- Red Hat OpenShift Service Mesh
- OpenShift Serverless
- Red Hat OpenShift Logging
- Red Hat OpenShift Pipelines
2.1.6.12. Kubernetes Operator 지원
OperatorHub 마켓플레이스에 나열된 모든 Operator를 설치할 수 있어야 합니다. Red Hat Operator를 포함하여 OperatorHub에서 설치한 Operator는 OpenShift Dedicated 서비스의 일부로 SRE를 관리하지 않습니다. 지정된 Operator의 지원 가능성에 대한 자세한 내용은 Red Hat 고객 포털 을 참조하십시오.
2.1.7. 보안
이 섹션에서는 OpenShift Dedicated 보안을 위한 서비스 정의에 대한 정보를 제공합니다.
2.1.7.1. 인증 공급자
클러스터에 대한 인증은 Red Hat OpenShift Cluster Manager 클러스터 생성 프로세스의 일부로 구성됩니다. OpenShift는 ID 공급자가 아니며 클러스터에 대한 모든 액세스는 고객이 통합 솔루션의 일부로 관리해야 합니다. 동시에 프로비저닝된 여러 ID 공급자를 프로비저닝하는 것이 지원됩니다. 지원되는 ID 공급자는 다음과 같습니다.
- GitHub 또는 GitHub Enterprise OAuth
- GitLab OAuth
- Google OAuth
- LDAP
- OpenID connect
2.1.7.2. 권한 있는 컨테이너
권한 있는 컨테이너는 OpenShift Dedicated에서 기본적으로 사용할 수 없습니다. anyuid 및 nonroot 보안 컨텍스트 제약 조건은 dedicated-admins 그룹의 멤버에서 사용할 수 있으며 많은 사용 사례를 처리해야 합니다. 권한 있는 컨테이너는 cluster-admin 사용자만 사용할 수 있습니다.
2.1.7.3. 고객 관리자
OpenShift Dedicated는 일반 사용자 외에도 dedicated-admin 이라는 OpenShift Dedicated 전용 그룹에 대한 액세스를 제공합니다. dedicated-admin 그룹의 멤버인 클러스터의 모든 사용자:
- 클러스터의 모든 고객 생성 프로젝트에 대한 관리자 액세스 권한이 있어야 합니다.
- 클러스터의 리소스 할당량 및 제한을 관리할 수 있습니다.
-
NetworkPolicy오브젝트를 추가하고 관리할 수 있습니다. - 스케줄러 정보를 포함하여 클러스터의 특정 노드 및 PV에 대한 정보를 볼 수 있습니다.
-
클러스터에서 예약된
dedicated-admin프로젝트에 액세스할 수 있으므로 승격된 권한이 있는 서비스 계정을 생성할 수 있으며 클러스터에서 프로젝트의 기본 제한 및 할당량을 업데이트할 수도 있습니다. -
OperatorHub에서 Operator를 설치할 수 있습니다(
*모든*.operators.coreos.comAPI 그룹의 동사).
2.1.7.4. 클러스터 관리 역할
CCO(Customer Cloud Subscription)를 사용하는 OpenShift Dedicated의 관리자는 cluster-admin 역할에 액세스할 수 있습니다. cluster-admin 역할을 사용하여 계정에 로그인하는 동안 클러스터를 제어하고 구성할 수 있는 무제한 액세스 권한이 대부분 있습니다. 클러스터의 불안정을 방지하기 위해 Webhook로 차단되거나 OpenShift Cluster Manager에서 관리되기 때문에 클러스터 내 변경 사항을 덮어쓰는 몇 가지 구성이 있습니다.
2.1.7.5. 프로젝트 셀프 서비스
기본적으로 모든 사용자는 프로젝트를 생성, 업데이트 및 삭제할 수 있습니다. dedicated-admin 그룹의 멤버가 인증된 사용자에서 self-provisioner 역할을 제거하는 경우 이를 제한할 수 있습니다.
$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth
적용을 통해 제한 사항을 되돌릴 수 있습니다.
$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth
2.1.7.6. 규정 준수
OpenShift Dedicated는 보안 및 제어를 위한 일반적인 업계 모범 사례를 따릅니다. 인증은 다음 표에 설명되어 있습니다.
| 컴플라이언스 | AWS의 OpenShift Dedicated | GCP의 OpenShift Dedicated |
|---|---|---|
| HIPAA 정규화된 | 제공됨 (고객 클라우드 서브스크립션만) | 제공됨 (고객 클라우드 서브스크립션만) |
| ISO 27001 | 제공됨 | 제공됨 |
| PCI DSS | 제공됨 | 제공됨 |
| SOC 2 Type 2 | 제공됨 | 제공됨 |
2.1.7.7. 네트워크 보안
각 OpenShift Dedicated 클러스터는 방화벽 규칙(AWS Security Groups 또는 Google Cloud Compute Engine 방화벽 규칙)을 사용하여 클라우드 인프라 수준에서 보안 네트워크 구성으로 보호됩니다. AWS의 OpenShift Dedicated 고객도 AWS Shield Standard 를 사용하여 DDoS 공격으로부터 보호됩니다. 마찬가지로 GCP의 OpenShift Dedicated에서 사용하는 모든 GCP 로드 밸런서 및 공용 IP 주소는 Google Cloud Armor Standard 를 사용하여 DDoS 공격으로부터 보호됩니다.
2.1.7.8. etcd 암호화
OpenShift Dedicated에서 컨트롤 플레인 스토리지는 기본적으로 암호화되어 etcd 볼륨의 암호화가 포함됩니다. 이 스토리지 수준 암호화는 클라우드 공급자의 스토리지 계층을 통해 제공됩니다.
etcd 암호화를 활성화하여 etcd의 키 값을 암호화하지만 키를 암호화할 수도 없습니다. etcd 암호화를 활성화하면 다음 Kubernetes API 서버 및 OpenShift API 서버 리소스가 암호화됩니다.
- 보안
- 구성 맵
- 라우트
- OAuth 액세스 토큰
- OAuth 승인 토큰
etcd 암호화 기능은 기본적으로 활성화되어 있지 않으며 클러스터 설치 시에만 활성화할 수 있습니다. etcd 암호화가 활성화된 상태에서도 etcd 키 값은 컨트롤 플레인 노드 또는 cluster-admin 권한에 액세스할 수 있는 모든 사용자가 액세스할 수 있습니다.
etcd의 키 값에 etcd 암호화를 활성화하면 약 20%의 성능 오버헤드가 발생합니다. 오버헤드는 etcd 볼륨을 암호화하는 기본 컨트롤 플레인 스토리지 암호화 외에도 이 두 번째 암호화 계층이 도입된 결과입니다. 특히 사용 사례에 필요한 경우에만 etcd 암호화를 활성화하는 것이 좋습니다.
