2.3. Red Hat OpenShift Service on AWS 클래식 아키텍처 서비스 정의

AWS 클래식 아키텍처의 Red Hat OpenShift Service는 AWS(Amazon Web Services) 계정에 직접 청구됩니다. ROSA 가격은 더 큰 할인을 위해 연간 약정 또는 3년의 약정과 함께 소비를 기반으로 합니다. ROSA의 총 비용은 두 가지 요소로 구성됩니다.

자세한 내용은 AWS 웹 사이트의 AWS 클래식 아키텍처 가격 책정 페이지를 참조하십시오.

고객은 다음을 포함하여 클러스터를 셀프 서비스할 수 있습니다.

ROSA(AWS 클래식 아키텍처) CLI, rosa 에서 Red Hat OpenShift Service를 사용하여 이러한 셀프 서비스 작업을 수행할 수 있습니다.

단일 가용성 영역 클러스터에는 최소 3개의 컨트롤 플레인 노드, 2개의 인프라 노드 및 단일 가용성 영역에 배포된 작업자 노드 2개가 필요합니다.

여러 가용성 영역 클러스터에는 최소 3개의 컨트롤 플레인 노드, 3개의 인프라 노드 및 3개의 작업자 노드가 필요합니다.

워크로드를 배포하고 관리할 때 다음 제한 사항을 고려하십시오.

AWS 클래식 아키텍처 구성 요소의 Red Hat OpenShift Service가 영향을 받는 경우 Red Hat은 컨트롤 플레인 또는 인프라 노드의 크기를 지정하고 크기를 조정할 수 있습니다.

컨트롤 플레인 및 인프라 노드는 Red Hat에서 배포 및 관리합니다. 이러한 노드는 리소스 사용량에 따라 자동으로 크기가 조정됩니다. 클러스터 요구 사항을 충족하기 위해 이러한 노드의 크기를 조정해야 하는 경우 지원 케이스를 작성하십시오.

작업자 노드에 배포해야 하는 Red Hat 워크로드에 대한 자세한 내용은 다음 Red Hat Operator 지원 섹션을 참조하십시오.

다음 AWS 리전은 현재 Red Hat OpenShift 4에서 사용할 수 있으며 AWS 클래식 아키텍처의 Red Hat OpenShift Service에서 지원됩니다.

클러스터는 가용성 영역이 3개 이상인 리전에만 배포할 수 있습니다. 자세한 내용은 AWS 문서의 리전 및 가용 영역 섹션을 참조하십시오.

AWS 클래식 아키텍처 클러스터의 새로운 Red Hat OpenShift Service는 단일 리전의 설치 관리자 또는 기존 VPC(Virtual Private Cloud) 내에 설치되며, 옵션은 단일 가용성 영역(Single-AZ)에 배포하거나 여러 가용 영역(Multi-AZ)에 배포할 수 있습니다. 이를 통해 클러스터 수준 네트워크 및 리소스 격리를 제공하고 VPN 연결 및 VPC 피어링과 같은 클라우드 공급자 VPC 설정을 활성화합니다. PV(영구 볼륨)는 Amazon EBS(Elastic Block Storage)에서 지원하며, 프로비저닝된 가용성 영역에 고유합니다. PVC(영구 볼륨 클레임)는 스케줄링할 수 없는 Pod를 방지하기 위해 관련 Pod 리소스가 특정 가용성 영역에 할당될 때까지 볼륨에 바인딩되지 않습니다. 가용성 영역별 리소스는 동일한 가용성 영역의 리소스에서만 사용할 수 있습니다.

AWS 클래식 아키텍처의 Red Hat OpenShift Service는 고객이 대기 시간에 민감한 애플리케이션 워크로드를 배치할 수 있는 metropolis-centralized 가용성 영역인 AWS Local Zones의 사용을 지원합니다. 로컬 영역은 자체 인터넷 연결이 있는 AWS 리전의 확장입니다. AWS 로컬 영역에 대한 자세한 내용은 AWS 문서 로컬 영역 작동 방식을 참조하십시오.

서비스 자체에 대한 SLA는 Red Hat Enterprise Agreement 부록 4(Online Subscription Services)의 부록 4 에 정의되어 있습니다.

클러스터가 제한된 지원 상태로 전환되면 Red Hat은 더 이상 클러스터를 사전 모니터링하지 않으며 SLA는 더 이상 적용되지 않으며 SLA에 대해 요청된 크레딧이 거부됩니다. 더 이상 제품 지원이 없다는 의미는 아닙니다. 위반 요소를 수정하는 경우 클러스터가 완전히 지원되는 상태로 돌아갈 수 있습니다. 그러나 다른 경우에는 클러스터를 삭제하고 다시 생성해야 할 수 있습니다.

클러스터는 다음 시나리오를 포함하여 여러 가지 이유로 제한된 지원 상태로 이동할 수 있습니다.

클러스터가 제한된 지원 상태로 이동하거나 추가 지원이 필요할 수 있는 특정 작업에 대해 질문이 있는 경우 지원 티켓을 여십시오.

AWS 클래식 아키텍처의 Red Hat OpenShift Service에는 Red Hat 고객 포털을 사용하여 액세스할 수 있는 Red Hat Premium 지원이 포함되어 있습니다.

지원 응답 시간은 Red Hat 제품 지원 약관 을 참조하십시오.

AWS 지원은 고객의 AWS와의 기존 지원 계약이 적용됩니다.

통합이 활성화된 경우 AWS CloudMonitor를 통해 클러스터 감사 로그를 사용할 수 있습니다. 통합이 활성화되지 않은 경우 지원 케이스를 열어 감사 로그를 요청할 수 있습니다.

STDOUT 으로 전송된 애플리케이션 로그는 Fluentd에서 수집하고 설치된 경우 클러스터 로깅 스택을 통해 AWS CloudMonitor로 전달됩니다.

AWS 클래식 아키텍처 클러스터의 Red Hat OpenShift Service에는 CPU, 메모리 및 네트워크 기반 메트릭을 포함한 클러스터 모니터링을 위한 통합 Prometheus 스택이 제공됩니다. 웹 콘솔을 통해 액세스할 수 있습니다. 이러한 메트릭을 사용하면 ROSA 사용자가 제공하는 CPU 또는 메모리 메트릭을 기반으로 수평 Pod 자동 스케일링을 수행할 수 있습니다.

클러스터 알림(서비스 로그라고도 함)은 클러스터의 상태, 상태 또는 성능에 대한 메시지입니다.

클러스터 알림은 Red Hat site Reliability Engineering(SRE)이 관리형 클러스터의 상태에 대해 귀하와 통신하는 기본 방법입니다. Red Hat SRE는 클러스터 알림을 사용하여 클러스터 문제를 해결하거나 방지하기 위해 작업을 수행하도록 요청할 수도 있습니다.

클러스터 소유자 및 관리자는 클러스터가 정상 상태로 유지되고 지원되는지 확인하기 위해 클러스터 알림을 정기적으로 검토하고 조치를 취해야 합니다.

클러스터의 클러스터 기록 탭에서 Red Hat Hybrid Cloud Console에서 클러스터 알림을 볼 수 있습니다. 기본적으로 클러스터 소유자만 이메일로 클러스터 알림을 수신합니다. 다른 사용자가 클러스터 알림 이메일을 수신해야 하는 경우 각 사용자를 클러스터에 대한 알림 연락처로 추가합니다.

경로에 사용자 지정 호스트 이름을 사용하려면 정식 이름(CNAME) 레코드를 생성하여 DNS 공급자를 업데이트해야 합니다. CNAME 레코드는 OpenShift 정식 라우터 호스트 이름을 사용자 지정 도메인에 매핑해야 합니다. OpenShift 표준 라우터 호스트 이름은 경로를 생성한 후 경로 세부 정보 페이지에 표시됩니다. 또는 지정된 호스트 이름의 모든 하위 도메인을 클러스터의 라우터에 라우팅하기 위해 와일드카드 CNAME 레코드를 한 번 생성할 수 있습니다.

ROSA에는 클러스터의 내부 및 외부 서비스에 모두 필요한 TLS 보안 인증서가 포함되어 있습니다. 외부 경로의 경우 각 클러스터에 제공 및 설치된 두 개의 별도의 TLS 와일드카드 인증서가 있습니다. 하나는 웹 콘솔과 경로 기본 호스트 이름용이고 다른 하나는 API 끝점에 사용됩니다. Let's Encrypt는 인증서에 사용되는 인증 기관입니다. 내부 API 끝점 과 같은 클러스터 내 경로는 클러스터의 기본 제공 인증 기관에서 서명한 TLS 인증서를 사용하며 TLS 인증서를 신뢰하기 위해 모든 Pod에서 CA 번들을 사용할 수 있어야 합니다.

ROSA는 이미지 레지스트리에서 이미지를 가져올 때 빌드에서 신뢰하는 사용자 정의 인증 기관 사용을 지원합니다.

AWS 클래식 아키텍처의 Red Hat OpenShift Service는 최대 5개의 로드 밸런서를 사용합니다.

프로젝트 관리자는 IP 허용 목록을 통한 수신 제어를 포함하여 다양한 목적으로 경로 주석을 추가할 수 있습니다.

ovs-networkpolicy 플러그인을 활용하는 NetworkPolicy 오브젝트를 사용하여 Ingress 정책을 변경할 수도 있습니다. 이를 통해 동일한 클러스터와 동일한 네임스페이스에 있는 Pod를 포함하여 Pod 수준까지 수신 네트워크 정책을 완전히 제어할 수 있습니다.

모든 클러스터 인그레스 트래픽은 정의된 로드 밸런서를 통과합니다. 모든 노드에 대한 직접 액세스는 클라우드 구성에 의해 차단됩니다.

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.]+'"

$ 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.]+'"

Red Hat OpenShift Service on AWS 클래식 아키텍처를 사용하면 다음과 같은 AWS 관리 기술을 통해 프라이빗 네트워크 연결을 구성할 수 있습니다.

프라이빗 클라우드 네트워크 구성이 있는 ROSA 클러스터의 경우 고객은 명시적으로 제공된 도메인에 대해 쿼리해야 하는 프라이빗 연결에서 사용할 수 있는 내부 DNS 서버를 지정할 수 있습니다.

ROSA 클러스터를 기존 VPC(Virtual Private Cloud)에 배포하거나 클러스터에 새로 추가된 서브넷을 사용하여 추가 머신 풀을 생성할 때 네트워크 확인 검사가 자동으로 실행됩니다. 검사를 통해 네트워크 구성을 확인하고 오류를 강조 표시하여 배포 전에 구성 문제를 해결할 수 있습니다.

네트워크 확인 검사를 수동으로 실행하여 기존 클러스터의 구성을 확인할 수도 있습니다.

컨트롤 플레인, 인프라 및 작업자 노드는 encrypted-at-rest Amazon EBS(Elastic Block Store) 스토리지를 사용합니다.

PV에 사용되는 EBS 볼륨은 기본적으로 암호화되어 있습니다.

PV(영구 볼륨)는 Amazon EBS(Elastic Block Store)가 Read-Write-Once인 Amazon EBS에서 지원합니다.

PV는 한 번에 단일 노드에만 연결할 수 있으며 프로비저닝된 가용성 영역에 고유합니다. 그러나 PV는 가용성 영역의 모든 노드에 연결할 수 있습니다.

각 클라우드 공급자에는 단일 노드에 연결할 수 있는 PV 수에 대한 자체 제한이 있습니다. 자세한 내용은 AWS 인스턴스 유형 제한을 참조하십시오.

AWS CSI 드라이버는 AWS 클래식 아키텍처에서 Red Hat OpenShift Service에 대한 RWX 지원을 제공하는 데 사용할 수 있습니다. 설정을 단순화하기 위해 커뮤니티 Operator가 제공됩니다. 자세한 내용은 Amazon Elastic File Storage Setup for Red Hat OpenShift Service on AWS 에서 참조하십시오.

노드 자동 스케일링은 AWS 클래식 아키텍처의 Red Hat OpenShift Service에서 사용할 수 있습니다. 클러스터의 머신 수를 자동으로 확장하도록 자동 스케일러 옵션을 구성할 수 있습니다.

고객은 AWS 클래식 아키텍처에서 Red Hat OpenShift Service에서 데몬 세트를 생성하고 실행할 수 있습니다. 데몬 세트를 작업자 노드에서만 실행되도록 제한하려면 다음 nodeSelector 를 사용합니다.

spec:
  nodeSelector:
    role: worker

spec:
  nodeSelector:
    role: worker

여러 가용성 영역 클러스터에서 컨트롤 플레인 노드는 가용성 영역에 분산되며 각 가용성 영역에 하나 이상의 작업자 노드가 필요합니다.

사용자 지정 노드 레이블은 노드 생성 중에 Red Hat에서 생성하며 현재 AWS 클래식 아키텍처 클러스터의 Red Hat OpenShift Service에서 변경할 수 없습니다. 그러나 새 머신 풀을 생성할 때 사용자 지정 레이블이 지원됩니다.

작업자 노드는 수명이 보장되지 않으며 OpenShift의 정상적인 작동 및 관리의 일부로 언제든지 교체될 수 있습니다.

다음과 같은 상황에서 작업자 노드를 교체할 수 있습니다.

Kubernetes 기반 시스템에서 실행되는 모든 컨테이너화된 워크로드의 경우 노드 교체에 탄력적으로 애플리케이션을 구성하는 것이 좋습니다.

Red Hat은 ROSA 클러스터에 대해 오브젝트 수준 백업 솔루션을 권장합니다. OADP(OpenShift API for Data Protection)는 OpenShift에 포함되어 있지만 기본적으로 활성화되어 있지 않습니다. 고객은 오브젝트 수준 백업 및 복원 기능을 달성하도록 클러스터에서 OADP를 구성할 수 있습니다.

Red Hat은 고객 애플리케이션 또는 애플리케이션 데이터를 백업하지 않습니다. 고객은 애플리케이션 및 데이터에 대한 전적인 책임이 있으며 자체 백업 및 복원 기능을 배치해야 합니다.

AWS 클래식 아키텍처의 Red Hat OpenShift Service는 서비스로 실행되며 최신 OpenShift Container Platform 버전으로 최신 상태로 유지됩니다. 최신 버전으로의 업그레이드 일정을 사용할 수 있습니다.

ROSA CLI, rosa 또는 OpenShift Cluster Manager를 사용하여 업그레이드를 예약할 수 있습니다.

업그레이드 정책 및 절차에 대한 자세한 내용은 AWS 클래식 아키텍처 라이프 사이클의 Red Hat OpenShift Service 를 참조하십시오.

현재 Windows Containers 용 Red Hat OpenShift 지원은 AWS 클래식 아키텍처의 Red Hat OpenShift Service에서 제공되지 않습니다.

AWS 클래식 아키텍처의 Red Hat OpenShift Service는 OpenShift 4에서 실행되며 사용 가능한 유일한 컨테이너 엔진으로 CRI-O 를 사용합니다.

AWS 클래식 아키텍처의 Red Hat OpenShift Service는 OpenShift 4에서 실행되며 모든 클러스터 노드의 운영 체제로 RHCOS(Red Hat CoreOS)를 사용합니다.

Red Hat 워크로드는 일반적으로 Operator Hub를 통해 제공되는 Red Hat 제공 Operator를 참조합니다. Red Hat 워크로드는 Red Hat SRE 팀에서 관리하지 않으며 작업자 노드에 배포해야 합니다. 이러한 Operator에는 추가 Red Hat 서브스크립션이 필요할 수 있으며 추가 클라우드 인프라 비용이 발생할 수 있습니다. Red Hat 제공 Operator의 예는 다음과 같습니다.

소프트웨어 카탈로그 마켓플레이스에 나열된 모든 Operator를 설치할 수 있어야 합니다. 이러한 Operator는 고객 워크로드로 간주되며 Red Hat SRE에서 모니터링하거나 관리하지 않습니다. Red Hat에서 작성한 Operator는 Red Hat에서 지원합니다.

클러스터의 인증은 OpenShift Cluster Manager 또는 클러스터 생성 프로세스를 사용하거나 ROSA CLI인 rosa 를 사용하여 구성할 수 있습니다. ROSA는 ID 공급자가 아니며 클러스터에 대한 모든 액세스는 고객이 통합 솔루션의 일부로 관리해야 합니다. 동시에 프로비저닝된 여러 ID 공급자 사용이 지원됩니다. 지원되는 ID 공급자는 다음과 같습니다.

cluster-admin 역할의 사용자가 권한 있는 컨테이너를 사용할 수 있습니다. cluster-admin 으로 권한 있는 컨테이너 사용은 Red Hat Enterprise Agreement 부록 4 (Online Subscription Services)의 책임이 적용됩니다.

일반 사용자 외에도 AWS 클래식 아키텍처의 Red Hat OpenShift Service는 dedicated-admin 이라는 ROSA별 그룹에 액세스할 수 있습니다. dedicated-admin 그룹의 멤버인 클러스터의 모든 사용자:

AWS 클래식 아키텍처에서 Red Hat OpenShift Service의 관리자는 조직 클러스터의 cluster-admin 역할에 대한 기본 액세스 권한을 갖습니다. cluster-admin 역할을 사용하여 계정에 로그인하는 동안 사용자는 권한 있는 보안 컨텍스트를 실행할 수 있는 권한이 증가했습니다.

기본적으로 모든 사용자는 프로젝트를 생성, 업데이트 및 삭제할 수 있습니다. dedicated-admin 그룹의 멤버가 인증된 사용자로부터 self-provisioner 역할을 제거하는 경우 이를 제한할 수 있습니다.

oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth

$ 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

$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth

최신 규정 준수 정보는 ROSA의 프로세스 및 보안 이해 의 규정 준수 표를 참조하십시오.

AWS 클래식 아키텍처의 Red Hat OpenShift Service를 사용하면 AWS Shield라는 모든 로드 밸런서에서 표준 DDoS 보호 기능을 제공합니다. 이를 통해 ROSA에 사용되는 모든 공개 대립 로드 밸런서에서 가장 일반적으로 사용되는 레벨 3 및 4 공격에 대해 95% 보호 기능을 제공합니다. haproxy 라우터로 들어오는 HTTP 요청에 대해 10초의 시간 초과가 추가되어 응답을 수신하거나 추가 보호를 제공하기 위해 연결이 닫힙니다.

AWS 클래식 아키텍처의 Red Hat OpenShift Service에서 컨트롤 플레인 스토리지는 etcd 볼륨 암호화를 포함하여 기본적으로 암호화됩니다. 이 스토리지 수준 암호화는 클라우드 공급자의 스토리지 계층을 통해 제공됩니다.

etcd의 키 값을 암호화하지만 키는 암호화하지 않는 etcd 암호화를 활성화할 수도 있습니다. etcd 암호화를 활성화하면 다음 Kubernetes API 서버 및 OpenShift API 서버 리소스가 암호화됩니다.

etcd 암호화 기능은 기본적으로 활성화되어 있지 않으며 클러스터 설치 시에만 활성화할 수 있습니다. etcd 암호화가 활성화된 경우에도 컨트롤 플레인 노드 또는 cluster-admin 권한에 액세스할 수 있는 모든 사용자가 etcd 키 값에 액세스할 수 있습니다.