エッジコンピューティング

手順

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

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

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

      $ export ISO_IMAGE_NAME=<iso_image_name> 

      1

      Copy to Clipboard

      $ export ROOTFS_IMAGE_NAME=<rootfs_image_name> 

      1

      Copy to Clipboard

      $ export OCP_VERSION=<ocp_version> 

      1

      Copy to Clipboard

      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}

      Copy to Clipboard

      $ 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}

      Copy to Clipboard

手順

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

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

   $ oc edit AgentServiceConfig

   Copy to Clipboard

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

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

   Copy to Clipboard

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

   <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

   Copy to Clipboard

   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> 

   3

   
         url: <iso_url> 

   4

   Copy to Clipboard

   1

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

   2

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

   3

   OpenShift Container Platform のバージョンを x.y または x.y.z 形式に設定します。

   4

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

手順

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

   $ oc edit AgentServiceConfig agent

   Copy to Clipboard

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

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

   Copy to Clipboard

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

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

   $ oc debug node/<node_name>

   Copy to Clipboard

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

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

   Copy to Clipboard

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

   <unauthenticated_registry>

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

   出力例

   Login Succeeded!

   Copy to Clipboard

手順

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 プラグインをインストールするには、ハブクラスター内の ArgoCD インスタンスに、関連するマルチクラスターエンジン (MCE) サブスクリプションイメージをパッチ適用します。以前に out/argocd/deployment/ ディレクトリーに展開したパッチファイルを環境に合わせてカスタマイズします。

   1. RHACM バージョンに一致する multicluster-operators-subscription イメージを選択します。

      • RHACM 2.8 および 2.9 の場合は、registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v<rhacm_version> イメージを使用します。
      • RHACM 2.10 以降の場合は、registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v<rhacm_version> イメージを使用します。
      重要

      multicluster-operators-subscription イメージのバージョンは、RHACM のバージョンと一致する必要があります。MCE 2.10 リリース以降、RHEL 9 は multicluster-operators-subscription イメージのベースイメージです。

      OpenShift Operator のライフサイクル の表「Platform Aligned Operators」の [Expand for Operator list] をクリックすると、OpenShift Container Platform でサポートされている Operator の完全なマトリックスが表示されます。

   2. out/argocd/deployment/argocd-openshift-gitops-patch.json ファイルに次の設定を追加します。

      {
        "args": [
          "-c",
          "mkdir -p /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator && cp /policy-generator/PolicyGenerator-not-fips-compliant /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator" 

      1

      
        ],
        "command": [
          "/bin/bash"
        ],
        "image": "registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10", 

      2

      3

      
        "name": "policy-generator-install",
        "imagePullPolicy": "Always",
        "volumeMounts": [
          {
            "mountPath": "/.config",
            "name": "kustomize"
          }
        ]
      }

      Copy to Clipboard

      1

      オプション: RHEL 9 イメージの場合、ArgoCD バージョンの /policy-generator/PolicyGenerator-not-fips-compliant フォルダーに必要なユニバーサル実行可能ファイルをコピーします。

      2

      multicluster-operators-subscription イメージを RHACM バージョンに一致させます。

      3

      非接続環境では、multicluster-operators-subscription イメージの URL を、ご使用の環境の非接続レジストリーに相当するものに置き換えます。

   3. ArgoCD インスタンスにパッチを適用します。以下のコマンドを実行します。

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

      Copy to Clipboard

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

   Copy to Clipboard

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

   $ oc apply -k out/argocd/deployment

   Copy to Clipboard

5. オプション: 既存の ArgoCD アプリケーションがある場合は、次のコマンドを実行して、Application リソースに PrunePropagationPolicy=background ポリシーが設定されていることを確認します。

   $ oc -n openshift-gitops get applications.argoproj.io  \
   clusters -o jsonpath='{.spec.syncPolicy.syncOptions}' |jq

   Copy to Clipboard

   既存のポリシーの出力例

   [
     "CreateNamespace=true",
     "PrunePropagationPolicy=background",
     "RespectIgnoreDifferences=true"
   ]

   Copy to Clipboard

   1. spec.syncPolicy.syncOption フィールドに PrunePropagationPolicy パラメーターが含まれていない場合、または PrunePropagationPolicy が foreground 値に設定されている場合は、Application リソースでポリシーを background に設定します。以下の例を参照してください。

      kind: Application
      spec:
        syncPolicy:
          syncOptions:
          - PrunePropagationPolicy=background

      Copy to Clipboard

   background 削除ポリシーを設定すると、ManagedCluster CR とそれに関連付けられたすべてのリソースが削除されます。

手順

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

   Copy to Clipboard

   $ mkdir -p ./out

   Copy to Clipboard

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

   Copy to Clipboard

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

   Copy to Clipboard
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

   Copy to Clipboard

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

   Copy to Clipboard

   /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'

   Copy to Clipboard

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

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

   Copy to Clipboard

手順

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

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

   Copy to Clipboard

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

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

   Copy to Clipboard

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

   Copy to Clipboard

手順

1. GitOps ZTP プラグインをインストールするには、ハブクラスター内の ArgoCD インスタンスに、関連するマルチクラスターエンジン (MCE) サブスクリプションイメージをパッチ適用します。以前に out/argocd/deployment/ ディレクトリーに展開したパッチファイルを環境に合わせてカスタマイズします。

   1. RHACM バージョンに一致する multicluster-operators-subscription イメージを選択します。

      • RHACM 2.8 および 2.9 の場合は、registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v<rhacm_version> イメージを使用します。
      • RHACM 2.10 以降の場合は、registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v<rhacm_version> イメージを使用します。
      重要

      multicluster-operators-subscription イメージのバージョンは、RHACM のバージョンと一致する必要があります。MCE 2.10 リリース以降、RHEL 9 は multicluster-operators-subscription イメージのベースイメージです。

      OpenShift Operator のライフサイクル の表「Platform Aligned Operators」の [Expand for Operator list] をクリックすると、OpenShift Container Platform でサポートされている Operator の完全なマトリックスが表示されます。

   2. out/argocd/deployment/argocd-openshift-gitops-patch.json ファイルに次の設定を追加します。

      {
        "args": [
          "-c",
          "mkdir -p /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator && cp /policy-generator/PolicyGenerator-not-fips-compliant /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator" 

      1

      
        ],
        "command": [
          "/bin/bash"
        ],
        "image": "registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10", 

      2

      3

      
        "name": "policy-generator-install",
        "imagePullPolicy": "Always",
        "volumeMounts": [
          {
            "mountPath": "/.config",
            "name": "kustomize"
          }
        ]
      }

      Copy to Clipboard

      1

      オプション: RHEL 9 イメージの場合、ArgoCD バージョンの /policy-generator/PolicyGenerator-not-fips-compliant フォルダーに必要なユニバーサル実行可能ファイルをコピーします。

      2

      multicluster-operators-subscription イメージを RHACM バージョンに一致させます。

      3

      非接続環境では、multicluster-operators-subscription イメージの URL を、ご使用の環境の非接続レジストリーに相当するものに置き換えます。

   3. ArgoCD インスタンスにパッチを適用します。以下のコマンドを実行します。

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

      Copy to Clipboard

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

   Copy to Clipboard

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

   $ oc apply -k out/argocd/deployment

   Copy to Clipboard

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

      Copy to Clipboard

      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 }}"

      Copy to Clipboard

      1

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

      2

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

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

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

   Copy to Clipboard

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

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

   Copy to Clipboard

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

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

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

   Copy to Clipboard

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

   $ cat /proc/cmdline

   Copy to Clipboard

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

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

      $ export CLUSTER=<clusterName>

      Copy to Clipboard

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

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

      Copy to Clipboard

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

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

      Copy to Clipboard

手順

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

   $ oc get AgentClusterInstall -n <cluster_name>

   Copy to Clipboard

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

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

   $ oc get managedcluster

   Copy to Clipboard

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

   $ oc get applications.argoproj.io -n openshift-gitops clusters -o yaml

   Copy to Clipboard

   1. マネージドクラスターのエラーログを識別するには、status.operationState.syncResult.resources フィールドを調べます。たとえば、SiteConfig CR の extraManifestPath に無効な値が割り当てられると、次のようなエラーが生成されます。

      syncResult:
        resources:
        - group: ran.openshift.io
          kind: SiteConfig
          message: The Kubernetes API could not find ran.openshift.io/SiteConfig for
            requested resource spoke-sno/spoke-sno. Make sure the "SiteConfig" CRD is
            installed on the destination cluster

      Copy to Clipboard

   2. より詳細な SiteConfig エラーを表示するには、次の手順を実行します。

      1. Argo CD ダッシュボードで、Argo CD が同期しようとしている SiteConfig リソースをクリックします。

      2. DESIRED MANIFEST タブをチェックして、siteConfigError フィールドを見つけます。

         siteConfigError: >- Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-1081291903: stat sno-extra-manifest: no such file or directory

         Copy to Clipboard

   3. 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

      Copy to Clipboard

手順

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

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

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

手順

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

2. 次の syncOptions フィールドを SiteConfig アプリケーションに追加します。

   kind: Application
   spec:
     syncPolicy:
       syncOptions:
       - PrunePropagationPolicy=background

   Copy to Clipboard

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

3. 任意: サイトを永続的に削除する場合は、Git リポジトリーから SiteConfig ファイルおよびサイト固有の PolicyGenTemplate ファイルも削除する必要があります。
4. 任意: たとえば、サイトを再デプロイする際にサイトを一時的に削除する場合には、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>

   Copy to Clipboard

手順

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

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

   $ oc delete -k out/argocd/deployment

   Copy to Clipboard
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>

   Copy to Clipboard

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

   Copy to Clipboard

   出力例

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

   Copy to Clipboard

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

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

      $ oc get policies -n $CLUSTER

      Copy to Clipboard

      出力例

      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

      Copy to Clipboard

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

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

手順

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

   $ oc describe -n openshift-gitops application policies

   Copy to Clipboard

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

   Copy to Clipboard

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

   Copy to Clipboard

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

   $ oc get policy -n $CLUSTER

   Copy to Clipboard

   出力例:

   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

   Copy to Clipboard

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

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

   $ oc get placementrule -n $NS

   Copy to Clipboard

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

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

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

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

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

   Copy to Clipboard

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

   $ oc get policy -n $CLUSTER

   Copy to Clipboard

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

手順

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

   $ export CLUSTER=<clusterName>

   Copy to Clipboard

   $ oc get clustergroupupgrades -n ztp-install $CLUSTER

   Copy to Clipboard

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

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

   Copy to Clipboard

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

   $ oc delete clustergroupupgrades -n ztp-install $CLUSTER

   Copy to Clipboard

手順

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

   Copy to Clipboard

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

   サンプル YAML

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

   Copy to Clipboard

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:

   Copy to Clipboard

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

   $ oc create -f cgu-remove.yaml

   Copy to Clipboard

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

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

   Copy to Clipboard

検証

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

   $ oc get <kind> <changed_cr_name>

   Copy to Clipboard

   出力例

   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

   Copy to Clipboard

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

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

   $ oc get <kind> <changed_cr_name>

   Copy to Clipboard

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

手順

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

   $ mkdir -p ./out

   Copy to Clipboard

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

   Copy to Clipboard

   ./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

   Copy to Clipboard

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

   $ mkdir -p ./site-install

   Copy to Clipboard

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:
       # - OperatorLifecycleManager is needed for 4.15 and later
       # - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier
       installConfigOverrides: |
         {
           "capabilities": {
             "baselineCapabilitySet": "None",
             "additionalEnabledCapabilities": [
               "NodeTuning",
               "OperatorLifecycleManager"
             ]
           }
         }
       # 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: "latest"
         # 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:
             deviceName: "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0"
           # disk partition at `/var/lib/containers` with ignitionConfigOverride. Some values must be updated. See DiskPartitionContainer.md for more details
           ignitionConfigOverride: |
              {
               "ignition": {
                 "version": "3.2.0"
               },
               "storage": {
                 "disks": [
                   {
                     "device": "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0",
                     "partitions": [
                       {
                        "label": "var-lib-containers",
                        "sizeMiB": 0,
                        "startMiB": 250000
                     }
                 ],
                 "wipeTable": false
                }
              ],
               "filesystems": [
                 {
                  "device": "/dev/disk/by-partlabel/var-lib-containers",
                  "format": "xfs",
                  "mountOptions": [
                    "defaults",
                    "prjquota"
                   ],
                   "path": "/var/lib/containers",
                   "wipeFilesystem": true
                  }
                ]
              },
              "systemd": {
                "units": [
                  {
                   "contents": "# Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target",
                   "enabled": true,
                   "name": "var-lib-containers.mount"
                  }
                 ]
               }
              }
           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

   Copy to Clipboard
   注記

   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

   Copy to Clipboard

   出力例

   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

   Copy to Clipboard

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

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

      $ mkdir -p ./site-machineconfig

      Copy to Clipboard

   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

      Copy to Clipboard

      出力例

      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

      Copy to Clipboard

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

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

      $ mkdir -p ./ref

      Copy to Clipboard

   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

      Copy to Clipboard

      このコマンドは、単一ノード 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

      Copy to Clipboard

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

      Copy to Clipboard

      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>

   Copy to Clipboard

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

   $ cat /proc/cmdline

   Copy to Clipboard

手順

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

   Copy to Clipboard

   1

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

   2

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

2. clusterImageSet CR を適用します。

   $ oc apply -f clusterImageSet-4.15.yaml

   Copy to Clipboard

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

   apiVersion: v1
   kind: Namespace
   metadata:
        name: <cluster_name> 

   1

   
        labels:
           name: <cluster_name> 

   2

   Copy to Clipboard

   1 2

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

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

   $ oc apply -f cluster-namespace.yaml

   Copy to Clipboard

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

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

   Copy to Clipboard

手順

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

   $ oc get managedcluster

   Copy to Clipboard

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

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

   $ oc get agent -n <cluster_name>

   Copy to Clipboard

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

   $ oc describe agent -n <cluster_name>

   Copy to Clipboard

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

   $ oc get agentclusterinstall -n <cluster_name>

   Copy to Clipboard

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

   $ oc describe agentclusterinstall -n <cluster_name>

   Copy to Clipboard

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

   $ oc get managedclusteraddon -n <cluster_name>

   Copy to Clipboard

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

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

   Copy to Clipboard

手順

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

   $ oc get managedcluster

   Copy to Clipboard

   出力例

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

   Copy to Clipboard

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

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

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

   $ oc get clusterdeployment -n <cluster_name>

   Copy to Clipboard

   出力例

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

   Copy to Clipboard

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

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

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

   Copy to Clipboard

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

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

      $ oc delete managedcluster <cluster_name>

      Copy to Clipboard

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

      $ oc delete namespace <cluster_name>

      Copy to Clipboard

      これにより、このクラスター用に作成された 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 Power and Performance Policy	パフォーマンス
   Uncore Frequency Scaling	無効
   Performance P-limit	無効
   Enhanced Intel SpeedStep ® Tech	有効
   Intel Configurable TDP	有効
   Configurable TDP Level	レベル 2
   Intel® Turbo Boost Technology	有効
   Energy Efficient Turbo	無効
   Hardware P-States	無効
   Package C-State	C0/C1 の状態
   C1E	無効
   Processor C6	無効