アドオン

次のコマンドを実行して <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 を、ブローカーの namespace に置き換えます。

Globalnet を有効にするには、true-or-false を true に置き換えます。

注:メタデータ名 パラメーターは 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:
    gatewayConfig:
      gateways: 1

managed-cluster-namespace をマネージドクラスターの名前に置き換えます。以下の例のように、SubmarinerConfig の名前は submariner である必要があります。

この設定では、ワーカーノードの 1 つをベアメタルクラスターの Submariner ゲートウェイとしてラベル付けします。

デフォルトでは、Submariner は IP セキュリティー (IPsec) を使用して、ゲートウェイノード上のクラスター間でセキュアなトンネルを確立します。デフォルトの IPsec NATT ポートを使用するか、設定した別のポートを指定できます。IPsec NATT ポートを指定せずに、この手順を実行すると、接続に 4500/UDP が使用されます。

Azure CLI から、次のコマンドを実行して拡張機能をインストールします。

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

.whl 拡張ファイルをダウンロードした場所へのパスに path-to-extension を置き換えます。

次のコマンドを実行して、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 mode を選択し、Kubeconfig ウィンドウで kubeconfig ファイルの内容を入力します。コンソールの指示に従ってインポートを完了します。

Infrastructure > Clusters に移動して、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'

次のコマンドを実行して、OpenShift Service on AWS にログインします。

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

次のコマンドを実行して、OpenShift Service on AWS クラスターの kubeconfig を作成します。

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

Kubeconfig Import mode を選択し、Kubeconfig ウィンドウで kubeconfig ファイルの内容を入力します。コンソールの指示に従ってインポートを完了します。

Infrastructure > Clusters に移動して、OpenShift Service on AWS クラスターが正常にインポートされたことを確認できます。

ManagedClusterSet の作成 ドキュメントに記載されている手順を使用して、ハブクラスターに ManagedClusterSet リソースを作成します。ManagedClusterSet のエントリーが次の内容のようになっていることを確認してください。

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

managed-cluster-set-name は、作成する ManagedClusterSet の名前に置き換えます。

重要: Kubernetes namespace の最大文字数は 63 文字です。<managed-cluster-set-name> に使用できる最大文字数は 56 文字です。<managed-cluster-set-name> の文字数が 56 文字を超える場合、<managed-cluster-set-name> は先頭から切り捨てられます。

ManagedClusterSet が作成されたら、submariner-addon は <managed-cluster-set-name>-broker と呼ばれる namespace を作成し、その namespace に Submariner ブローカーをデプロイします。

次の例のような YAML コンテンツをカスタマイズして適用することにより、<managed-cluster-set-name>-broker namespace のハブクラスターに 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 に設定します。

次のコマンドを実行して、1 つのマネージドクラスターを ManagedClusterSet に追加します。

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

managedcluster-name は、ManagedClusterSet に追加するマネージドクラスターの名前に置き換えます。

ManagedClusterSet-name は、マネージドクラスターを追加する ManagedClusterSet の名前に置き換えます。

次の例のような YAML コンテンツをカスタマイズして適用します。

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

managed-cluster-namespace は、マネージドクラスターの 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

managedcluster-name は、Submariner で使用するマネージドクラスターの名前に置き換えます。

ManagedClusterAddOn の仕様の installNamespace フィールドは、Submariner をインストールするマネージドクラスター上の namespace に置き換えます。現在、Submariner-operator namespace に Submariner をインストールする必要があります。

ManagedClusterAddOn の作成後に、submariner-addon は Submariner をマネージドクラスターの submariner-operator namespace にデプロイします。この ManagedClusterAddOn のステータスから Submariner のデプロイメントステータスを表示できます。

注記: ManagedClusterAddOn の名前は submariner である必要があります。

マネージドクラスターに Submariner をデプロイしたら、次のコマンドを入力して、Submariner ManagedClusterAddOn のステータスを確認して、Submariner のデプロイメントステータスを確認できます。

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

cluster-name は、マネージドクラスターの名前に置き換えます。

Submariner ManagedClusterAddOn のステータスの 3 つの条件により、Submariner のデプロイメントステータスが分かります。

以下のコマンドを入力して、ManagedClusterSet のマネージドクラスターに nginx サービスのインスタンスを適用します。

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

次のコマンドのような subctl ツールを使用してコマンドを入力し、ServiceExport エントリーを作成して、サービスをエクスポートします。

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

service-namespace を、サービスが置かれた namespace の名前に置き換えます。この例では、default になります。

service-name を、エクスポートするサービスの名前に置き換えます。この例では、nginx になります。

その他の使用可能なフラグの詳細は、Submariner ドキュメントの export を参照してください。

別のマネージドクラスターから以下のコマンドを実行して、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 を削除する他のクラスターについても、これらの手順を繰り返します。

ヒント: 複数のクラスターを選択して Actions をクリックすると、同じクラスターセット内の複数のクラスターから Submariner アドオンを削除できます。Uninstall Submariner add-ons を選択します。

次のコマンドを実行して、クラスターの Submariner デプロイメントを削除します。

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

managed-cluster-namespace は、マネージドクラスターの namespace に置き換えます。

次のコマンドを実行して、クラスターのクラウドリソースを削除します。

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

managed-cluster-namespace は、マネージドクラスターの 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 コマンドを実行してリポジトリーを初期化する必要がある手順をスキップしてください。VolSync は、最初のバックアップ中にリポジトリーを自動的に初期化します。

重要: 複数の永続ボリューム要求を同じ 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

source は、バックアップしている永続ボリュームクレームに置き換えます。

schedule の値は、バックアップを実行する頻度に置き換えます。この例では、30 分ごとにスケジュールが指定されています。詳しくは Synchronization のスケジュール を参照してください。

PruneIntervalDays の値は、インスタンスで次にデータの圧縮するまでの経過時間 (日数) に置き換えて、スペースを節約します。プルーニング操作は、実行中に大量の I/O トラフィックを生成する可能性があります。

restic-config は、ステップ 1 で作成したシークレットの名前に置き換えます。

retain の値は、バックアップしたイメージの保持ポリシーに設定します。

ベストプラクティス: CopyMethod の値に Clone を使用して、特定の時点のイメージが確実に保存されるようにします。

バックアップオプションの詳細は、VolSync ドキュメントの Backup options を参照してください。

次の例のような 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 をソースが置かれている Persistent Volume Claim の namespace に置き換えます。

source は、レプリケートしている永続ボリュームクレームに置き換えます。

スケジュール の値は、レプリケーションを実行する頻度に置き換えます。この例では、6 分ごとにスケジュールが指定されています。この値は引用符で囲む必要があります。詳しくは Synchronization のスケジュール を参照してください。

Intermediate-s3-bucket は、Rclone 設定ファイルの設定セクションへのパスに置き換えます。

destination-bucket は、レプリケートされたファイルをコピーするオブジェクトバケットへのパスに置き換えます。

rclone-secret は、Rclone 設定情報を含むシークレットの名前に置き換えます。

copyMethod の値は Clone、Direct、または Snapshot として設定します。この値は、ある特定の時点でのコピーを生成するかどうか、生成する場合は、生成方法を指定します。

my-sc-name は、ポイントインタイムコピーに使用するストレージクラスの名前に置き換えます。指定しない場合、ソースボリュームのストレージクラスが使用されます。

スナップショット を 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>

スケジュール の値は、レプリケーションを宛先に移動する頻度に置き換えます。移動元と宛先のスケジュールをオフセットして、データが宛先からプルされる前に複製を完了できるようにする必要があります。この例では、オフセットは 3 分で、6 分間隔でスケジュールされています。この値は引用符で囲む必要があります。詳しくは Synchronization のスケジュール を参照してください。

Intermediate-s3-bucket は、Rclone 設定ファイルの設定セクションへのパスに置き換えます。

destination-bucket は、レプリケートされたファイルをコピーするオブジェクトバケットへのパスに置き換えます。

rclone-secret は、Rclone 設定情報を含むシークレットの名前に置き換えます。

copyMethod の値は Clone、Direct、または Snapshot として設定します。この値は、ある特定の時点でのコピーを生成するかどうか、生成する場合は、生成方法を指定します。

accessModes の値は、永続ボリュームクレームのアクセスモードを指定します。有効な値は ReadWriteOnce または ReadWriteMany です。

容量 は宛先ボリュームのサイズを指定します。このサイズは、着信データを格納するのに十分な大きさに指定します。

my-sc は、特定の時点のコピーの宛先として使用するストレージクラスの名前に置き換えます。指定しない場合、システムストレージクラスが使用されます。

スナップショット を copyMethod として指定した場合は my-vsc を使用する VolumeSnapshotClass の名前に置き換えます。これは、他のタイプの copyMethod には必要ありません。含まれていない場合は、システムのデフォルトの VolumeSnapshotClass が使用されます。