3.3. Red Hat OpenShift Service on AWS 서비스 정의
이 문서에서는 ROSA(Red Hat OpenShift Service on AWS) 관리 서비스의 서비스 정의에 대해 간단히 설명합니다.
3.3.1. 계정 관리
이 섹션에서는 AWS 계정 관리의 Red Hat OpenShift Service 서비스 정의에 대해 설명합니다.
3.3.1.1. 청구
AWS의 Red Hat OpenShift Service는 OpenShift 서비스용 로드 밸런서, 스토리지, EC2 인스턴스, 기타 구성 요소 및 Red Hat 서브스크립션과 같은 서비스에서 사용하는 AWS(Amazon Web Services)를 통해 청구됩니다.
추가 Red Hat 소프트웨어는 별도로 구매해야 합니다.
3.3.1.2. 클러스터 셀프 서비스
고객은 다음을 포함하여 클러스터를 셀프 서비스할 수 있습니다.
- 클러스터 생성
- 클러스터 삭제
- ID 공급자 추가 또는 제거
- 승격된 그룹에서 사용자 추가 또는 제거
- 클러스터 개인 정보 보호 설정
- 머신 풀 추가 또는 제거 및 자동 스케일링 구성
- 업그레이드 정책 정의
이러한 작업은 rosa CLI 유틸리티를 사용하여 셀프 서비스를 수행할 수 있습니다.
3.3.1.3. 인스턴스 유형
단일 가용성 영역 클러스터에는 최소 3개의 컨트롤 플레인 노드, 인프라 노드 2개, 단일 가용성 영역에 배포된 작업자 노드 2개가 필요합니다.
여러 가용성 영역 클러스터에는 최소 3개의 컨트롤 플레인 노드가 필요합니다. 인프라 노드 3개와 작업자 노드 3개 적절한 노드 배포를 유지하려면 3개의 여러 노드에서 추가 노드를 구입해야 합니다.
AWS 클러스터의 모든 Red Hat OpenShift Service는 최대 180개의 작업자 노드를 지원합니다.
클러스터를 생성한 후에는 Default 머신 풀 노드 유형 및 크기는 변경할 수 없습니다.
컨트롤 플레인 및 인프라 노드는 Red Hat에서 배포 및 관리합니다. 클라우드 공급자 콘솔을 통해 기본 인프라를 종료하면 지원되지 않으며 데이터가 손실될 수 있습니다. etcd 및 API 관련 워크로드를 처리하는 컨트롤 플레인 노드가 3개 이상 있습니다. 메트릭, 라우팅, 웹 콘솔 및 기타 워크로드를 처리하는 인프라 노드가 두 개 이상 있습니다. 제어 및 인프라 노드에서 워크로드를 실행하지 않아야 합니다. 실행하려는 워크로드는 작업자 노드에 배포해야 합니다. 작업자 노드에 배포해야 하는 Red Hat 워크로드에 대한 자세한 내용은 아래 Red Hat Operator 지원 섹션을 참조하십시오.
약 1개의 vCPU 코어 및 1GiB의 메모리가 각 작업자 노드에 예약되며 할당 가능한 리소스에서 제거됩니다. 기본 플랫폼에 필요한 프로세스를 실행하려면 이 리소스 예약이 필요합니다. 이러한 프로세스에는 udev, kubelet 및 컨테이너 런타임과 같은 시스템 데몬이 포함됩니다. 예약된 리소스는 커널 예약도 계정합니다.
감사 로그 집계, 지표 수집, DNS, 이미지 레지스트리, SDN 등과 같은 OpenShift Container Platform 코어 시스템은 클러스터의 안정성과 유지 관리를 위해 추가 할당 가능한 리소스를 사용할 수 있습니다. 소비되는 추가 리소스는 사용량에 따라 다를 수 있습니다.
자세한 내용은 Kubernetes 설명서 를 참조하십시오.
AWS 버전 4.8.35의 Red Hat OpenShift Service, 4.9.26, 4.10.6, AWS 기본값인 Red Hat OpenShift Service는 4096 입니다. 이 PID 제한을 활성화하려면 AWS 클러스터에서 이러한 버전 이상으로 Red Hat OpenShift Service를 업그레이드해야 합니다. 이전 버전이 있는 AWS 클러스터의 Red Hat OpenShift Service는 기본 PID 제한 1024 를 사용합니다.
AWS 클러스터의 모든 Red Hat OpenShift Service에서 Pod별 PID 제한을 구성할 수 없습니다.
추가 리소스
3.3.1.4. AWS 인스턴스 유형
AWS의 Red Hat OpenShift Service는 다음과 같은 작업자 노드 인스턴스 유형 및 크기를 제공합니다.
예 3.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)
이러한 인스턴스 유형은 48개의 물리적 코어에서 96개의 논리 프로세서를 제공합니다. 두 개의 물리적 Intel 소켓이 있는 단일 서버에서 실행됩니다.
예 3.2. Burstable 일반 목적
- t3.xlarge (4 vCPU, 16GiB)
- t3.2xlarge (8 vCPU, 32GiB)
- t3a.xlarge (4 vCPU, 16GiB)
- t3a.2xlarge (8 vCPU, 32GiB)
예 3.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)
예 3.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)
이러한 인스턴스 유형은 48개의 물리적 코어에서 96개의 논리 프로세서를 제공합니다. 두 개의 물리적 Intel 소켓이 있는 단일 서버에서 실행됩니다.
이 인스턴스 유형은 24개의 물리적 코어에서 48개의 논리 프로세서를 제공합니다.
예 3.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)
- 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 인스턴스 유형을 수용할 수 있는지 확인합니다.
예 3.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)
예 3.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)
이 인스턴스 유형은 36 개의 물리적 코어에서 72 개의 논리 프로세서를 제공합니다.
가상 인스턴스 유형은 ".metal" 인스턴스 유형보다 더 빨리 초기화됩니다.
추가 리소스
3.3.1.5. 지역 및 가용성 영역
다음 AWS 리전은 Red Hat OpenShift 4에서 지원되며 AWS의 Red Hat OpenShift Service에서 지원됩니다. 참고: OpenShift 4에 대한 지원에 관계없이 중국 및 GovCloud (US) 리전은 지원되지 않습니다.
- af-south-1 (AWS opt-in 필요)
- ap-east-1 (홍콩, AWS 옵트인 필요)
- ap-northeast-1(도쿄)
- ap-northeast-2(서울)
- ap-northeast-3 (오사카)
- ap-south-1(뭄바이)
- ap-southeast-1(싱가포르)
- ap-southeast-2(시드니)
- ap-southeast-3 (AWS 옵트인 필요)
- ca-central-1 (캐나다)
- eu-central-1(프랑크푸르트)
- eu-north-1(스톡홀름)
- eu-south-1 (AWS 옵트인 필요)
- eu-west-1(아일랜드)
- eu-west-2(런던)
- eu-west-3(파리)
- me-south-1 (Bahrain, AWS opt-in 필요)
- sa-east-1(상파울루)
- us-east-1(버지니아 북부)
- us-east-2(오하이오)
- us-west-1(캘리포니아 북부)
- us-west-2(오레곤)
여러 가용성 영역 클러스터는 가용성 영역이 3개 이상인 지역에만 배포할 수 있습니다. 자세한 내용은 AWS 문서의 리전 및 가용 영역 섹션을 참조하십시오.
AWS의 새로운 Red Hat OpenShift Service는 단일 리전의 설치 관리자 생성 또는 기존 VPC(Virtual Private Cloud) 내에 설치됩니다. 이 옵션을 통해 단일 가용성 영역(Single-AZ) 또는 여러 가용성 영역(Multi-AZ)에 배포할 수 있습니다. 이를 통해 클러스터 수준 네트워크 및 리소스 분리를 제공하고 VPN 연결 및 VPC 피어링과 같은 클라우드 공급자 VPC 설정을 활성화합니다. PV(영구 볼륨)는 AWS EBS(Elastic Block Storage)에서 지원하며, 프로비저닝되는 가용성 영역에 따라 다릅니다. PVC(영구 볼륨 클레임)는 예약할 수 없는 Pod를 방지하기 위해 연결된 Pod 리소스가 특정 가용 영역에 할당될 때까지 볼륨에 바인딩되지 않습니다. 가용성 영역별 리소스는 동일한 가용성 영역의 리소스에서만 사용할 수 있습니다.
클러스터를 배포한 후에는 단일 또는 여러 가용성 영역의 리전 및 선택 사항을 변경할 수 없습니다.
3.3.1.6. SLA(서비스 수준 계약)
서비스 자체에 대한 SLA는 Red Hat Enterprise Agreement 부록 4 (Online Subscription Services)의 부록 4 에 정의되어 있습니다.
3.3.1.7. 제한된 지원 상태
클러스터가 제한된 지원 상태로 전환되면 Red Hat은 더 이상 클러스터를 적극적으로 모니터링하지 않으며 SLA는 더 이상 적용되지 않으며 SLA에 대해 요청된 자립이 거부됩니다. 이는 더 이상 제품 지원이 없다는 의미는 아닙니다. 일부 경우 위반 요인을 수정하면 클러스터가 완전히 지원되는 상태로 돌아갈 수 있습니다. 그러나 다른 경우에는 클러스터를 삭제하고 다시 생성해야 할 수도 있습니다.
다음 시나리오를 포함하여 여러 가지 이유로 클러스터가 제한된 지원 상태로 이동할 수 있습니다.
- 라이프 사이클 종료일 전에 클러스터를 지원되는 버전으로 업그레이드하지 않는 경우
Red Hat은 라이프 사이클 종료일 이후 버전에 대해 런타임 또는 SLA를 보장하지 않습니다. 지속적인 지원을 받으려면 종료일 이전에 클러스터를 지원되는 버전으로 업그레이드하십시오. 라이프 사이클 종료일 이전에 클러스터를 업그레이드하지 않으면 클러스터가 지원되는 버전으로 업그레이드될 때까지 제한된 지원 상태로 전환됩니다.
Red Hat은 지원되지 않는 버전에서 지원되는 버전으로 업그레이드하기 위해 상업적으로 합리적인 지원을 제공합니다. 그러나 지원되는 업그레이드 경로를 더 이상 사용할 수 없는 경우 새 클러스터를 생성하고 워크로드를 마이그레이션해야 할 수 있습니다.
- AWS 구성 요소에서 기본 Red Hat OpenShift Service 또는 Red Hat에서 설치 및 관리하는 기타 구성 요소를 제거하거나 교체하는 경우
- 클러스터 관리자 권한을 사용한 경우 Red Hat은 인프라 서비스, 서비스 가용성 또는 데이터 손실에 영향을 미치는 사용자 또는 사용자의 권한이 있는 사용자의 조치에 대해 책임을 지지 않습니다. Red Hat에서 이러한 작업을 감지하면 클러스터가 제한된 지원 상태로 전환될 수 있습니다. Red Hat은 상태 변경을 알리며 클러스터를 삭제하고 다시 생성해야 할 수 있는 수정 단계를 탐색할 수 있는 조치를 되돌리거나 지원 케이스를 생성해야 합니다.
클러스터가 제한된 지원 상태로 이동하거나 추가 지원이 필요한 특정 작업에 대한 질문이 있는 경우 지원 티켓을 엽니다.
3.3.1.8. 지원
AWS의 Red Hat OpenShift Service에는 Red Hat 고객 포털을 사용하여 액세스할 수 있는 Red Hat Premium 지원이 포함되어 있습니다.
지원 응답 시간은 Red Hat OpenShift Service on AWS SLA 를 참조하십시오.
AWS 지원은 AWS와 고객의 기존 지원 계약의 적용을 받습니다.
3.3.2. 로깅
AWS의 Red Hat OpenShift Service는 Amazon (AWS) 10.0.0.1에 선택적 통합 로그 전달 기능을 제공합니다.
3.3.2.1. 클러스터 감사 로깅
통합이 활성화된 경우 클러스터 감사 로그를 AWS3-4를 통해 사용할 수 있습니다. 통합이 활성화되지 않은 경우 지원 케이스를 열어 감사 로그를 요청할 수 있습니다.
3.3.2.2. 애플리케이션 로깅
STDOUT 으로 전송된 애플리케이션 로그는 Fluentd에 의해 수집되며 설치된 경우 클러스터 로깅 스택을 통해 AWS#177로 전달됩니다.
3.3.3. 모니터링
이 섹션에서는 AWS 모니터링 시 Red Hat OpenShift Service의 서비스 정의에 대해 설명합니다.
3.3.3.1. 클러스터 메트릭
AWS 클러스터의 Red Hat OpenShift Service에는 CPU, 메모리, 네트워크 기반 메트릭을 포함한 클러스터 모니터링을 위해 통합된 Prometheus 스택이 제공됩니다. 웹 콘솔을 통해 액세스할 수 있습니다. 또한 이러한 메트릭을 사용하면 AWS 사용자의 Red Hat OpenShift Service에서 제공하는 CPU 또는 메모리 메트릭을 기반으로 수평 Pod 자동 스케일링을 수행할 수 있습니다.
3.3.3.2. 클러스터 상태 알림
Red Hat은 OpenShift Cluster Manager에서 사용 가능한 클러스터 대시보드의 조합과 원래 클러스터를 배포한 연락처의 이메일 주소 및 고객이 지정한 추가 연락처로 전송된 이메일 알림을 통해 AWS 클러스터에서 Red Hat OpenShift Service의 상태 및 상태를 전달합니다.
3.3.4. 네트워킹
이 섹션에서는 AWS 네트워킹의 Red Hat OpenShift Service의 서비스 정의에 대해 설명합니다.
3.3.4.1. 애플리케이션용 사용자 정의 도메인
경로에 사용자 지정 호스트 이름을 사용하려면 CNAME(정규 이름) 레코드를 생성하여 DNS 공급자를 업데이트해야 합니다. CNAME 레코드는 OpenShift 표준 라우터 호스트 이름을 사용자 정의 도메인에 매핑해야 합니다. 경로를 생성한 후 OpenShift 정식 라우터 호스트 이름은 경로 세부 정보 페이지에 표시됩니다. 또는 와일드카드 CNAME 레코드를 한 번 생성하여 지정된 호스트 이름의 모든 하위 도메인을 클러스터의 라우터로 라우팅할 수 있습니다.
3.3.4.2. 도메인 검증 인증서
AWS의 Red Hat OpenShift Service에는 클러스터의 내부 및 외부 서비스에 필요한 TLS 보안 인증서가 포함되어 있습니다. 외부 경로의 경우 각 클러스터에 제공 및 설치된 두 개의 TLS 와일드카드 인증서가 있습니다. 하나는 웹 콘솔과 라우팅 기본 호스트 이름이며 다른 하나는 API 엔드포인트용입니다. Let's Encrypt는 인증서에 사용되는 인증 기관입니다. 내부 API 끝점 과 같은 클러스터 내의 경로는 클러스터의 내장 인증 기관에서 서명한 TLS 인증서를 사용하며, TLS 인증서를 신뢰하기 위해 모든 Pod에서 CA 번들을 사용할 수 있어야 합니다.
3.3.4.3. 빌드를 위한 사용자 정의 인증 기관
AWS의 Red Hat OpenShift Service에서는 이미지 레지스트리에서 이미지를 가져올 때 빌드에서 신뢰할 사용자 정의 인증 기관을 사용할 수 있습니다.
3.3.4.4. 로드 밸런서
AWS의 Red Hat OpenShift Service는 최대 5개의 로드 밸런서를 사용합니다.
- 내부 클러스터 통신을 위해 트래픽의 균형을 조정하는 데 사용되는 내부 컨트롤 플레인 로드 밸런서입니다.
- OpenShift 및 Kubernetes API에 액세스하는 데 사용되는 외부 컨트롤 플레인 로드 밸런서입니다. OpenShift Cluster Manager에서 이 로드 밸런서를 비활성화할 수 있습니다. 이 로드 밸런서가 비활성화된 경우 Red Hat은 내부 컨트롤 플레인 로드 밸런서를 가리키도록 API DNS를 재구성합니다.
- Red Hat에서 클러스터 관리용으로 예약한 Red Hat의 외부 컨트롤 플레인 로드 밸런서입니다. 액세스는 엄격하게 제어되며 허용 목록에 있는 베스천 호스트에서만 통신이 가능합니다.
-
URL의
앱에표시된 기본 외부 라우터/수신 로드 밸런서입니다. OpenShift Cluster Manager에서 기본 로드 밸런서를 인터넷을 통해 공개적으로 액세스하거나 기존 개인 연결을 통해 비공개로만 액세스할 수 있도록 구성할 수 있습니다. 클러스터의 모든 애플리케이션 경로는 로깅 UI, 지표 API 및 레지스트리와 같은 클러스터 서비스를 포함하여 기본 라우터 로드 밸런서에 노출됩니다. -
선택 사항: URL의
apps2에 표시된 보조 애플리케이션 로드 밸런서인 보조 라우터/수신 로드 밸런서입니다. 보조 로드 밸런서는 인터넷을 통해 공개적으로 액세스하거나 기존 개인 연결을 통해 비공개로만 액세스할 수 있도록 OpenShift Cluster Manager에서 구성할 수 있습니다.레이블 일치가 이 라우터 로드 밸런서에 구성된 경우 이 레이블과 일치하는 애플리케이션 경로만 이 라우터 로드 밸런서에 노출됩니다. 그렇지 않으면 모든 애플리케이션 경로도 이 라우터 로드 밸런서에 노출됩니다. - 선택사항: 서비스용 로드 밸런서입니다. 서비스에 대해 비HTTP/SNI 트래픽 및 비표준 포트를 활성화합니다. 이러한 로드 밸런서는 AWS의 Red Hat OpenShift Service에서 실행되는 서비스에 매핑되어 비HTTP/SNI 트래픽 또는 비표준 포트 사용과 같은 고급 수신 기능을 활성화할 수 있습니다. 각 AWS 계정에는 각 클러스터 내에서 사용할 수 있는 클래식 로드 밸런서의 수를 제한하는 할당량이 있습니다.
3.3.4.5. 클러스터 인그레스
프로젝트 관리자는 IP 허용 목록을 통한 수신 제어를 포함하여 다양한 용도로 경로 주석을 추가할 수 있습니다.
ovs-networkpolicy 플러그인을 활용하는 NetworkPolicy 오브젝트를 사용하여 Ingress 정책을 변경할 수도 있습니다. 이를 통해 동일한 클러스터의 Pod와 동일한 네임스페이스에도 Pod 수준을 포함하여 수신 네트워크 정책을 완전히 제어할 수 있습니다.
모든 클러스터 인그레스 트래픽은 정의된 로드 밸런서를 통해 이동합니다. 클라우드 구성에 의해 모든 노드에 대한 직접 액세스가 차단됩니다.
3.3.4.6. 클러스터 송신
EgressNetworkPolicy 오브젝트를 통한 Pod 송신 트래픽 제어를 사용하여 AWS의 Red Hat OpenShift Service에서 아웃바운드 트래픽을 방지하거나 제한할 수 있습니다.
컨트롤 플레인 및 인프라 노드의 공용 아웃바운드 트래픽이 필요하며 클러스터 이미지 보안 및 클러스터 모니터링을 유지 관리하는 데 필요합니다. 0.0.0.0/0 경로는 인터넷 게이트웨이에만 속해야 합니다. 이 범위를 프라이빗 연결을 통해 라우팅할 수 없습니다.
OpenShift 4 클러스터는 NAT 게이트웨이를 사용하여 클러스터를 나가는 공용 아웃바운드 트래픽에 대한 공용 고정 IP를 제공합니다. 클러스터가 배포된 각 가용성 영역은 별도의 NAT 게이트웨이를 수신하므로 클러스터 송신 트래픽에 대해 최대 3개의 고유한 고정 IP 주소가 존재할 수 있습니다. 클러스터 내부에 남아 있거나 공용 인터넷으로 전달하지 않는 트래픽은 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.]+'"
3.3.4.7. 클라우드 네트워크 구성
Red Hat OpenShift Service on AWS를 사용하면 AWS 관리 기술을 통한 프라이빗 네트워크 연결을 설정할 수 있습니다.
- VPN 연결
- VPC 피어링
- Transport Gateway
- Direct Connect
Red Hat 사이트 안정성 엔지니어(SRE)는 사설 네트워크 연결을 모니터링하지 않습니다. 이러한 연결을 모니터링하는 것은 고객의 책임입니다.
3.3.4.8. DNS 전달
프라이빗 클라우드 네트워크 구성이 있는 AWS 클러스터의 Red Hat OpenShift Service의 경우 고객은 해당 프라이빗 연결에서 사용 가능한 내부 DNS 서버를 지정할 수 있습니다. 이 서버는 명시적으로 제공된 도메인에 대해 쿼리해야 합니다.
3.3.5. 스토리지
이 섹션에서는 AWS 스토리지의 Red Hat OpenShift Service의 서비스 정의에 대해 설명합니다.
3.3.5.1. encrypted-at-rest OS 및 노드 스토리지
컨트롤 플레인, 인프라 및 작업자 노드는 encrypted-at-rest AWS EBS(Elastic Block Store) 스토리지를 사용합니다.
3.3.5.2. encrypted-at-rest PV
PV에 사용되는 EBS 볼륨은 기본적으로 암호화-at-rest입니다.
3.3.5.3. 블록 스토리지(RWO)
PV(영구 볼륨)는 AWS EBS에서 지원합니다. 이는 Read-Write-Once입니다.
PV는 한 번에 단일 노드에만 연결할 수 있으며 프로비저닝된 가용성 영역과 관련이 있습니다. 그러나 가용성 영역의 모든 노드에 PV를 연결할 수 있습니다.
각 클라우드 공급자에는 단일 노드에 연결할 수 있는 PV 수에 대한 자체 제한이 있습니다. 자세한 내용은 AWS 인스턴스 유형 제한을 참조하십시오.
3.3.6. 플랫폼
이 섹션에서는 ROSA(Red Hat OpenShift Service on AWS) 플랫폼의 서비스 정의에 대해 설명합니다.
3.3.6.1. 클러스터 백업 정책
고객은 애플리케이션 및 애플리케이션 데이터에 대한 백업 계획을 가지고 있어야 합니다.
애플리케이션 및 애플리케이션 데이터 백업은 AWS 서비스의 Red Hat OpenShift Service의 일부가 아닙니다. 다음 표에는 클러스터 백업 정책이 요약되어 있습니다.
| 구성 요소 | 스냅샷 빈도 | 보존 | 참고 |
|---|---|---|---|
| 전체 오브젝트 저장소 백업, 모든 클러스터 PV(영구 볼륨) | daily | 7일 | 이는 etcd와 같은 모든 Kubernetes 오브젝트와 클러스터의 모든 PV에 대한 전체 백업입니다. |
| weekly | 30일 | ||
| 전체 오브젝트 저장소 백업 | hourly | 24시간 | 이는 etcd와 같은 모든 Kubernetes 오브젝트의 전체 백업입니다. 이 백업 일정에는 PV가 백업되지 않습니다. |
| 노드 루트 볼륨 | Never | 해당 없음 | 노드는 단기적으로 간주됩니다. 중요한 것은 노드의 루트 볼륨에 저장해야 합니다. |
3.3.6.2. 자동 확장
AWS의 Red Hat OpenShift Service에서 노드 자동 스케일링을 사용할 수 있습니다. 클러스터의 머신 수를 자동으로 확장하도록 자동 스케일러 옵션을 구성할 수 있습니다.
추가 리소스
3.3.6.3. DaemonSets
고객은 AWS의 Red Hat OpenShift Service에서 daemonsets를 생성하고 실행할 수 있습니다. 데몬 세트를 작업자 노드에서만 실행되도록 제한하려면 다음 nodeSelector 를 사용합니다.
...
spec:
nodeSelector:
role: worker
...3.3.6.4. 다중 가용성 영역
여러 가용성 영역 클러스터에서 컨트롤 플레인 노드는 가용성 영역에 분산되어 있으며 각 가용성 영역에 하나 이상의 작업자 노드가 필요합니다.
3.3.6.5. 노드 라벨
사용자 정의 노드 레이블은 노드 생성 중에 Red Hat에서 생성하며 현재 AWS 클러스터의 Red Hat OpenShift Service에서 변경할 수 없습니다. 그러나 새 머신 풀을 생성할 때 사용자 정의 라벨이 지원됩니다.
3.3.6.6. OpenShift 버전
AWS의 Red Hat OpenShift Service는 서비스로 실행되며 최신 OpenShift Container Platform 버전으로 최신 상태로 유지됩니다. 최신 버전으로 스케줄링을 사용할 수 있습니다.
3.3.6.7. 업그레이드
Rosa CLI 유틸리티를 사용하거나 OpenShift Cluster Manager를 통해 업그레이드를 예약할 수 있습니다.
업그레이드 정책 및 절차에 대한 자세한 내용은 AWS 라이프 사이클의 Red Hat OpenShift Service 를 참조하십시오.
3.3.6.8. Windows 컨테이너
Windows Containers 용 Red Hat OpenShift 지원은 현재 AWS의 Red Hat OpenShift Service에서 사용할 수 없습니다.
3.3.6.9. 컨테이너 엔진
AWS의 Red Hat OpenShift Service는 OpenShift 4에서 실행되며 CRI-O 를 사용 가능한 유일한 컨테이너 엔진으로 사용합니다.
3.3.6.10. 운영 체제
AWS의 Red Hat OpenShift Service는 OpenShift 4에서 실행되며 Red Hat CoreOS를 모든 컨트롤 플레인 및 작업자 노드의 운영 체제로 사용합니다.
3.3.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
3.3.6.12. Kubernetes Operator 지원
Operator Hub 마켓플레이스에 나열된 모든 Operator를 설치할 수 있어야 합니다. 이러한 운영자는 고객 워크로드로 간주되며 Red Hat SRE에서 모니터링하지 않습니다.
3.3.7. 보안
이 섹션에서는 AWS 보안의 Red Hat OpenShift Service의 서비스 정의에 대해 설명합니다.
3.3.7.1. 인증 공급자
클러스터 인증은 OpenShift Cluster Manager Hybrid Cloud Console 또는 클러스터 생성 프로세스를 사용하거나 rosa CLI를 사용하여 구성할 수 있습니다. AWS의 Red Hat OpenShift Service는 ID 공급자가 아니며 클러스터에 대한 모든 액세스는 고객이 통합 솔루션의 일부로 관리해야 합니다. 동시에 프로비저닝된 여러 ID 공급자를 사용하는 것이 지원됩니다. 지원되는 ID 공급자는 다음과 같습니다.
- GitHub 또는 GitHub Enterprise
- GitLab
- LDAP
- OpenID Connect
3.3.7.2. 권한 있는 컨테이너
cluster-admin 역할을 가진 사용자는 권한 있는 컨테이너를 사용할 수 있습니다. cluster-admin 으로 권한 있는 컨테이너의 사용은 Red Hat Enterprise Agreement 부록 4 (Online Subscription Services)의 책임 및 제외 노트의 적용을 받습니다.
3.3.7.3. 고객 관리자
일반 사용자 외에도 AWS의 Red Hat OpenShift Service는 AWS별 그룹인 dedicated-admin 그룹의 Red Hat OpenShift Service에 액세스할 수 있습니다. dedicated-admin 그룹의 멤버인 클러스터의 모든 사용자:
- 클러스터의 모든 고객 생성 프로젝트에 대한 관리자 액세스 권한이 있어야 합니다.
- 클러스터의 리소스 할당량 및 제한을 관리할 수 있습니다.
-
NetworkPolicy오브젝트를 추가하고 관리할 수 있습니다. - 스케줄러 정보를 포함하여 클러스터의 특정 노드 및 PV에 대한 정보를 볼 수 있습니다.
-
클러스터에서 예약된
dedicated-admin프로젝트에 액세스할 수 있으므로 승격된 권한이 있는 서비스 계정을 생성할 수 있으며 클러스터에서 프로젝트의 기본 제한 및 할당량을 업데이트할 수도 있습니다.
3.3.7.4. 클러스터 관리 역할
AWS의 Red Hat OpenShift Service 관리자는 조직의 클러스터의 cluster-admin 역할에 대한 기본 액세스 권한이 있습니다. cluster-admin 역할로 계정에 로그인되어 있는 동안 사용자에게 권한 있는 보안 컨텍스트를 실행할 수 있는 권한이 향상되었습니다.
3.3.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
3.3.7.6. 규정 준수
최신 규정 준수 정보는 ROSA의 프로세스 및 보안 이해를 참조하십시오.
3.3.7.7. 네트워크 보안
AWS의 Red Hat OpenShift Service를 통해 AWS는 모든 로드 밸런서에 대해 AWS Shield라는 표준 CloudEvent 보호 기능을 제공합니다. 이는 AWS의 Red Hat OpenShift Service에 사용되는 모든 공용 로드 밸런서에 대한 가장 일반적으로 사용되는 로드 밸런서에 대한 가장 일반적으로 사용되는 레벨 3 및 4 공격에 대해 95%의 보호를 제공합니다. 응답을 수신하기 위해 haproxy 라우터로 들어오는 HTTP 요청에 대해 10초의 시간 초과가 추가되거나 추가 보호를 제공하기 위해 연결이 닫힙니다.
3.3.7.8. etcd 암호화
AWS의 Red Hat OpenShift Service에서 컨트롤 플레인 스토리지는 기본적으로 암호화되며 여기에는 etcd 볼륨의 암호화가 포함됩니다. 이 스토리지 수준 암호화는 클라우드 공급자의 스토리지 계층을 통해 제공됩니다.
etcd 암호화를 활성화하여 etcd의 키 값을 암호화하지만 키를 암호화할 수도 없습니다. etcd 암호화를 활성화하면 다음 Kubernetes API 서버 및 OpenShift API 서버 리소스가 암호화됩니다.
- 보안
- 구성 맵
- 라우트
- OAuth 액세스 토큰
- OAuth 승인 토큰
etcd 암호화 기능은 기본적으로 활성화되어 있지 않으며 클러스터 설치 시에만 활성화할 수 있습니다. etcd 암호화가 활성화된 상태에서도 etcd 키 값은 컨트롤 플레인 노드 또는 cluster-admin 권한에 액세스할 수 있는 모든 사용자가 액세스할 수 있습니다.
etcd의 키 값에 etcd 암호화를 활성화하면 약 20%의 성능 오버헤드가 발생합니다. 오버헤드는 etcd 볼륨을 암호화하는 기본 컨트롤 플레인 스토리지 암호화 외에도 이 두 번째 암호화 계층이 도입된 결과입니다. 특히 사용 사례에 필요한 경우에만 etcd 암호화를 활성화하는 것이 좋습니다.
추가 리소스
- 최신 규정 준수 정보는 ROSA의 프로세스 및 보안 이해를 참조하십시오.
- ROSA 라이프 사이클보기
