애드온

다음 명령을 실행하여 < broker-namespace >를 검색합니다.

oc get ManagedClusterSet <cluster-set-name> -o jsonpath="{.metadata.annotations['cluster\.open-cluster-management\.io/submariner-broker-ns']}"

submariner-broker 라는 YAML 파일을 생성하여 Globalnet 구성을 지정하는 submariner-broker 오브젝트를 생성합니다. 다음 행과 유사한 콘텐츠를 YAML 파일에 추가합니다.

apiVersion: submariner.io/v1alpha1
kind: Broker
metadata:
  name: submariner-broker
  namespace: <broker-namespace>
spec:
  globalnetEnabled: <true-or-false>

broker-namespace 를 브로커 네임스페이스의 이름으로 교체합니다.

Globalnet을 활성화하려면 true-or-false 를 true 로 바꿉니다.

참고: metadata name 매개변수는 submariner-broker 여야 합니다.

다음 명령을 입력하여 YAML 파일에 파일을 적용합니다.

oc apply -f submariner-broker.yaml

다음 예와 유사한 YAML 콘텐츠를 사용자 지정하고 적용합니다.

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
    name: submariner
    namespace: <managed-cluster-namespace>
spec:{}

managed-cluster-namespace 를 관리형 클러스터의 이름으로 교체합니다. SubmarinerConfig 의 이름은 예제에 표시된 대로 submariner 여야 합니다.

이 구성에서는 작업자 노드 중 하나에 베어 메탈 클러스터의 Submariner 게이트웨이에 레이블을 지정합니다.

기본적으로 Submariner는 IP 보안 (IPsec)을 사용하여 게이트웨이 노드의 클러스터 간 보안 터널을 설정합니다. 기본 IPsec NATT 포트를 사용하거나 구성한 다른 포트를 지정할 수 있습니다. IPsec NATT 포트를 지정하지 않고 이 절차를 실행하면 연결에 4500/UDP가 사용됩니다.

Azure CLI에서 다음 명령을 실행하여 확장을 설치합니다.

az extension add --upgrade -s <path-to-extension>

path-to-extension 을 .w >-< 확장 파일을 다운로드한 경로로 교체합니다.

다음 명령을 실행하여 CLI 확장이 사용 중인지 확인합니다.

az extension list

확장 기능을 사용하는 경우 출력은 다음 예와 유사합니다.

"experimental": false,
"extensionType": "whl",
"name": "aro",
"path": "<path-to-extension>",
"preview": true,
"version": "1.0.x"

Azure CLI에서 다음 명령을 실행하여 프리뷰 기능을 등록합니다.

az feature registration create --namespace Microsoft.RedHatOpenShift --name AdminKubeconfig

다음 명령을 실행하여 관리자 kubeconfig 를 검색합니다.

az aro get-admin-kubeconfig -g <resource group> -n <cluster resource name>

참고: az aro 명령은 kubeconfig 를 로컬 디렉터리에 저장하고 kubeconfig 라는 이름을 사용합니다. 이를 사용하려면 환경 변수 KUBECONFIG 가 파일의 경로와 일치하도록 설정합니다. 다음 예제를 참조하십시오.

export KUBECONFIG=<path-to-kubeconfig>
oc get nodes

Kubeconfig Import 모드를 선택하고 Kubeconfig 창의 kubeconfig 파일에서 콘텐츠를 입력합니다. 콘솔의 지침에 따라 가져오기를 완료합니다.

인프라 > 클러스터로 이동하여 Azure Red Hat OpenShift 클러스터를 성공적으로 가져왔는지 확인할 수 있습니다.

다음 명령을 실행하여 Submariner 게이트웨이를 실행할 새 노드를 만듭니다.

rosa create machinepool --cluster=<cluster_name> --name=sm-gw-mp --replicas=<number of Submariner gateway > --labels='submariner.io/gateway=true'

다음 명령을 실행하여 AWS에서 OpenShift Service에 로그인합니다.

rosa login
oc login <rosa-cluster-url>:6443 --username cluster-admin --password <password>

다음 명령을 실행하여 AWS 클러스터에서 OpenShift Service의 kubeconfig 를 생성합니다.

oc config view --flatten=true > rosa_kube/kubeconfig

Kubeconfig Import 모드를 선택하고 Kubeconfig 창의 kubeconfig 파일에서 콘텐츠를 입력합니다. 콘솔의 지침에 따라 가져오기를 완료합니다.

Infrastructure > Clusters 로 이동하여 AWS 클러스터의 OpenShift Service를 성공적으로 가져왔는지 확인할 수 있습니다.

ManagedClusterSet 설명서에 제공된 지침을 사용하여 hub 클러스터에 ManagedClusterSet 리소스를 생성합니다. ManagedClusterSet 의 항목이 다음 콘텐츠와 일치하는지 확인합니다.

apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSet
metadata:
  name: <managed-cluster-set-name>

managed-cluster-set-name 을 생성 중인 ManagedClusterSet 의 이름으로 교체합니다.

중요: Kubernetes 네임스페이스의 최대 문자 길이는 63자입니다. < managed-cluster-set-name>에 사용할 수 있는 최대 문자 길이는 CloudEvent자입니다. < managed-cluster-set-name >의 문자 길이가234자를 초과하면 < managed-cluster-set-name >이 헤드에서 차단됩니다.

ManagedClusterSet 이 생성된 후 submariner-addon 은 < managed-cluster-set-name>-broker 라는 네임스페이스를 생성하고 Submariner 브로커를 배포합니다.

다음 예와 유사한 YAML 콘텐츠를 사용자 정의하고 적용하여 < managed-cluster-set-name>-broker 네임스페이스의 hub 클러스터에서 Broker 구성을 생성합니다.

apiVersion: submariner.io/v1alpha1
kind: Broker
metadata:
     name: submariner-broker
     namespace: <managed-cluster-set-name>-broker
     labels:
         cluster.open-cluster-management.io/backup: submariner
spec:
     globalnetEnabled: <true-or-false>

managed-cluster-set-name 을 관리형 클러스터의 이름으로 교체합니다.

ManagedClusterSet 에서 Submariner Globalnet을 활성화하려면 globalnetEnabled 의 값을 true 로 설정합니다.

다음 명령을 실행하여 ManagedClusterSet 에 하나의 관리형 클러스터를 추가합니다.

oc label managedclusters <managed-cluster-name> "cluster.open-cluster-management.io/clusterset=<managed-cluster-set-name>" --overwrite

& lt;managed-cluster-name >을 ManagedClusterSet 에 추가할 관리형 클러스터 이름으로 바꿉니다.

& lt;managed-cluster-set-name >을 관리 클러스터를 추가할 ManagedClusterSet 의 이름으로 바꿉니다.

다음 예와 유사한 YAML 콘텐츠를 사용자 지정하고 적용합니다.

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
    name: submariner
    namespace: <managed-cluster-namespace>
spec:{}

managed-cluster-namespace 를 관리 클러스터의 네임스페이스로 교체합니다.

참고: SubmarinerConfig 의 이름은 예제에 표시된 대로 submariner 여야 합니다.

다음 예와 유사한 YAML 콘텐츠를 사용자 지정하고 적용하여 관리형 클러스터에 Submariner를 배포합니다.

apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ManagedClusterAddOn
metadata:
     name: submariner
     namespace: <managed-cluster-name>
spec:
     installNamespace: submariner-operator

managed-cluster-name 을 Submariner와 함께 사용하려는 관리형 클러스터의 이름으로 교체합니다.

ManagedClusterAddOn 사양의 installNamespace 필드는 Submariner를 설치하는 관리 클러스터의 네임스페이스입니다. 현재는 submariner-operator 네임스페이스에 Submariner가 설치되어 있어야 합니다.

ManagedClusterAddOn 이 생성된 후 submariner-addon 은 Submariner를 관리 클러스터의 submariner-operator 네임스페이스에 배포합니다. 이 ManagedClusterAddOn 의 상태에서 Submariner의 배포 상태를 볼 수 있습니다.

참고: ManagedClusterAddOn 의 이름은 submariner 여야 합니다.

Submariner가 관리 클러스터에 배포된 후 다음 명령을 실행하여 잠수함 ManagedClusterAddOn 의 상태를 확인하여 Submariner 배포 상태를 확인할 수 있습니다.

oc -n <managed-cluster-name> get managedclusteraddons submariner -oyaml

managed-cluster-name 을 관리 클러스터의 이름으로 교체합니다.

Submariner ManagedClusterAddOn 의 상태에서 세 가지 조건은 Submariner 배포 상태를 나타냅니다.

다음 명령을 입력하여 ManagedClusterSet 에 있는 관리형 클러스터에 nginx 서비스의 인스턴스를 적용합니다.

oc -n default create deployment nginx --image=nginxinc/nginx-unprivileged:stable-alpine
oc -n default expose deployment nginx --port=8080

다음 명령과 유사한 서브ctl 툴을 사용하여 명령을 입력하여 ServiceExport 항목을 생성하여 서비스를 내보냅니다.

subctl export service --namespace <service-namespace> <service-name>

service-namespace 를 서비스가 있는 네임스페이스의 이름으로 교체합니다. 이 예에서는 기본값 입니다.

service-name 을 내보낸 서비스 이름으로 교체합니다. 이 예제에서는 nginx 입니다.

사용 가능한 다른 플래그에 대한 자세한 내용은 Submariner 설명서에서 내보내기 를 참조하십시오.

다른 관리 클러스터에서 다음 명령을 실행하여 nginx 서비스에 액세스할 수 있는지 확인합니다.

oc -n default run --generator=run-pod/v1 tmp-shell --rm -i --tty --image quay.io/submariner/nettest -- /bin/bash curl nginx.default.svc.clusterset.local:8080

Submariner를 제거할 다른 클러스터에 대해 해당 단계를 반복합니다.

팁: 여러 클러스터를 선택하고 작업을 클릭하여 동일한 클러스터의 여러 클러스터에서 Submariner 애드온을 제거할 수 있습니다. Submariner 애드온 제거를 선택합니다.

다음 명령을 실행하여 클러스터의 Submariner 배포를 제거합니다.

oc -n <managed-cluster-namespace> delete managedclusteraddon submariner

managed-cluster-namespace 를 관리 클러스터의 네임스페이스로 교체합니다.

다음 명령을 실행하여 클러스터의 클라우드 리소스를 제거합니다.

oc -n <managed-cluster-namespace> delete submarinerconfig submariner

managed-cluster-namespace 를 관리 클러스터의 네임스페이스로 교체합니다.

다음 명령을 실행하여 브로커 세부 정보를 제거하도록 클러스터 세트를 삭제합니다.

oc delete managedclusterset <managedclusterset>

managedclusterset 를 관리 클러스터 세트의 이름으로 교체합니다.

다음 명령을 실행하여 클러스터에 남아 있는 Submariner 리소스를 나열합니다.

oc get cluster <CLUSTER_NAME> grep submariner

CLUSTER_NAME 을 클러스터 이름으로 바꿉니다.

다음 명령을 입력하여 목록의 리소스를 제거합니다.

oc delete resource <RESOURCE_NAME> cluster <CLUSTER_NAME>

RESOURCE_NAME 을 삭제하려는 Submariner 리소스의 이름으로 바꿉니다.

다음 YAML 콘텐츠와 유사한 보안을 생성하여 백업 이미지가 저장된 리포지터리를 지정합니다.

apiVersion: v1
kind: Secret
metadata:
  name: restic-config
type: Opaque
stringData:
  RESTIC_REPOSITORY: <my-restic-repository>
  RESTIC_PASSWORD: <my-restic-password>
  AWS_ACCESS_KEY_ID: access
  AWS_SECRET_ACCESS_KEY: password

my-restic-repository 를 백업 파일을 저장하려는 S3 버킷 리포지토리의 위치로 교체합니다.

my-restic-password 를 리포지토리에 액세스하는 데 필요한 암호화 키로 교체합니다.

필요한 경우 액세스 및 암호를 공급자의 인증 정보로 바꿉니다. 자세한 내용은 새 리포지토리 준비를 참조하십시오.

새 리포지토리를 준비해야 하는 경우 프로시저를 위한 새 리포지토리 준비를 참조하십시오. 해당 절차를 사용하는 경우 restic init 명령을 실행하여 리포지토리를 초기화해야 하는 단계를 건너뜁니다. gRPCSync는 첫 번째 백업 중에 자동으로 저장소를 초기화합니다.

중요: 동일한 S3 버킷에 여러 영구 볼륨 클레임을 백업할 때 버킷 경로는 각 영구 볼륨 클레임마다 고유해야 합니다. 각 영구 볼륨 클레임은 별도의 ReplicationSource 로 백업되며 각각 별도의 restic-config 시크릿이 필요합니다.

동일한 S3 버킷을 공유하면 각 ReplicationSource 에 전체 S3 버킷에 대한 쓰기 액세스 권한이 있습니다.

다음 YAML 콘텐츠와 유사한 ReplicationSource 오브젝트를 생성하여 백업 정책을 구성합니다.

apiVersion: volsync.backube/v1alpha1
kind: ReplicationSource
metadata:
  name: mydata-backup
spec:
  sourcePVC: <source>
  trigger:
    schedule: "*/30 * * * *" #\*
  restic:
    pruneIntervalDays: 14
    repository: <restic-config>
    retain:
      hourly: 6
      daily: 5
      weekly: 4
      monthly: 2
      yearly: 1
    copyMethod: Clone
  # The StorageClass to use when creating the PiT copy (same as source PVC if omitted)
  #storageClassName: my-sc-name
  # The VSC to use if the copy method is Snapshot (default if omitted)
  #volumeSnapshotClassName: my-vsc-name

소스를 백업 중인 영구 볼륨 클레임으로 교체합니다.

일정 값을 백업을 실행하는 빈도로 바꿉니다. 이 예제에는 30분마다 일정이 있습니다. 자세한 내용은 동기화 스케줄링 을 참조하십시오.

PruneIntervalDays 값을 데이터를 다시 압축하여 공간을 절약하기 위해 경과한 일 수로 바꿉니다. 정리 작업을 수행하면 실행 중에 상당한 I/O 트래픽을 생성할 수 있습니다.

restic-config 를 1단계에서 생성한 보안 이름으로 교체합니다.

백업된 이미지의 보존 정책으로 보존 값을 설정합니다.

모범 사례: CopyMethod 값으로 Clone 을 사용하여 지정 시간 이미지가 저장되도록 합니다.

백업 옵션에 대한 자세한 내용은 WorkingSync 설명서의 백업 옵션을 참조하십시오.

다음 예와 유사한 ReplicationSource 사용자 정의 리소스를 만듭니다.

apiVersion: volsync.backube/v1alpha1
kind: ReplicationSource
metadata:
  name: <source>
  namespace: <source-ns>
spec:
  sourcePVC: <source-pvc>
  trigger:
    schedule: "*/6 * * * *" #\*
  rclone:
    rcloneConfigSection: <intermediate-s3-bucket>
    rcloneDestPath: <destination-bucket>
    rcloneConfig: <rclone-secret>
    copyMethod: Snapshot
    storageClassName: <my-sc-name>
    volumeSnapshotClassName: <my-vsc>

source-pvc 를 복제 소스 사용자 정의 리소스의 이름으로 교체합니다.

source-ns 를 소스가 있는 영구 볼륨 클레임의 네임스페이스로 바꿉니다.

복제 중인 영구 볼륨 클레임으로 소스를 교체합니다.

일정 값을 복제 실행 빈도로 바꿉니다. 이 예제에는 6분마다 일정이 있습니다. 이 값은 따옴표 내에 있어야 합니다. 자세한 내용은 동기화 스케줄링 을 참조하십시오.

intermediate-s3-bucket 을 Rclone 구성 파일의 구성 섹션 경로로 바꿉니다.

destination-bucket 을 복제된 파일을 복사하려는 오브젝트 버킷의 경로로 교체합니다.

rclone-secret 을 Rclone 구성 정보가 포함된 시크릿 이름으로 교체합니다.

copyMethod 의 값을 Clone,Direct, Snapshot 으로 설정합니다. 이 값은 지정 시간 복사가 생성되는지 여부를 지정하고, 그렇다면 이를 생성하는 데 사용되는 메서드를 지정합니다.

my-sc-name 을 지정 시간 복사에 사용하려는 스토리지 클래스의 이름으로 바꿉니다. 지정하지 않으면 소스 볼륨의 스토리지 클래스가 사용됩니다.

Snapshot 을 copyMethod 로 지정한 경우 my-vsc 를 사용할 VolumeSnapshotClass 이름으로 교체합니다. 다른 유형의 copyMethod 에는 이 작업이 필요하지 않습니다.

다음 예와 유사한 ReplicationDestination 사용자 정의 리소스를 만듭니다.

apiVersion: volsync.backube/v1alpha1
kind: ReplicationDestination
metadata:
  name: database-destination
  namespace: dest
spec:
  trigger:
    schedule: "3,9,15,21,27,33,39,45,51,57 * * * *" #/*
  rclone:
    rcloneConfigSection: <intermediate-s3-bucket>
    rcloneDestPath: <destination-bucket>
    rcloneConfig: <rclone-secret>
    copyMethod: Snapshot
    accessModes: [ReadWriteOnce]
    capacity: 10Gi
    storageClassName: <my-sc>
    volumeSnapshotClassName: <my-vsc>

일정 값을 복제를 대상으로 이동하는 빈도로 바꿉니다. 데이터가 대상에서 가져오기 전에 복제를 완료할 수 있도록 소스 및 대상의 일정을 오프셋해야 합니다. 이 예제에는 6분마다 일정이 있으며 3분 간격으로 오프셋됩니다. 이 값은 따옴표 내에 있어야 합니다. 자세한 내용은 동기화 스케줄링 을 참조하십시오.

intermediate-s3-bucket 을 Rclone 구성 파일의 구성 섹션 경로로 바꿉니다.

destination-bucket 을 복제된 파일을 복사하려는 오브젝트 버킷의 경로로 교체합니다.

rclone-secret 을 Rclone 구성 정보가 포함된 시크릿 이름으로 교체합니다.

copyMethod 의 값을 Clone,Direct, Snapshot 으로 설정합니다. 이 값은 지정 시간 복사가 생성되는지 여부와 같은 경우 이를 생성하는 데 사용되는 메서드를 지정합니다.

accessModes 값은 영구 볼륨 클레임의 액세스 모드를 지정합니다. 유효한 값은 ReadWriteOnce 또는 ReadWriteMany 입니다.

capacity 는 대상 볼륨의 크기를 지정합니다. 이 크기는 들어오는 데이터를 포함할 수 있을 만큼 커야 합니다.

my-sc 를 지정 시간 복사의 대상으로 사용할 스토리지 클래스의 이름으로 바꿉니다. 지정하지 않으면 시스템 스토리지 클래스가 사용됩니다.

Snapshot 을 copyMethod 로 지정한 경우 my-vsc 를 사용할 VolumeSnapshotClass 이름으로 교체합니다. 다른 유형의 copyMethod 에는 이 작업이 필요하지 않습니다. 포함되지 않은 경우 시스템 기본 VolumeSnapshotClass 가 사용됩니다.