Red Hat Advanced Cluster Management を使用する multicluster engine Operator
Red Hat Advanced Cluster Management インテグレーションを使用する multicluster engine Operator
概要
第1章 Red Hat Advanced Cluster Management インテグレーションを使用する multicluster engine Operator リンクのコピーリンクがクリップボードにコピーされました!
multicluster engine Operator を使用しており、後から Red Hat Advanced Cluster Management をインストールすると、Observability や Policy をはじめとする多くのマルチクラスター管理機能にアクセスできるようになります。
統合機能は、次の要件を参照してください。
- Red Hat Advanced Cluster Management がインストールされている。Red Hat Advanced Cluster Management インストールおよびアップグレード に関するドキュメントを参照してください。
- インストール後の Red Hat Advanced Cluster Management の詳細は、MultiClusterHub 詳細設定 参照してください。
multicluster engine Operator と Red Hat Advanced Cluster Management マルチクラスター管理には、次の手順を参照してください。
1.1. Red Hat Advanced Cluster Management でのマルチクラスターエンジン Operator がホストするクラスターの検出 リンクのコピーリンクがクリップボードにコピーされました!
複数の ホステッドクラスター をホストしているマルチクラスターエンジン Operator クラスターがある場合は、それらのホステッドクラスターを Red Hat Advanced Cluster Management ハブクラスターに移動して、アプリケーションライフサイクル や ガバナンス などの Red Hat Advanced Cluster Management 管理コンポーネントを使用して管理できます。
これらのホステッドクラスターは自動的に検出され、マネージドクラスターとしてインポートできます。
注記: Hosted Control Plane はマネージドマルチクラスターエンジン Operator クラスターノード上で実行されます。そのため、クラスターがホストできる Hosted Control Plane の数は、マネージドマルチクラスターエンジン Operator クラスターノードのリソースの可用性と、マネージドマルチクラスターエンジン Operator クラスターの数によって決まります。ノードまたはマネージドクラスターを追加すると、より多くの Hosted Control Plane をホストできます。
必要なアクセス権: クラスター管理者
1.1.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- 1 つ以上のマルチクラスターエンジン Operator クラスターがある。
- ハブクラスターとして設定された Red Hat Advanced Cluster Management クラスターがある。
次のコマンドを実行して
clusteradmCLI をインストールする。curl -L https://raw.githubusercontent.com/open-cluster-management-io/clusteradm/main/install.sh | bash
1.1.2. マルチクラスターエンジン Operator クラスターをインポートするための Red Hat Advanced Cluster Management の設定 リンクのコピーリンクがクリップボードにコピーされました!
マルチクラスターエンジン Operator には、管理対象のハブクラスターである local-cluster があります。この local-cluster では、open-cluster-management-agent-addon namespace で次のデフォルトのアドオンが有効になっています。
-
cluster-proxy -
managed-serviceaccount -
work-manager
1.1.2.1. アドオンの設定 リンクのコピーリンクがクリップボードにコピーされました!
マルチクラスターエンジン Operator が Red Hat Advanced Cluster Management にインポートされると、Red Hat Advanced Cluster Management は、マルチクラスターエンジン Operator を管理するために、同じアドオンのセットを有効にします。
これらのアドオンを別のマルチクラスターエンジン Operator の namespace にインストールして、マルチクラスターエンジン Operator が local-cluster のアドオンを使用して自己管理できるようにし、同時に Red Hat Advanced Cluster Management がマルチクラスターエンジン Operator を管理できるようにします。次の手順を実行します。
- CLI を使用して Red Hat Advanced Cluster Management にログインします。
AddOnDeploymentConfigリソースを作成し、別のアドオンインストール用 namespace を指定します。次の例を参照してください。agentInstallNamespaceがopen-cluster-management-agent-addon-discoveryを参照しています。apiVersion: addon.open-cluster-management.io/v1alpha1 kind: AddOnDeploymentConfig metadata: name: addon-ns-config namespace: multicluster-engine spec: agentInstallNamespace: open-cluster-management-agent-addon-discovery-
oc apply -f <filename>.yamlを実行して、ファイルを適用します。 アドオンの既存の
ClusterManagementAddOnリソースを更新して、作成したAddOnDeploymentConfigリソースで指定されているopen-cluster-management-agent-addon-discoverynamespace にアドオンがインストールされるようにします。次の例を参照してください。namespace としてopen-cluster-management-global-setを使用しています。apiVersion: addon.open-cluster-management.io/v1alpha1 kind: ClusterManagementAddOn metadata: name: work-manager spec: addonMeta: displayName: work-manager installStrategy: placements: - name: global namespace: open-cluster-management-global-set rolloutStrategy: type: All type: PlacementsaddonDeploymentConfigsをClusterManagementAddOnに追加します。以下の例を参照してください。apiVersion: addon.open-cluster-management.io/v1alpha1 kind: ClusterManagementAddOn metadata: name: work-manager spec: addonMeta: displayName: work-manager installStrategy: placements: - name: global namespace: open-cluster-management-global-set rolloutStrategy: type: All configs: - group: addon.open-cluster-management.io name: addon-ns-config namespace: multicluster-engine resource: addondeploymentconfigs type: PlacementsAddOnDeploymentConfigをmanaged-serviceaccountに追加します。以下の例を参照してください。apiVersion: addon.open-cluster-management.io/v1alpha1 kind: ClusterManagementAddOn metadata: name: managed-serviceaccount spec: addonMeta: displayName: managed-serviceaccount installStrategy: placements: - name: global namespace: open-cluster-management-global-set rolloutStrategy: type: All configs: - group: addon.open-cluster-management.io name: addon-ns-config namespace: multicluster-engine resource: addondeploymentconfigs type: Placements-
cluster-proxyという名前のClusterManagementAddOnリソースにaddondeploymentconfigs値を追加します。以下の例を参照してください。
apiVersion: addon.open-cluster-management.io/v1alpha1 kind: ClusterManagementAddOn metadata: name: cluster-proxy spec: addonMeta: displayName: cluster-proxy installStrategy: placements: - name: global namespace: open-cluster-management-global-set rolloutStrategy: type: All configs: - group: addon.open-cluster-management.io name: addon-ns-config namespace: multicluster-engine resource: addondeploymentconfigs type: Placements次のコマンドを実行して、Red Hat Advanced Cluster Management の
local-cluster用のアドオンが、指定した namespace に再インストールされていることを確認します。oc get deployment -n open-cluster-management-agent-addon-discovery次の出力例を参照してください。
NAME READY UP-TO-DATE AVAILABLE AGE cluster-proxy-proxy-agent 1/1 1 1 24h klusterlet-addon-workmgr 1/1 1 1 24h managed-serviceaccount-addon-agent 1/1 1 1 24h
1.1.2.2. KlusterletConfig リソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
マルチクラスターエンジン Operator には、管理対象のハブクラスターである local-cluster があります。この local-cluster に対して、klusterlet という名前のリソースが作成されます。
マルチクラスターエンジン Operator が Red Hat Advanced Cluster Management にインポートされると、Red Hat Advanced Cluster Management は、マルチクラスターエンジン Operator を管理するために、同じ名前の klusterlet (klusterlet) をインストールします。これは、マルチクラスターエンジン Operator の local-cluster の klusterlet と競合します。
競合を回避するために、klusterlet が別の名前でインストールされるように、ManagedCluster リソースがマルチクラスターエンジン Operator クラスターのインポートに使用する KlusterletConfig リソースを作成する必要があります。次の手順を実行します。
次の例を使用して
KlusterletConfigリソースを作成します。このKlusterletConfigリソースがマネージドクラスターで参照された場合、spec.installMode.noOperator.postfixフィールドの値が klusterlet 名の接尾辞として使用されます (例:klusterlet-mce-import)。kind: KlusterletConfig apiVersion: config.open-cluster-management.io/v1alpha1 metadata: name: mce-import-klusterlet-config spec: installMode: type: noOperator noOperator: postfix: mce-import-
oc apply -f <filename>.yamlを実行して、ファイルを適用します。
1.1.2.3. バックアップと復元の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Advanced Cluster Management をインストールすると、バックアップおよび復元 機能も使用できます。
障害復旧シナリオでハブクラスターが復元されると、インポートされたマルチクラスターエンジン Operator クラスターとホステッドクラスターが、新しい Red Hat Advanced Cluster Management ハブクラスターにインポートされます。
このとき、Red Hat Advanced Cluster Management ハブクラスターの復元の一環として、以前の設定を復元する必要があります。
バックアップを有効にするには、backup=true ラベルを追加します。各アドオンは、次の手順を参照してください。
addon-ns-configの場合は、次のコマンドを実行します。oc label addondeploymentconfig addon-ns-config -n multicluster-engine cluster.open-cluster-management.io/backup=truehypershift-addon-deploy-configの場合は、次のコマンドを実行します。oc label addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine cluster.open-cluster-management.io/backup=truework-managerの場合は、次のコマンドを実行します。oc label clustermanagementaddon work-manager cluster.open-cluster-management.io/backup=true`cluster-proxy` の場合は、次のコマンドを実行します。
oc label clustermanagementaddon cluster-proxy cluster.open-cluster-management.io/backup=truemanaged-serviceaccountの場合は、次のコマンドを実行します。oc label clustermanagementaddon managed-serviceaccount cluster.open-cluster-management.io/backup=truemce-import-klusterlet-configの場合は、次のコマンドを実行します。oc label KlusterletConfig mce-import-klusterlet-config cluster.open-cluster-management.io/backup=true
1.1.3. マルチクラスターエンジン Operator の手動インポート リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Advanced Cluster Management クラスターからマルチクラスターエンジン Operator クラスターを手動でインポートするには、次の手順を実行します。
Red Hat Advanced Cluster Management クラスターから、
ManagedClusterリソースを手動で作成し、マルチクラスターエンジン Operator クラスターをインポートします。次のファイルの例を参照してください。apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: annotations: agent.open-cluster-management.io/klusterlet-config: mce-import-klusterlet-config1 labels: cloud: auto-detect vendor: auto-detect name: mce-a2 spec: hubAcceptsClient: true leaseDurationSeconds: 60-
oc apply -f <filename>.yamlを実行して、ファイルを適用します。 マルチクラスターエンジン Operator クラスターの
kubeconfigを参照するauto-import-secretシークレットを作成します。CLI を使用してマネージドクラスターをインポートする の 自動インポートシークレットを使用してクラスターをインポートする に記載されているとおり、自動インポートシークレットを追加してマルチクラスターエンジン Operator 自動インポートプロセスを完了します。Red Hat Advanced Cluster Management クラスターのマルチクラスターエンジン Operator 管理クラスターの namespace に自動インポートシークレットを作成すると、マネージドクラスターが登録されます。
次のコマンドを実行して、ステータスを取得します。
oc get managedclusterマネージドクラスターのステータスとサンプル URL を含む次の出力例を参照してください。
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE local-cluster true https://<api.acm-hub.com:port> True True 44h mce-a true https://<api.mce-a.com:port> True True 27s
重要: インポートされたマルチクラスターエンジン Operator に対して、他の Red Hat Advanced Cluster Management アドオンを有効にしないでください。
1.1.4. ホステッドクラスターの検出 リンクのコピーリンクがクリップボードにコピーされました!
すべてのマルチクラスターエンジン Operator クラスターを Red Hat Advanced Cluster Management にインポートしたら、それらのマネージドマルチクラスターエンジン Operator クラスターで hypershift-addon を有効にして、ホステッドクラスターを検出する必要があります。
前の手順では、デフォルトのアドオンを別の namespace にインストールしました。同様に、マルチクラスターエンジン Operator の別の namespace に hypershift-addon をインストールして、マルチクラスターエンジン Operator の local-cluster のアドオンエージェントと Red Hat Advanced Cluster Management のエージェントが、マルチクラスターエンジン Operator で動作できるようにします。
重要: 以下のすべてのコマンドで、<managed-cluster-names> を、マルチクラスターエンジン Operator のコンマ区切りのマネージドクラスター名に置き換えてください。
次のコマンドを実行して、アドオンの
agentInstallNamespacenamespace をopen-cluster-management-agent-addon-discoveryに設定します。oc patch addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine --type=merge -p '{"spec":{"agentInstallNamespace":"open-cluster-management-agent-addon-discovery"}}'次のコマンドを実行して、メトリクスを無効にし、HyperShift Operator 管理を無効にします。
oc patch addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine --type=merge -p '{"spec":{"customizedVariables":[{"name":"disableMetrics","value": "true"},{"name":"disableHOManagement","value": "true"}]}}'次のコマンドを実行して、マルチクラスターエンジン Operator の
hypershift-addonを有効にします。clusteradm addon enable --names hypershift-addon --clusters <managed-cluster-names>Red Hat Advanced Cluster Management で次のコマンドを実行すると、マルチクラスターエンジン Operator が管理するクラスターの名前を取得できます。
oc get managedclusterマルチクラスターエンジン Operator クラスターにログインし、指定した namespace に
hypershift-addonがインストールされていることを確認します。以下のコマンドを実行します。oc get deployment -n open-cluster-management-agent-addon-discoveryアドオンがリスト表示されている次の出力例を参照してください。
NAME READY UP-TO-DATE AVAILABLE AGE cluster-proxy-proxy-agent 1/1 1 1 24h klusterlet-addon-workmgr 1/1 1 1 24h hypershift-addon-agent 1/1 1 1 24h managed-serviceaccount-addon-agent 1/1 1 1 24h
Red Hat Advanced Cluster Management が hypershift-addon をデプロイします。これは、マルチクラスターエンジン Operator からホステッドクラスターを検出する検出エージェントです。エージェントは、ホステッドクラスターの kube-apiserver が利用可能になると、Red Hat Advanced Cluster Management ハブクラスター内のマルチクラスターエンジン Operator が管理するクラスター namespace に、対応する DiscoveredCluster カスタムリソースを作成します。
検出されたクラスターはコンソールで表示できます。
- ハブクラスターコンソールにログインし、All Clusters > Infrastructure > Clusters に移動します。
-
Discovered clusters タブを見つけて、タイプが
MultiClusterEngineHCPのマルチクラスターエンジン Operator から検出されたすべてのホステッドクラスターを表示します。
次に、検出されたホステッドクラスターのインポートの自動化 を参照して、クラスターを自動的にインポートする方法を確認してください。
1.2. 検出されたホステッドクラスターのインポートの自動化 リンクのコピーリンクがクリップボードにコピーされました!
個々のクラスターを手動でインポートすることなく、DiscoveredCluster リソースを使用してホステッドクラスターのインポートを自動化し、クラスター管理を迅速化します。
検出されたホステッドクラスターを Red Hat Advanced Cluster Management に自動的にインポートすると、すべての Red Hat Advanced Cluster Management アドオンが有効になり、利用可能な管理ツールを使用してホステッドクラスターの管理を開始できるようになります。
ホステッドクラスターは、マルチクラスターエンジン Operator にも 自動的にインポート されます。マルチクラスターエンジン Operator のコンソールから、ホステッドクラスターのライフサイクルを管理できます。Red Hat Advanced Cluster Management のコンソールからは、ホステッドクラスターのライフサイクルを管理できません。
必要なアクセス権: クラスター管理者
1.2.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- Red Hat Advanced Cluster Management がインストールされている。Red Hat Advanced Cluster Management インストールおよびアップグレード に関するドキュメントを参照してください。
- ポリシー を理解している。Red Hat Advanced Cluster Management ドキュメントの ガバナンス の概要を参照してください。
1.2.2. 自動インポートの設定 リンクのコピーリンクがクリップボードにコピーされました!
マネージドマルチクラスターエンジン Operator クラスターから検出されたホステッドクラスターは、Red Hat Advanced Cluster Management のマネージドマルチクラスターエンジン Operator クラスターの namespace にある DiscoveredCluster カスタムリソースで表されます。次の DiscoveredCluster リソースと namespace の例を参照してください。
apiVersion: discovery.open-cluster-management.io/v1
kind: DiscoveredCluster
metadata:
creationTimestamp: "2024-05-30T23:05:39Z"
generation: 1
labels:
hypershift.open-cluster-management.io/hc-name: hosted-cluster-1
hypershift.open-cluster-management.io/hc-namespace: clusters
name: hosted-cluster-1
namespace: mce-1
resourceVersion: "1740725"
uid: b4c36dca-a0c4-49f9-9673-f561e601d837
spec:
apiUrl: https://a43e6fe6dcef244f8b72c30426fb6ae3-ea3fec7b113c88da.elb.us-west-1.amazonaws.com:6443
cloudProvider: aws
creationTimestamp: "2024-05-30T23:02:45Z"
credential: {}
displayName: mce-1-hosted-cluster-1
importAsManagedCluster: false
isManagedCluster: false
name: hosted-cluster-1
openshiftVersion: 0.0.0
status: Active
type: MultiClusterEngineHCP
これらの検出されたホステッドクラスターは、spec.importAsManagedCluster フィールドが true に設定されるまで、Red Hat Advanced Cluster Management に自動的にインポートされません。Red Hat Advanced Cluster Management のポリシーを使用して、DiscoveredCluster リソース内のすべての type.MultiClusterEngineHCP でこのフィールドを自動的に true に設定し、検出されたホステッドクラスターがすぐに Red Hat Advanced Cluster Management に自動的にインポートされるようにする方法を説明します。
検出されたすべてのホステッドクラスターを自動的にインポートするようにポリシーを設定します。CLI からハブクラスターにログインして、次の手順を実行します。
DiscoveredClusterカスタムリソースの YAML ファイルを作成し、次の例で後述する設定を編集します。apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: name: policy-mce-hcp-autoimport namespace: open-cluster-management-global-set annotations: policy.open-cluster-management.io/standards: NIST SP 800-53 policy.open-cluster-management.io/categories: CM Configuration Management policy.open-cluster-management.io/controls: CM-2 Baseline Configuration policy.open-cluster-management.io/description: Discovered clusters that are of type MultiClusterEngineHCP can be automatically imported into ACM as managed clusters. This policy configure those discovered clusters so they are automatically imported. Fine tuning MultiClusterEngineHCP clusters to be automatically imported can be done by configure filters at the configMap or add annotation to the discoverd cluster. spec: disabled: false policy-templates: - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: mce-hcp-autoimport-config spec: object-templates: - complianceType: musthave objectDefinition: apiVersion: v1 kind: ConfigMap metadata: name: discovery-config namespace: open-cluster-management-global-set data: rosa-filter: "" remediationAction: enforce1 severity: low - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: policy-mce-hcp-autoimport spec: remediationAction: enforce severity: low object-templates-raw: | {{- /* find the MultiClusterEngineHCP DiscoveredClusters */ -}} {{- range $dc := (lookup "discovery.open-cluster-management.io/v1" "DiscoveredCluster" "" "").items }} {{- /* Check for the flag that indicates the import should be skipped */ -}} {{- $skip := "false" -}} {{- range $key, $value := $dc.metadata.annotations }} {{- if and (eq $key "discovery.open-cluster-management.io/previously-auto-imported") (eq $value "true") }} {{- $skip = "true" }} {{- end }} {{- end }} {{- /* if the type is MultiClusterEngineHCP and the status is Active */ -}} {{- if and (eq $dc.spec.status "Active") (contains (fromConfigMap "open-cluster-management-global-set" "discovery-config" "mce-hcp-filter") $dc.spec.displayName) (eq $dc.spec.type "MultiClusterEngineHCP") (eq $skip "false") }} - complianceType: musthave objectDefinition: apiVersion: discovery.open-cluster-management.io/v1 kind: DiscoveredCluster metadata: name: {{ $dc.metadata.name }} namespace: {{ $dc.metadata.namespace }} spec: importAsManagedCluster: true2 {{- end }} {{- end }}-
oc apply -f <filename>.yaml -n <namespace>を実行して、ファイルを適用します。
1.2.3. 配置定義の作成 リンクのコピーリンクがクリップボードにコピーされました!
ポリシーのデプロイ先のマネージドクラスターを指定する配置定義を作成する必要があります。次の手順を実行します。
管理対象のハブクラスターである
local-clusterのみを選択するPlacement定義を作成します。以下の YAML 例を使用してください。apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: policy-mce-hcp-autoimport-placement namespace: open-cluster-management-global-set spec: tolerations: - key: cluster.open-cluster-management.io/unreachable operator: Exists - key: cluster.open-cluster-management.io/unavailable operator: Exists clusterSets: - global predicates: - requiredClusterSelector: labelSelector: matchExpressions: - key: local-cluster operator: In values: - "true"-
oc apply -f placement.yaml -n <namespace>を実行します。namespaceは、以前に作成したポリシーに使用した namespace と同じものです。
1.2.4. インポートポリシーを配置定義にバインドする リンクのコピーリンクがクリップボードにコピーされました!
ポリシーと配置を作成したら、2 つのリソースを結び付ける必要があります。以下の手順を実行します。
PlacementBindingリソースを使用してリソースを結び付けます。次の例を参照してください。placementRefは作成したPlacementを参照し、subjectsは作成したPolicyを参照します。apiVersion: policy.open-cluster-management.io/v1 kind: PlacementBinding metadata: name: policy-mce-hcp-autoimport-placement-binding namespace: open-cluster-management-global-set placementRef: name: policy-mce-hcp-autoimport-placement apiGroup: cluster.open-cluster-management.io kind: Placement subjects: - name: policy-mce-hcp-autoimport apiGroup: policy.open-cluster-management.io kind: Policy検証するには、次のコマンドを実行します。
oc get policies.policy.open-cluster-management.io policy-mce-hcp-autoimport -n <namespace>
重要: Red Hat Advanced Cluster Management コンソールの Detach オプションを使用するか、コマンドラインから対応する ManagedCluster カスタムリソースを削除することにより、ホステッドクラスターを Red Hat Advanced Cluster Management から デタッチ できます。
最適な結果を得るには、ホステッドクラスターを 破棄 する前に、管理対象のホステッドクラスターをデタッチしてください。
検出されたクラスターがデタッチされると、検出されたクラスターが再度インポートされるのを防ぐために、次のアノテーションが DiscoveredCluster リソースに追加されます。
annotations:
discovery.open-cluster-management.io/previously-auto-imported: "true"
検出されたデタッチ済みクラスターを再インポートする場合は、このアノテーションを削除します。
1.3. 検出された OpenShift Service on AWS クラスターのインポートの自動化 リンクのコピーリンクがクリップボードにコピーされました!
個々のクラスターを手動でインポートすることなく、Red Hat Advanced Cluster Management のポリシー適用を使用して OpenShift Service on AWS クラスターのインポートを自動化し、クラスター管理を迅速化します。
必要なアクセス権: クラスター管理者
1.3.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- Red Hat Advanced Cluster Management がインストールされている。Red Hat Advanced Cluster Management インストールおよびアップグレード に関するドキュメントを参照してください。
- ポリシー を理解している。Red Hat Advanced Cluster Management ドキュメントの ガバナンス の概要を参照してください。
1.3.2. 自動インポートポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
次のポリシーと手順は、検出されたすべての OpenShift Service on AWS クラスターを自動的にインポートする方法の例です。
CLI からハブクラスターにログインして、次の手順を実行します。
次の例を使用して YAML ファイルを作成し、後述する変更を適用します。
apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: name: policy-rosa-autoimport annotations: policy.open-cluster-management.io/standards: NIST SP 800-53 policy.open-cluster-management.io/categories: CM Configuration Management policy.open-cluster-management.io/controls: CM-2 Baseline Configuration policy.open-cluster-management.io/description: OpenShift Service on AWS discovered clusters can be automatically imported into Red Hat Advanced Cluster Management as managed clusters with this policy. You can select and configure those managed clusters so you can import. Configure filters or add an annotation if you do not want all of your OpenShift Service on AWS clusters to be automatically imported. spec: remediationAction: inform1 disabled: false policy-templates: - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: rosa-autoimport-config spec: object-templates: - complianceType: musthave objectDefinition: apiVersion: v1 kind: ConfigMap metadata: name: discovery-config namespace: open-cluster-management-global-set data: rosa-filter: ""2 remediationAction: enforce severity: low - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: policy-rosa-autoimport spec: remediationAction: enforce severity: low object-templates-raw: | {{- /* find the ROSA DiscoveredClusters */ -}} {{- range $dc := (lookup "discovery.open-cluster-management.io/v1" "DiscoveredCluster" "" "").items }} {{- /* Check for the flag that indicates the import should be skipped */ -}} {{- $skip := "false" -}} {{- range $key, $value := $dc.metadata.annotations }} {{- if and (eq $key "discovery.open-cluster-management.io/previously-auto-imported") (eq $value "true") }} {{- $skip = "true" }} {{- end }} {{- end }} {{- /* if the type is ROSA and the status is Active */ -}} {{- if and (eq $dc.spec.status "Active") (contains (fromConfigMap "open-cluster-management-global-set" "discovery-config" "rosa-filter") $dc.spec.displayName) (eq $dc.spec.type "ROSA") (eq $skip "false") }} - complianceType: musthave objectDefinition: apiVersion: discovery.open-cluster-management.io/v1 kind: DiscoveredCluster metadata: name: {{ $dc.metadata.name }} namespace: {{ $dc.metadata.namespace }} spec: importAsManagedCluster: true {{- end }} {{- end }} - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: policy-rosa-managedcluster-status spec: remediationAction: enforce severity: low object-templates-raw: | {{- /* Use the same DiscoveredCluster list to check ManagedCluster status */ -}} {{- range $dc := (lookup "discovery.open-cluster-management.io/v1" "DiscoveredCluster" "" "").items }} {{- /* Check for the flag that indicates the import should be skipped */ -}} {{- $skip := "false" -}} {{- range $key, $value := $dc.metadata.annotations }} {{- if and (eq $key "discovery.open-cluster-management.io/previously-auto-imported") (eq $value "true") }} {{- $skip = "true" }} {{- end }} {{- end }} {{- /* if the type is ROSA and the status is Active */ -}} {{- if and (eq $dc.spec.status "Active") (contains (fromConfigMap "open-cluster-management-global-set" "discovery-config" "rosa-filter") $dc.spec.displayName) (eq $dc.spec.type "ROSA") (eq $skip "false") }} - complianceType: musthave objectDefinition: apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: {{ $dc.spec.displayName }} namespace: {{ $dc.spec.displayName }} status: conditions: - type: ManagedClusterConditionAvailable status: "True" {{- end }} {{- end }}-
oc apply -f <filename>.yaml -n <namespace>を実行して、ファイルを適用します。
1.3.3. 配置定義の作成 リンクのコピーリンクがクリップボードにコピーされました!
ポリシーのデプロイ先のマネージドクラスターを指定する配置定義を作成する必要があります。
管理対象のハブクラスターである
local-clusterのみを選択する配置定義を作成します。以下の YAML 例を使用してください。apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement-openshift-plus-hub spec: predicates: - requiredClusterSelector: labelSelector: matchExpressions: - key: name operator: In values: - local-cluster-
oc apply -f placement.yaml -n <namespace>を実行します。namespaceは、以前に作成したポリシーに使用した namespace と同じものです。
1.3.4. インポートポリシーを配置定義にバインドする リンクのコピーリンクがクリップボードにコピーされました!
ポリシーと配置を作成したら、2 つのリソースを結び付ける必要があります。
PlacementBindingを使用してリソースを結び付けます。次の例を参照してください。placementRefは作成したPlacementを参照し、subjectsは作成したPolicyを参照します。apiVersion: policy.open-cluster-management.io/v1 kind: PlacementBinding metadata: name: binding-policy-rosa-autoimport placementRef: apiGroup: cluster.open-cluster-management.io kind: Placement name: placement-policy-rosa-autoimport subjects: - apiGroup: policy.open-cluster-management.io kind: Policy name: policy-rosa-autoimport検証するには、次のコマンドを実行します。
oc get policies.policy.open-cluster-management.io policy-rosa-autoimport -n <namespace>
1.4. 可観測性の統合 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Advanced Cluster Management の可観測性機能を使用すると、クラスター全体の健全性と使用状況を表示できます。Red Hat Advanced Cluster Management をインストールして可観測性機能を有効にできます。
1.4.1. Hosted Control Plane の観測 リンクのコピーリンクがクリップボードにコピーされました!
multicluster-observability Pod を有効にすると、Red Hat Advanced Cluster Management Observability Grafana ダッシュボードを使用して、Hosted Control Plane に関する次の情報を表示できます。
- ACM > Hosted Control Planes Overview で、Hosted Control Plane をホストするためのクラスター容量の推定値、関連するクラスターリソース、および既存の Hosted Control Plane のリストとステータスを確認できます。詳細は、Hosted Control Plane の概要 を参照してください。
- ACM > Resources > Hosted Control Plane ダッシュボード (Overview ページからアクセス可能) で、選択した Hosted Control Plane のリソース使用率を確認できます。詳細は、Hosted Control Plane のコマンドラインインターフェイスのインストール を参照してください。
有効にするには、Observability サービス を参照してください。
第2章 SiteConfig リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig Operator は、SiteConfig ジェネレーター kustomize プラグインの SiteConfig API から派生した、統合 ClusterInstance API を使用したテンプレート駆動型のクラスタープロビジョニングソリューションを提供します。
SiteConfig Operator の使用方法の詳細は、次のドキュメントを参照してください。
高度なトピックは、次のドキュメントを参照してください。
2.1. SiteConfig Operator について リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig Operator は、テンプレートドリブンのクラスタープロビジョニングソリューションを提供します。これにより、さまざまなインストール方法でクラスターをプロビジョニングできます。
SiteConfig Operator は、SiteConfig ジェネレーター kustomize プラグインの SiteConfig API から派生した統合 ClusterInstance API を導入します。
ClusterInstance API は、クラスターを定義するパラメーターを、クラスターがデプロイされる方法から分離します。
この分離により、エージェントクラスターのインストールや Argo CD に関連するスケーラビリティー制約など、現在の GitOps Zero Touch Provisioning (ZTP) フロー の SiteConfig kustomize プラグインがもたらす特定の制限が削除されます。
統合された ClusterInstance API を使用すると、SiteConfig Operator により次のように改善されます。
- 独立性
-
クラスター定義をインストール方法から分離します。
ClusterInstanceカスタムリソースはクラスター定義をキャプチャーし、インストールテンプレートはクラスターアーキテクチャーとインストール方法をキャプチャーします。 - 統合
-
SiteConfig Operator は、Git ワークフローと非 Git ワークフローの両方を統合します。
ClusterInstanceカスタムリソースをハブクラスターに直接適用することも、ArgoCD などの GitOps ソリューションを通じてリソースを同期することもできます。 - 一貫性
- Assisted Installer、Image Based Install Operator、その他のカスタムテンプレートベースのアプローチなど、いずれを使用しているかにかかわらず、インストール方法をまたいで一貫した API が維持されます。
- スケーラビリティー
-
各クラスターで、
SiteConfigkustomize プラグインよりも高いスケーラビリティーを実現できます。 - 柔軟性
- カスタムテンプレートを使用することで、クラスターのデプロイとインストールが強化されます。
- トラブルシューティング
- クラスターのデプロイメントステータスとレンダリングされたマニフェストに関する有益な情報を取得でき、トラブルシューティングエクスペリエンスが大幅に向上します。
Image Based Install Operator の詳細は、Image Based Install Operator を参照してください。
Assisted Installer の詳細は、Assisted Installer を使用したオンプレミスクラスターのインストール を参照してください。
2.1.1. SiteConfig Operator フロー リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig Operator は、ClusterInstance カスタムリソースのデータからインスタンス化されたユーザー定義テンプレートに基づき、インストールマニフェストを動的に生成します。
ClusterInstance カスタムリソースは、ArgoCD を介して Git リポジトリーから取得するか、ハブクラスター上で手動で直接作成するか、外部ツールとワークフローを使用して作成できます。
以下は、その大まかなプロセスです。
- ハブクラスター上に 1 つ以上のインストールテンプレートセットを作成します。
-
これらのインストールテンプレートとサポートマニフェストを参照する
ClusterInstanceカスタムリソースを作成します。 -
リソースが作成されると、SiteConfig Operator は、カスタムリソースで参照されるテンプレートフィールドに値を入力して
ClusterInstanceカスタムリソースを調整します。 - SiteConfig Operator はインストールマニフェストを検証してレンダリングし、その後 Operator がドライランを実行します。
- ドライランが成功すると、マニフェストが作成され、基盤となる Operator がマニフェストを使用および処理します。
- インストールが開始します。
-
SiteConfig Operator は、関連付けられている
ClusterDeploymentリソースの変更を継続的に監視し、それに応じてClusterInstanceカスタムリソースのstatusフィールドを更新します。
2.2. インストールテンプレートの概要 リンクのコピーリンクがクリップボードにコピーされました!
インストールテンプレートは、インストールアーティファクトのセットを生成するために使用されるデータドリブンテンプレートです。これらのテンプレートは Golang の text/template 形式に従っており、ClusterInstance カスタムリソースのデータを使用してインスタンス化されます。これにより、同様の設定を持ちながらも値が異なる各ターゲットクラスターのインストールマニフェストを動的に作成できるようになります。
さまざまなインストール方法やクラスタートポロジーに基づいて複数のセットを作成することもできます。SiteConfig Operator は、次のタイプのインストールテンプレートをサポートします。
- クラスターレベル
- クラスター固有のフィールドのみを参照する必要があるテンプレート。
- ノードレベル
- クラスター固有のフィールドとノード固有のフィールドの両方を参照できるテンプレート。
インストールテンプレートの詳細は、次のドキュメントを参照してください。
2.2.1. テンプレート関数 リンクのコピーリンクがクリップボードにコピーされました!
テンプレート化されたフィールドをカスタマイズできます。SiteConfig Operator は、すべての sprig ライブラリー関数 をサポートします。
ClusterInstance API は、カスタムマニフェストの作成時に使用できる次の関数も提供します。
toYaml-
toYaml関数は、項目を YAML 文字列にエンコードします。項目を YAML に変換できない場合、関数は空の文字列を返します。
次に示す、ClusterInstance.Spec.Proxy フィールドの .toYaml 仕様の例を参照してください。
{{ if .Spec.Proxy }}
proxy:
{{ .Spec.Proxy | toYaml | indent 4 }}
{{ end }}
2.2.2. デフォルトのテンプレートセット リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig Operator は、Operator がインストールされているのと同じ namespace に、次の検証済みかつイミュータブルなデフォルトテンプレートセットを提供します。
| インストール方法 | テンプレートタイプ | ファイル名 | テンプレートコンテンツ |
|---|---|---|---|
| Assisted Installer | クラスターレベルのテンプレート |
|
|
| ノードレベルのテンプレート |
|
| |
| Image-based Install Operator | クラスターレベルのテンプレート |
|
|
| ノードレベルのテンプレート |
|
|
ClusterInstance API の詳細は、ClusterInstance API を参照してください。
2.2.3. 特殊なテンプレート変数 リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig Operator は、テンプレートで使用できる特殊なテンプレート変数のセットを提供します。次のリストを参照してください。
CurrentNode- SiteConfig Operator は、ノードオブジェクトの反復を明示的に制御し、テンプレーティングで処理されている現在のノードのすべてのコンテンツにアクセスするために、この変数を公開します。
InstallConfigOverrides-
マージされた
networkType、cpuPartitioningMode、およびinstallConfigOverridesコンテンツが含まれます。 ControlPlaneAgents-
コントロールプレーンエージェントの数で構成され、
ClusterInstanceノードオブジェクトから自動的に導出されます。 WorkerAgents-
ワーカーエージェントの数で構成され、
ClusterInstanceノードオブジェクトから自動的に導出されます。
テキストテンプレート内のフィールド名を大文字にして、カスタムテンプレート化されたフィールドを作成します。
たとえば、ClusterInstance spec フィールドは .Spec 接頭辞で参照されます。ただし、特殊変数フィールドは .SpecialVars 接頭辞を使用して参照する必要があります。
重要: spec.nodes フィールドに .Spec.Nodes 接頭辞を使用するのではなく、.SpecialVars.CurrentNode 特殊テンプレート変数を使用して参照する必要があります。
たとえば、CurrentNode 特殊テンプレート変数を使用して現在のノードの name および namespace を指定する場合は、次の形式でフィールド名を使用します。
name: "{{ .SpecialVars.CurrentNode.HostName }}"
namespace: "{{ .Spec.ClusterName }}"
2.2.4. マニフェスト順序のカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
siteconfig.open-cluster-management.io/sync-wave アノテーションを使用して、マニフェストが作成、更新、削除される順序を制御できます。アノテーションは整数を値として取得し、その整数が wave を構成します。
1 つの wave に 1 つ以上のマニフェストを追加できます。値を指定しない場合、アノテーションはデフォルト値 0 を取得します。
SiteConfig Operator は、リソースの作成時または更新時にマニフェストを昇順で調整し、リソースを降順で削除します。
次の例では、SiteConfig Operator がマニフェストを作成または更新すると、AgentClusterInstall および ClusterDeployment カスタムリソースは最初の wave で調整され、KlusterletAddonConfig および ManagedCluster カスタムリソースは 3 番目の wave で調整されます。
apiVersion: v1
data:
AgentClusterInstall: |-
...
siteconfig.open-cluster-management.io/sync-wave: "1"
...
ClusterDeployment: |-
...
siteconfig.open-cluster-management.io/sync-wave: "1"
...
InfraEnv: |-
...
siteconfig.open-cluster-management.io/sync-wave: "2"
...
KlusterletAddonConfig: |-
...
siteconfig.open-cluster-management.io/sync-wave: "3"
...
ManagedCluster: |-
...
siteconfig.open-cluster-management.io/sync-wave: "3"
...
kind: ConfigMap
metadata:
name: assisted-installer-templates
namespace: example-namespace
SiteConfig Operator がリソースを削除すると、KlusterletAddonConfig および ManagedCluster カスタムリソースが最初に削除され、AgentClusterInstall および ClusterDeployment カスタムリソースは最後に削除されます。
2.2.5. 追加のアノテーションとラベルの設定 リンクのコピーリンクがクリップボードにコピーされました!
ClusterInstance API の extraAnnotations フィールドと extraLabels フィールドを使用して、クラスターレベルとノードレベルの両方のインストールマニフェストに追加のアノテーションとラベルを設定できます。SiteConfig Operator は、ClusterInstance リソースで指定したマニフェストに追加のアノテーションとラベルを適用します。
追加のアノテーションとラベルを作成するときは、SiteConfig Operator がそれらをすべての一致するマニフェストに適用できるように、マニフェストタイプを指定する必要があります。ただし、アノテーションとラベルは任意であり、アプリケーションにとって意味のある任意のキーと値のペアを設定できます。
注記: 追加のアノテーションとラベルは、参照されたテンプレートを通じてレンダリングされたリソースにのみ適用されます。
extraAnnotations と extraLabels の次の例の適用例を確認してください。
extraAnnotations と extraLabels の応用例
apiVersion: siteconfig.open-cluster-management.io/v1alpha1
kind: ClusterInstance
metadata:
name: "example-sno"
namespace: "example-sno"
spec:
[...]
clusterName: "example-sno"
extraAnnotations:
ClusterDeployment:
myClusterAnnotation: success
extraLabels:
ManagedCluster:
common: "true"
group-du: ""
nodes:
- hostName: "example-sno.example.redhat.com"
role: "master"
extraAnnotations:
BareMetalHost:
myNodeAnnotation: success
extraLabels:
BareMetalHost:
"testExtraLabel": "success"
- 1 2
- このフィールドは、SiteConfig Operator が
ManagedClusterマニフェストおよびClusterDeploymentマニフェストに適用するクラスターレベルのアノテーションとラベルをサポートします。 - 3 4
- このフィールドは、SiteConfig Operator が
BareMetalHostマニフェストに適用するノードレベルのアノテーションとラベルをサポートします。次のコマンドを実行すると、追加のラベルが適用されていることを確認できます。
oc get managedclusters example-sno -ojsonpath='{.metadata.labels}' | jq適用されたラベルの次の例を確認してください。
適用されたラベルの例
{ "common": "true", "group-du": "", ... }- 次のコマンドを実行すると、追加のアノテーションが適用されていることを確認できます。
oc get bmh example-sno.example.redhat.com -n example-sno -ojsonpath='{.metadata.annotations}' | jq適用されたアノテーションの次の例を確認してください。
適用されたアノテーションの例
{ "myNodeAnnotation": "success", ... }
2.3. SiteConfig Operator を有効にする リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig Operator によるデフォルトのインストールテンプレートの使用と、シングルノード OpenShift クラスターの大規模なインストールが可能になります。
必要なアクセス権: クラスター管理者
2.3.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- Red Hat Advanced Cluster Management バージョン 2.12 ハブクラスターがある。
2.3.2. MultiClusterHub リソースから SiteConfig Operator を有効にする リンクのコピーリンクがクリップボードにコピーされました!
MultiClusterHub リソースにパッチを適用し、SiteConfig Operator が有効になっていることを確認します。次の手順を実行します。
次のコマンドを実行して、
MultiClusterHubOperator の namespace に一致する環境変数を設定します。export MCH_NAMESPACE=<namespace>次のコマンドを実行して、
Multiclusterhubリソースのspec.overrides.componentsのsiteconfigエントリーでenabledフィールドをtrueに設定します。oc patch multiclusterhubs.operator.open-cluster-management.io multiclusterhub -n ${MCH_NAMESPACE} --type json --patch '[{"op": "add", "path":"/spec/overrides/components/-", "value": {"name":"siteconfig","enabled": true}}]'ハブクラスターで次のコマンドを実行して、SiteConfig Operator が有効になっていることを確認します。
oc -n ${MCH_NAMESPACE} get po | grep siteconfig以下の出力例を参照してください。
siteconfig-controller-manager-6fdd86cc64-sdg87 2/2 Running 0 43sオプション: ハブクラスターで次のコマンドを実行して、デフォルトのインストールテンプレートがあることを確認します。
oc -n ${MCH_NAMESPACE} get cm出力例の次のテンプレートのリストを参照してください。
NAME DATA AGE ai-cluster-templates-v1 5 97s ai-node-templates-v1 2 97s ... ibi-cluster-templates-v1 3 97s ibi-node-templates-v1 3 97s ...
2.4. Image Based Install Operator リンクのコピーリンクがクリップボードにコピーされました!
既存のインストール方法と同じ API を使用してイメージベースのクラスターインストールを完了および管理できるように、Image Based Install Operator をインストールします。
Image Based Install Operator の詳細と有効にする方法には、シングルノード OpenShift のイメージベースのインストール を参照してください。
2.5. SiteConfig Operator を使用してシングルノード OpenShift クラスターをインストールする リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのインストールテンプレートを使用して、SiteConfig Operator でクラスターをインストールします。手順を完了するには、Image-Based Install Operator のインストールテンプレートを使用します。
必要なアクセス権: クラスター管理者
2.5.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- GitOps ZTP を使用している場合は、GitOps ZTP 環境を設定します。環境を設定するには、GitOps ZTP 用のハブクラスターの準備 を参照してください。
- デフォルトのインストールテンプレートが必要です。デフォルトテンプレートの詳細は、デフォルトのテンプレートセット を参照してください。
基盤となる任意の Operator をインストールして設定します。
- シングルノード OpenShift の Image Based Install Operator の詳細とインストール方法は、Image Based Install Operator を参照してください。
- Assisted Installer をインストールするには、Assisted Installer を使用してオンプレミスクラスターをインストールする を参照してください。
SiteConfig Operator を使用してクラスターをインストールするには、次の手順を実行します。
2.5.2. ターゲット namespace を作成する リンクのコピーリンクがクリップボードにコピーされました!
プルシークレット、BMC シークレット、追加のマニフェスト ConfigMap オブジェクト、および ClusterInstance カスタムリソースを作成する場合は、ターゲット namespace が必要です。
ターゲット namespace を作成するには、次の手順を実行します。
ターゲット namespace の YAML ファイルを作成します。
clusterinstance-namespace.yamlという名前の次のサンプルファイルを参照してください。apiVersion: v1 kind: Namespace metadata: name: example-snoファイルを適用してリソースを作成します。ハブクラスターで以下のコマンドを実行してください。
oc apply -f clusterinstance-namespace.yaml
2.5.3. プルシークレットを作成する リンクのコピーリンクがクリップボードにコピーされました!
クラスターがコンテナーレジストリーからイメージをプルできるようにするには、プルシークレットが必要です。プルシークレットを作成するには、次の手順を実行します。
イメージをプルするための YAML ファイルを作成します。
pull-secret.yamlという名前のファイルの次の例を参照してください。apiVersion: v1 kind: Secret metadata: name: pull-secret namespace: example-sno1 data: .dockerconfigjson: <encoded_docker_configuration>2 type: kubernetes.io/dockerconfigjsonファイルを適用してリソースを作成します。ハブクラスターで以下のコマンドを実行してください。
oc apply -f pull-secret.yaml
2.5.4. BMC シークレットを作成する リンクのコピーリンクがクリップボードにコピーされました!
ベースボード管理コントローラー (BMC) に接続するにはシークレットが必要です。シークレットを作成するには、次の手順を実行します。
BMC シークレットの YAML ファイルを作成します。
example-bmc-secret.yamlという名前の次のサンプルファイルを参照してください。apiVersion: v1 data: password: <password> username: <username> kind: Secret metadata: name: example-bmh-secret namespace: "example-sno"1 type: Opaque- 1
namespace値がターゲット namespace と一致していることを確認します。
ファイルを適用してリソースを作成します。ハブクラスターで以下のコマンドを実行してください。
oc apply -f example-bmc-secret.yaml
2.5.5. オプション: 追加のマニフェストを作成する リンクのコピーリンクがクリップボードにコピーされました!
ClusterInstance カスタムリソースで参照する必要がある追加のマニフェストを作成できます。追加のマニフェストを作成するには、次の手順を実行します。
追加のマニフェスト
ConfigMapオブジェクトの YAML ファイル (例:enable-crun.yaml) を作成します。apiVersion: v1 kind: ConfigMap metadata: name: enable-crun namespace: example-sno1 data: enable-crun-master.yaml: | apiVersion: machineconfiguration.openshift.io/v1 kind: ContainerRuntimeConfig metadata: name: enable-crun-master spec: machineConfigPoolSelector: matchLabels: pools.operator.machineconfiguration.openshift.io/master: "" containerRuntimeConfig: defaultRuntime: crun enable-crun-worker.yaml: | apiVersion: machineconfiguration.openshift.io/v1 kind: ContainerRuntimeConfig metadata: name: enable-crun-worker spec: machineConfigPoolSelector: matchLabels: pools.operator.machineconfiguration.openshift.io/worker: "" containerRuntimeConfig: defaultRuntime: crun- 1
namespace値がターゲット namespace と一致していることを確認します。
ハブクラスターで次のコマンドを実行してリソースを作成します。
oc apply -f enable-crun.yaml
2.5.6. インストールマニフェストをレンダリングする リンクのコピーリンクがクリップボードにコピーされました!
ClusterInstance カスタムリソース内のテンプレートとサポートマニフェストを参照します。デフォルトクラスターおよびノードテンプレートを使用してインストールマニフェストをレンダリングするには、次の手順を実行します。
次の例のように、
example-snonamespace でclusterinstance-ibi.yamlという名前のClusterInstanceカスタムリソースを作成します。apiVersion: siteconfig.open-cluster-management.io/v1alpha1 kind: ClusterInstance metadata: name: "example-clusterinstance" namespace: "example-sno"1 spec: #clusterType: "SNO"2 holdInstallation: false extraManifestsRefs:3 - name: extra-machine-configs - name: enable-crun pullSecretRef: name: "pull-secret"4 [...] clusterName: "example-sno"5 [...] clusterImageSetNameRef: "img4.17-x86-64" [...] templateRefs:6 - name: ibi-cluster-templates-v1 namespace: rhacm [...] nodes: [...] bmcCredentialsName:7 name: "example-bmh-secret" [...] templateRefs:8 - name: ibi-node-templates-v1 namespace: rhacm [...]- 1
ClusterInstanceカスタムリソース内のnamespaceが、定義したターゲットの namespace と一致していることを確認します。- 2
- オプション: シングルノード OpenShift クラスターでスケールアウトまたはスケーリングする場合は、
spec.clusterTypeフィールドを"SNO"に設定する必要があります。 - 3
- 1 つ以上の追加マニフェスト
ConfigMapオブジェクトのnameを参照します。 - 4
- プルシークレットの
nameを参照します。 - 5
ClusterInstanceカスタムリソースのclusterNameフィールドの値がnamespaceフィールドの値と一致していることを確認します。- 6
spec.templateRefsフィールドでクラスターレベルのテンプレートのnameを参照してください。デフォルトのインストールテンプレートを使用している場合は、namespaceを Operator がインストールされている namespace と一致させる必要があります。- 7
- BMC シークレットの
nameを参照します。 - 8
spec.nodes.templateRefsフィールドでノードレベルのテンプレートのnameを参照してください。デフォルトのインストールテンプレートを使用している場合は、namespaceを Operator がインストールされている namespace と一致させる必要があります。
次のコマンドを実行してファイルを適用し、リソースを作成します。
oc apply -f clusterinstance-ibi.yamlカスタムリソースを作成すると、SiteConfig Operator は
ClusterInstanceカスタムリソースの調整を開始してからインストールマニフェストを検証してレンダリングします。SiteConfig Operator は、
ClusterDeploymentカスタムリソースの変更を継続的に監視し、対応するClusterInstanceカスタムリソースのクラスターインストールの進捗を更新します。次のコマンドを実行してプロセスを監視します。
oc get clusterinstance <cluster_name> -n <target_namespace> -o yamlマニフェストの生成が成功すると、
status.conditionsセクションの出力が次の例のようになります。message: Applied site config manifests reason: Completed status: "True" type: RenderedTemplatesApplied次のコマンドを実行して、SiteConfig Operator がレンダリングしたマニフェストを確認します。
oc get clusterinstance <cluster_name> -n <target_namespace> -o jsonpath='{.status.manifestsRendered}'
ステータス条件の詳細は、ClusterInstance API を参照してください。
2.6. SiteConfig Operator を使用してシングルノード OpenShift クラスターをデプロビジョニングする リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig Operator を使用してクラスターをデプロビジョニングし、そのクラスターに関連付けられているすべてのリソースとアクセスを削除します。
必要なアクセス権: クラスター管理者
2.6.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- デフォルトのインストールテンプレートを使用して、SiteConfig Operator でクラスターをデプロイします。
2.6.2. シングルノード OpenShift クラスターのデプロビジョニング リンクのコピーリンクがクリップボードにコピーされました!
クラスターを削除するには、次の手順を実行します。
次のコマンドを実行して、
ClusterInstanceカスタムリソースを削除します。oc delete clusterinstance <cluster_name> -n <target_namespace>次のコマンドを実行して、削除が成功したことを確認します。
oc get clusterinstance <cluster_name> -n <target_namespace>
次の出力例の (NotFound) エラーは、クラスターがデプロビジョニングされたことを示しています。
Error from server (NotFound): clusterinstances.siteconfig.open-cluster-management.io "<cluster_name>" not found
2.7. SiteConfig の高度なトピック リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig オペレーターは、カスタムテンプレートの作成やワーカーノードのスケーリングなど、追加の機能を提供します。これは、ほとんどのユースケースに適用される標準操作を拡張します。SiteConfig Operator の高度なトピックは、以下のドキュメントを参照してください。
2.7.1. SiteConfig Operator を使用してカスタムテンプレートを作成する リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのテンプレートセットに用意されていないユーザー定義テンプレートを作成します。
必要なアクセス権: クラスター管理者
カスタムテンプレートを作成するには、次の手順を実行します。
ConfigMapオブジェクトにクラスターレベルのテンプレートが含まれる YAML ファイルを、my-custom-secret.yamlという名前で作成します。apiVersion: v1 kind: ConfigMap metadata: name: my-custom-secret namespace: rhacm data: MySecret: |- apiVersion: v1 kind: Secret metadata: name: "{{ .Spec.ClusterName }}-my-custom-secret-key" namespace: "clusters" annotations: siteconfig.open-cluster-management.io/sync-wave: "1"1 type: Opaque data: key: <key>- 1
siteconfig.open-cluster-management.io/sync-waveアノテーションは、マニフェストが作成、更新、または削除される順序を制御します。
次のコマンドを実行して、ハブクラスターにカスタムテンプレートを適用します。
oc apply -f my-custom-secret.yamlclusterinstance-my-custom-secret.yamlという名前のClusterInstanceカスタムリソースでテンプレートを参照します。spec: ... templateRefs: - name: ai-cluster-templates-v1.yaml namespace: rhacm - name: my-custom-secret.yaml namespace: rhacm ...次のコマンドを実行して、
ClusterInstanceカスタムリソースを適用します。oc apply -f clusterinstance-my-custom-secret.yaml
2.7.2. SiteConfig Operator を使用してシングルノード OpenShift クラスターをスケーリングする リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig Operator によってインストールされたマネージドクラスターをスケールインします。ワーカーノードを削除することでクラスターをスケールインできます。
必要なアクセス権: クラスター管理者
2.7.2.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- GitOps ZTP を使用している場合は、GitOps ZTP 環境が設定されている。環境を設定するには、GitOps ZTP 用のハブクラスターの準備 を参照してください。
- デフォルトテンプレートがある。デフォルトテンプレートの詳細は、デフォルトのテンプレートセット を参照してください。
- SiteConfig Operator を使用してクラスターをインストールした。SiteConfig Operator を使用してクラスターをインストールするには、SiteConfig Operator を使用してシングルノード OpenShift クラスターをインストールする を参照してください。
-
spec.clusterTypeを"SNO"に設定している。
2.7.2.2. ワーカーノードにアノテーションを追加する リンクのコピーリンクがクリップボードにコピーされました!
削除するワーカーノードにアノテーションを追加します。
マネージドクラスターからワーカーノードにアノテーションを付けるには、次の手順を実行します。
クラスターのプロビジョニングに使用される
ClusterInstanceカスタムリソースのワーカーノードエントリーのextraAnnotationsフィールドに、アノテーションを追加します。spec: ... nodes: - hostName: "worker-node2.example.com" role: "worker" ironicInspect: "" extraAnnotations: BareMetalHost: bmac.agent-install.openshift.io/remove-agent-and-node-on-delete: "true" ...変更を適用します。以下のオプションを参照してください。
- Red Hat OpenShift GitOps を使用せずに Red Hat Advanced Cluster Management を使用している場合は、ハブクラスターで次のコマンドを実行します。
oc apply -f <clusterinstance>.yaml- GitOps ZTP を使用している場合は、Git リポジトリーにプッシュし、Argo CD が変更を同期するのを待ちます。
ハブクラスターで次のコマンドを実行して、アノテーションが
BaremetalHostワーカーリソースに適用されていることを確認します。oc get bmh -n <clusterinstance_namespace> worker-node2.example.com -ojsonpath='{.metadata.annotations}' | jqアノテーションが正常に適用された場合の出力例を次に示します。
{
"baremetalhost.metal3.io/detached": "assisted-service-controller",
"bmac.agent-install.openshift.io/hostname": "worker-node2.example.com",
"bmac.agent-install.openshift.io/remove-agent-and-node-on-delete": "true"
"bmac.agent-install.openshift.io/role": "master",
"inspect.metal3.io": "disabled",
"siteconfig.open-cluster-management.io/sync-wave": "1",
}
2.7.2.3. ワーカーノードの BareMetalHost リソースを削除する リンクのコピーリンクがクリップボードにコピーされました!
削除するワーカーノードの BareMetalHost リソースを削除します。
マネージドクラスターからワーカーノードを削除するには、次の手順を実行します。
既存の
ClusterInstanceカスタムリソースで削除するノードオブジェクトを、次の設定で更新します。... spec: ... nodes: - hostName: "worker-node2.example.com" ... pruneManifests: - apiVersion: metal3.io/v1alpha1 kind: BareMetalHost ...変更を適用します。以下のオプションを参照してください。
- Red Hat OpenShift GitOps を使用せずに Red Hat Advanced Cluster Management を使用している場合は、ハブクラスターで次のコマンドを実行します。
oc apply -f <clusterinstance>.yaml- GitOps ZTP を使用している場合は、Git リポジトリーにプッシュし、Argo CD が変更を同期するのを待ちます。
ハブクラスターで次のコマンドを実行して、
BareMetalHostリソースが削除されていることを確認します。oc get bmh -n <clusterinstance_namespace> --watch --kubeconfig <hub_cluster_kubeconfig_filename>以下の出力例を参照してください。
NAME STATE CONSUMER ONLINE ERROR AGE master-node1.example.com provisioned true 81m worker-node2.example.com deprovisioning true 44m worker-node2.example.com powering off before delete true 20h worker-node2.example.com deleting true 50mハブクラスターで次のコマンドを実行して、
Agentリソースが削除されていることを確認します。oc get agents -n <clusterinstance_namespace> --kubeconfig <hub_cluster_kubeconfig_filename>以下の出力例を参照してください。
NAME CLUSTER APPROVED ROLE STAGE master-node1.example.com <managed_cluster_name> true master Done master-node2.example.com <managed_cluster_name> true master Done master-node3.example.com <managed_cluster_name> true master Done worker-node1.example.com <managed_cluster_name> true worker Doneマネージドクラスターで次のコマンドを実行して、
Nodeリソースが削除されていることを確認します。oc get nodes --kubeconfig <managed_cluster_kubeconfig_filename>以下の出力例を参照してください。
NAME STATUS ROLES AGE VERSION worker-node2.example.com NotReady,SchedulingDisabled worker 19h v1.30.5 worker-node1.example.com Ready worker 19h v1.30.5 master-node1.example.com Ready control-plane,master 19h v1.30.5 master-node2.example.com Ready control-plane,master 19h v1.30.5 master-node3.example.com Ready control-plane,master 19h v1.30.5-
ワーカーノードの
BareMetalHostオブジェクトが正常に削除されたら、ClusterInstanceリソースのspec.nodesセクションから、関連付けられたワーカーノード定義を削除します。
2.7.3. SiteConfig Operator を使用してシングルノードの OpenShift クラスターをスケールアウトする リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig Operator でインストールされたマネージドクラスターをスケールアウトします。ワーカーノードを追加することでクラスターをスケールアウトできます。
必要なアクセス権: クラスター管理者
2.7.3.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- GitOps ZTP を使用している場合は、GitOps ZTP 環境を設定しておきます。環境を設定するには、GitOps ZTP 用のハブクラスターの準備 を参照してください。
- デフォルトのインストールテンプレートが必要です。デフォルトテンプレートの詳細は、デフォルトのテンプレートセット を参照してください。
- SiteConfig Operator を使用してクラスターをインストールした。SiteConfig Operator を使用してクラスターをインストールするには、SiteConfig Operator を使用してシングルノード OpenShift クラスターをインストールする を参照してください。
-
spec.clusterTypeを"SNO"に設定している。
2.7.3.2. ワーカーノードを追加する リンクのコピーリンクがクリップボードにコピーされました!
クラスターのプロビジョニングに使用される ClusterInstance カスタムリソースを更新して、ワーカーノードを追加します。
マネージドクラスターにワーカーノードを追加するには、次の手順を実行します。
既存の
ClusterInstanceカスタムリソースに新しいノードオブジェクトを定義します。spec: ... nodes: - hostName: "<host_name>" role: "worker" templateRefs: - name: ai-node-templates-v1 namespace: rhacm bmcAddress: "<bmc_address>" bmcCredentialsName: name: "<bmc_credentials_name>" bootMACAddress: "<boot_mac_address>" ...変更を適用します。以下のオプションを参照してください。
- Red Hat OpenShift GitOps を使用せずに Red Hat Advanced Cluster Management を使用している場合は、ハブクラスターで次のコマンドを実行します。
oc apply -f <clusterinstance>.yaml- GitOps ZTP を使用している場合は、Git リポジトリーにプッシュし、Argo CD が変更を同期するのを待ちます。
ハブクラスターで次のコマンドを実行して、新しい
BareMetalHostリソースが追加されたことを確認します。oc get bmh -n <clusterinstance_namespace> --watch --kubeconfig <hub_cluster_kubeconfig_filename>以下の出力例を参照してください。
NAME STATE CONSUMER ONLINE ERROR AGE master-node1.example.com provisioned true 81m worker-node2.example.com provisioning true 44mハブクラスターで次のコマンドを実行して、新しい
Agentリソースが追加されたことを確認します。oc get agents -n <clusterinstance_namespace> --kubeconfig <hub_cluster_kubeconfig_filename>以下の出力例を参照してください。
NAME CLUSTER APPROVED ROLE STAGE master-node1.example.com <managed_cluster_name> true master Done master-node2.example.com <managed_cluster_name> true master Done master-node3.example.com <managed_cluster_name> true master Done worker-node1.example.com <managed_cluster_name> false worker worker-node2.example.com <managed_cluster_name> true worker Starting installation worker-node2.example.com <managed_cluster_name> true worker Installing worker-node2.example.com <managed_cluster_name> true worker Writing image to disk worker-node2.example.com <managed_cluster_name> true worker Waiting for control plane worker-node2.example.com <managed_cluster_name> true worker Rebooting worker-node2.example.com <managed_cluster_name> true worker Joined worker-node2.example.com <managed_cluster_name> true worker Doneマネージドクラスターで次のコマンドを実行して、新しい
Nodeリソースが追加されたことを確認します。oc get nodes --kubeconfig <managed_cluster_kubeconfig_filename>以下の出力例を参照してください。
NAME STATUS ROLES AGE VERSION worker-node2.example.com Ready worker 1h v1.30.5 worker-node1.example.com Ready worker 19h v1.30.5 master-node1.example.com Ready control-plane,master 19h v1.30.5 master-node2.example.com Ready control-plane,master 19h v1.30.5 master-node3.example.com Ready control-plane,master 19h v1.30.5
2.7.4. 非接続環境向けのミラーリングイメージ リンクのコピーリンクがクリップボードにコピーされました!
イメージベースのインストール Operator を基礎となる Operator として使用することで、SiteConfig Operator でクラスターをデプロイできます。非接続環境で Image Based Install Operator を使用してクラスターをデプロイする場合は、ミラーイメージを ClusterInstance カスタムリソースの追加マニフェストとして提供する必要があります。
必要なアクセス権: クラスター管理者
非接続環境のイメージをミラーリングするには、次の手順を実行します。
ミラーレジストリーの場所を含む
ImageDigestMirrorSetオブジェクト用に、idms-configmap.yamlという名前の YAML ファイルを作成します。kind: ConfigMap apiVersion: v1 metadata: name: "idms-configmap" namespace: "example-sno" data: 99-example-idms.yaml: | apiVersion: config.openshift.io/v1 kind: ImageDigestMirrorSet metadata: name: example-idms spec: imageDigestMirrors: - mirrors: - mirror.registry.example.com/image-repo/image source: registry.example.com/image-repo/image
重要: ClusterInstance リソースと同じ namespace に追加のマニフェストを含む ConfigMap リソースを定義します。
ハブクラスターで次のコマンドを実行してリソースを作成します。
oc apply -f idms-configmap.yamlClusterInstanceカスタムリソース内のImageDigestMirrorSetオブジェクトを参照します。apiVersion: siteconfig.open-cluster-management.io/v1alpha1 kind: ClusterInstance metadata: name: "example-sno" namespace: "example-sno" spec: ... extraManifestsRefs: - name: idms-configmap ...