./subscribe/channel.yaml ファイルを更新して、stolostron ではなく、フォークしたリポジトリーの GitHub 名にアクセスするように spec: pathname を変更します。この手順では、ハブクラスターによるリリースイメージの取得先を指定します。更新後の内容は以下の例のようになります。

spec:
  type: Git
  pathname: https://github.com/<forked_content>/acm-hive-openshift-releases.git

forked_content はフォークしたリポジトリーのへのパスに置き換えます。

acm-hive-openshift-releases リポジトリーをクローンした後に fast リリースイメージの一覧を同期するには、以下のコマンドを入力して fast イメージを更新します。

make subscribe-fast

注記: この make コマンドは、Linux または MacOS のオペレーティングシステムを使用している場合のみ実行できます。

このコマンドを実行後に、利用可能な fast リリースイメージの一覧が、現在利用可能なイメージに約 1 分ほどで更新されます。

デフォルトでは、fast イメージのみが一覧表示されます。stable リリースイメージを同期して表示するには、以下のコマンドを実行します。

make subscribe-stable

注記: この make コマンドは、Linux または MacOS のオペレーティングシステムを使用している場合のみ実行できます。

このコマンドを実行後に、利用可能な安定版のリリースイメージの一覧が、現在利用可能なイメージに約 1 分ほどで更新されます。

デフォルトでは、Red Hat Advanced Cluster Management は、複数の ClusterImageSets を事前に読み込みます。以下のコマンドを使用して、利用可能ものを表示し、デフォルトの設定を削除します。

oc get clusterImageSets
oc delete clusterImageSet <clusterImageSet_NAME>

注記: multiclusterhub の disableUpdateClusterImageSets の値を true に設定して、インストーラー管理の ClusterImageSets の自動更新をまだ無効にしていない場合は、削除するイメージが自動的に再作成されます。

管理対象クラスターに適合する次の手順を実行して、管理対象クラスターと切断されたリポジトリーの間にクラスターイメージセットを含むマッピングを追加します。

残りの OpenShift Container Platform リリースイメージの clusterImageSet YAML ファイルを、イメージの保存先の正しいオフラインリポジトリーを参照するように変更します。更新は次の例のようになります。

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
    name: img4.4.0-rc.6-x86-64
spec:
    releaseImage: IMAGE_REGISTRY_IPADDRESS_or_DNSNAME/REPO_PATH/ocp-release:4.4.0-rc.6-x86_64

YAML ファイルで参照されているオフラインイメージレジストリーにイメージがロードされていることを確認します。

各 YAML ファイルに以下のコマンドを入力して、各 clusterImageSets を作成します。

oc create -f <clusterImageSet_FILE>

clusterImageSet_FILE を、クラスターイメージセットファイルの名前に置き換えます。以下は例になります。

oc create -f img4.9.9-x86_64.yaml

追加するリソースごとにこのコマンドを実行すると、利用可能なリリースイメージの一覧が使用できるようになります。

以下の BareMetalAsset および Secret CR を作成し、ファイルを baremetalasset-cr.yaml として保存します。

apiVersion: inventory.open-cluster-management.io/v1alpha1
kind: BareMetalAsset
metadata:
  name: <baremetalasset-machine>
  namespace: <baremetalasset-namespace>
spec:
  bmc:
    address: ipmi://<out_of_band_ip>:<port>
    credentialsName: baremetalasset-machine-secret
  bootMACAddress: "00:1B:44:11:3A:B7"
  hardwareProfile: "hardwareProfile"
  role: "<role>"
  clusterName: "<cluster name>"
---
apiVersion: v1
kind: Secret
metadata:
  name: baremetalasset-machine-secret
type: Opaque
data:
  username: <username>
  password: <password>

以下のコマンドを実行して BareMetalAsset CR を作成します。

$ oc create -f baremetalasset-cr.yaml

BareMetalAsset が正常に作成されていることを確認します。

$ oc get baremetalassets -A

NAMESPACE   		    NAME                              AGE
ocp-example-bm      baremetalasset-machine   			    2m
ocp-example-bm      csv-f24-h27-000-r630-master-1-1   4d21h

Import assets を選択し、ベアメタルアセットのデータを含む CSV ファイルをインポートします。CSV ファイルには、以下のヘッダーコラムが必要です。

hostName, hostNamespace, bmcAddress, macAddress, role (optional), username, password

ハブクラスターのログイントークンを取得して、コマンドラインでクラスターにログインします。以下は例になります。

$ oc login --token=<login_token> --server=https://<hub_cluster_api_url>:6443

以下の curl コマンドを、クラスターに追加するベアメタルアセットの詳細を使用して変更し、コマンドを実行します。

$ curl --location --request POST '<hub_cluster_api_url>:6443/apis/inventory.open-cluster-management.io/v1alpha1/namespaces/<bare_metal_asset_namespace>/baremetalassets?fieldManager=kubectl-create' \
--header 'Authorization: Bearer <login_token>' \
--header 'Content-Type: application/json' \
--data-raw '{
    "apiVersion": "inventory.open-cluster-management.io/v1alpha1",
    "kind": "BareMetalAsset",
    "metadata": {
        "name": "<baremetalasset_name>",
        "namespace": "<bare_metal_asset_namespace>"
    },
    "spec": {
        "bmc": {
            "address": "ipmi://<ipmi_address>",
            "credentialsName": "<credentials-secret>"
        },
        "bootMACAddress": "<boot_mac_address>",
        "clusterName": "<cluster_name>",
        "hardwareProfile": "hardwareProfile",
        "role": "worker"
    }
}'

Clusters ページで、Create cluster をクリックします。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、ハブクラスターへのターゲットマネージドクラスターのインポート の手順を参照してください。

クラスターの詳細を追加します。

コントロールプレーンプールに関する詳細を入力します。コントロールプレーンプールには、クラスター向けに作成されたコントロールプレーンノードが 3 つあります。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。オプションの情報には以下のフィールドが含まれます。

ワーカープールに関する情報を入力します。ワーカープールにワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。オプションの情報には以下のフィールドが含まれます。

クラスターのネットワーク情報を入力します。この情報は必須です。IPv6 を使用するには、複数のネットワークが必要です。

クラスターのインストールまたはアップグレードの前後に実行する Ansible Automation template (任意) を追加します。

Add automation template をクリックしてテンプレートを作成できます。

情報を確認し、必要に応じてカスタマイズします。

Create を選択してクラスターを作成します。

注記: クラスターのインポートには、クラスターの詳細で提示された kubectl コマンドを実行する必要はありません。クラスターを作成すると、Red Hat Advanced Cluster Management で管理されるように自動的に設定されます。

Clusters ページで、Create cluster をクリックします。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、ハブクラスターへのターゲットマネージドクラスターのインポート の手順を参照してください。

クラスターの詳細を追加します。

コントロールプレーンプールに関する詳細を入力します。コントロールプレーンプールには、クラスター向けに作成されたコントロールプレーンノードが 3 つあります。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。オプションの情報には以下のフィールドが含まれます。

ワーカープールに関する情報を入力します。ワーカープールにワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。オプションの情報には以下のフィールドが含まれます。

クラスターのネットワーク情報を入力します。この情報は必須です。IPv6 を使用するには、複数のネットワークが必要です。

クラスターのインストールまたはアップグレードの前後に実行する Ansible Automation template (任意) を追加します。

Add automation template をクリックしてテンプレートを作成できます。

情報を確認し、必要に応じてカスタマイズします。

Create を選択してクラスターを作成します。

注記: クラスターのインポートには、クラスターの詳細で提示された kubectl コマンドを実行する必要はありません。クラスターを作成すると、Red Hat Advanced Cluster Management で管理されるように自動的に設定されます。

Clusters ページで、Create Cluster タブを選択します。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、ハブクラスターへのターゲットマネージドクラスターのインポート の手順を参照してください。

クラスターの詳細を追加します。

コントロールプレーンプールに関する詳細を入力します。コントロールプレーンプールには、クラスター向けに作成されたコントロールプレーンノードが 3 つあります。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。オプションの情報には以下のフィールドが含まれます。

ワーカープールに関する情報を入力します。ワーカープールにワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。オプションの情報には以下のフィールドが含まれます。

クラスターのネットワーク情報を入力します。この情報は必須です。IPv6 を使用するには、複数のネットワークが必要です。

クラスターのインストールまたはアップグレードの前後に実行する Ansible Automation template (任意) を追加します。

Add automation template をクリックしてテンプレートを作成できます。

情報を確認し、必要に応じてカスタマイズします。

Create を選択してクラスターを作成します。

注記: クラスターのインポートには、クラスターの詳細で提示された kubectl コマンドを実行する必要はありません。クラスターを作成すると、Red Hat Advanced Cluster Management で管理されるように自動的に設定されます。

Clusters ページで、Create cluster をクリックします。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、ハブクラスターへのターゲットマネージドクラスターのインポート の手順を参照してください。

クラスターの詳細を追加します。

コントロールプレーンプールに関する詳細を入力します。コントロールプレーンプールには、クラスター向けに作成されたコントロールプレーンノードが 3 つあります。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。必要な情報には以下のフィールドが含まれます。

ワーカープールに関する情報を入力します。ワーカープールにワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。情報には以下のフィールドが含まれます。

クラスターネットワークオプションを設定します。この情報は必須です。IPv6 を使用するには、複数のネットワークが必要です。

クラスターのインストールまたはアップグレードの前後に実行する Ansible Automation template (任意) を追加します。

Add automation template をクリックしてテンプレートを作成できます。

情報を確認し、必要に応じてカスタマイズします。

Create を選択してクラスターを作成します。

注記: クラスターのインポートには、クラスターの詳細で提示された kubectl コマンドを実行する必要はありません。クラスターを作成すると、Red Hat Advanced Cluster Management で管理されるように自動的に設定されます。

Clusters ページで、Create cluster をクリックします。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、ハブクラスターへのターゲットマネージドクラスターのインポート の手順を参照してください。

クラスターの詳細を追加します。

コントロールプレーンノードの詳細を入力します。コントロールプレーンプールには、クラスター向けに作成されたコントロールプレーンノードが 3 つあります。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。オプションの情報には以下のフィールドが含まれます。

ワーカープールに関する情報を入力します。ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。オプションの情報には以下のフィールドが含まれます。

クラスターのネットワーク情報を入力します。IPv4 ネットワーク用に 1 つ以上のネットワークの値を指定する必要があります。IPv6 ネットワークの場合は、複数のネットワークを定義する必要があります。

クラスターのインストールまたはアップグレードの前後に実行する Ansible Automation template (任意) を追加します。

Add automation template をクリックしてテンプレートを作成できます。

情報を確認し、必要に応じてカスタマイズします。

Create を選択してクラスターを作成します。

注記: クラスターのインポートには、クラスターの詳細で提示された kubectl コマンドを実行する必要はありません。クラスターを作成すると、Red Hat Advanced Cluster Management で管理されるように自動的に設定されます。

Clusters ページで、Create cluster をクリックします。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、ハブクラスターへのターゲットマネージドクラスターのインポート の手順を参照してください。

クラスターの詳細を追加します。

認証情報に関連付けられたホスト一覧から、お使いのホストを選択します。ハイパーバイザーと同じブリッジネットワークにあるベアメタルアセットを 3 つ以上選択します。

ホストの一覧は、既存のベアメタルアセットからコンパイルされます。ベアメタルホストで最新のファームウェアを実行していることを確認してください。実行していないと、プロビジョニングが失敗する可能性があります。ベアメタルアセットを作成していない場合は、作成プロセスを続行する前に Import assets を選択して作成またはインポートを行うことができます。ベアメタルアセットの詳細は、ベアメタルアセットの作成および変更 を参照してください。Disable certificate verification を選択して要件を無視することができます。

クラスターネットワークオプションを設定します。以下の表では、ネットワークオプションとその説明をまとめています。

Add network をクリックして、追加のネットワークを追加できます。IPv6 アドレスを使用している場合は、複数のネットワークが必要です。

クラスターのインストールまたはアップグレードの前後に実行する Ansible Automation template (任意) を追加します。

Add automation template をクリックしてテンプレートを作成できます。

情報を確認し、必要に応じてカスタマイズします。

Create を選択してクラスターを作成します。

注記: クラスターのインポートには、クラスターの詳細で提示された kubectl コマンドを実行する必要はありません。クラスターを作成すると、Red Hat Advanced Cluster Management で管理されるように自動的に設定されます。

クラスターの詳細を追加します。

クラスターを確認し、保存します。

ヒント: この時点でクラスターを確認し、保存した後に、クラスターはドラフトクラスターとして保存されます。Clusters ページでクラスター名を選択すると、作成プロセスを閉じてプロセスを終了することができます。

独自にホストを選択するかどうか、またはそれらのホストを自動的に選択するかを選びます。ホストの数は、選択したノード数に基づいています。たとえば、SNO クラスターではホストが 1 つだけ必要ですが、標準の 3 ノードクラスターには 3 つのホストが必要です。

このクラスターの要件を満たす利用可能なホストの場所は、ホストの場所 の一覧に表示されます。ホストと高可用性設定の分散については、複数の場所を選択します。

以下の IP アドレスを追加します。

以下のコマンドを入力して、休止するクラスターの設定を編集します。

oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>

name-of-cluster は、休止するクラスター名に置き換えます。

namespace-of-cluster は、休止するクラスターの namespace に置き換えます。

以下のコマンドを実行して、クラスターのステータスを表示します。

oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml

name-of-cluster は、休止するクラスター名に置き換えます。

namespace-of-cluster は、休止するクラスターの namespace に置き換えます。

クラスターを休止するプロセスが完了すると、クラスターのタイプの値は type=Hibernating になります。

以下のコマンドを入力してクラスターの設定を編集します。

oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>

name-of-cluster は、休止するクラスター名に置き換えます。

namespace-of-cluster は、休止するクラスターの namespace に置き換えます。

以下のコマンドを実行して、クラスターのステータスを表示します。

oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml

name-of-cluster は、休止するクラスター名に置き換えます。

namespace-of-cluster は、休止するクラスターの namespace に置き換えます。

クラスターの再開プロセスが完了すると、クラスターのタイプの値は type=Running になります。

オプション: ラベル を追加します。

注記: Red Hat OpenShift Dedicated クラスターをインポートし、vendor=OpenShiftDedicated のラベルを追加してベンダーが指定されないようにする場合、または vendor=auto-detect のラベルを追加する場合は、managed-by=platform ラベルがクラスターに自動的に追加されます。この追加ラベルを使用して、クラスターを Red Hat OpenShift Dedicated クラスターとして識別し、Red Hat OpenShift Dedicated クラスターをグループとして取得できます。

以下のオプションからインポートするクラスター特定に使用する インポートモード を選択します。

オプション: oc get managedcluster コマンドを実行する際に、テーブルに表示される URL を設定して、クラスターの詳細ページにある Cluster API アドレス を設定します。

以下のコマンドを実行して ハブクラスター にログインします。

oc login

ハブクラスターで以下のコマンドを実行し、プロジェクトおよび namespace を作成します。注記: CLUSTER_NAME で定義したクラスター名は、YAML ファイルおよびコマンドでクラスターの namespace としても使用します。

oc new-project ${CLUSTER_NAME}
oc label namespace ${CLUSTER_NAME} cluster.open-cluster-management.io/managedCluster=${CLUSTER_NAME}

以下の内容例で managed-cluster.yaml という名前のファイルを作成します。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: ${CLUSTER_NAME}
  labels:
    cloud: auto-detect
    vendor: auto-detect
spec:
  hubAcceptsClient: true

cloud および vendor の値を auto-detect する場合、Red Hat Advanced Cluster Management はインポートしているクラスターからクラウドおよびベンダータイプを自動的に検出します。オプションで、auto-detect の値をクラスターのクラウドおよびベンダーの値に置き換えることができます。以下の例を参照してください。

cloud: Amazon
vendor: OpenShift

以下のコマンドを入力して、YAML ファイルを ManagedCluster リソースに適用します。

oc apply -f managed-cluster.yaml

${CLUSTER_NAME} namespace に auto-import-secret.yaml ファイルを作成します。

インポートしたクラスターのステータス (JOINED および AVAILABLE) を確認します。ハブクラスターから以下のコマンドを実行します。

oc get managedcluster ${CLUSTER_NAME}

管理対象クラスターで次のコマンドを実行して、管理対象クラスターにログインします。

oc login

次のコマンドを実行して、インポートするクラスターの Pod ステータスを検証します。

oc get pod -n open-cluster-management-agent

以下のコマンドを実行して、ハブクラスターでインポートコントローラーによって生成された klusterlet-crd.yaml ファイルを取得します。

oc get secret ${CLUSTER_NAME}-import -n ${CLUSTER_NAME} -o jsonpath={.data.crds\\.yaml} | base64 --decode > klusterlet-crd.yaml

以下のコマンドを実行して、ハブクラスターにインポートコントローラーによって生成された import.yaml ファイルを取得します。

oc get secret ${CLUSTER_NAME}-import -n ${CLUSTER_NAME} -o jsonpath={.data.import\\.yaml} | base64 --decode > import.yaml

インポートするクラスターで次の手順を実行します。

次のコマンドを入力して、インポートする管理対象クラスターにログインします。

oc login

以下のコマンドを実行して、手順 1 で生成した klusterlet-crd.yaml を適用します。

oc apply -f klusterlet-crd.yaml

以下のコマンドを実行して、以前に生成した import.yaml ファイルを適用します。

oc apply -f import.yaml

インポートしているクラスターの JOINED および AVAILABLE のステータスを検証します。ハブクラスターから以下のコマンドを実行します。

oc get managedcluster ${CLUSTER_NAME}

以下の例のような YAML ファイルを作成します。

apiVersion: agent.open-cluster-management.io/v1
kind: KlusterletAddonConfig
metadata:
  name: <cluster_name>
  namespace: <cluster_name>
spec:
  applicationManager:
    enabled: true
  certPolicyController:
    enabled: true
  iamPolicyController:
    enabled: true
  policyController:
    enabled: true
  searchCollector:
    enabled: true

以下のコマンドを実行して YAML を適用します。

oc apply -f klusterlet-addon-config.yaml

ManagedCluster-Import-Controller は ${CLUSTER_NAME}-import という名前のシークレットを生成します。${CLUSTER_NAME}-import シークレットには、import.yaml が含まれており、このファイルをユーザーがマネージドクラスターに適用して klusterlet をインストールします。

アドオンは、インポートするクラスターの AVAILABLE の後にインストールされます。

次のコマンドを実行して、インポートするクラスター上のアドオンの Pod ステータスを検証します。

oc get pod -n open-cluster-management-agent-addon

クラスターをインポートする必要のある namespace にプルシークレットを作成します。これらの手順では、これは myNamespace です。

$ kubectl create secret docker-registry myPullSecret \
  --docker-server=<your-registry-server> \
  --docker-username=<my-name> \
  --docker-password=<my-password>

作成した namespace に Placement を作成します。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: myPlacement
  namespace: myNamespace
spec:
  clusterSets:
  - myClusterSet

ManagedClusterSet リソースを作成し、これを namespace にバインドします。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ManagedClusterSet
metadata:
  name: myClusterSet

---
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ManagedClusterSetBinding
metadata:
  name: myClusterSet
  namespace: myNamespace
spec:
  clusterSet: myClusterSet

namespace に ManagedClusterImageRegistry CRD を作成します。

apiVersion: imageregistry.open-cluster-management.io/v1alpha1
kind: ManagedClusterImageRegistry
metadata:
  name: myImageRegistry
  namespace: myNamespace
spec:
  placementRef:
    group: cluster.open-cluster-management.io
    resource: placements
    name: myPlacement
  pullSecret:
    name: myPullSecret
  registry: myRegistryAddress

以下のコマンドを入力してリソースを編集します。

kubectl edit klusterletaddonconfigs.agent.open-cluster-management.io <cluster-name> -n <cluster-name>

Save を選択して変更を保存します。

注記: マネージドクラスターを別のマネージドクラスターセットに移動する場合は、マネージドクラスター両方で RBAC パーミッションの設定が必要です。

managedclustersets/join の仮想サブリソースに作成できるように、RBAC ClusterRole エントリーが追加されていることを確認します。このパーミッションがない場合は、マネージドクラスターを ManagedClusterSet に割り当てることはできません。

このエントリーが存在しない場合は、yaml ファイルに追加します。サンプルエントリーは以下の内容のようになります。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: clusterrole1
rules:
  - apiGroups: ["cluster.open-cluster-management.io"]
    resources: ["managedclustersets/join"]
    resourceNames: ["<clusterset1>"]
    verbs: ["create"]

clusterset1 は ManagedClusterSet の名前に置き換えます。

注記: マネージドクラスターを別の ManagedClusterSet に移動する場合には、マネージドクラスターセット両方でパーミッションの設定が必要です。

yaml ファイルでマネージドクラスターの定義を検索します。ラベルの追加先のマネージドクラスター定義のセクションは、以下の内容のようになります。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true

この例では、cluster1 はマネージドクラスターの名前です。

ManagedClusterSet の名前を cluster.open-cluster-management.io/clusterset: clusterset1 形式で指定してラベルを追加します。

コードは以下の例のようになります。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
  labels:
    cluster.open-cluster-management.io/clusterset: clusterset1
spec:
  hubAcceptsClient: true

この例では、cluster1 は、clusterset1 のマネージドクラスターセット名に追加するクラスターです。

注記: マネージドクラスターが削除済みのマネージドクラスターセットにこれまでに割り当てられていた場合は、すでに存在しないクラスターが指定されたマネージドクラスターセットがマネージドクラスターに設定されている可能性があります。その場合は、名前を新しい名前に置き換えます。

Manage resource assignments ページで、クラスターセットから削除するリソースのチェックボックスを選択します。

この手順では、クラスターセットのメンバーであるリソースを削除するか、クラスターセットのメンバーでないリソースを追加します。マネージドクラスターの詳細を表示して、リソースがすでにクラスターセットのメンバーであるかどうかを確認できます。

以下のコマンドを実行して、マネージドクラスターセットでマネージドクラスターのリストを表示します。

oc get managedclusters -l cluster.open-cluster-management.io/clusterset=<clusterset1>

clusterset1 はマネージドクラスターセットの名前を置き換えます。

削除するクラスターの yaml エントリーからラベルを削除します。ラベルの例については、以下のコードを参照してください。

labels:
   cluster.open-cluster-management.io/clusterset: clusterset1

namespace および認証情報を選択します。

フィルターを設定して、関連するクラスターを検出します。

以下の例のような内容を含むスクリプトファイルを作成します。

UPSTREAM_REGISTRY=quay.io
PRODUCT_REPO=openshift-release-dev
RELEASE_NAME=ocp-release
OCP_RELEASE=4.5.2-x86_64
LOCAL_REGISTRY=$(hostname):5000
LOCAL_SECRET_JSON=/path/to/pull/secret

oc adm -a ${LOCAL_SECRET_JSON} release mirror \
--from=${UPSTREAM_REGISTRY}/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \
--to=${LOCAL_REGISTRY}/ocp4 \
--to-release-image=${LOCAL_REGISTRY}/ocp4/release:${OCP_RELEASE}

path-to-pull-secret は、OpenShift Container Platform のプルシークレットへのパスに置き換えます。

Operator のインストールが完了するまで待ちます。

ヒント: OpenShift Container Platform コマンドラインで oc get pods コマンドを入力して、インストールのステータスを確認できます。Operator の状態が running であることを確認します。

以下のコマンドを入力して、グラフデータ Git リポジトリーのクローンを作成します。

git clone https://github.com/openshift/cincinnati-graph-data

グラフデータの init の情報が含まれるファイルを作成します。このサンプル Dockerfile は、cincinnati-operator GitHub リポジトリーにあります。ファイルの内容は以下の例のようになります。

FROM registry.access.redhat.com/ubi8/ubi:8.1

RUN curl -L -o cincinnati-graph-data.tar.gz https://github.com/openshift/cincinnati-graph-data/archive/master.tar.gz

RUN mkdir -p /var/lib/cincinnati/graph-data/

CMD exec /bin/bash -c "tar xvzf cincinnati-graph-data.tar.gz -C /var/lib/
cincinnati/graph-data/ --strip-components=1"

この例では、以下のように設定されています。

以下のコマンドを実行して、 graph data init container をビルドします。

podman build -f <path_to_Dockerfile> -t ${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container:latest
podman push ${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container:latest --authfile=/path/to/pull_secret.json

path_to_Dockerfile は、直前の手順で作成したファイルへのパスに置き換えます。

${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container は、ローカルグラフデータ init container へのパスに置き換えます。

/path/to/pull_secret は、プルシークレットへのパスに置き換えます。

注記: podman がインストールされていない場合は、コマンドの podman を docker に置き換えることもできます。

image.config.openshift.io にある OpenShift Container Platform 外部レジストリー API を検索します。これは、外部レジストリーの CA 証明書の保存先です。

詳細は、OpenShift Container Platform ドキュメントの イメージレジストリーアクセス用の追加のトラストストアの設定 を参照してください。

キー updateservice-registry の下に CA 証明書を追加します。OpenShift Update Service はこの設定を使用して、証明書を特定します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: trusted-ca
data:
  updateservice-registry: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

image.config.openshift.io API の cluster リソースを編集して、additionalTrustedCA フィールドを作成した ConfigMap 名に設定します。

oc patch image.config.openshift.io cluster -p '{"spec":{"additionalTrustedCA":{"name":"trusted-ca"}}}' --type merge

trusted-ca は、新しい ConfigMap へのパスに置き換えます。

デフォルトの Operator の namespace (openshift-cincinnati) を使用しない場合は、お使いの OpenShift Update Service インスタンスの namespace を作成します。

OpenShift Update Service インスタンスからコンテンツを貼り付けます。YAML ファイルは以下のマニフェストのようになります。

apiVersion: cincinnati.openshift.io/v1beta2
kind: Cincinnati
metadata:
  name: openshift-update-service-instance
  namespace: openshift-cincinnati
spec:
  registry: <registry_host_name>:<port>
  replicas: 1
  repository: ${LOCAL_REGISTRY}/ocp4/release
  graphDataImage: '<host_name>:<port>/cincinnati-graph-data-container'

spec.registry の値は、イメージの非接続環境にあるローカルレジストリーへのパスに置き換えます。

spec.graphDataImage の値は、グラフデータ init container へのパスに置き換えます。ヒント: これは、podman push コマンドを使用して、グラフデータ init container をプッシュする時に使用した値と同じです。

以下の YAML コンテンツをウィンドウに貼り付け、カスタムポリシーを作成します。

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-pod
  namespace: default
  annotations:
    policy.open-cluster-management.io/standards:
    policy.open-cluster-management.io/categories:
    policy.open-cluster-management.io/controls:
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-pod-sample-nginx-pod
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: v1
                kind: Pod
                metadata:
                  name: sample-nginx-pod
                  namespace: default
                status:
                  phase: Running
          remediationAction: inform
          severity: low
  remediationAction: enforce
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-pod
  namespace: default
placementRef:
  name: placement-policy-pod
  kind: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-pod
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-pod
  namespace: default
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      []  # selects all clusters if not specified

テンプレートの objectDefinition セクション内のコンテンツは、ImageContentSourcePolicy の設定を追加する以下の内容に置き換えます。

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: <your-local-mirror-name>
spec:
  repositoryDigestMirrors:
  - mirrors:
    - <your-registry>
    source: registry.redhat.io

以下の YAML コンテンツをウィンドウに貼り付け、カスタムポリシーを作成します。

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-pod
  namespace: default
  annotations:
    policy.open-cluster-management.io/standards:
    policy.open-cluster-management.io/categories:
    policy.open-cluster-management.io/controls:
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-pod-sample-nginx-pod
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: v1
                kind: Pod
                metadata:
                  name: sample-nginx-pod
                  namespace: default
                status:
                  phase: Running
          remediationAction: inform
          severity: low
  remediationAction: enforce
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-pod
  namespace: default
placementRef:
  name: placement-policy-pod
  kind: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-pod
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-pod
  namespace: default
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      []  # selects all clusters if not specified

以下の内容をポリシーに追加します。

apiVersion: config.openshift.io/vi
kind: OperatorHub
metadata:
 name: cluster
spec:
 disableAllDefaultSources: true

以下の内容を追加します。

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: my-operator-catalog
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: <registry_host_name>:<port>/olm/redhat-operators:v1
  displayName: My Operator Catalog
  publisher: grpc

spec.image の値は、ローカルの制約付きのカタログソースイメージへのパスに置き換えます。

マネージドクラスターから、以下のコマンドを入力して ClusterVersion アップストリームパラメーターがデフォルトの OpenShift Update Service オペランドであることを確認します。

oc get clusterversion -o yaml

返される内容は以下のようになります。

apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.4
    upstream: https://api.openshift.com/api/upgrades_info/v1/graph

ハブクラスターから、oc get routes というコマンドを入力して OpenShift Update Service オペランドへのルート URL を特定します。

ヒント: 今後の手順で使用できるようにこの値をメモします。

以下の YAML コンテンツをウィンドウに貼り付け、カスタムポリシーを作成します。

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-pod
  namespace: default
  annotations:
    policy.open-cluster-management.io/standards:
    policy.open-cluster-management.io/categories:
    policy.open-cluster-management.io/controls:
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-pod-sample-nginx-pod
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: v1
                kind: Pod
                metadata:
                  name: sample-nginx-pod
                  namespace: default
                status:
                  phase: Running
          remediationAction: inform
          severity: low
  remediationAction: enforce
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-pod
  namespace: default
placementRef:
  name: placement-policy-pod
  kind: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-pod
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-pod
  namespace: default
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      []  # selects all clusters if not specified

policy セクションの policy.spec に以下の内容を追加します。

apiVersion: config.openshift.io/v1
  kind: ClusterVersion
  metadata:
    name: version
  spec:
    channel: stable-4.4
    upstream: https://example-cincinnati-policy-engine-uri/api/upgrades_info/v1/graph

spec.upstream の値は、ハブクラスター OpenShift Update Service オペランドへのパスに置き換えます。

ヒント: 以下の手順を実行すると、オペランドへのパスを確認できます。

マネージドクラスター CLI で、ClusterVersion のアップストリームパラメーターがローカルハブクラスター OpenShift Update Service URL に更新されていることを確認します。これには以下のコマンドを入力します。

oc get clusterversion -o yaml

結果は、以下の内容のようになります。

apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.4
    upstream: https://<hub-cincinnati-uri>/api/upgrades_info/v1/graph

オプションのアップグレードパスが利用可能であることを確認します。

注記: 現行バージョンがローカルのイメージリポジトリーにミラーリングされていないと、利用可能なアップグレードバージョンは表示されません。

etcd 履歴を圧縮します。

バックアップおよび復元 Operator、backupschedule.cluster.open-cluster-management.io および restore.cluster.open-cluster-management.io リソースを使用して、cluster_v1beta1_backupschedule.yaml サンプルファイルで、backupschedule.cluster.open-cluster-management.io リソースを作成します。cluster-backup-operator サンプル を参照してください。以下のコマンドを実行し、cluster_v1beta1_backupschedule.yaml サンプルファイルを使用して、backupschedule.cluster.open-cluster-management.io リソースを作成します。

kubectl create -n <oadp-operator-ns> -f config/samples/cluster_v1beta1_backupschedule.yaml

リソースは以下のファイルのようになります。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
  name: schedule-acm
spec:
  maxBackups: 10 # maximum number of backups after which old backups should be removed
  veleroSchedule: 0 */6 * * * # Create a backup every 6 hours
  veleroTtl: 72h # deletes scheduled backups after 72h; optional, if not specified, the maximum default value set by velero is used - 720h

backupschedule.cluster.open-cluster-management.io spec プロパティーに関する以下の説明を確認してください。

backupschedule.cluster.open-cluster-management.io リソースの状態をチェックします。3 つの schedule.velero.io リソースの定義が表示されます。以下のコマンドを実行します。

oc get bsch -n <oadp-operator-ns>

注意: 復元操作は、復元シナリオ向けに別のハブクラスターで実行します。復元操作を開始するには、バックアップを復元するハブクラスターに restore.cluster.open-cluster-management.io リソースを作成します。

クラスターのバックアップおよび復元 Operator、backup schedule.cluster.open-cluster-management.io および restore.cluster.open-cluster-management.io リソースを使用して、バックアップまたは復元リソースを作成できます。cluster-backup-operator サンプル を参照してください。

以下のコマンドを実行して、 cluster_v1beta1_restore.yaml サンプルファイルを使用して restore.cluster.open-cluster-management.io リソースを作成します。oadp-operator-ns は、OADP Operator のインストールに使用される namespace 名に置き換えます。OADP Operator インストール namespace のデフォルト値は oadp-operator です。

kubectl create -n <oadp-operator-ns> -f config/samples/cluster_v1beta1_restore.yaml

リソースは以下のファイルのようになります。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm
spec:
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

restore.cluster.open-cluster-management.io の 3 つの必要な spec プロパティーの説明は次のとおりです。

以下のコマンドを実行して Velero Restore リソースを表示します。

oc get restore.velero.io -n <oadp-operator-ns>

以下の YAML の例を参照して、さまざまなタイプのバックアップファイルを復元します。