手順

1. ミラーホストにログインします。

2. mirror.openshift.com から RHCOS ISO イメージおよび RootFS イメージを取得します。以下は例になります。

   1. 必要なイメージ名と OpenShift Container Platform のバージョンを環境変数としてエクスポートします。

      $ export ISO_IMAGE_NAME=<iso_image_name> 1

      $ export ROOTFS_IMAGE_NAME=<rootfs_image_name> 1

      $ export OCP_VERSION=<ocp_version> 1

      1

      ISO イメージ名 (例: rhcos-4.15.1-x86_64-live.x86_64.iso)

      1

      RootFS イメージ名 (例: rhcos-4.15.1-x86_64-live-rootfs.x86_64.img)

      1

      OpenShift Container Platform バージョン (例: 4.15.1)

   2. 必要なイメージをダウンロードします。

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.15/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.15/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}

手順

1. Provisioning リソースを有効にして、すべての namespace を監視し、非接続環境のミラーを設定します。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。

2. 以下のコマンドを実行して、AgentServiceConfig CR を更新します。

   $ oc edit AgentServiceConfig

3. CR の items.spec.osImages フィールドに次のエントリーを追加します。

   - cpuArchitecture: x86_64
       openshiftVersion: "4.15"
       rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img
       url: https://<mirror-registry>/<path>/rhcos-live.x86_64.iso

   ここでは、以下のようになります。

   <host>

   ターゲットミラーレジストリー HTTP サーバーの完全修飾ドメイン名 (FQDN) です。

   <path>

   ターゲットミラーレジストリー上のイメージへのパスです。

   エディターを保存して終了し、変更を適用します。

手順

1. ミラーレジストリー設定を含む ConfigMap を作成します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: assisted-installer-mirror-config
     namespace: multicluster-engine 1
     labels:
       app: assisted-service
   data:
     ca-bundle.crt: | 2
       -----BEGIN CERTIFICATE-----
       <certificate_contents>
       -----END CERTIFICATE-----
   
     registries.conf: | 3
       unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
   
       [[registry]]
          prefix = ""
          location = "quay.io/example-repository" 4
          mirror-by-digest-only = true
   
          [[registry.mirror]]
          location = "mirror1.registry.corp.com:5000/example-repository" 5

   1

   ConfigMap namespace は multicluster-engine に設定する必要があります。

   2

   ミラーレジストリーの作成時に使用されるミラーレジストリーの証明書。

   3

   ミラーレジストリーの設定ファイル。ミラーレジストリー設定は、検出イメージの /etc/containers/registries.conf ファイルにミラー情報を追加します。ミラー情報は、インストールプログラムに渡される際、install-config.yaml ファイルの imageContentSources セクションに保存されます。ハブクラスターで実行される Assisted Service Pod は、設定されたミラーレジストリーからコンテナーイメージをフェッチします。

   4

   ミラーレジストリーの URL。ミラーレジストリーを設定する場合は 、oc adm release Mirror コマンドを実行して、imageContentSources セクションの URL を使用する必要があります。詳細は、OpenShift Container Platform イメージリポジトリーのミラーリング セクションを参照してください。

   5

   registries.conf ファイルで定義されるレジストリーは、レジストリーではなくリポジトリーによってスコープが指定される必要があります。この例では、quay.io/example-repository リポジトリーと mirror1.registry.corp.com:5000/example-repository リポジトリーの両方のスコープが example-repository リポジトリーにより指定されます。

   これにより、以下のように AgentServiceConfig カスタムリソースの mirrorRegistryRef が更新されます。

   出力例

   apiVersion: agent-install.openshift.io/v1beta1
   kind: AgentServiceConfig
   metadata:
     name: agent
     namespace: multicluster-engine 1
   spec:
     databaseStorage:
       volumeName: <db_pv_name>
       accessModes:
       - ReadWriteOnce
       resources:
         requests:
           storage: <db_storage_size>
     filesystemStorage:
       volumeName: <fs_pv_name>
       accessModes:
       - ReadWriteOnce
       resources:
         requests:
           storage: <fs_storage_size>
     mirrorRegistryRef:
       name: assisted-installer-mirror-config 2
     osImages:
       - openshiftVersion: <ocp_version>
         url: <iso_url> 3

   1

   ConfigMap namespace と一致するように、AgentServiceConfig namespace を multicluster-engine に設定します。

   2

   関連する ConfigMap CR で指定された定義と一致するように、mirrorRegistryRef.name を設定します。

   3

   httpd サーバーでホストされる ISO の URL を設定します。

手順

1. 次のコマンドを実行して、AgentServiceConfig カスタムリソース (CR) を更新します。

   $ oc edit AgentServiceConfig agent

2. CR に unauthenticatedRegistries フィールドを追加します。

   apiVersion: agent-install.openshift.io/v1beta1
   kind: AgentServiceConfig
   metadata:
     name: agent
   spec:
     unauthenticatedRegistries:
     - example.registry.com
     - example.registry2.com
     ...

   非認証レジストリーは、AgentServiceConfig リソースの spec.unauthenticatedRegistries の下に一覧表示されます。このリストにあるレジストリーのエントリーは、スポーククラスターのインストールに使用されるプルシークレットに含める必要はありません。assisted-service は、インストールに使用されるすべてのイメージレジストリーの認証情報がプルシークレットに含まれていることを確認して、プルシークレットを検証します。

1. ハブクラスターへのデバッグシェルプロンプトを開きます。

   $ oc debug node/<node_name>

2. 次のコマンドを実行して、非認証レジストリーへのアクセスをテストします。

   sh-4.4# podman login -u kubeadmin -p $(oc whoami -t) <unauthenticated_registry>

   ここでは、以下のようになります。

   <unauthenticated_registry>

   unauthenticated-image-registry.openshift-image-registry.svc:5000 などの新しいレジストリーです。

   出力例

   Login Succeeded!

手順

1. ArgoCD パイプライン設定を準備します。

   1. example ディレクトリーと同様にディレクトリー構造で Git リポジトリーを作成します。詳細は、「GitOps ZTP サイト設定リポジトリーの準備」を参照してください。

   2. ArgoCD UI を使用して、リポジトリーへのアクセスを設定します。Settings で以下を設定します。

      • リポジトリー: 接続情報を追加します。URL は .git などで終わって いる必要があります。https://repo.example.com/repo.git とクレデンシャルを指定します。
      • certificates: 必要に応じて、リポジトリーのパブリック証明書を追加します。

   3. 2 つの ArgoCD アプリケーション、out/argocd/deployment/clusters-app.yaml と out/argocd/deployment/policies-app.yaml を、Git リポジトリーに基づいて修正します。

      • Git リポジトリーを参照するように URL を更新します。URL は .git で終わります (例: https://repo.example.com/repo.git)。
      • targetRevision は、監視する Git リポジトリーブランチを示します。
      • path は、それぞれ SiteConfig CR および PolicyGenTemplate CR へのパスを指定します。

2. GitOps ZTP プラグインをインストールするために、以前に out/argocd/deployment/ ディレクトリーに展開したパッチファイルを使用して、ハブクラスター内の ArgoCD インスタンスにパッチを適用します。以下のコマンドを実行します。

   $ oc patch argocd openshift-gitops \
   -n openshift-gitops --type=merge \
   --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json

3. RHACM 2.7 以降では、マルチクラスターエンジンはデフォルトで cluster-proxy-addon 機能を有効にします。次のパッチを適用して、cluster-proxy-addon 機能を無効にし、このアドオンに関連するハブクラスターとマネージド Pod を削除します。以下のコマンドを実行します。

   $ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json

4. 次のコマンドを実行して、パイプライン設定をハブクラスターに適用します。

   $ oc apply -k out/argocd/deployment

手順

1. SiteConfig CR と PolicyGenTemplate CR の個別のパスを持つディレクトリー構造を作成します。

   注記

   SiteConfig および PolicyGenTemplate CR を個別のディレクトリーで保持します。SiteConfig ディレクトリーおよび PolicyGenTemplate ディレクトリーには、そのディレクトリー内のファイルを明示的に含める kustomization.yaml ファイルが含まれている必要があります。

2. 以下のコマンドを使用して ztp-site-generate コンテナーイメージから argocd ディレクトリーをエクスポートします。

   $ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15

   $ mkdir -p ./out

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 extract /home/ztp --tar | tar x -C ./out

3. out ディレクトリーに以下のサブディレクトリーが含まれていることを確認します。

   • out/extra-manifest には、SiteConfig が追加の manifest configMap の生成に使用するソース CR ファイルが含まれます。
   • out/source-crs には、PolicyGenTemplate が Red Hat Advanced Cluster Management (RHACM) ポリシーを生成するために使用するソース CR ファイルが含まれています。
   • out/argocd/deployment には、この手順の次のステップで使用するハブクラスターに適用するパッチおよび YAML ファイルが含まれます。
   • out/argocd/example には、推奨の設定を表す SiteConfig ファイルおよび PolicyGenTemplate ファイルのサンプルが含まれています。
4. out/source-crs フォルダーとその内容を PolicyGentemplate ディレクトリーにコピーします。

5. out/extra-manifests ディレクトリーには、RAN DU クラスターの参照マニフェストが含まれています。out/extra-manifests ディレクトリーを SiteConfig フォルダーにコピーします。このディレクトリーには、ztp-site-generate コンテナーからの CR のみを含める必要があります。ユーザー提供の CR をここに追加しないでください。ユーザー提供の CR を使用する場合は、そのコンテンツ用に別のディレクトリーを作成する必要があります。以下に例を示します。

   example/
     ├── policygentemplates
     │   ├── kustomization.yaml
     │   └── source-crs/
     └── siteconfig
           ├── extra-manifests
           └── kustomization.yaml

6. ディレクトリー構造と kustomization.yaml ファイルをコミットし、Git リポジトリーにプッシュします。Git への最初のプッシュには、kustomization.yaml ファイルが含まれている必要があります。

1. 既存のすべてのクラスターに ztp-done ラベルを付けます。
2. ArgoCD アプリケーションを停止します。
3. 新しい GitOps ZTP ツールをインストールします。
4. Git リポジトリーで必要なコンテンツおよびオプションの変更を更新します。
5. アプリケーション設定を更新して再起動します。

手順

1. GitOps ZTP で使用するために Red Hat OpenShift GitOps を設定するために使用されるカスタムリソース (CR) を持つ GitOps ZTP コンテナーの最新バージョンを取得します。

2. 次のコマンドを使用して、argocd/deployment ディレクトリーを抽出します。

   $ mkdir -p ./update

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 extract /home/ztp --tar | tar x -C ./update

   /update ディレクトリーには、次のサブディレクトリーが含まれています。

   • update/extra-manifest: SiteConfig CR が追加のマニフェスト configMap を生成するために使用するソース CR ファイルが含まれています。
   • update/source-crs には、PolicyGenTemplate CR が Red Hat Advanced Cluster Management (RHACM) ポリシーを生成するために使用するソース CR ファイルが含まれています。
   • update/argocd/deployment には、この手順の次のステップで使用するハブクラスターに適用するパッチおよび YAML ファイルが含まれます。
   • update/argocd/example: 推奨される設定を表す SiteConfig および PolicyGenTemplate ファイルの例が含まれています。

3. clusters-app.yaml ファイルおよび policies-app.yaml ファイルを更新して、Git リポジトリーのアプリケーションおよび URL、ブランチ、およびパスを反映します。

   アップグレードにポリシーの廃止につながる変更が含まれている場合は、アップグレードを実行する前に、廃止されたポリシーを削除する必要があります。

4. /update フォルダー内の設定およびデプロイソース CR と、フリートサイト CR を管理する Git リポジトリーとの間の変更を比較します。必要な変更をサイトリポジトリーに適用してプッシュします。

   重要

   GitOps ZTP を最新バージョンに更新するときは、update/argocd/deployment ディレクトリーからサイトリポジトリーに変更を適用する必要があります。古いバージョンの argocd/deployment/ ファイルは使用しないでください。

手順

1. local-cluster!=true など、GitOps Zero Touch Provisioning (ZTP) でデプロイされたマネージドクラスターを一覧表示するラベルセレクターを見つけます。

   $ oc get managedcluster -l 'local-cluster!=true'

2. 結果のリストに、GItOps ZTP でデプロイされたすべてのマネージドクラスターが含まれていることを確認してから、そのセレクターを使用して ztp-done ラベルを追加します。

   $ oc label managedcluster -l 'local-cluster!=true' ztp-done=

手順

1. clusters アプリケーションで非カスケード削除を実行して、生成されたすべてのリソースをそのまま残します。

   $ oc delete -f update/argocd/deployment/clusters-app.yaml

2. policies アプリケーションでカスケード削除を実行して、以前のすべてのポリシーを削除します。

   $ oc patch -f policies-app.yaml -p '{"metadata": {"finalizers": ["resources-finalizer.argocd.argoproj.io"]}}' --type merge

   $ oc delete -f update/argocd/deployment/policies-app.yaml

手順

1. GitOps ZTP プラグインをインストールするために、以前に out/argocd/deployment/ ディレクトリーに展開したパッチファイルを使用して、ハブクラスター内の ArgoCD インスタンスにパッチを適用します。以下のコマンドを実行します。

   $ oc patch argocd openshift-gitops \
   -n openshift-gitops --type=merge \
   --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json

2. RHACM 2.7 以降では、マルチクラスターエンジンはデフォルトで cluster-proxy-addon 機能を有効にします。次のパッチを適用して、cluster-proxy-addon 機能を無効にし、このアドオンに関連するハブクラスターとマネージド Pod を削除します。以下のコマンドを実行します。

   $ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json

3. 次のコマンドを実行して、パイプライン設定をハブクラスターに適用します。

   $ oc apply -k out/argocd/deployment

1. Discovery イメージの ISO ファイルが生成され、ターゲットホストで起動します。
2. ISO ファイルがターゲットホストで正常に起動すると、ホストのハードウェア情報が RHACM にレポートされます。
3. すべてのホストの検出後に、OpenShift Container Platform がインストールされます。
4. OpenShift Container Platform のインストールが完了すると、ハブは klusterlet サービスをターゲットクラスターにインストールします。
5. 要求されたアドオンサービスがターゲットクラスターにインストールされている。

手順

1. ホスト Baseboard Management Controller (BMC) の認証情報と、OpenShift およびすべてのアドオンクラスター Operator のインストールに必要なプルシークレットを含む YAML シークレットファイルを作成します。

   1. 次の YAML をファイル example-sno-secret.yaml として保存します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: example-sno-bmc-secret
        namespace: example-sno 1
      data: 2
        password: <base64_password>
        username: <base64_username>
      type: Opaque
      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: pull-secret
        namespace: example-sno  3
      data:
        .dockerconfigjson: <pull_secret> 4
      type: kubernetes.io/dockerconfigjson

      1

      関連する SiteConfig CR で設定された namespace と一致する必要があります

      2

      password と username の Base64 エンコード値

      3

      関連する SiteConfig CR で設定された namespace と一致する必要があります

      4

      Base64 でエンコードされたプルシークレット

2. example-sno-secret.yaml への相対パスを、クラスターのインストールに使用する kustomization.yaml ファイルに追加します。

手順

1. InfraEnv CR を作成し、spec.kernelArguments 仕様を編集してカーネル引数を設定します。

   1. 次の YAML を InfraEnv-example.yaml ファイルに保存します。

      注記

      この例の InfraEnv CR は、SiteConfig CR の値に基づいて入力される {{ .Cluster.ClusterName }} などのテンプレート構文を使用します。SiteConfig CR は、デプロイメント中にこれらのテンプレートの値を自動的に設定します。テンプレートを手動で編集しないでください。

      apiVersion: agent-install.openshift.io/v1beta1
      kind: InfraEnv
      metadata:
        annotations:
          argocd.argoproj.io/sync-wave: "1"
        name: "{{ .Cluster.ClusterName }}"
        namespace: "{{ .Cluster.ClusterName }}"
      spec:
        clusterRef:
          name: "{{ .Cluster.ClusterName }}"
          namespace: "{{ .Cluster.ClusterName }}"
        kernelArguments:
          - operation: append 1
            value: audit=0 2
          - operation: append
            value: trace=1
        sshAuthorizedKey: "{{ .Site.SshPublicKey }}"
        proxy: "{{ .Cluster.ProxySettings }}"
        pullSecretRef:
          name: "{{ .Site.PullSecretRef.Name }}"
        ignitionConfigOverride: "{{ .Cluster.IgnitionConfigOverride }}"
        nmStateConfigLabelSelector:
          matchLabels:
            nmstate-label: "{{ .Cluster.ClusterName }}"
        additionalNTPSources: "{{ .Cluster.AdditionalNTPSources }}"

      1

      カーネル引数を追加するには、追加操作を指定します。

      2

      設定するカーネル引数を指定します。この例では、audit カーネル引数と trace カーネル引数を設定します。

2. InfraEnv-example.yaml CR を、Git リポジトリー内の SiteConfig CR と同じ場所にコミットし、変更をプッシュします。次の例は、サンプルの Git リポジトリー構造を示しています。

   ~/example-ztp/install
             └── site-install
                  ├── siteconfig-example.yaml
                  ├── InfraEnv-example.yaml
                  ...

3. SiteConfig CR の spec.clusters.crTemplates 仕様を編集して、Git リポジトリーの InfraEnv-example.yaml CR を参照します。

   clusters:
     crTemplates:
       InfraEnv: "InfraEnv-example.yaml"

   SiteConfig CR をコミットおよびプッシュしてクラスターをデプロイする準備ができたら、ビルドパイプラインは Git リポジトリー内のカスタム InfraEnv-example CR を使用して、カスタムカーネル引数を含むインフラストラクチャー環境を設定します。

1. ターゲットホストとの SSH セッションを開始します。

   $ ssh -i /path/to/privatekey core@<host_name>

2. 次のコマンドを使用して、システムのカーネル引数を表示します。

   $ cat /proc/cmdline

1. Assisted Service Operator は OpenShift Container Platform をクラスターにインストールします。次のコマンドを実行して、RHACM ダッシュボードまたはコマンドラインからクラスターのインストールの進行状況を監視できます。

   1. クラスター名をエクスポートします。

      $ export CLUSTER=<clusterName>

   2. マネージドクラスターの AgentClusterInstall CR をクエリーします。

      $ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq

   3. クラスターのインストールイベントを取得します。

      $ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}')  | jq '.[-2,-1]'

手順

1. インストール CR が作成されたことは、以下のコマンドで確認することができます。

   $ oc get AgentClusterInstall -n <cluster_name>

   オブジェクトが返されない場合は、以下の手順を使用して ArgoCD パイプラインフローを SiteConfig ファイルからインストール CR にトラブルシューティングします。

2. ハブクラスターで SiteConfig CR を使用して ManagedCluster CR が生成されたことを確認します。

   $ oc get managedcluster

3. ManagedCluster が見つからない場合は、clusters アプリケーションが Git リポジトリーからハブクラスターへのファイルの同期に失敗したかどうかを確認します。

   $ oc describe -n openshift-gitops application clusters

   1. Status.Conditions フィールドを確認して、マネージドクラスターのエラーログを表示します。たとえば、SiteConfig CR で extraManifestPath: に無効な値を設定すると、次のエラーが発生します。

      Status:
        Conditions:
          Last Transition Time:  2021-11-26T17:21:39Z
          Message:               rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/siteconfigs/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not create extra-manifest ranSite1.extra-manifest3 stat extra-manifest3: no such file or directory 2021/11/26 17:21:40 Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-913473579: stat extra-manifest3: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-913473579; exit status 1: exit status 1
          Type:  ComparisonError

   2. Status.Sync フィールドを確認します。ログエラーがある場合、Status.Sync フィールドは Unknown エラーを示している可能性があります。

      Status:
        Sync:
          Compared To:
            Destination:
              Namespace:  clusters-sub
              Server:     https://kubernetes.default.svc
            Source:
              Path:             sites-config
              Repo URL:         https://git.com/ran-sites/siteconfigs/.git
              Target Revision:  master
          Status:               Unknown

手順

1. 次のコマンドを実行して、Provisioning リソースの TLS を無効にします。

   $ oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"disableVirtualMediaTLS": true}}'

2. シングルノード OpenShift クラスターをデプロイする手順を続行します。

手順

1. 関連する SiteConfig ファイルと PolicyGenTemplate ファイルを kustomization.yaml ファイルから削除して、サイトと関連する CR を削除します。

   GitOps ZTP パイプラインを再度実行すると、生成された CR は削除されます。

2. 任意: サイトを永続的に削除する場合は、Git リポジトリーから SiteConfig ファイルおよびサイト固有の PolicyGenTemplate ファイルも削除する必要があります。
3. 任意: たとえば、サイトを再デプロイする際にサイトを一時的に削除する場合には、Git リポジトリーに SiteConfig およびサイト固有の PolicyGenTemplate CR を残しておくことができます。

手順

1. Git リポジトリーから影響を受ける PolicyGenTemplate ファイルを削除し、コミットしてリモートリポジトリーにプッシュしてください。
2. アプリケーションを介して変更が同期され、影響を受けるポリシーがハブクラスターから削除されるのを待ちます。

3. 更新された PolicyGenTemplate ファイルを Git リポジトリーに再び追加し、リモートリポジトリーにコミットし、プッシュします。

   注記

   Git リポジトリーから GitOps Zero Touch Provisioning (ZTP) ポリシーを削除し、その結果としてハブクラスターからもポリシーが削除されても、マネージドクラスターの設定には影響しません。ポリシーとそのポリシーによって管理される CR は、マネージドクラスターに残ります。

4. 任意: 別の方法として、PolicyGenTemplate CR に変更を加えて古いポリシーを作成した後、これらのポリシーをハブクラスターから手動で削除することができます。ポリシーの削除は、RHACM コンソールから Governance タブを使用するか、以下のコマンドを使用して行うことができます。

   $ oc delete policy -n <namespace> <policy_name>

手順

1. ハブクラスターの Red Hat Advanced Cluster Management (RHACM) からすべてのクラスターを切り離します。

2. 次のコマンドを使用して、deployment ディレクトリーの kustomization.yaml ファイルを削除します。

   $ oc delete -k out/argocd/deployment

3. 変更をコミットして、サイトリポジトリーにプッシュします。

手順

1. サイト固有の設定 CR の PolicyGenTemplate CR を作成します。

   1. CR の適切な例を out/argocd/example/policygentemplates フォルダーから選択します (example-sno-site.yaml または example-multinode-site.yaml)。

   2. サンプルファイルの bindingRules フィールドを、SiteConfig CR に含まれるサイト固有のラベルと一致するように変更します。サンプルの SiteConfig ファイルでは、サイト固有のラベルは sites: example-sno です。

      注記

      PolicyGenTemplate bindingRules フィールドで定義されているラベルが、関連するマネージドクラスターの SiteConfig CR で定義されているラベルに対応していることを確認してください。

   3. サンプルファイルの内容を目的の設定に合わせて変更します。

2. オプション: クラスターのフリート全体に適用される一般的な設定 CR の PolicyGenTemplate CR を作成します。

   1. out/argocd/example/policygentemplates フォルダーから CR の適切な例を選択します (例: common-ranGen.yaml)。
   2. サンプルファイルの内容を目的の設定に合わせて変更します。

3. オプション: フリート内のクラスターの特定のグループに適用されるグループ設定 CR の PolicyGenTemplate CR を作成します。

   オーバーレイド仕様ファイルの内容が必要な終了状態と一致することを確認します。out/source-crs ディレクトリーには、PolicyGenTemplate テンプレートに含めることができる source-crs の完全な一覧が含まれます。

   注記

   クラスターの特定の要件に応じて、クラスターの種類ごとに 1 つ以上のグループポリシーが必要になる場合があります。特に、サンプルのグループポリシーにはそれぞれ単一の PerformancePolicy.yaml ファイルがあり、それらのクラスターが同一のハードウェア設定である場合にのみクラスターのセット全体で共有できることを考慮しています。

   1. out/argocd/example/policygentemplates フォルダーから CR の適切な例を選択します (例: group-du-sno-ranGen.yaml)。
   2. サンプルファイルの内容を目的の設定に合わせて変更します。
4. オプション: GitOps ZTP のインストールとデプロイされたクラスターの設定が完了したときに通知するバリデータ通知ポリシー PolicyGenTemplate CR を作成します。詳細は、バリデータ通知ポリシーの作成を参照してください。

5. out/argocd/example/policygentemplates/ns.yaml ファイルの例と同様の YAML ファイルで、すべてのポリシーの namespace を定義してください。

   重要

   Namespace CR を PolicyGenTemplate CR と同じファイルに含めないでください。

6. out/argocd/example/policygentemplates/kustomization.yaml に示されている例と同様に、PolicyGenTemplate CR と Namespace CR をジェネレーターセクションの kustomization.yaml ファイルに追加します。

7. PolicyGenTemplate CR、Namespace CR、および関連する kustomization.yaml ファイルを Git リポジトリーにコミットし、変更をプッシュします。

   ArgoCD パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。SiteConfig CR と PolicyGenTemplate CR に同時に変更をプッシュすることができます。

手順

1. Topology Aware Lifecycle Manager (TALM) は、クラスターにバインドされている設定ポリシーを適用します。

   クラスターのインストールが完了し、クラスターが Ready になると、ran.openshift.io/ztp-deploy-wave アノテーションで 定義された順序付きポリシーのリストで、このクラスターに対応する ClusterGroupUpgrade CR が TALM により自動的に作成されます。クラスターのポリシーは、ClusterGroupUpgrade CR に記載されている順序で適用されます。

   以下のコマンドを使用して、設定ポリシー調整のハイレベルの進捗を監視できます。

   $ export CLUSTER=<clusterName>

   $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq

   出力例

   {
     "lastTransitionTime": "2022-11-09T07:28:09Z",
     "message": "Remediating non-compliant policies",
     "reason": "InProgress",
     "status": "True",
     "type": "Progressing"
   }

2. RHACM ダッシュボードまたはコマンドラインを使用して、詳細なクラスターポリシーのコンプライアンスステータスを監視できます。

   1. oc を使用してポリシーのコンプライアンスを確認するには、次のコマンドを実行します。

      $ oc get policies -n $CLUSTER

      出力例

      NAME                                                     REMEDIATION ACTION   COMPLIANCE STATE   AGE
      ztp-common.common-config-policy                          inform               Compliant          3h42m
      ztp-common.common-subscriptions-policy                   inform               NonCompliant       3h42m
      ztp-group.group-du-sno-config-policy                     inform               NonCompliant       3h42m
      ztp-group.group-du-sno-validator-du-policy               inform               NonCompliant       3h42m
      ztp-install.example1-common-config-policy-pjz9s          enforce              Compliant          167m
      ztp-install.example1-common-subscriptions-policy-zzd9k   enforce              NonCompliant       164m
      ztp-site.example1-config-policy                          inform               NonCompliant       3h42m
      ztp-site.example1-perf-policy                            inform               NonCompliant       3h42m

   2. RHACM Web コンソールからポリシーのステータスを確認するには、次のアクションを実行します。

      1. ガバナンス → ポリシーの検索 をクリックします。
      2. クラスターポリシーをクリックして、ステータスを確認します。

手順

1. ポリシーの詳細情報を表示するには、次のコマンドを実行します。

   $ oc describe -n openshift-gitops application policies

2. Status: Conditions: の有無を確認し、エラーログを表示します。例えば、無効な sourceFile→fileName: を設定すると、以下のようなエラーが発生します。

   Status:
     Conditions:
       Last Transition Time:  2021-11-26T17:21:39Z
       Message:               rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1
       Type:  ComparisonError

3. Status: Sync: をチェックします。Status: Conditions:: でログエラーが発生した場合 Status: Sync: に Unknown または Error と表示されます。

   Status:
     Sync:
       Compared To:
         Destination:
           Namespace:  policies-sub
           Server:     https://kubernetes.default.svc
         Source:
           Path:             policies
           Repo URL:         https://git.com/ran-sites/policies/.git
           Target Revision:  master
       Status:               Error

4. Red Hat Advanced Cluster Management (RHACM) が ManagedCluster オブジェクトにポリシーが適用されることを認識すると、ポリシー CR オブジェクトがクラスターネームスペースに適用されます。ポリシーがクラスターネームスペースにコピーされたかどうかを確認します。

   $ oc get policy -n $CLUSTER

   出力例:

   NAME                                         REMEDIATION ACTION   COMPLIANCE STATE   AGE
   ztp-common.common-config-policy              inform               Compliant          13d
   ztp-common.common-subscriptions-policy       inform               Compliant          13d
   ztp-group.group-du-sno-config-policy         inform               Compliant          13d
   Ztp-group.group-du-sno-validator-du-policy   inform               Compliant          13d
   ztp-site.example-sno-config-policy           inform               Compliant          13d

   RHACM は、適用可能なすべてのポリシーをクラスターの namespace にコピーします。コピーされたポリシー名の形式は <policyGenTemplate.Namespace>.<policyGenTemplate.Name>-<policyName> です。

5. クラスター namespace にコピーされないポリシーの配置ルールを確認します。これらのポリシーの PlacementRule の matchSelector、ManagedCluster オブジェクトのラベルと一致する必要があります。

   $ oc get placementrule -n $NS

6. PlacementRule 名は、以下のコマンドを使用して、不足しているポリシー (common、group、または site) に適した名前であることに注意してください。

   $ oc get placementrule -n $NS <placementRuleName> -o yaml

   • status-decisions にはクラスター名が含まれている必要があります。
   • spec の matchSelector の key-value ペアは、マネージドクラスター上のラベルと一致する必要があります。

7. 以下のコマンドを使用して、ManagedCluster オブジェクトのラベルを確認します。

   $ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq

8. 以下のコマンドを使用して、準拠しているポリシーを確認します。

   $ oc get policy -n $CLUSTER

   Namespace、OperatorGroup、および Subscription ポリシーが準拠しているが Operator 設定ポリシーが該当しない場合、Operator はマネージドクラスターにインストールされていない可能性があります。このため、スポークに CRD がまだ適用されていないため、Operator 設定ポリシーの適用に失敗します。

手順

1. ClusterGroupUpgrade CR は、管理クラスターの状態が Ready になった後に Topology Aware Lifecycle Manager によって namespace ztp-install に生成されます。

   $ export CLUSTER=<clusterName>

   $ oc get clustergroupupgrades -n ztp-install $CLUSTER

2. 予期せぬ問題が発生し、設定されたタイムアウト (デフォルトは 4 時間) 内にポリシーが苦情にならなかった場合、ClusterGroupUpgrade CR のステータスは UpgradeTimedOut と 表示されます。

   $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'

3. UpgradeTimedOut 状態の ClusterGroupUpgrade CR は、1 時間ごとにポリシー照合を自動的に再開します。ポリシーを変更した場合は、既存の ClusterGroupUpgrade CR を削除して再試行をすぐに開始できます。これにより、ポリシーをすぐに調整する新規 ClusterGroupUpgrade CR の自動作成がトリガーされます。

   $ oc delete clustergroupupgrades -n ztp-install $CLUSTER

手順

1. 影響を受ける CR から不要になったコンテンツを削除します。この例では、SriovOperatorConfig CR から disableDrain: false 行が削除されました。

   CR の例:

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovOperatorConfig
   metadata:
     name: default
     namespace: openshift-sriov-network-operator
   spec:
     configDaemonNodeSelector:
       "node-role.kubernetes.io/$mcp": ""
     disableDrain: true
     enableInjector: true
     enableOperatorWebhook: true

2. group-du-sno-ranGen.yaml ファイル内で、影響を受けるポリシーの complianceType を mustonlyhave に変更します。

   サンプル YAML

   # ...
   - fileName: SriovOperatorConfig.yaml
     policyName: "config-policy"
     complianceType: mustonlyhave
   # ...

3. ClusterGroupUpdates CR を作成し、CR の変更を受け取る必要があるクラスターを指定します。

   ClusterGroupUpdates CR の例

   apiVersion: ran.openshift.io/v1alpha1
   kind: ClusterGroupUpgrade
   metadata:
     name: cgu-remove
     namespace: default
   spec:
     managedPolicies:
       - ztp-group.group-du-sno-config-policy
     enable: false
     clusters:
     - spoke1
     - spoke2
     remediationStrategy:
       maxConcurrency: 2
       timeout: 240
     batchTimeoutAction:

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

   $ oc create -f cgu-remove.yaml

5. たとえば適切なメンテナンス期間中などに変更を適用する準備が完了したら、次のコマンドを実行して spec.enable フィールドの値を true に変更します。

   $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \
   --patch '{"spec":{"enable":true}}' --type=merge

検証

1. 以下のコマンドを実行してポリシーのステータスを確認します。

   $ oc get <kind> <changed_cr_name>

   出力例

   NAMESPACE   NAME                                                   REMEDIATION ACTION   COMPLIANCE STATE   AGE
   default     cgu-ztp-group.group-du-sno-config-policy               enforce                                 17m
   default     ztp-group.group-du-sno-config-policy                   inform               NonCompliant       15h

   ポリシーの COMPLIANCE STATE が Compliant の場合、CR が更新され、不要なコンテンツが削除されたことを意味します。

2. マネージドクラスターで次のコマンドを実行して、対象クラスターからポリシーが削除されたことを確認します。

   $ oc get <kind> <changed_cr_name>

   結果がない場合、CR はマネージドクラスターから削除されます。

手順

1. 次のコマンドを実行して、出力フォルダーを作成します。

   $ mkdir -p ./out

2. ztp-site-generate コンテナーイメージから argocd ディレクトリーをエクスポートします。

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 extract /home/ztp --tar | tar x -C ./out

   ./out ディレクトリーの out/argocd/example/ フォルダーには、参照 PolicyGenTemplate CR および SiteConfig CR があります。

   出力例

   out
    └── argocd
         └── example
              ├── policygentemplates
              │     ├── common-ranGen.yaml
              │     ├── example-sno-site.yaml
              │     ├── group-du-sno-ranGen.yaml
              │     ├── group-du-sno-validator-ranGen.yaml
              │     ├── kustomization.yaml
              │     └── ns.yaml
              └── siteconfig
                     ├── example-sno.yaml
                     ├── KlusterletAddonConfigOverride.yaml
                     └── kustomization.yaml

3. サイトインストール CR の出力フォルダーを作成します。

   $ mkdir -p ./site-install

4. インストールするクラスタータイプのサンプル SiteConfig CR を変更します。example-sno.yaml を site-1-sno.yaml にコピーし、インストールするサイトとベアメタルホストの詳細に一致するように CR を変更します。次に例を示します。

   # example-node1-bmh-secret & assisted-deployment-pull-secret need to be created under same namespace example-sno
   ---
   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "example-sno"
     namespace: "example-sno"
   spec:
     baseDomain: "example.com"
     pullSecretRef:
       name: "assisted-deployment-pull-secret"
     clusterImageSetNameRef: "openshift-4.10"
     sshPublicKey: "ssh-rsa AAAA..."
     clusters:
       - clusterName: "example-sno"
         networkType: "OVNKubernetes"
         # installConfigOverrides is a generic way of passing install-config
         # parameters through the siteConfig.  The 'capabilities' field configures
         # the composable openshift feature.  In this 'capabilities' setting, we
         # remove all but the marketplace component from the optional set of
         # components.
         # Notes:
         # - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier
         installConfigOverrides: "{\"capabilities\":{\"baselineCapabilitySet\": \"None\", \"additionalEnabledCapabilities\": [ \"marketplace\", \"NodeTuning\" ] }}"
         # It is strongly recommended to include crun manifests as part of the additional install-time manifests for 4.13+.
         # The crun manifests can be obtained from source-crs/optional-extra-manifest/ and added to the git repo ie.sno-extra-manifest.
         # extraManifestPath: sno-extra-manifest
         clusterLabels:
           # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples
           du-profile: "4.14"
           # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples in ../policygentemplates:
           # ../policygentemplates/common-ranGen.yaml will apply to all clusters with 'common: true'
           common: true
           # ../policygentemplates/group-du-sno-ranGen.yaml will apply to all clusters with 'group-du-sno: ""'
           group-du-sno: ""
           # ../policygentemplates/example-sno-site.yaml will apply to all clusters with 'sites: "example-sno"'
           # Normally this should match or contain the cluster name so it only applies to a single cluster
           sites: "example-sno"
         clusterNetwork:
           - cidr: 1001:1::/48
             hostPrefix: 64
         machineNetwork:
           - cidr: 1111:2222:3333:4444::/64
         serviceNetwork:
           - 1001:2::/112
         additionalNTPSources:
           - 1111:2222:3333:4444::2
         # Initiates the cluster for workload partitioning. Setting specific reserved/isolated CPUSets is done via PolicyTemplate
         # please see Workload Partitioning Feature for a complete guide.
         cpuPartitioningMode: AllNodes
         # Optionally; This can be used to override the KlusterletAddonConfig that is created for this cluster:
         #crTemplates:
         #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml"
         nodes:
           - hostName: "example-node1.example.com"
             role: "master"
             # Optionally; This can be used to configure desired BIOS setting on a host:
             #biosConfigRef:
             #  filePath: "example-hw.profile"
             bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1"
             bmcCredentialsName:
               name: "example-node1-bmh-secret"
             bootMACAddress: "AA:BB:CC:DD:EE:11"
             # Use UEFISecureBoot to enable secure boot
             bootMode: "UEFI"
             rootDeviceHints:
               wwn: "0x11111000000asd123"
               # example of diskPartition below is used for image registry (check ImageRegistry.md for more details), but it's not limited to this use case
             #        diskPartition:
             #          - device: /dev/disk/by-id/wwn-0x11111000000asd123 # match rootDeviceHints
             #            partitions:
             #              - mount_point: /var/imageregistry
             #                size: 102500
             #                start: 344844
   
             nodeNetwork:
               interfaces:
                 - name: eno1
                   macAddress: "AA:BB:CC:DD:EE:11"
               config:
                 interfaces:
                   - name: eno1
                     type: ethernet
                     state: up
                     ipv4:
                       enabled: false
                     ipv6:
                       enabled: true
                       address:
                         # For SNO sites with static IP addresses, the node-specific,
                         # API and Ingress IPs should all be the same and configured on
                         # the interface
                         - ip: 1111:2222:3333:4444::aaaa:1
                           prefix-length: 64
                 dns-resolver:
                   config:
                     search:
                       - example.com
                     server:
                       - 1111:2222:3333:4444::2
                 routes:
                   config:
                     - destination: ::/0
                       next-hop-interface: eno1
                       next-hop-address: 1111:2222:3333:4444::1
                       table-id: 254

   注記

   ztp-site-generate コンテナーの out/extra-manifest ディレクトリーから参照 CR 設定ファイルを抽出したら、extraManifests.searchPaths を使用して、それらのファイルを含む git ディレクトリーへのパスを含めることができます。これにより、GitOps ZTP パイプラインはクラスターのインストール中にこれらの CR ファイルを適用できるようになります。searchPaths ディレクトリーを設定すると、GitOps ZTP パイプラインは、サイトのインストール中に ztp-site-generate コンテナーからマニフェストを取得しません。

5. 次のコマンドを実行して、変更された SiteConfig CR site-1-sno.yaml を処理し、Day 0 インストール CR を生成します。

   $ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-install:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 generator install site-1-sno.yaml /output

   出力例

   site-install
   └── site-1-sno
       ├── site-1_agentclusterinstall_example-sno.yaml
       ├── site-1-sno_baremetalhost_example-node1.example.com.yaml
       ├── site-1-sno_clusterdeployment_example-sno.yaml
       ├── site-1-sno_configmap_example-sno.yaml
       ├── site-1-sno_infraenv_example-sno.yaml
       ├── site-1-sno_klusterletaddonconfig_example-sno.yaml
       ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml
       ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml
       ├── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml
       ├── site-1-sno_managedcluster_example-sno.yaml
       ├── site-1-sno_namespace_example-sno.yaml
       └── site-1-sno_nmstateconfig_example-node1.example.com.yaml

6. オプション: -E オプションを使用して参照 SiteConfig CR を処理することにより、特定のクラスタータイプの Day 0 MachineConfig インストール CR のみを生成します。たとえば、以下のコマンドを実行します。

   1. MachineConfig CR の出力フォルダーを作成します。

      $ mkdir -p ./site-machineconfig

   2. MachineConfig インストール CR を生成します。

      $ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-machineconfig:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 generator install -E site-1-sno.yaml /output

      出力例

      site-machineconfig
      └── site-1-sno
          ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml
          ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml
          └── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml

7. 前のステップの参照 PolicyGenTemplate CR を使用して、Day 2 の設定 CR を生成してエクスポートします。以下のコマンドを実行します。

   1. Day 2 CR の出力フォルダーを作成します。

      $ mkdir -p ./ref

   2. Day 2 設定 CR を生成してエクスポートします。

      $ podman run -it --rm -v `pwd`/out/argocd/example/policygentemplates:/resources:Z -v `pwd`/ref:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 generator config -N . /output

      このコマンドは、単一ノード OpenShift、3 ノードクラスター、および標準クラスター用のサンプルグループおよびサイト固有の PolicyGenTemplate CR を ./ref フォルダーに生成します。

      出力例

      ref
       └── customResource
            ├── common
            ├── example-multinode-site
            ├── example-sno
            ├── group-du-3node
            ├── group-du-3node-validator
            │    └── Multiple-validatorCRs
            ├── group-du-sno
            ├── group-du-sno-validator
            ├── group-du-standard
            └── group-du-standard-validator
                 └── Multiple-validatorCRs

8. クラスターのインストールに使用する CR のベースとして、生成された CR を使用します。「単一のマネージドクラスターのインストール」で説明されているように、インストール CR をハブクラスターに適用します。設定 CR は、クラスターのインストールが完了した後にクラスターに適用できます。

手順

1. ホスト Baseboard Management Controller (BMC) の認証情報と、OpenShift およびすべてのアドオンクラスター Operator のインストールに必要なプルシークレットを含む YAML シークレットファイルを作成します。

   1. 次の YAML をファイル example-sno-secret.yaml として保存します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: example-sno-bmc-secret
        namespace: example-sno 1
      data: 2
        password: <base64_password>
        username: <base64_username>
      type: Opaque
      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: pull-secret
        namespace: example-sno  3
      data:
        .dockerconfigjson: <pull_secret> 4
      type: kubernetes.io/dockerconfigjson

      1

      関連する SiteConfig CR で設定された namespace と一致する必要があります

      2

      password と username の Base64 エンコード値

      3

      関連する SiteConfig CR で設定された namespace と一致する必要があります

      4

      Base64 でエンコードされたプルシークレット

2. example-sno-secret.yaml への相対パスを、クラスターのインストールに使用する kustomization.yaml ファイルに追加します。

手順

1. InfraEnv CR の spec.kernelArguments 仕様を編集して、カーネル引数を設定します。

1. ターゲットホストとの SSH セッションを開始します。

   $ ssh -i /path/to/privatekey core@<host_name>

2. 次のコマンドを使用して、システムのカーネル引数を表示します。

   $ cat /proc/cmdline

手順

1. デプロイする特定のクラスターバージョンごとに ClusterImageSet を作成します (例: clusterImageSet-4.15.yaml)。ClusterImageSet のフォーマットは以下のとおりです。

   apiVersion: hive.openshift.io/v1
   kind: ClusterImageSet
   metadata:
     name: openshift-4.15.0 1
   spec:
      releaseImage: quay.io/openshift-release-dev/ocp-release:4.15.0-x86_64 2

   1

   デプロイする記述バージョン。

   2

   デプロイする releaseImage を指定し、オペレーティングシステムイメージのバージョンを決定します。検出 ISO は、releaseImage で設定されたイメージバージョン、または正確なバージョンが利用できない場合は最新バージョンに基づいています。

2. clusterImageSet CR を適用します。

   $ oc apply -f clusterImageSet-4.15.yaml

3. cluster-namespace.yaml ファイルに Namespace CR を作成します。

   apiVersion: v1
   kind: Namespace
   metadata:
        name: <cluster_name> 1
        labels:
           name: <cluster_name> 2

   1 2

   プロビジョニングするマネージドクラスターの名前。

4. 以下のコマンドを実行して Namespace CR を適用します。

   $ oc apply -f cluster-namespace.yaml

5. ztp-site-generate コンテナーから抽出し、要件を満たすようにカスタマイズした、生成された day-0 CR を適用します。

   $ oc apply -R ./site-install/site-sno-1

手順

1. マネージドクラスターのステータスを確認します。

   $ oc get managedcluster

   True はマネージドクラスターの準備が整っていることを示します。

2. エージェントのステータスを確認します。

   $ oc get agent -n <cluster_name>

3. describe コマンドを使用して、エージェントの条件に関する詳細な説明を指定します。認識できるステータスには、BackendError、InputError、ValidationsFailing、InstallationFailed、および AgentIsConnected が含まれます。これらのステータスは、Agent および AgentClusterInstall カスタムリソースに関連します。

   $ oc describe agent -n <cluster_name>

4. クラスターのプロビジョニングのステータスを確認します。

   $ oc get agentclusterinstall -n <cluster_name>

5. describe コマンドを使用して、クラスターのプロビジョニングステータスの詳細な説明を指定します。

   $ oc describe agentclusterinstall -n <cluster_name>

6. マネージドクラスターのアドオンサービスのステータスを確認します。

   $ oc get managedclusteraddon -n <cluster_name>

7. マネージドクラスターの kubeconfig ファイルの認証情報を取得します。

   $ oc get secret -n <cluster_name> <cluster_name>-admin-kubeconfig -o jsonpath={.data.kubeconfig} | base64 -d > <directory>/<cluster_name>-kubeconfig

手順

1. マネージドクラスターのステータスを確認します。

   $ oc get managedcluster

   出力例

   NAME            HUB ACCEPTED   MANAGED CLUSTER URLS   JOINED   AVAILABLE   AGE
   SNO-cluster     true                                   True     True      2d19h

   AVAILABLE 列のステータスが True の場合、マネージドクラスターはハブによって管理されます。

   AVAILABLE 列のステータスが Unknown の場合、マネージドクラスターはハブによって管理されていません。その他の情報を取得するには、以下の手順を使用します。

2. AgentClusterInstall インストールのステータスを確認します。

   $ oc get clusterdeployment -n <cluster_name>

   出力例

   NAME        PLATFORM            REGION   CLUSTERTYPE   INSTALLED    INFRAID    VERSION  POWERSTATE AGE
   Sno0026    agent-baremetal                               false                          Initialized
   2d14h

   INSTALLED 列のステータスが false の場合、インストールは失敗していました。

3. インストールが失敗した場合は、以下のコマンドを実行して AgentClusterInstall リソースのステータスを確認します。

   $ oc describe agentclusterinstall -n <cluster_name> <cluster_name>

4. エラーを解決し、クラスターをリセットします。

   1. クラスターのマネージドクラスターリソースを削除します。

      $ oc delete managedcluster <cluster_name>

   2. クラスターの namespace を削除します。

      $ oc delete namespace <cluster_name>

      これにより、このクラスター用に作成された namespace スコープのカスタムリソースがすべて削除されます。続行する前に、ManagedCluster CR の削除が完了するのを待つ必要があります。

   3. マネージドクラスターのカスタムリソースを再作成します。

手順

1. UEFI/BIOS Boot Mode を UEFI に設定します。
2. ホスト起動シーケンスの順序で、ハードドライブ を設定します。

3. ハードウェアに特定のファームウェア設定を適用します。以下の表は、Intel FlexRAN 4G および 5G baseband PHY 参照設計をベースとした Intel Xeon Skylake または Intel Cascade Lake サーバーの典型的なファームウェア設定を説明しています。

   重要

   ファームウェア設定は、実際のハードウェアおよびネットワークの要件によって異なります。以下の設定例は、説明のみを目的としています。

   表7.2 Intel Xeon Skylake または Cascade Lake サーバーのファームウェア設定例

   ファームウェア設定	設定
   CPU パワーとパフォーマンスポリシー	パフォーマンス
   Uncore Frequency Scaling	Disabled
   パフォーマンスの制限	Disabled
   Intel SpeedStep ® Tech の強化	有効
   Intel Configurable TDP	有効
   設定可能な TDP レベル	レベル 2
   Intel® Turbo Boost Technology	有効
   energy Efficient Turbo	Disabled
   Hardware P-States	Disabled
   Package C-State	C0/C1 の状態
   C1E	Disabled
   Processor C6	Disabled

手順

1. デフォルトの Operator Hub ソースが無効になっていることを確認します。以下のコマンドを実行します。

   $ oc get operatorhub cluster -o yaml

   出力例

   spec:
       disableAllDefaultSources: true

2. 次のコマンドを実行して、必要なすべての CatalogSource リソースにワークロードのパーティショニング (PreferredDuringScheduling) のアノテーションが付けられていることを確認します。

   $ oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'

   出力例

   certified-operators -- {"effect": "PreferredDuringScheduling"}
   community-operators -- {"effect": "PreferredDuringScheduling"}
   ran-operators 1
   redhat-marketplace -- {"effect": "PreferredDuringScheduling"}
   redhat-operators -- {"effect": "PreferredDuringScheduling"}

   1

   アノテーションが付けられていない CatalogSource リソースも返されます。この例では、ran-operators CatalogSource リソースにはアノテーションが付けられておらず、PreferredDuringScheduling アノテーションがありません。

   注記

   適切に設定された vDU クラスターでは、単一のアノテーション付きカタログソースのみがリスト表示されます。

3. 該当するすべての OpenShift Container Platform Operator の namespace がワークロードのパーティショニング用にアノテーションされていることを確認します。これには、コア OpenShift Container Platform とともにインストールされたすべての Operator と、参照 DU チューニング設定に含まれる追加の Operator のセットが含まれます。以下のコマンドを実行します。

   $ oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'

   出力例

   default --
   openshift-apiserver -- management
   openshift-apiserver-operator -- management
   openshift-authentication -- management
   openshift-authentication-operator -- management

   重要

   追加の Operator は、ワークロードパーティショニングのためにアノテーションを付けてはなりません。前のコマンドからの出力では、追加の Operator が -- セパレーターの右側に値なしでリストされている必要があります。

4. ClusterLogging 設定が正しいことを確認してください。以下のコマンドを実行します。

   1. 適切な入力ログと出力ログが設定されていることを確認します。

      $ oc get -n openshift-logging ClusterLogForwarder instance -o yaml

      出力例

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogForwarder
      metadata:
        creationTimestamp: "2022-07-19T21:51:41Z"
        generation: 1
        name: instance
        namespace: openshift-logging
        resourceVersion: "1030342"
        uid: 8c1a842d-80c5-447a-9150-40350bdf40f0
      spec:
        inputs:
        - infrastructure: {}
          name: infra-logs
        outputs:
        - name: kafka-open
          type: kafka
          url: tcp://10.46.55.190:9092/test
        pipelines:
        - inputRefs:
          - audit
          name: audit-logs
          outputRefs:
          - kafka-open
        - inputRefs:
          - infrastructure
          name: infrastructure-logs
          outputRefs:
          - kafka-open
      ...

   2. キュレーションスケジュールがアプリケーションに適していることを確認します。

      $ oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yaml

      出力例

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogging
      metadata:
        creationTimestamp: "2022-07-07T18:22:56Z"
        generation: 1
        name: instance
        namespace: openshift-logging
        resourceVersion: "235796"
        uid: ef67b9b8-0e65-4a10-88ff-ec06922ea796
      spec:
        collection:
          logs:
            fluentd: {}
            type: fluentd
        curation:
          curator:
            schedule: 30 3 * * *
          type: curator
        managementState: Managed
      ...

5. 次のコマンドを実行して、Web コンソールが無効になっている (managementState: Removed) ことを確認します。

   $ oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"

   出力例

   Removed

6. 次のコマンドを実行して、クラスターノードで chronyd が無効になっていることを確認します。

   $ oc debug node/<node_name>

   ノードで chronyd のステータスを確認します。

   sh-4.4# chroot /host

   sh-4.4# systemctl status chronyd

   出力例

   ● chronyd.service - NTP client/server
       Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
       Active: inactive (dead)
         Docs: man:chronyd(8)
               man:chrony.conf(5)

7. linuxptp-daemon コンテナーへのリモートシェル接続と PTP Management Client (pmc) ツールを使用して、PTP インターフェイスがプライマリークロックに正常に同期されていることを確認します。

   1. 次のコマンドを実行して、$PTP_POD_NAME 変数に linuxptp-daemon Pod の名前を設定します。

      $ PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)

   2. 次のコマンドを実行して、PTP デバイスの同期ステータスを確認します。

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'

      出力例

      sending: GET PORT_DATA_SET
        3cecef.fffe.7a7020-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
          portIdentity            3cecef.fffe.7a7020-1
          portState               SLAVE
          logMinDelayReqInterval  -4
          peerMeanPathDelay       0
          logAnnounceInterval     1
          announceReceiptTimeout  3
          logSyncInterval         0
          delayMechanism          1
          logMinPdelayReqInterval 0
          versionNumber           2
        3cecef.fffe.7a7020-2 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
          portIdentity            3cecef.fffe.7a7020-2
          portState               LISTENING
          logMinDelayReqInterval  0
          peerMeanPathDelay       0
          logAnnounceInterval     1
          announceReceiptTimeout  3
          logSyncInterval         0
          delayMechanism          1
          logMinPdelayReqInterval 0
          versionNumber           2

   3. 次の pmc コマンドを実行して、PTP クロックのステータスを確認します。

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET TIME_STATUS_NP'

      出力例

      sending: GET TIME_STATUS_NP
        3cecef.fffe.7a7020-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
          master_offset              10 1
          ingress_time               1657275432697400530
          cumulativeScaledRateOffset +0.000000000
          scaledLastGmPhaseChange    0
          gmTimeBaseIndicator        0
          lastGmPhaseChange          0x0000'0000000000000000.0000
          gmPresent                  true 2
          gmIdentity                 3c2c30.ffff.670e00

      1

      master_offset は -100 から 100 ns の間である必要があります。

      2

      PTP クロックがマスターに同期されており、ローカルクロックがグランドマスタークロックではないことを示します。

   4. /var/run/ptp4l.0.config の値に対応する予期される master offset 値が linuxptp-daemon-container ログにあることを確認します。

      $ oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-container

      出力例

      phc2sys[56020.341]: [ptp4l.1.config] CLOCK_REALTIME phc offset  -1731092 s2 freq -1546242 delay    497
      ptp4l[56020.390]: [ptp4l.1.config] master offset         -2 s2 freq   -5863 path delay       541
      ptp4l[56020.390]: [ptp4l.0.config] master offset         -8 s2 freq  -10699 path delay       533

8. 次のコマンドを実行して、SR-IOV 設定が正しいことを確認します。

   1. SriovOperatorConfig リソースの disableDrain 値が true に設定されていることを確認します。

      $ oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"

      出力例

      true

   2. 次のコマンドを実行して、SriovNetworkNodeState 同期ステータスが Succeeded であることを確認します。

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"

      出力例

      Succeeded

   3. SR-IOV 用に設定された各インターフェイスの下の仮想機能 (Vfs) の予想される数と設定が、.status.interfaces フィールドに存在し、正しいことを確認します。以下に例を示します。

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yaml

      出力例

      apiVersion: v1
      items:
      - apiVersion: sriovnetwork.openshift.io/v1
        kind: SriovNetworkNodeState
      ...
        status:
          interfaces:
          ...
          - Vfs:
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.0
              vendor: "8086"
              vfID: 0
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.1
              vendor: "8086"
              vfID: 1
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.2
              vendor: "8086"
              vfID: 2
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.3
              vendor: "8086"
              vfID: 3
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.4
              vendor: "8086"
              vfID: 4
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.5
              vendor: "8086"
              vfID: 5
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.6
              vendor: "8086"
              vfID: 6
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.7
              vendor: "8086"
              vfID: 7

9. クラスターパフォーマンスプロファイルが正しいことを確認します。cpu セクションと hugepages セクションは、ハードウェア設定によって異なります。以下のコマンドを実行します。

   $ oc get PerformanceProfile openshift-node-performance-profile -o yaml

   出力例

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     creationTimestamp: "2022-07-19T21:51:31Z"
     finalizers:
     - foreground-deletion
     generation: 1
     name: openshift-node-performance-profile
     resourceVersion: "33558"
     uid: 217958c0-9122-4c62-9d4d-fdc27c31118c
   spec:
     additionalKernelArgs:
     - idle=poll
     - rcupdate.rcu_normal_after_boot=0
     - efi=runtime
     cpu:
       isolated: 2-51,54-103
       reserved: 0-1,52-53
     hugepages:
       defaultHugepagesSize: 1G
       pages:
       - count: 32
         size: 1G
     machineConfigPoolSelector:
       pools.operator.machineconfiguration.openshift.io/master: ""
     net:
       userLevelNetworking: true
     nodeSelector:
       node-role.kubernetes.io/master: ""
     numa:
       topologyPolicy: restricted
     realTimeKernel:
       enabled: true
   status:
     conditions:
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "True"
       type: Available
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "True"
       type: Upgradeable
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "False"
       type: Progressing
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "False"
       type: Degraded
     runtimeClass: performance-openshift-node-performance-profile
     tuned: openshift-cluster-node-tuning-operator/openshift-node-performance-openshift-node-performance-profile

   注記

   CPU 設定は、サーバーで使用可能なコアの数に依存し、ワークロードパーティショニングの設定に合わせる必要があります。hugepages の設定は、サーバーとアプリケーションに依存します。

10. 次のコマンドを実行して、PerformanceProfile がクラスターに正常に適用されたことを確認します。

    $ oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"

    出力例

    Available -- True
    Upgradeable -- True
    Progressing -- False
    Degraded -- False

11. 次のコマンドを実行して、Tuned パフォーマンスパッチの設定を確認します。

    $ oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yaml

    出力例

    apiVersion: tuned.openshift.io/v1
    kind: Tuned
    metadata:
      creationTimestamp: "2022-07-18T10:33:52Z"
      generation: 1
      name: performance-patch
      namespace: openshift-cluster-node-tuning-operator
      resourceVersion: "34024"
      uid: f9799811-f744-4179-bf00-32d4436c08fd
    spec:
      profile:
      - data: |
          [main]
          summary=Configuration changes profile inherited from performance created tuned
          include=openshift-node-performance-openshift-node-performance-profile
          [bootloader]
          cmdline_crash=nohz_full=2-23,26-47 1
          [sysctl]
          kernel.timer_migration=1
          [scheduler]
          group.ice-ptp=0:f:10:*:ice-ptp.*
          [service]
          service.stalld=start,enable
          service.chronyd=stop,disable
        name: performance-patch
      recommend:
      - machineConfigLabels:
          machineconfiguration.openshift.io/role: master
        priority: 19
        profile: performance-patch

    1

    cmdline=nohz_full= の cpu リストは、ハードウェア設定によって異なります。

12. 次のコマンドを実行して、クラスターネットワーク診断が無効になっていることを確認します。

    $ oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'

    出力例

    true

13. Kubelet のハウスキーピング間隔が、遅い速度に調整されていることを確認します。これは、containerMountNS マシン設定で設定されます。以下のコマンドを実行します。

    $ oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION

    出力例

    Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"

14. 次のコマンドを実行して、Grafana と alertManagerMain が無効になっていること、および Prometheus の保持期間が 24 時間に設定されていることを確認します。

    $ oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"

    出力例

    grafana:
      enabled: false
    alertmanagerMain:
      enabled: false
    prometheusK8s:
       retention: 24h

    1. 次のコマンドを使用して、Grafana および alertManagerMain ルートがクラスター内に見つからないことを確認します。

       $ oc get route -n openshift-monitoring alertmanager-main

       $ oc get route -n openshift-monitoring grafana

       どちらのクエリーも Error from server (NotFound) メッセージを返す必要があります。

15. 次のコマンドを実行して、PerformanceProfile、Tuned performance-patch、ワークロードパーティショニング、およびカーネルコマンドライン引数のそれぞれに reserved として割り当てられた CPU が少なくとも 4 つあることを確認します。

    $ oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"

    出力例

    0-3

    注記

    ワークロードの要件によっては、追加の予約済み CPU の割り当てが必要になる場合があります。

手順

1. GitOps ZTP パイプラインがクラスターインストールのカスタマイズ使用する、追加のマニフェスト CR のセットを作成します。

2. カスタム /siteconfig ディレクトリーに、追加のマニフェスト用のサブディレクトリー /custom-manifest を作成します。以下の例は、/custom-manifest フォルダーを持つ /siteconfig のサンプルを示しています。

   siteconfig
   ├── site1-sno-du.yaml
   ├── site2-standard-du.yaml
   ├── extra-manifest/
   └── custom-manifest
       └── 01-example-machine-config.yaml

   注記

   全体で使用されているサブディレクトリー名 /custom-manifest および /extra-manifest は、名前の例にすぎません。これらの名前を使用する必要はなく、これらのサブディレクトリーに名前を付ける方法に制限はありません。この例では、/extra-manifest は、ztp-site-generate コンテナーの /extra-manifest の内容を保存する Git サブディレクトリーを指します。

3. カスタムの追加マニフェスト CR を siteconfig/custom-manifest ディレクトリーに追加します。

4. SiteConfig CR で、extraManifests.searchPaths フィールドにディレクトリー名を入力します。例:

   clusters:
   - clusterName: "example-sno"
     networkType: "OVNKubernetes"
     extraManifests:
       searchPaths:
         - extra-manifest/ 1
         - custom-manifest/ 2

   1

   ztp-site-generate コンテナーからコピーされたマニフェストのフォルダー。

   2

   カスタムマニフェストのフォルダー。

5. SiteConfig、/extra-manifest、および /custom-manifest CR を保存し、サイト設定リポジトリーにプッシュします。

手順

1. GitOps ZTP パイプラインが 03-sctp-machine-config-worker.yaml CR ファイルを適用しないようにするには、SiteConfig CR で次の YAML を適用します。

   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "site1-sno-du"
     namespace: "site1-sno-du"
   spec:
     baseDomain: "example.com"
     pullSecretRef:
       name: "assisted-deployment-pull-secret"
     clusterImageSetNameRef: "openshift-4.15"
     sshPublicKey: "<ssh_public_key>"
     clusters:
   - clusterName: "site1-sno-du"
     extraManifests:
       filter:
         exclude:
           - 03-sctp-machine-config-worker.yaml

   GitOps ZTP パイプラインは、インストール中に 03-sctp-machine-config-worker.yaml CR をスキップします。/source-crs/extra-manifest 内の他のすべての CR が適用されます。

2. SiteConfig CR を保存し、変更をサイト設定リポジトリーにプッシュします。

   GitOps ZTP パイプラインは、SiteConfig フィルター命令に基づいて適用する CR を監視および調整します。

3. オプション: クラスターのインストール中に GitOps ZTP パイプラインがすべての /source-crs/extra-manifest CR を適用しないようにするには、SiteConfig CR で次の YAML を適用します。

   - clusterName: "site1-sno-du"
     extraManifests:
       filter:
         inclusionDefault: exclude

4. オプション: インストール中にすべての /source-crs/extra-manifest RAN CR を除外し、代わりにカスタム CR ファイルを含めるには、カスタム SiteConfig CR を編集してカスタムマニフェストフォルダーと include ファイルを設定します。次に例を示します。

   clusters:
   - clusterName: "site1-sno-du"
     extraManifestPath: "<custom_manifest_folder>" 1
     extraManifests:
       filter:
         inclusionDefault: exclude  2
         include:
           - custom-sctp-machine-config-worker.yaml

   1

   <custom_manifest_folder> を、カスタムインストール CR を含むフォルダーの名前 (user-custom-manifest/ など) に置き換えます。

   2

   インストール中に GitOps ZTP パイプラインが /source-crs/extra-manifest 内のファイルを適用しないようにするには、inclusionDefault を exclude に設定します。

   次の例は、カスタムフォルダー構造を示しています。

   siteconfig
     ├── site1-sno-du.yaml
     └── user-custom-manifest
           └── custom-sctp-machine-config-worker.yaml

手順

1. SiteConfig CR を更新して、bmac.agent-install.openshift.io/remove-agent-and-node-on-delete=true を追加します。

   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "cnfdf20"
     namespace: "cnfdf20"
   spec:
     Clusters:
       nodes:
       - hostname: node6
         role: "worker"
         crAnnotations:
           add:
             BareMetalHost:
               bmac.agent-install.openshift.io/remove-agent-and-node-on-delete: true
   # ...

2. SiteConfig CR を更新して crSuppression.BareMetalHost アノテーションを含めることで、BareMetalHost CR の生成を抑制します。

   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "cnfdf20"
     namespace: "cnfdf20"
   spec:
     clusters:
     - nodes:
       - hostName: node6
         role: "worker"
         crSuppression:
         - BareMetalHost
   # ...

3. 変更を Git リポジトリーにプッシュし、プロビジョニング解除が開始するまで待ちます。BareMetalHost CR のステータスが deprovisioning に変更されるはずです。BareMetalHost のプロビジョニング解除が完了し、完全に削除されるまで待ちます。

検証

1. 次のコマンドを実行して、ワーカーノードの BareMetalHost および Agent CR がハブクラスターから削除されていることを確認します。

   $ oc get bmh -n <cluster-ns>

   $ oc get agent -n <cluster-ns>

2. 次のコマンドを実行して、スポーククラスターからノードレコードが削除されたことを確認します。

   $ oc get nodes

   注記

   シークレットを操作している場合は、シークレットを削除するのが早すぎると、ArgoCD が削除後に再同期を完了するためにシークレットを必要とするため、問題が発生する可能性があります。現在の ArgoCD 同期が完了したら、ノードのクリーンアップ後にのみシークレットを削除します。

手順

1. 既存のコンテンツのベースラインソース CR を確認します。参照 PolicyGenTemplate CR に記載されているソース CR を GitOps Zero Touch Provisioning (ZTP) コンテナーから抽出し、確認すできます。

   1. /out フォルダーを作成します。

      $ mkdir -p ./out

   2. ソース CR を抽出します。

      $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15.1 extract /home/ztp --tar | tar x -C ./out

2. ./out/source-crs/PerformanceProfile.yaml にあるベースライン PerformanceProfile CR を確認します。

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: $name
     annotations:
       ran.openshift.io/ztp-deploy-wave: "10"
   spec:
     additionalKernelArgs:
     - "idle=poll"
     - "rcupdate.rcu_normal_after_boot=0"
     cpu:
       isolated: $isolated
       reserved: $reserved
     hugepages:
       defaultHugepagesSize: $defaultHugepagesSize
       pages:
         - size: $size
           count: $count
           node: $node
     machineConfigPoolSelector:
       pools.operator.machineconfiguration.openshift.io/$mcp: ""
     net:
       userLevelNetworking: true
     nodeSelector:
       node-role.kubernetes.io/$mcp: ''
     numa:
       topologyPolicy: "restricted"
     realTimeKernel:
       enabled: true

   注記

   ソース CR のフィールドで $... を含むものは、PolicyGenTemplate CR で提供されない場合、生成された CR から削除されます。

3. group-du-sno-ranGen.yaml リファレンスファイルの PerformanceProfile の PolicyGenTemplate エントリーを更新します。次の例の PolicyGenTemplate CR スタンザは、適切な CPU 仕様を提供し、hugepages 設定を設定し、globallyDisableIrqLoadBalancing を false に設定する新しいフィールドを追加しています。

   - fileName: PerformanceProfile.yaml
     policyName: "config-policy"
     metadata:
       name: openshift-node-performance-profile
     spec:
       cpu:
         # These must be tailored for the specific hardware platform
         isolated: "2-19,22-39"
         reserved: "0-1,20-21"
       hugepages:
         defaultHugepagesSize: 1G
         pages:
           - size: 1G
             count: 10
       globallyDisableIrqLoadBalancing: false

4. Git で PolicyGenTemplate 変更をコミットし、GitOps ZTP argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。

手順

1. PolicyGenTemplate カスタムリソース (CR) の kustomization.yaml ファイルが含まれるディレクトリーに、source-crs という名前のサブディレクトリーを作成します。

2. 次の例に示すように、ユーザー提供の CR を source-crs サブディレクトリーに追加します。

   example
   └── policygentemplates
       ├── dev.yaml
       ├── kustomization.yaml
       ├── mec-edge-sno1.yaml
       ├── sno.yaml
       └── source-crs 1
           ├── PaoCatalogSource.yaml
           ├── PaoSubscription.yaml
           ├── custom-crs
           |   ├── apiserver-config.yaml
           |   └── disable-nic-lldp.yaml
           └── elasticsearch
               ├── ElasticsearchNS.yaml
               └── ElasticsearchOperatorGroup.yaml

   1

   source-crs サブディレクトリーは、kustomization.yaml ファイルと同じディレクトリーにある必要があります。

3. 必要な PolicyGenTemplate CR を更新して、source-crs/custom-crs および source-crs/elasticsearch ディレクトリーに追加したコンテンツへの参照を含めます。以下に例を示します。

   apiVersion: ran.openshift.io/v1
   kind: PolicyGenTemplate
   metadata:
     name: "group-dev"
     namespace: "ztp-clusters"
   spec:
     bindingRules:
       dev: "true"
     mcp: "master"
     sourceFiles:
       # These policies/CRs come from the internal container Image
       #Cluster Logging
       - fileName: ClusterLogNS.yaml
         remediationAction: inform
         policyName: "group-dev-cluster-log-ns"
       - fileName: ClusterLogOperGroup.yaml
         remediationAction: inform
         policyName: "group-dev-cluster-log-operator-group"
       - fileName: ClusterLogSubscription.yaml
         remediationAction: inform
         policyName: "group-dev-cluster-log-sub"
       #Local Storage Operator
       - fileName: StorageNS.yaml
         remediationAction: inform
         policyName: "group-dev-lso-ns"
       - fileName: StorageOperGroup.yaml
         remediationAction: inform
         policyName: "group-dev-lso-operator-group"
       - fileName: StorageSubscription.yaml
         remediationAction: inform
         policyName: "group-dev-lso-sub"
       #These are custom local polices that come from the source-crs directory in the git repo
       # Performance Addon Operator
       - fileName: PaoSubscriptionNS.yaml
         remediationAction: inform
         policyName: "group-dev-pao-ns"
       - fileName: PaoSubscriptionCatalogSource.yaml
         remediationAction: inform
         policyName: "group-dev-pao-cat-source"
         spec:
           image: <image_URL_here>
       - fileName: PaoSubscription.yaml
         remediationAction: inform
         policyName: "group-dev-pao-sub"
       #Elasticsearch Operator
       - fileName: elasticsearch/ElasticsearchNS.yaml 1
         remediationAction: inform
         policyName: "group-dev-elasticsearch-ns"
       - fileName: elasticsearch/ElasticsearchOperatorGroup.yaml
         remediationAction: inform
         policyName: "group-dev-elasticsearch-operator-group"
       #Custom Resources
       - fileName: custom-crs/apiserver-config.yaml 2
         remediationAction: inform
         policyName: "group-dev-apiserver-config"
       - fileName: custom-crs/disable-nic-lldp.yaml
         remediationAction: inform
         policyName: "group-dev-disable-nic-lldp"

   1 2

   /source-crs 親ディレクトリーからのファイルへの相対パスを含むように fileName を設定します。

4. Git で PolicyGenTemplate の変更をコミットし、GitOps ZTP Argo CD ポリシーアプリケーションが監視する Git リポジトリーにプッシュします。

5. ClusterGroupUpgrade CR を更新して、変更された PolicyGenTemplate を含め、cgu-test.yaml として保存します。次の例は、生成された cgu-test.yaml ファイルを示しています。

   apiVersion: ran.openshift.io/v1alpha1
   kind: ClusterGroupUpgrade
   metadata:
     name: custom-source-cr
     namespace: ztp-clusters
   spec:
     managedPolicies:
       - group-dev-config-policy
     enable: true
     clusters:
     - cluster1
     remediationStrategy:
       maxConcurrency: 2
       timeout: 240

6. 次のコマンドを実行して、更新された ClusterGroupUpgrade CR を適用します。

   $ oc apply -f cgu-test.yaml

手順

1. PolicyGenTemplate CR のすべてのポリシーの評価間隔を設定するには、evaluationInterval を spec フィールドに追加し、適切な compliant 値と noncompliant 値を設定します。以下に例を示します。

   spec:
     evaluationInterval:
       compliant: 30m
       noncompliant: 20s

2. PolicyGenTemplate CR で spec.sourceFiles オブジェクトの評価間隔を設定するには、次の例のように、evaluationInterval を sourceFiles フィールドに追加します。

   spec:
     sourceFiles:
      - fileName: SriovSubscription.yaml
        policyName: "sriov-sub-policy"
        evaluationInterval:
          compliant: never
          noncompliant: 10s

3. PolicyGenTemplate CR ファイルを Git リポジトリーにコミットし、変更をプッシュします。

1. 管理対象クラスターで cluster-admin 権限を持つユーザーとしてログインします。

2. open-cluster-management-agent-addon namespace で実行されている Pod を取得します。以下のコマンドを実行します。

   $ oc get pods -n open-cluster-management-agent-addon

   出力例

   NAME                                         READY   STATUS    RESTARTS        AGE
   config-policy-controller-858b894c68-v4xdb    1/1     Running   22 (5d8h ago)   10d

3. config-policy-controller Pod のログで、適用されたポリシーが予想される間隔で評価されていることを確認します。

   $ oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb

   出力例

   2022-05-10T15:10:25.280Z       info   configuration-policy-controller controllers/configurationpolicy_controller.go:166      Skipping the policy evaluation due to the policy not reaching the evaluation interval  {"policy": "compute-1-config-policy-config"}
   2022-05-10T15:10:25.280Z       info   configuration-policy-controller controllers/configurationpolicy_controller.go:166      Skipping the policy evaluation due to the policy not reaching the evaluation interval  {"policy": "compute-1-common-compute-1-catalog-policy-config"}

手順

1. ソースファイル validatorCRs/informDuValidator.yaml を含むスタンドアロンの PolicyGenTemplate カスタムリソース (CR) を作成します。スタンドアロン PolicyGenTemplate CR は、各クラスタータイプに 1 つだけ必要です。たとえば、次の CR は、単一ノードの OpenShift クラスターにバリデータ通知ポリシーを適用します。

   単一ノードクラスターバリデータ通知ポリシー CR の例 (group-du-sno-validator-ranGen.yaml)

   apiVersion: ran.openshift.io/v1
   kind: PolicyGenTemplate
   metadata:
     name: "group-du-sno-validator" 1
     namespace: "ztp-group" 2
   spec:
     bindingRules:
       group-du-sno: "" 3
     bindingExcludedRules:
       ztp-done: "" 4
     mcp: "master" 5
     sourceFiles:
       - fileName: validatorCRs/informDuValidator.yaml
         remediationAction: inform 6
         policyName: "du-policy" 7

   1

   PolicyGenTemplates オブジェクトの名前。この名前は、placementBinding、placementRule、および要求された namespace で作成される policy の一部としても使用されます。

   2

   この値は、グループ PolicyGenTemplates で使用される namespace と一致する必要があります。

   3

   bindingRules で定義された group-du-* ラベルは SiteConfig ファイルに存在している必要があります。

   4

   bindingExcludedRules で定義されたラベルは 'ztp-done:' でなければなりません。ztp-done ラベルは、Topology Aware Lifecycle Manager と調整するために使用されます。

   5

   mcp はソースファイル validatorCRs/informDuValidator.yaml で使用される MachineConfigPool オブジェクトを定義する。これは、単一ノードの場合は master であり、標準のクラスターデプロイメントの場合は 3 ノードクラスターデプロイメントおよび worker である必要があります。

   6

   オプション: デフォルト値は inform です。

   7

   この値は、生成された RHACM ポリシーの名前の一部として使用されます。単一ノードの例の生成されたバリデーターポリシーは group-du-sno-validator-du-policy という名前です。

2. PolicyGenTemplate CR ファイルを Git リポジトリーにコミットし、変更をプッシュします。

手順

1. 新しいマネージドクラスター用に LVM ストレージを設定するには、次の YAML を common-ranGen.yaml ファイルの spec.sourceFiles に追加します。

   - fileName: StorageLVMOSubscriptionNS.yaml
     policyName: subscription-policies
   - fileName: StorageLVMOSubscriptionOperGroup.yaml
     policyName: subscription-policies
   - fileName: StorageLVMOSubscription.yaml
     spec:
       name: lvms-operator
       channel: stable-4.15
     policyName: subscription-policies

   注記

   Storage LVMO サブスクリプションは非推奨になりました。OpenShift Container Platform の将来のリリースでは、ストレージ LVMO サブスクリプションは利用できなくなります。代わりに、Storage LVMS サブスクリプションを使用する必要があります。

   OpenShift Container Platform 4.15 では、LVMO サブスクリプションの代わりに Storage LVMS サブスクリプションを使用できます。LVMS サブスクリプションでは、common-ranGen.yaml ファイルを手動で上書きする必要はありません。Storage LVMS サブスクリプションを使用するには、次の YAML を common-ranGen.yaml ファイルの spec.sourceFiles に追加します。

   - fileName: StorageLVMSubscriptionNS.yaml
     policyName: subscription-policies
   - fileName: StorageLVMSubscriptionOperGroup.yaml
     policyName: subscription-policies
   - fileName: StorageLVMSubscription.yaml
     policyName: subscription-policies

2. 特定のグループまたは個々のサイト設定ファイルの spec.sourceFiles に LVMCluster CR を追加します。たとえば、group-du-sno-ranGen.yaml ファイルに次を追加します。

   - fileName: StorageLVMCluster.yaml
     policyName: "lvms-config" 1
     spec:
       storage:
         deviceClasses:
         - name: vg1
           thinPoolConfig:
             name: thin-pool-1
             sizePercent: 90
             overprovisionRatio: 10

   1

   この設定例では、OpenShift Container Platform がインストールされているディスクを除く、使用可能なすべてのデバイスを含むボリュームグループ (vg1) を作成します。シンプール論理ボリュームも作成されます。

3. 必要なその他の変更およびファイルをカスタムサイトリポジトリーにマージします。
4. Git で PolicyGenTemplate の変更をコミットし、その変更をサイト設定リポジトリーにプッシュして、GitOps ZTP を使用して LVM ストレージを新しいサイトにデプロイします。

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub ページに移動します。
2. 利用可能な Operator のリストから Topology Aware Lifecycle Manager を検索し、Install をクリックします。
3. Installation mode ["All namespaces on the cluster (default)"] および Installed Namespace ("openshift-operators") のデフォルトの選択を維持し、Operator が適切にインストールされていることを確認します。
4. Install をクリックします。

1. Operators → Installed Operators ページに移動します。
2. Operator が All Namespaces ネームスペースにインストールされ、そのステータスが Succeeded であることを確認します。

1. Operators → Installed Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
2. Workloads → Pods ページに移動し、問題を報告している cluster-group-upgrades-controller-manager Pod のコンテナーのログを確認します。

手順

1. SubscriptionCR を作成します。

   1. Subscription CR を定義し、YAML ファイルを保存します (例: talm-subscription.yaml)。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: openshift-topology-aware-lifecycle-manager-subscription
        namespace: openshift-operators
      spec:
        channel: "stable"
        name: topology-aware-lifecycle-manager
        source: redhat-operators
        sourceNamespace: openshift-marketplace

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

      $ oc create -f talm-subscription.yaml

検証

1. CSV リソースを調べて、インストールが成功したことを確認します。

   $ oc get csv -n openshift-operators

   出力例

   NAME                                                   DISPLAY                            VERSION               REPLACES                           PHASE
   topology-aware-lifecycle-manager.4.15.x   Topology Aware Lifecycle Manager   4.15.x                                      Succeeded

2. TALM が稼働していることを確認します。

   $ oc get deploy -n openshift-operators

   出力例

   NAMESPACE                                          NAME                                             READY   UP-TO-DATE   AVAILABLE   AGE
   openshift-operators                                cluster-group-upgrades-controller-manager        1/1     1            1           14s