OpenShift Dedicated 소개

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

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

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

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

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

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

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

컨트롤 플레인 및 인프라 노드는 Red Hat에서 배포 및 관리합니다. etcd 및 API 관련 워크로드를 처리하는 컨트롤 플레인 노드가 3개 이상 있습니다. 메트릭, 라우팅, 웹 콘솔 및 기타 워크로드를 처리하는 인프라 노드가 2개 이상 있습니다. 컨트롤 플레인 및 인프라 노드에서 워크로드를 실행하지 않아야 합니다. 실행하려는 모든 워크로드는 작업자 노드에 배포해야 합니다.

작업자 노드에 배포해야 하는 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)이 관리형 클러스터의 상태에 대해 귀하와 통신하는 기본 방법입니다. Red Hat 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개의 로드 밸런서를 사용합니다.

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

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

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

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

EgressNetworkPolicy 오브젝트를 통한 Pod 송신 트래픽 제어를 사용하여 OpenShift Dedicated에서 아웃바운드 트래픽을 방지하거나 제한할 수 있습니다.

컨트롤 플레인 및 인프라 노드의 공용 아웃 바운드 트래픽이 필요하며 클러스터 이미지 보안 및 클러스터 모니터링을 유지 관리하는 데 필요합니다. 이를 위해서는 0.0.0.0/0 경로가 인터넷 게이트웨이에만 속해야 하며 이 범위를 개인 연결을 통해 라우팅할 수 없습니다.

OpenShift Dedicated 클러스터는 NAT 게이트웨이를 사용하여 클러스터를 나가는 모든 공용 아웃바운드 트래픽에 대한 공용 고정 IP를 제공합니다. 클러스터가 배포된 각 서브넷은 고유한 NAT 게이트웨이를 수신합니다. 여러 가용성 영역이 있는 AWS에 배포된 클러스터의 경우 클러스터 송신 트래픽에 대해 최대 3개의 고유한 고정 IP 주소가 존재할 수 있습니다. 가용성 영역 토폴로지에 관계없이 Google Cloud에 배포된 클러스터의 경우 작업자 노드 송신 트래픽에 대해 1개의 고정 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.]+'"

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

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

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

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

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

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

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

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

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

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

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

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

다음 표에서는 백업 빈도를 보여 줍니다.The following table shows the frequency of backups:

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

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

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

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

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

사용자 정의 노드 레이블은 노드 생성 중에 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 Marketplace에 나열된 모든 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에서 관리되고 클러스터 내 변경 사항을 덮어쓰기 위해 Webhook로 차단되는 몇 가지 구성이 있습니다.

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

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 권한에 액세스할 수 있는 모든 사용자가 액세스할 수 있습니다.

고객은 고객 애플리케이션 데이터의 사고 및 운영 관리 및 고객이 클러스터 네트워크 또는 가상 네트워크에 대해 구성한 사용자 지정 네트워킹을 담당합니다.

Red Hat은 고객이 제어할 클러스터 인프라 및 서비스를 변경하고 컨트롤 플레인 노드, 인프라 노드 및 서비스 및 작업자 노드의 버전을 유지 관리해야 합니다. 고객은 인프라 변경 요청을 시작하고 클러스터에서 선택적 서비스 및 네트워킹 구성을 설치 및 유지 관리하고 고객 데이터 및 고객 애플리케이션에 대한 모든 변경 사항을 담당합니다.

액세스 및 ID 권한 부여 매트릭스에는 클러스터, 애플리케이션 및 인프라 리소스에 대한 권한 있는 액세스 관리 책임이 포함되어 있습니다. 여기에는 액세스 제어 메커니즘, 인증, 권한 부여 및 리소스에 대한 액세스 관리 등의 작업이 포함됩니다.

다음은 컴플라이언스와 관련된 역할 및 제어입니다.

재해 복구에는 데이터 및 구성 백업, 재해 복구 환경에 대한 데이터 및 구성 복제, 재해 이벤트 장애 조치(failover)가 포함됩니다.

클러스터 알림은 클러스터의 상태와 영향을 미치는 높은 영향을 미치는 이벤트에 대한 정보를 유지하도록 설계되었습니다.

대부분의 클러스터 알림은 자동으로 생성되고 전송되어 즉시 문제에 대한 정보 또는 클러스터 상태에 대한 중요한 변경 사항을 확인할 수 있습니다.

특정 상황에서 Red Hat 사이트 안정성 엔지니어링(SRE)은 클러스터 알림을 생성하고 전송하여 복잡한 문제에 대한 추가 컨텍스트 및 지침을 제공합니다.

영향을 받지 않는 이벤트, 위험이 낮은 보안 업데이트, 일상적인 운영 및 유지 관리 또는 Red Hat SRE가 신속하게 해결하는 일시적인 문제에 대해서는 클러스터 알림이 전송되지 않습니다.

Red Hat 서비스는 다음과 같은 경우 자동으로 알림을 보냅니다.

SRE는 다음과 같은 경우 알림을 생성하고 보냅니다.

Red Hat 사이트 안정성 엔지니어(SRE)는 모든 OpenShift Dedicated 클러스터 구성 요소, SRE 서비스 및 기본 클라우드 공급자 계정에 대해 중앙 집중식 모니터링 및 경고 시스템을 유지 관리합니다. 플랫폼 감사 로그는 중앙 집중식 SIEM(보안 정보 및 이벤트 모니터링) 시스템으로 안전하게 전달됩니다. 여기서 SRE 팀에 구성된 경고를 트리거할 수 있으며 수동 검토도 적용됩니다. 감사 로그는 1년 동안 SIEM에 보관됩니다. 클러스터가 삭제될 때 지정된 클러스터의 감사 로그는 삭제되지 않습니다.

사고는 하나 이상의 Red Hat 서비스의 성능 저하 또는 중단을 초래하는 이벤트입니다.

고객 또는 CEE(Customer Experience and Engagement) 멤버, 중앙 집중식 모니터링 및 경고 시스템에 의해 직접 또는 SRE 팀의 구성원에 의해 직접 사고가 발생할 수 있습니다.

서비스 및 고객에 미치는 영향에 따라 이 문제는 심각도 별로 분류됩니다.

Red Hat은 새로운 사고를 관리할 때 다음과 같은 일반적인 워크플로를 사용합니다.

고객이 지원 티켓에 제공되는 내용 외에 자세한 정보가 필요한 경우 다음 워크플로우를 요청할 수 있습니다.

Red Hat은 지원 케이스를 통해 발생하는 고객 사고도 지원합니다. Red Hat은 다음을 포함하되 이에 국한되지 않는 활동을 지원할 수 있습니다.

모든 OpenShift Dedicated 클러스터는 클라우드 공급자 스냅샷을 사용하여 백업됩니다. 특히 PV(영구 볼륨)에 저장된 고객 데이터는 포함되지 않습니다. 모든 스냅샷은 적절한 클라우드 공급자 스냅샷 API를 사용하여 수행되며 클러스터와 동일한 계정의 보안 오브젝트 스토리지 버킷(AWS의 S3 및 Google Cloud의 GCS)에 업로드됩니다.

클러스터 용량 평가 및 관리는 Red Hat과 고객 간에 공유되는 책임이 있습니다. Red Hat SRE는 클러스터의 모든 컨트롤 플레인 및 인프라 노드의 용량을 담당합니다.

Red Hat SRE는 업그레이드 중에 클러스터 용량을 평가하고 클러스터 알림에 대응합니다. 클러스터 업그레이드 용량의 영향은 업그레이드 테스트 프로세스의 일부로 평가되어 클러스터에 새로운 추가 기능의 영향을 받지 않도록 합니다. 클러스터 업그레이드 중에 업그레이드 프로세스 중에 총 클러스터 용량이 유지되도록 추가 작업자 노드가 추가됩니다.

SRE 직원의 용량 평가는 특정 기간 동안 사용량 임계값이 초과된 경우 클러스터의 경고에 따라 수행됩니다. 이러한 경고는 또한 고객에게 알림을 초래할 수 있습니다.

클러스터 배포, 작업자 노드 확장 또는 클러스터 삭제와 같은 셀프 서비스 기능을 사용하여 변경을 시작할 수 있습니다.

변경 내역은 OpenShift Cluster Manager 개요 탭 의 클러스터 기록 섹션에 캡처되며 사용자가 볼 수 있습니다. 변경 기록에는 다음 변경 사항의 로그가 포함되어 있지만 이에 국한되지는 않습니다.

다음 구성 요소에 대해 OpenShift Cluster Manager의 변경을 방지하여 유지 관리 제외를 구현할 수 있습니다.

Red Hat SRE(사이트 안정성 엔지니어링)는 GitOps 워크플로우 및 완전히 자동화된 CI/CD 파이프라인을 사용하여 OpenShift Dedicated의 인프라, 코드 및 구성을 관리합니다. 이러한 프로세스를 통해 Red Hat은 고객에게 부정적인 영향을 주지 않고 지속적으로 서비스 개선을 안전하게 도입할 수 있습니다.

제안된 모든 변경 사항은 체크인 시 즉시 일련의 자동화된 검증을 거칩니다. 그런 다음 자동화된 통합 테스트를 수행한 스테이징 환경에 변경 사항이 배포됩니다. 마지막으로 변경 사항이 프로덕션 환경에 배포됩니다. 각 단계는 완전히 자동화됩니다.

승인된 SRE 검토자는 각 단계에 대한 진행 사항을 승인해야 합니다. 검토자는 변경을 제안한 개인과 같을 수 없습니다. 모든 변경 사항 및 승인은 GitOps 워크플로우의 일부로 완전히 감사할 수 있습니다.

일부 변경 사항은 기능 플래그를 사용하여 지정된 클러스터 또는 고객에 대한 새 기능의 가용성을 제어하여 점진적으로 릴리스됩니다.

일반 z-stream 업그레이드의 버그 및 취약점에 대해 OpenShift Container Platform 소프트웨어 및 기본 변경 불가능한 RHCOS(Red Hat Enterprise Linux CoreOS) 운영 체제 이미지가 패치됩니다. OpenShift Container Platform 설명서에서 RHCOS 아키텍처에 대해 자세히 알아보십시오.

Red Hat은 클러스터를 자동으로 업그레이드하지 않습니다. OpenShift Cluster Manager 웹 콘솔을 사용하여 정기적으로 클러스터를 업그레이드(재개 업그레이드) 또는 한 번만(개인 업그레이드)하도록 예약할 수 있습니다. Red Hat은 클러스터가 심각한 영향을 미치는 CVE의 영향을 받는 경우에만 클러스터를 새로운 z-stream 버전으로 강제 업그레이드할 수 있습니다. OpenShift Cluster Manager 웹 콘솔에서 모든 클러스터 업그레이드 이벤트 기록을 검토할 수 있습니다. 릴리스에 대한 자세한 내용은 라이프 사이클 정책을 참조하십시오.

Red Hat은 데이터 분류 표준을 정의하고 준수하여 데이터의 민감도를 결정하고 데이터를 수집, 사용, 전송 및 처리하는 동안 데이터의 기밀성과 무결성에 대한 고유 한 위험을 강조합니다. 고객 소유 데이터는 최고 수준의 민감도 및 처리 요구 사항으로 분류됩니다.

OpenShift Dedicated는 AWS KMS(Key Management Service) 및 Google Cloud KMS와 같은 클라우드 공급자 서비스를 사용하여 영구 데이터의 암호화 키를 안전하게 관리할 수 있습니다. 이러한 키는 모든 컨트롤 플레인, 인프라 및 작업자 노드 루트 볼륨을 암호화하는 데 사용됩니다. 고객은 설치 시 루트 볼륨을 암호화하기 위해 자체 KMS 키를 지정할 수 있습니다. PV(영구 볼륨)는 키 관리에 KMS도 사용합니다. 고객은 KMS 키 ARM(Amazon Resource Name) 또는 ID를 참조하는 새 StorageClass 를 생성하여 PV를 암호화하기 위해 자체 KMS 키를 지정할 수 있습니다.

고객이 OpenShift Dedicated 클러스터를 삭제하면 컨트롤 플레인 데이터 볼륨 및 고객 애플리케이션 데이터 볼륨(예: PV)을 포함하여 모든 클러스터 데이터가 영구적으로 삭제됩니다.

Red Hat은 업계 표준 툴을 사용하여 OpenShift Dedicated의 주기적인 취약점 스캔을 수행합니다. 확인된 취약점은 심각도에 따라 타임라인에 따라 수정으로 추적됩니다. 취약점 검사 및 수정 작업은 규정 준수 인증 감사 과정에서 타사 평가자가 확인하기 위해 문서화됩니다.

Red Hat은 OpenShift Dedicated에 대해 주기적인 침투 테스트를 수행합니다. 테스트는 업계 표준 툴 및 모범 사례를 사용하여 독립적인 내부 팀에서 수행합니다.

발견된 모든 문제는 심각도에 따라 우선순위가 지정됩니다. 오픈 소스 프로젝트에 속한 모든 문제는 커뮤니티와 공유하여 문제를 해결합니다.

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

사용 가능한 하위 프로세서 목록은 Red Hat 고객 포털의 Red Hat 하위 프로세서 목록을 참조하십시오.

SRES는 프록시를 통해 OpenShift Dedicated 클러스터에 액세스합니다. 프록시는 로그인할 때 SREs에 대한 OpenShift Dedicated 클러스터에서 서비스 계정을 mints합니다. OpenShift Dedicated 클러스터에 대해 구성된 ID 공급자가 없으므로 SREs는 로컬 웹 콘솔 컨테이너를 실행하여 프록시에 액세스합니다. SRES는 클러스터 웹 콘솔에 직접 액세스하지 않습니다. SRES는 감사 가능성을 보장하기 위해 개별 사용자로 인증해야 합니다. 모든 인증 시도는 SIEM(Security Information and Event Management) 시스템에 기록됩니다.

Red Hat SRE는 OpenShift Dedicated 및 퍼블릭 클라우드 공급자 구성 요소에 액세스할 때 최소 권한 원칙을 따릅니다. 수동 SRE 액세스에는 다음 네 가지 기본 카테고리가 있습니다.

이러한 액세스 유형 각각은 구성 요소에 대한 서로 다른 수준의 액세스 권한을 갖습니다.

Red Hat 직원은 일상적인 OpenShift Dedicated 작업 과정에서 클라우드 인프라 계정에 액세스하지 않습니다. 긴급 문제 해결을 위해 Red Hat SRE는 클라우드 인프라 계정에 액세스하기 위한 잘 정의되고 감사 가능한 절차가 있습니다.

AWS에서 SREs는 AWS STS(보안 토큰 서비스)를 사용하여 BYOCAdminAccess 사용자에 대한 단기 AWS 액세스 토큰을 생성합니다. STS 토큰에 대한 액세스는 감사 기록 및 개별 사용자로 추적할 수 있습니다. BYOCAdminAccess 에는 AdministratorAccess IAM 정책이 연결되어 있습니다.

Google Cloud에서 SREs 액세스 리소스는 Red Hat SAML ID 공급자(IDP)에 대해 인증됩니다. IDP는 라이브 만료 기간이 있는 토큰을 인증합니다. 토큰 발행은 기업 Red Hat IT에서 감사할 수 있으며 개별 사용자와 다시 연결됩니다.

Red Hat CEE 팀의 구성원은 일반적으로 클러스터의 일부에 대한 읽기 전용 액세스 권한을 갖습니다. 특히 CEE는 핵심 및 제품 네임스페이스에 대한 액세스를 제한하고 고객 네임스페이스에 대한 액세스 권한이 없습니다.

Cloud Infrastructure Account는 기본 AWS 또는 Google Cloud 계정을 나타냅니다.

고객 액세스는 고객이 생성한 네임스페이스 및 고객 관리자 역할에서 RBAC를 사용하여 부여하는 권한으로 제한됩니다. 기본 인프라 또는 제품 네임스페이스에 대한 액세스는 일반적으로 cluster-admin 액세스없이 허용되지 않습니다. 고객 액세스 및 인증에 대한 자세한 내용은 설명서의 인증 이해 섹션에서 확인할 수 있습니다.

새로운 SRE 사용자 액세스에는 관리 승인이 필요합니다. 분리되거나 전송된 SRE 계정은 자동화된 프로세스를 통해 권한 있는 사용자로 제거됩니다. 또한 SRE는 권한 있는 사용자 목록의 관리 서명을 포함하여 정기적인 액세스 검토를 수행합니다.

Pod는 설계상 짧은 기간 동안 존재해야 합니다. 애플리케이션 Pod의 여러 인스턴스가 실행되는 개별 Pod 또는 컨테이너의 문제로부터 보호되도록 서비스를 적절하게 스케일링합니다. 노드 스케줄러는 복원력을 추가로 개선하기 위해 이러한 워크로드가 서로 다른 작업자 노드에 분산되어 있는지도 확인할 수 있습니다.

가능한 Pod 오류를 처리할 때 스토리지가 애플리케이션에 연결된 방식을 이해하는 것도 중요합니다. 단일 포드에 연결된 단일 영구 볼륨은 포드 확장의 모든 이점을 활용할 수 없지만 복제된 데이터베이스, 데이터베이스 서비스 또는 공유 스토리지는 가능합니다.

계획된 유지 관리 기간(예: 업그레이드) 동안 애플리케이션의 중단을 방지하려면 Pod 중단 예산을 정의하는 것이 중요합니다. 이는 Kubernetes API의 일부이며 다른 오브젝트 유형과 마찬가지로 OpenShift CLI(oc)를 사용하여 관리할 수 있습니다. 유지 관리를 위해 노드를 드레이닝하는 것과 같이 작업 중에 pod 에 대한 보안 제약 조건을 지정할 수 있습니다.

작업자 노드는 애플리케이션 pod가 포함된 가상 머신입니다. 기본적으로 OpenShift Dedicated 클러스터에는 단일 가용성 영역 클러스터에 대해 최소 4개의 작업자 노드가 있습니다. 작업자 노드 오류가 발생하는 경우 기존 노드와 관련된 문제가 해결되거나 노드가 교체될 때까지 충분한 용량이 있는 한 작업자 노드가 작동되도록 Pod가 재배치됩니다. 더 많은 작업자 노드는 단일 노드 중단을 방지할 수 있으며 노드 장애가 발생할 경우 Pod를 다시 예약할 수 있는 적절한 클러스터 용량을 보장합니다.

OpenShift Dedicated 클러스터에는 3개 이상의 컨트롤 플레인 노드와 3개의 인프라 노드가 있으며, 이 노드는 단일 영역 또는 선택한 클러스터 유형에 따라 여러 영역에서 사전 구성되어 있습니다. 즉, 컨트롤 플레인 및 인프라 노드는 작업자 노드와 동일한 복원력을 가지며 Red Hat에서 완전히 관리할 수 있는 추가 이점이 있습니다.

완전한 컨트롤 플레인 노드 중단이 발생하면 OpenShift API가 작동하지 않으며 기존 작업자 노드 pod는 영향을 받지 않습니다. 그러나 Pod 또는 노드 중단이 동시에 발생하는 경우 새 Pod 또는 노드를 추가하거나 예약하기 전에 컨트롤 플레인 노드를 복구해야 합니다.

인프라 노드에서 실행되는 모든 서비스는 Red Hat에서 고가용성으로 구성하고 인프라 노드에 분산합니다. 완전한 인프라 중단이 발생하는 경우 이러한 노드가 복구될 때까지 이러한 서비스를 사용할 수 없습니다.

퍼블릭 클라우드 공급자의 영역 오류는 작업자 노드, 블록 또는 공유 스토리지, 단일 가용성 영역과 관련된 로드 밸런서와 같은 모든 가상 구성 요소에 영향을 미칩니다. 영역 장애로부터 보호하기 위해 OpenShift Dedicated는 다중 가용 영역 클러스터라는 세 가지 가용성 영역에 분산된 클러스터에 대한 옵션을 제공합니다. 기존 상태 비저장 워크로드는 충분한 용량이 있는 경우 중단 시 영향을 받지 않는 영역에 재배포됩니다.

상태 저장 애플리케이션을 배포한 경우 스토리지는 중요한 구성 요소이며 고가용성을 고려할 때 고려해야 합니다. 단일 블록 스토리지 PV는 Pod 수준에서도 중단을 방지할 수 없습니다. 스토리지의 가용성을 유지하는 가장 좋은 방법은 복제된 스토리지 솔루션, 중단의 영향을 받지 않는 공유 스토리지 또는 클러스터와 무관한 데이터베이스 서비스를 사용하는 것입니다.