시작하기 전에

클러스터를 생성하기 전에, 클러스터 생성 명령어에 입력해야 할 VPC 및 Cloud Object Storage 관련 정보를 미리 준비해 두십시오.

1. VPC ID를 조회하십시오. 각 클러스터에 사용할 VPC의 ID를 기록해 두십시오.

   ibmcloud is vpcs
   

2. 특정 VPC에 대한 서브넷 세부 정보를 조회합니다. 각 클러스터에 사용할 서브넷 ID를 기록해 두십시오.

   ibmcloud is subnets --vpc VPC_ID
   

3. Cloud Object Storage 인스턴스 목록을 표시하세요.

   ibmcloud resource service-instances --service-name cloud-object-storage
   

4. 사용하려는 인스턴스의 CRN을 조회합니다. ID 필드의 값을 확인해 주세요.

   ibmcloud resource service-instance SERVICE_INSTANCE
   

1단계. 허브 클러스터 생성

허브 클러스터

이 클러스터는 ACM을 설치하여 주 ODF 클러스터와 보조 ODF 클러스터를 관리하는 데 사용되는 클러스터입니다. 허브 클러스터에 최소 16 vCPU x 64 GB 의 사용 가능한 컴퓨팅 용량이 확보되어 있는지 확인하십시오.

각 클러스터에 대해 CLI에 --disable-outbound-traffic-protection 매개 변수를 포함하거나 UI에서 아웃바운드 트래픽 보호를 비활성화하는 옵션을 선택하여 아웃바운드 트래픽을 허용해야 합니다.

1. VPC 클러스터 만들기 us-east 에 접속하여 ACM을 설치하세요. 이 클러스터는 ODF 클러스터를 관리하는 데 사용할 수 있는 허브 클러스터입니다. 허브 클러스터에 RHCOS를 실행하는 워커 노드가 최소 3개 이상 있고, 사용 가능한 컴퓨팅 용량이 최소 16 vCPU 와 64GB이며, 아웃바운드 트래픽이 비활성화되어 있고, ACM 응시 요건 에 명시된 모든 요구 사항을 충족하는지 확인하십시오. 다음 예제 명령은 us-east 에 ACM용 클러스터를 생성합니다.

   ibmcloud ks cluster create vpc-gen2 --flavor bx2.16x64 --name acm-hub-cluster-dr-odf --subnet-id SUBNET_ID --vpc-id VPC_ID --zone us-east-2 --version 4.21.27_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
   

2. 출력 결과에서 클러스터 ID를 확인하십시오. 나중에 이 단계에서 필요하게 될 거예요.

2단계. 허브 클러스터에 대한 신뢰할 수 있는 프로필 생성

허브 클러스터

1. 신뢰할 수 있는 프로필을 생성합니다.

   ibmcloud iam trusted-profile-create acm-operator-profile
   

2. Red Hat OpenShift 컴퓨팅 리소스의 kube-system 네임스페이스를 적용 범위로 하는 컴퓨팅 리소스 신뢰 규칙을 생성합니다.

   ibmcloud iam trusted-profile-rule-create acm-operator-profile \
     --name kube-system-rule \
     --type Profile-CR \
     --conditions claim:namespace,operator:EQUALS,value:kube-system \
     --cr-type ROKS_SA
   

3. 프로필에 IAM 액세스 정책을 할당합니다. CLUSTER_ID 을 사용자의 허브 클러스터 ID로 대체하십시오.

   ibmcloud iam trusted-profile-policy-create acm-operator-profile \
     --roles Reader,Viewer,Operator,Editor \
     --service-name containers-kubernetes \
     --service-instance CLUSTER_ID
   

4. 허브 클러스터에 신뢰할 수 있는 프로필을 할당합니다. 클러스터에 신뢰할 수 있는 프로필을 할당한 후에는 이를 제거할 수 없습니다.

   ibmcloud oc experimental trusted-profile set --cluster CLUSTER_NAME_OR_ID --trusted-profile TRUSTED_PROFILE_ID
   

5. ODF 버전 4.21 이상을 사용하는 경우, 허브 클러스터에 OpenShift GitOps 연산자를 설치하십시오. 설치 단계에 대해서는 웹 콘솔에서 ‘ Red Hat OpenShift GitOps Operator 설치’를 참조하십시오.

3단계. 관리형 클러스터 생성

관리형 클러스터

1. us-east 에서 RHCOS를 실행하는 워커 노드가 최소 3개 이상이고, 사용 가능한 컴퓨팅 용량이 최소 16 vCPU 와 64 GB이며, 아웃바운드 트래픽 보호 기능이 비활성화된 VPC 클러스터를 생성합니다. 이 클러스터가 기본 관리 ODF 클러스터가 됩니다. 다음 예제 명령어는 us-east 에 클러스터를 생성합니다.

   ibmcloud ks cluster create vpc-gen2 --flavor bx2.16x64 --name managed-cluster-1-dr-odf --subnet-id SUBNET_ID --vpc-id VPC_ID --zone us-east-2 --version 4.21.27_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
   

2. jp-tok 에서 RHCOS를 실행하는 워커 노드가 최소 3개 이상이고, 사용 가능한 컴퓨팅 용량이 최소 16 vCPU 와 64 GB이며, 아웃바운드 트래픽 보호 기능이 비활성화된 VPC 클러스터를 생성합니다. 이 클러스터가 보조 관리 ODF 클러스터가 됩니다. 고가용성을 위해 보조 클러스터의 네트워크가 기본 클러스터의 네트워크와 겹치지 않도록 하세요. 다음 예제 명령어는 jp-tok 에 클러스터를 생성합니다.

   ibmcloud ks cluster create vpc-gen2 --flavor bx2.16x64 --name managed-cluster-2-dr-odf --subnet-id SUBNET_ID --vpc-id VPC_ID --zone jp-tok --version 4.21.27_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
   

4단계. ACM을 위한 시크릿 준비하기

허브 클러스터

ACM을 통해 관리하려는 각 클러스터에 대해, 허브 클러스터에서 관리 대상 클러스터의 액세스 토큰과 서버 URL 을 포함하는 시크릿을 생성해야 합니다.

ACM 애드온 설치 과정에서 관리형 클러스터를 가져오려면, 설치를 시작하기 전에 다음 단계를 완료하십시오. 허브 클러스터에 애드온을 설치한 후 시크릿을 생성하고 관리형 클러스터를 가져오기로 선택한 경우, CLI를 사용하여 추가 단계를 수행하면 됩니다.

관리하려는 각 클러스터에 대해 다음 단계를 수행하십시오.

1. ACM으로 관리하려는 클러스터에서 다음 명령어를 실행하여 서버를 확인하십시오. URL. 출력 결과에서 ‘ URL ’의 값을 찾아 기록해 두십시오. 시크릿에서 참조할 서버는 URL 입니다. 또한 다음 단계에서 이 URL 도 사용하게 됩니다.

   ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
   

   출력 예.

   NAME:                           mycluster
   ID:                             1234567
   State:                          normal
   Created:                        2025-01-22T19:22:16+0000
   Location:                       dal10
   Master URL:                     https://c100-e.<region>.containers.cloud.ibm.com:<port>
   ...
   

2. Red Hat OpenShift OAuth 서버의 기본 URL 를 가져옵니다. MASTER_URL 을 이전 단계에서 확인한 URL 으로 대체하십시오. 이 명령어는 /oauth/token 접미사를 제외한 기본 주소 URL 를 추출합니다.

   curl -sS MASTER_URL/.well-known/oauth-authorization-server | jq -r .token_endpoint | sed 's#/oauth/token##'
   

   출력 예.

   https://c111-e.us-east.containers.cloud.ibm.com:31282
   

3. 이전 단계에서 확인한 엔드포인트를 사용하여 액세스 토큰을 가져옵니다. 다음 cURL 명령을 실행하되, URL 을 이전 단계의 출력 결과로, API_KEY 을 본인의 [IBM Cloud API 키](https://cloud.ibm.com/iam/apikeys){: external}으로 대체하십시오. 출력 결과에서 Location 응답 에 포함된 ACCESS_TOKEN 을 찾아보세요. 이것이 시크릿에 포함해야 할 액세스 토큰입니다.

   curl 요청 예:

   curl -u 'apikey:API_KEY' -H "X-CSRF-Token: a" 'URL/oauth/authorize?client_id=openshift-challenging-client&response_type=token' -vvv
   

   출력 예. ACCESS_TOKEN은 Location 응답 문자열에 포함되어 있습니다.

   < HTTP/1.1 302 Found
   < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
   < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
   < Expires: 0
   < Expires: Fri, 01 Jan 2030 00:00:00 GMT
   < Location: TOKEN_ENDPOINT/oauth/token/implicit#access_token=ACCESS_TOKEN&expires_in=86400&scope=user%3Afull&token_type=Bearer
   ...
   

4. 허브 클러스터에서 클러스터 액세스 토큰과 서버 URL 을 포함하는 시크릿을 생성합니다. 시크릿 생성 방법에 대한 자세한 내용은 ‘ Kubernetes ’ 문서의 ‘시크릿 관리’ 섹션을 참조하십시오.

   비밀 예시.

   apiVersion: v1
   kind: Secret
   metadata:
     name: SECRET_NAME
     namespace: SECRET_NAMESPACE  # The namespace that the secret is to be created in
   type: Opaque
   stringData:
     token: ACCESS_TOKEN
     server: SERVER_URL
   

5단계. 허브 클러스터에 ACM 애드온을 설치하십시오

허브 클러스터

CLI를 사용하여 허브 클러스터에 ACM 애드온을 설치하십시오.

1. ACM 애드온의 기본 버전을 찾으세요.

   ibmcloud oc cluster addon versions
   

2. ACM 추가 기능 옵션을 확인해 보세요. 명령어에서 이전 단계에서 확인한 기본 버전을 지정하십시오. 애드온을 설치할 때 포함하고 싶은 옵션이 있다면 기록해 두세요.

   ibmcloud oc cluster addon options --addon acm --version DEFAULT_VERSION
   

3. 애드온에서 관리할 클러스터를 가져오려면, 아직 수행하지 않았다면 ‘ACM용 시크릿 준비’ 단계에 따라 진행하십시오. 허브 클러스터에서 생성한 시크릿의 클러스터 ID와 이름, 네임스페이스를 반드시 저장해 두십시오. 이 프로세스는 허브 클러스터에 애드온이 설치된 후에도 완료할 수 있지만, 설치 후 관리 대상 클러스터를 가져오려면 추가 단계가 필요합니다.

4. 애드온을 활성화하려면 해당 명령을 실행하십시오. 설치 과정에서 클러스터를 가져오려면 billingPlan 및 isLicenseAccepted 매개변수를 반드시 지정해야 하며, 필요한 경우 --managedClusters 매개변수도 함께 지정해야 합니다.

   ibmcloud oc cluster addon enable acm --cluster HUB_CLUSTER_ID --param 'managedClusters=["clusterid:CLUSTER_ID;secretname:SECRET_NAME;secretnamespace:SECRET_NAMESPACE;action:IMPORT"]' --param 'billingPlan=PLAN' --param 'isLicenseAccepted=BOOLEAN'
   

   명령 매개변수. 각 매개변수 유형에 대한 예시는 아래의 명령어 예시를 참조하십시오.

   --cluster

   필수. ACM 애드온을 설치할 허브 클러스터의 ID입니다.

   --param 'managedClusters=["]

   선택사항입니다. 애드온 설치 과정에서 관리형 클러스터를 가져오려면 이 매개변수를 한 번 이상 포함하십시오. 이 단계는 나중에 진행하셔도 됩니다. 자세한 내용은 ‘ACM용 시크릿 준비’를 참조하십시오.

   다음 값을 지정하십시오.

   • clusterid: 가져올 관리형 클러스터의 ID입니다.

   • secretname: 허브 클러스터에서 생성한 시크릿의 이름입니다. 이 시크릿에는 관리형 클러스터의 인증 정보가 포함되어 있습니다.

   • secretnamespace: 허브 클러스터에서 생성한 시크릿의 네임스페이스입니다. 이 시크릿에는 관리형 클러스터의 인증 정보가 포함되어 있습니다.

   • action:IMPORT: 관리 대상 클러스터에 대한 IMPORT 작업을 지정하는 매개변수입니다.

   --param 'billingPlan='

   필수. ACM에 대해 선택하려는 요금제입니다. Kubernetes 요금제의 ACM에 대해 ‘ KUBERNETES ’을 지정하십시오.

   --param 'isLicenseAccepted='

   필수. TRUE 를 지정하여 선택한 요금제의 라이선스 계약에 동의하십시오. 본 라이선스에 동의함으로써, 귀하는 해당 이용 약관에 동의하며, 선택한 요금제에 포함된 서비스를 이해했음을 확인하는 것입니다.

   Kubernetes 용 ACM 요금제를 사용하여 ACM 애드온을 설치하고 관리형 클러스터를 가져오는 명령어 예시입니다.

   ibmcloud ks cluster addon enable acm --cluster a5bcde982dfer2nwxq73 --param 'managedClusters=["clusterid:w7rthce34gfbq7ww12d3;secretname:managed-secret-1;secretnamespace:managed-ns1;action:Import"]' --param 'billingPlan=KUBERNETES' --param 'isLicenseAccepted=true'
   

5. 애드온이 제대로 설치되었는지 확인하십시오. 다음 출력 결과에 애드온이 표시되기까지 몇 분 정도 걸릴 수 있습니다.

   1. 허브 클러스터에서 ‘ acmhub ’ 리소스가 생성되었는지 확인하십시오.

       oc get acmhub
       ```
       출력 예.
   
       ```sh {: screen}
           NAME       AGE
           acm-auto   1h
       ```
   1. 허브 클러스터에서 ‘ `acmhub` ’ 상태를 확인하십시오.
   
   ```sh {: pre}
       oc describe acmhubstatus
       ```
       출력 예.
   
       ```sh {: screen}
       status
           phase: Ready
       ```
   

6단계. 서브마리너 애드온 구성

관리형 클러스터

다음 단계에 따라 관리되는 두 클러스터에 연결을 설정하는 Submariner 애드온을 설치 및 구성하세요. 이 단계에서는 ACM 콘솔을 사용합니다. 더 자세한 내용은 ‘ Red Hat ’ 문서의 “콘솔을 사용하여 Submariner 배포하기” 섹션을 참조하십시오.

1. ACM 콘솔로 이동합니다. 그런 다음 Fleet Management > 인프라 > 클러스터 > 클러스터 세트를 클릭합니다.
2. 클러스터 집합 만들기를 클릭합니다. 지시에 따라 두 개의 관리형 클러스터를 클러스터 집합에 추가합니다.
3. 클러스터 세트에 서브마리너 애드온을 설치하는 옵션을 클릭합니다.
4. 관리되는 클러스터를 애드온 설치 대상 클러스터로 선택합니다.
5. 두 클러스터의 구성을 검토할 때, 아래와 같이 설정을 변경하고 나머지는 기본값으로 놔둡니다. 그런 다음 ‘설치’를 클릭하세요.

   globalnetEnabled: true (checked)
   gateways: 2
   NATTEnable: false (unchecked)
   cableDriver: vxlan.
   

6. Submariner 애드온 상태가 정상(녹색)으로 표시될 때까지 기다리십시오. 이 과정은 최대 20분 정도 소요될 수 있습니다.

7단계. OpenShift Data Foundation 설치 및 구성

관리형 클러스터

2개의 관리형 클러스터에 ODF를 설치하고 구성합니다. 기본 및 보조 관리형 클러스터 모두에서 이 단계를 완료해야 합니다.

1. 다음 단계에 따라 2개의 관리형 클러스터에 OpenShift Data Foundation 애드온을 설치하세요. 기본 ODF 버전 이상을 지정합니다. 설치 시 추가 옵션으로 NooBaa 을 활성화하는 옵션을 포함해야 합니다.

2. ODF 파운데이션이 성공적으로 설치되었는지 확인합니다. 출력에서 상태가 Ready 로 표시되는지 확인합니다.

   oc get storagecluster -n openshift-storage ocs-storagecluster -o jsonpath='{.status.phase}{"\n"}'
   

3. 명령을 실행하여 storageCluster 리소스의 multiClusterService 섹션에서 ACM Managed Cluster Name 을 업데이트합니다. 이를 통해 ODF는 GlobalNet 을 사용할 수 있습니다. 자세한 내용은 관리형 클러스터에서 OpenShift Data Foundation 클러스터 만들기를 참조하세요.

   명령에서 MANAGED_CLUSTER_NAME 을 관리되는 클러스터의 이름으로 바꿔야 합니다.

   kubectl patch storagecluster -n openshift-storage ocs-storagecluster --type merge -p'{"spec":{"network":{"multiClusterService":{"clusterID":"MANAGED_CLUSTER_NAME","enabled":true}}}}'
   

4. 서비스 내보내기를 확인합니다. 출력에 표시되려면 몇 분 정도 걸릴 수 있습니다.

   oc get serviceexport -n openshift-storage
   

   출력 예:

   NAME              AGE
   rook-ceph-mon-d   4d14h
   rook-ceph-mon-e   4d14h
   rook-ceph-mon-f   4d14h
   rook-ceph-osd-0   4d14h
   rook-ceph-osd-1   4d14h
   rook-ceph-osd-2   4d14h
   

5. 다음 YAML을 사용하여 ocs-provider-server 에 대한 서비스 내보내기를 만듭니다.

   apiVersion: multicluster.x-k8s.io/v1alpha1
   kind: ServiceExport
   metadata:
     name: ocs-provider-server
     namespace: openshift-storage
   

6. 명령을 실행하여 storageCluster 리소스를 업데이트하여 생성한 ocs-provider-server 서비스 내보내기를 사용하도록 합니다.

   oc annotate storagecluster ocs-storagecluster -n openshift-storage ocs.openshift.io/api-server-exported-address=MANAGED_CLUSTER_NAME.ocs-provider-server.openshift-storage.svc.clusterset.local:50051.
   

7. storageCluster 리소스가 준비되었는지 확인합니다.

   oc get storagecluster -n openshift-storage
   

   출력 예.

   NAME                    PHASE  
   ocs-storagecluster      Ready   
   

8단계. 지역 재해 복구 정책 구성

허브 클러스터

허브 클러스터에 ODF 멀티클러스터 오케스트레이터를 설치하고, 관리 대상인 두 클러스터 간의 미러링을 활성화하는 DR 정책을 생성하십시오.

1. oDF 멀티클러스터 오케스트레이터 설치 으로 이동하여 ACM 허브 클러스터 으로 이동합니다. 호환성을 보장하려면 이전 섹션에서 관리형 클러스터에 설치한 ODF 버전과 동일한 버전 번호를 설치해야 합니다.

2. 운영자 파드가 실행 중인지 확인하여 설치를 확인합니다.

   oc get pods -n openshift-operators
   

   출력 예.

   NAME                                        READY   STATUS       RESTARTS    AGE
   odf-multicluster-console-6845b795b9-blxrn   1/1     Running      0           4d20h
   odfmo-controller-manager-f9d9dfb59-jbrsd    1/1     Running      0           4d20h
   ramen-hub-operator-6fb887f885-fss4w         2/2     Running      0           4d20h
   

3. ACM 허브 클러스터에서 5분 동기화 간격으로 DR 정책을 만들고 매개변수에서 각 관리되는 클러스터를 지정합니다. 이렇게 하면 두 관리형 클러스터에 NooBaa 오브젝트 버킷이 생성되고 볼륨 복제를 위한 ODF Ceph 블록 풀 미러링이 활성화됩니다.

   1. ACM 콘솔로 이동한 다음 플릿 관리 > 데이터 서비스 > 재해 복구 > 정책 > DR 정책 만들기를 클릭합니다.
   2. 다음 매개 변수가 포함된 DR 정책을 만듭니다.
      • 연결된 클러스터: PRIMARY_MANAGED_CLUSTER_NAME, SECONDARY_MANAGED_CLUSTER_NAME
      • 복제 정책: 비동기
      • 복제 간격: 5m

4. 허브 클러스터에서 다음 명령을 실행하여 DR 정책이 생성되어 관리되는 클러스터에 적용되었는지 확인합니다.

   oc get drpolicy DRPOLICY_NAME -o jsonpath='{.status.conditions[].reason}{"\n"}'
   

   oc get drclusters
   

   출력 예.

   NAME        AGE
   managed-cluster1   4m42s
   managed-cluster2   4m42s
   

5. 관리되는 각 클러스터에서 DR 정책이 적용되었고 정상 상태인지 확인합니다.

   oc get csv,pod -n openshift-dr-system
   

   출력 예.

   NAME                                                                          DISPLAY                         VERSION        REPLACES   PHASE
   clusterserviceversion.operators.coreos.com/odr-cluster-operator.v4.15.0       Openshift DR Cluster Operator   4.15.0                    Succeeded
   clusterserviceversion.operators.coreos.com/volsync-product.v0.8.0             VolSync                         0.8.0                     Succeeded
   NAME                                             READY   STATUS    RESTARTS   AGE
   pod/ramen-dr-cluster-operator-6467cf5d4c-cc8kz   2/2     Running   0          3d12h
   

   oc get cephblockpool ocs-storagecluster-cephblockpool -n openshift-storage -o jsonpath='{.status.mirroringStatus.summary}{"\n"}'
   

   출력 예.

   {"daemon_health":"OK","health":"OK","image_health":"OK","states":{}}
   

6. 선택 사항입니다: ODF 지역 재해 복구 기능을 향상시키기 위해 설치할 수 있는 운영자를 검토합니다.

7. 선택 사항입니다: 재해 복구 구성을 테스트합니다.

ODF 지역 재해 복구를 위한 선택적 운영자

ACM 허브 또는 관리형 클러스터에 설치할 수 있는 옵션 운영자를 검토하여 ODF 지역 재해 복구 기능을 강화하세요. IBM 은 이러한 운영자를 관리할 책임이 없습니다.

업데이트, 모니터링, 복구 및 재설치를 포함하되 이에 국한되지 않는 이러한 운영자를 관리할 책임은 회원님에게 있습니다.

재해 복구 구성 테스트

재해 복구 솔루션을 테스트할 수 있는 샘플 애플리케이션을 만듭니다. 자세한 내용은 재해 복구 애플리케이션 테스트를 위한 샘플 애플리케이션 만들기를 참고하세요.

1. ACM 콘솔에서 구독 기반 애플리케이션을 배포합니다. 애플리케이션의 토폴로지 탭은 모든 애플리케이션 리소스가 성공적으로 배치되면 녹색으로 표시됩니다.

2. 애플리케이션 페이지에서, 작업 > 데이터 정책 관리로 이동합니다.

3. 앞서 만든 DR 정책을 이 애플리케이션에 할당합니다.

4. 응용 프로그램 포드가 주 클러스터에서 실행되고 있는지 확인합니다.

5. 애플리케이션 페이지에서, 작업 > 애플리케이션 페일오버로 이동합니다. 보조 ODF 클러스터를 대상 클러스터로 선택합니다. 시작을 클릭합니다.

6. 애플리케이션 포드가 보조 클러스터로 이동되었는지 확인합니다.

7. 애플리케이션 페이지에서, 작업 > 애플리케이션 재배치 로 이동합니다. 주요 ODF 클러스터를 대상 클러스터로 선택합니다. 시작을 클릭합니다.

8. 애플리케이션 포드가 기본 클러스터로 다시 이동되었는지 확인합니다.

ODF 지역 재해 복구 환경 업그레이드

ODF-RDR 환경의 구성 요소를 언제, 어떻게 업그레이드해야 하는지에 대한 자세한 내용은 “ODF 지역 재해 복구 환경 업그레이드”를 참조하십시오.

문제점 해결

ODF 지역 재해 복구 구성에 문제가 발생하면, ‘ OpenShift 데이터 기반 지역 재해 복구 구성 확인’ 문서를 참조하여 설정된 각 구성 요소의 상태를 확인하십시오.

지원되는 애플리케이션 및 워크로드

설정을 완료한 후, ‘지역별 재해 복구’를 적용할 수 있는 애플리케이션 및 워크로드 유형을 확인하십시오.

구독 기반

애플리케이션이 외부 소스(예: GitHub, Helm 리포지토리 또는 Object Storage )에서 배포됩니다.

자세한 내용은 Red Hat 문서에서 샘플 구독 기반 애플리케이션 만들기를 참조하세요.

ApplicationSet-based

애플리케이션은 지속적인 배포를 관리하는 GitOps 오퍼레이터를 통해 GitHub 저장소에서 배포됩니다. 여기에는 두 가지 하위 유형이 포함됩니다:

• GitOps 풀 모델( ArgoCD pull): 관리형 클러스터는 GitOps 연산자를 사용하여 GitHub 에서 애플리케이션을 가져옵니다.

• GitOps 푸시 모델( ArgoCD push): GitOps 운영자는 배포 및 업데이트 중에 애플리케이션을 관리형 클러스터로 푸시합니다.

자세한 내용은 Red Hat 문서에서 애플리케이션 세트 기반 애플리케이션 만들기를 참조하세요.

GitOps 하위 유형에 대한 자세한 내용은 Red Hat 문서에서 푸시 및 풀 모델을 사용한 Argo CD 배포를 참조하세요.

검색된 애플리케이션

애플리케이션이 ACM을 사용하지 않고 관리형 클러스터에 사전 배포되었습니다. 이 경우 사전 설치된 앱에 대해 ACM 검색을 사용하면서 DR 정책을 계속 구성할 수 있습니다.

자세한 내용은 Red Hat 문서에서 검색된 애플리케이션에 대한 재해 복구 보호를 참조하세요.

VM 배포를 포함하는 애플리케이션

VM-기반 애플리케이션이 ACM 콘솔에서 관리되는 클러스터에 배포됩니다. 앞서 설명한 바와 같이, 이러한 VM 애플리케이션은 구독 기반, ApplicationSet-based, 또는 검색 가능한 형태일 수 있습니다. 이러한 유형의 애플리케이션에 대해서는 ACM 콘솔에서 ‘ VM ’ 작업의 시작, 중지, 일시 중지 및 삭제 옵션을 사용할 수 있습니다.

자세한 내용은 Red Hat 문서에서 가상화를 위한 고급 클러스터 관리(Red Hat )를 참조하세요.