2장. 정책 및 서비스 정의

고객은 OSD(OpenShift Dedicated)의 연간 서브스크립션을 구입하거나 클라우드 마켓플레이스를 통해 온디맨드로 사용할 수 있는 옵션이 있습니다. 고객은 고객 클라우드 서브스크립션(CCS)이라는 자체 클라우드 인프라 계정을 가져오거나 Red Hat이 소유한 클라우드 공급자 계정에 배포할 수 있습니다. 아래 표에서는 청구 및 지원되는 배포 옵션에 대한 추가 정보를 제공합니다.

다음을 포함하여 OpenShift Dedicated 클러스터에 대한 추가 리소스를 구입할 수 있습니다.

고객은 필요한 서브스크립션을 이미 구매한 경우 OpenShift Cluster Manager 에서 클러스터를 생성, 확장 및 삭제할 수 있습니다.

Red Hat OpenShift Cluster Manager에서 사용 가능한 작업은 클러스터 내에서 직접 수행할 수 없습니다. 이로 인해 모든 작업이 자동으로 되돌아가는 것을 포함하여 불리한 영향을 미칠 수 있습니다.

OpenShift Dedicated는 다음 클라우드 공급자에서 OpenShift Container Platform 클러스터를 관리형 서비스로 제공합니다.

단일 가용성 영역 클러스터에는 단일 가용성 영역에 배포된 고객 클라우드 서브스크립션(CCS) 클러스터에 최소 2개의 작업자 노드가 필요합니다. 표준 클러스터에는 최소 4개의 작업자 노드가 필요합니다. 이 4개의 작업자 노드는 기본 서브스크립션에 포함되어 있습니다.

여러 가용성 영역 클러스터에는 각각 3개의 가용성 영역에 배포된 고객 클라우드 서브스크립션(CCS) 클러스터에 최소 3개의 작업자 노드가 필요합니다. 표준 클러스터에는 최소 9개의 작업자 노드가 필요합니다. 이 9개의 작업자 노드는 기본 서브스크립션에 포함되어 있으며 적절한 노드 배포를 유지하려면 추가 노드를 3의 다중에서 구입해야 합니다.

컨트롤 플레인 및 인프라 노드도 Red Hat에서 제공합니다. etcd 및 API 관련 워크로드를 처리하는 컨트롤 플레인 노드가 3개 이상 있습니다. 메트릭, 라우팅, 웹 콘솔 및 기타 워크로드를 처리하는 인프라 노드가 두 개 이상 있습니다. 컨트롤 플레인 및 인프라 노드에서 워크로드를 실행하지 않아야 합니다. 실행하려는 워크로드는 작업자 노드에 배포해야 합니다. 작업자 노드에 배포해야 하는 Red Hat 워크로드에 대한 자세한 내용은 아래 Red Hat Operator 지원 섹션을 참조하십시오.

OpenShift Dedicated는 AWS에서 다음과 같은 작업자 노드 인스턴스 유형 및 크기를 제공합니다.

OpenShift Dedicated는 AWS에서 다음과 같은 작업자 노드 유형 및 크기를 제공합니다.

OpenShift Dedicated는 다른 클라우드 인스턴스 유형과 동일한 공통 CPU 및 메모리 용량을 가지도록 선택한 Google Cloud에서 다음과 같은 작업자 노드 유형과 크기를 제공합니다.

다음 리전은 OpenShift Container Platform 4에서 지원되며 OpenShift Dedicated에서 지원됩니다.

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

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

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

클러스터가 제한된 지원 상태로 전환되거나 추가 지원이 필요한 특정 작업에 대한 질문이 있는 경우 지원 티켓을 엽니다.

OpenShift Dedicated에는 Red Hat 고객 포털을 사용하여 액세스할 수 있는 Red Hat 프리미엄 지원이 포함되어 있습니다.

OpenShift Dedicated에 대한 지원 관련 사항에 대한 자세한 내용은 지원 범위 페이지를 참조하십시오.

지원 응답 시간은 OpenShift Dedicated SLA 를 참조하십시오.

통합이 활성화된 경우 AWS의 Amazon Cloud Logging 또는 GCP의 Google Cloud Logging을 통해 클러스터 감사 로그를 사용할 수 있습니다. 통합이 활성화되지 않은 경우 지원 케이스를 열어 감사 로그를 요청할 수 있습니다. 감사 로그 요청은 21 일을 초과하지 않는 날짜 및 시간 범위를 지정해야 합니다. 감사 로그를 요청할 때 고객은 감사 로그의 크기가 하루에 최대GB임을 알고 있어야 합니다.

STDOUT 으로 전송된 애플리케이션 로그는 설치된 경우 클러스터 로깅 스택을 통해 AWS의 Amazon Cloud Logging 또는 Google Cloud Logging(Google Cloud Logging)으로 전달됩니다.

OpenShift Dedicated 클러스터에는 CPU, 메모리 및 네트워크 기반 메트릭을 포함한 클러스터 모니터링을 위한 통합된 Prometheus/Grafana 스택이 제공됩니다. 웹 콘솔을 통해 액세스할 수 있으며 Grafana 대시보드를 통해 클러스터 수준 상태 및 용량/사용을 볼 수도 있습니다. 이러한 메트릭을 사용하면 OpenShift Dedicated 사용자가 제공하는 CPU 또는 메모리 메트릭을 기반으로 수평 Pod 자동 스케일링을 수행할 수 있습니다.

클러스터 알림은 클러스터의 상태, 상태 또는 성능에 대한 메시지입니다.

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

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

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

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

사용자 정의 도메인 및 하위 도메인은 플랫폼 서비스 경로(예: API 또는 웹 콘솔 경로 또는 기본 애플리케이션 경로)에는 사용할 수 없습니다.

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

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

OpenShift Dedicated는 최대 5개의 로드 밸런서를 사용합니다.

표준 OpenShift Dedicated 클러스터의 경우 네트워크 사용량은 인바운드, VPC 피어링, VPN 및 AZ 트래픽 간의 데이터 전송을 기반으로 측정됩니다. 표준 OpenShift Dedicated 기본 클러스터에서 12TB의 네트워크 I/O가 제공됩니다. 추가 네트워크 I/O는 12TB 단위로 구매할 수 있습니다. CCS OpenShift Dedicated 클러스터의 경우 네트워크 사용량은 모니터링되지 않으며 클라우드 공급자가 직접 청구합니다.

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

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

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

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

OpenShift Dedicated를 사용하면 여러 클라우드 공급자 관리형 기술을 통해 프라이빗 네트워크 연결을 구성할 수 있습니다.

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

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

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

컨트롤 플레인 노드는 encrypted-at-rest-EBS 스토리지를 사용합니다.

PV(영구 볼륨)에 사용되는 EBS 볼륨은 기본적으로 암호화된 볼륨입니다.

PV(영구 볼륨)는 AWS EBS 및 Google Cloud 영구 디스크 블록 스토리지에서 지원합니다. 이 블록 스토리지는 RWO(ReadWriteOnce) 액세스 모드를 사용합니다. 표준 OpenShift Dedicated 기본 클러스터에서 PV에 100GB의 블록 스토리지가 제공되며 애플리케이션 요청에 따라 동적으로 프로비저닝 및 재활용됩니다. 추가 영구 스토리지는 500GB 단위로 구매할 수 있습니다.

PV는 한 번에 단일 노드에만 연결할 수 있으며 프로비저닝된 가용성 영역과 관련이 있지만 가용성 영역의 모든 노드에 연결할 수 있습니다.

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

AWS CSI 드라이버는 AWS에서 OpenShift Dedicated에 RWX 지원을 제공하는 데 사용할 수 있습니다. 커뮤니티 Operator가 설정을 단순화하기 위해 제공됩니다. 자세한 내용은 AWS Dedicated 및 Red Hat OpenShift Service용 AWS EFS 설정을 참조하십시오.

애플리케이션 및 애플리케이션 데이터 백업은 OpenShift Dedicated 서비스의 일부가 아닙니다. 각 OpenShift Dedicated 클러스터의 모든 Kubernetes 오브젝트는 클러스터가 작동하지 않는 경우 신속하게 복구할 수 있도록 백업됩니다.

백업은 클러스터와 동일한 계정에 있는 보안 개체 스토리지(Multi-AZ) 버킷에 저장됩니다. Red Hat Enterprise Linux CoreOS는 OpenShift Container Platform 클러스터에서 완전히 관리되고 노드의 루트 볼륨에 저장해서는 안되므로 노드 루트 볼륨이 백업되지 않습니다.

다음 표에서는 백업 빈도를 보여줍니다.

노드 자동 스케일링은 OpenShift Dedicated에서 사용할 수 있습니다. 클러스터에서 노드 자동 스케일링에 대한 자세한 내용은 클러스터에서 노드 자동 스케일링 정보를 참조하십시오.

고객은 OpenShift Dedicated에서 DaemonSet을 생성하고 실행할 수 있습니다. DaemonSets를 작업자 노드에서만 실행하도록 제한하려면 다음 nodeSelector를 사용합니다.

...
spec:
  nodeSelector:
    role: worker
...

여러 가용성 영역 클러스터에서 제어 노드는 가용성 영역에 분산되어 있으며 각 가용성 영역에는 세 개 이상의 작업자 노드가 필요합니다.

사용자 정의 노드 레이블은 노드 생성 중에 Red Hat에서 생성하며 현재 OpenShift Dedicated 클러스터에서 변경할 수 없습니다.

OpenShift Dedicated는 서비스로 실행되며 최신 OpenShift Container Platform 버전으로 최신 상태로 유지됩니다.

업그레이드 정책 및 절차에 대한 자세한 내용은 OpenShift Dedicated 라이프 사이클 을 참조하십시오.

현재 OpenShift Dedicated에서는 Windows 컨테이너를 사용할 수 없습니다.

OpenShift Dedicated는 OpenShift 4에서 실행되며 사용 가능한 유일한 컨테이너 엔진으로 CRI-O 를 사용합니다.

OpenShift Dedicated는 OpenShift 4에서 실행되며 모든 컨트롤 플레인 및 작업자 노드의 운영 체제로 Red Hat Enterprise Linux CoreOS를 사용합니다.

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

OperatorHub 마켓플레이스에 나열된 모든 Operator를 설치할 수 있어야 합니다. Red Hat Operator를 포함하여 OperatorHub에서 설치한 Operator는 OpenShift Dedicated 서비스의 일부로 SRE를 관리하지 않습니다. 지정된 Operator의 지원 가능성에 대한 자세한 내용은 Red Hat 고객 포털 을 참조하십시오.

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

권한 있는 컨테이너는 OpenShift Dedicated에서 기본적으로 사용할 수 없습니다. anyuid 및 nonroot 보안 컨텍스트 제약 조건은 dedicated-admins 그룹의 멤버에서 사용할 수 있으며 많은 사용 사례를 처리해야 합니다. 권한 있는 컨테이너는 cluster-admin 사용자만 사용할 수 있습니다.

OpenShift Dedicated는 일반 사용자 외에도 dedicated-admin 이라는 OpenShift Dedicated 전용 그룹에 대한 액세스를 제공합니다. dedicated-admin 그룹의 멤버인 클러스터의 모든 사용자:

CCO(Customer Cloud Subscription)를 사용하는 OpenShift Dedicated의 관리자는 cluster-admin 역할에 액세스할 수 있습니다. cluster-admin 역할을 사용하여 계정에 로그인하는 동안 클러스터를 제어하고 구성할 수 있는 무제한 액세스 권한이 대부분 있습니다. 클러스터의 불안정을 방지하기 위해 Webhook로 차단되거나 OpenShift Cluster Manager에서 관리되기 때문에 클러스터 내 변경 사항을 덮어쓰는 몇 가지 구성이 있습니다.

기본적으로 모든 사용자는 프로젝트를 생성, 업데이트 및 삭제할 수 있습니다. 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

OpenShift Dedicated는 보안 및 제어를 위한 일반적인 업계 모범 사례를 따릅니다. 인증은 다음 표에 설명되어 있습니다.

각 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 공격으로부터 보호됩니다.

OpenShift Dedicated에서 컨트롤 플레인 스토리지는 기본적으로 암호화되어 etcd 볼륨의 암호화가 포함됩니다. 이 스토리지 수준 암호화는 클라우드 공급자의 스토리지 계층을 통해 제공됩니다.

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

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