17.13. GitOps ZTP を使用した単一ノードの OpenShift クラスターの拡張

GitOps ZTP を使用して、単一ノードの OpenShift クラスターを拡張できます。単一ノードの OpenShift クラスターにワーカーノードを追加すると、元の単一ノードの OpenShift クラスターがコントロールプレーンノードのロールを保持します。ワーカーノードを追加しても、既存の単一ノード OpenShift クラスターのダウンタイムは必要ありません。

注記

単一ノードの OpenShift クラスターに追加できるワーカーノードの数に指定された制限はありませんが、追加のワーカーノード用にコントロールプレーンノードで予約されている CPU 割り当てを再評価する必要があります。

ワーカーノードでワークロードパーティショニングが必要な場合は、ノードをインストールする前に、ハブクラスターでマネージドクラスターポリシーをデプロイして修正する必要があります。そうすることで、GitOps ZTP ワークフローが MachineConfig Iignition ファイルをワーカーノードに適用する前に、ワークロードパーティショニング MachineConfig オブジェクトがレンダリングされ、worker マシン設定プールに関連付けられます。

最初にポリシーを修正してから、ワーカーノードをインストールすることを推奨します。ワーカーノードのインストール後にワークロードパーティショニングマニフェストを作成する場合は、ノードを手動でドレインし、デーモンセットによって管理されるすべての Pod を削除する必要があります。管理デーモンセットが新しい Pod を作成すると、新しい Pod はワークロードパーティショニングプロセスを実行します。

重要

GitOps ZTP を使用した単一ノードの OpenShift クラスターへのワーカーノードの追加は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

関連情報

17.13.1. ワーカーノードへのプロファイルの適用

DU プロファイルを使用して、追加のワーカーノードを設定できます。

ZTP GitOps 共通、グループ、およびサイト固有の PolicyGenTemplate リソースを使用して、RAN 分散ユニット (DU) プロファイルをワーカーノードクラスターに適用できます。ArgoCD policies アプリケーションにリンクされている GitOps ZTP パイプラインには、ztp-site-generate コンテナーを抽出するときに out/argocd/example/policygentemplates フォルダーにある次の CR が含まれています。

  • common-ranGen.yaml
  • group-du-sno-ranGen.yaml
  • example-sno-site.yaml
  • ns.yaml
  • kustomization.yaml

ワーカーノードでの DU プロファイルの設定は、アップグレードと見なされます。アップグレードフローを開始するには、既存のポリシーを更新するか、追加のポリシーを作成する必要があります。次に、ClusterGroupUpgrade CR を作成して、クラスターのグループ内のポリシーを調整する必要があります。

17.13.2. (オプション) PTP および SR-IOV デーモンセレクターの互換性の確保

DU プロファイルが GitOps ZTP プラグインバージョン 4.11 以前を使用してデプロイされた場合、PTP および SR-IOV Operator は、master というラベルの付いたノードにのみデーモンを配置するように設定されている可能性があります。この設定により、PTP および SR-IOV デーモンがワーカーノードで動作しなくなります。システムで PTP および SR-IOV デーモンノードセレクターが正しく設定されていない場合は、ワーカー DU プロファイル設定に進む前にデーモンを変更する必要があります。

手順

  1. スポーククラスターの 1 つで PTP Operator のデーモンノードセレクター設定を確認します。

    $ oc get ptpoperatorconfig/default -n openshift-ptp -ojsonpath='{.spec}' | jq

    PTP Operator の出力例

    {"daemonNodeSelector":{"node-role.kubernetes.io/master":""}} 1

    1
    ノードセレクターが master に設定されている場合、スポークは、変更が必要なバージョンの ZTP プラグインでデプロイされています。
  2. スポーククラスターの 1 つで SR-IOV Operator のデーモンノードセレクター設定を確認します。

    $  oc get sriovoperatorconfig/default -n \
    openshift-sriov-network-operator -ojsonpath='{.spec}' | jq

    SR-IOV Operator の出力例

    {"configDaemonNodeSelector":{"node-role.kubernetes.io/worker":""},"disableDrain":false,"enableInjector":true,"enableOperatorWebhook":true} 1

    1
    ノードセレクターが master に設定されている場合、スポークは、変更が必要なバージョンの ZTP プラグインでデプロイされています。
  3. グループポリシーで、次の ComplianceType および spec エントリーを追加します。

    spec:
        - fileName: PtpOperatorConfig.yaml
          policyName: "config-policy"
          complianceType: mustonlyhave
          spec:
            daemonNodeSelector:
              node-role.kubernetes.io/worker: ""
        - fileName: SriovOperatorConfig.yaml
          policyName: "config-policy"
          complianceType: mustonlyhave
          spec:
            configDaemonNodeSelector:
              node-role.kubernetes.io/worker: ""
    重要

    daemonNodeSelector フィールドを変更すると、一時的な PTP Synchronization が失われ、SR-IOV 接続が失われます。

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

17.13.3. PTP および SR-IOV ノードセレクターの互換性

PTP 設定リソースと SR-IOV ネットワークノードポリシーは、ノードセレクターとして node-role.kubernetes.io/master: "" を使用します。追加のワーカーノードの NIC 設定がコントロールプレーンノードと同じである場合、コントロールプレーンノードの設定に使用されたポリシーをワーカーノードに再利用できます。ただし、両方のノードタイプを選択するようにノードセレクターを変更する必要があります (たとえば、node-role.kubernetes.io/worker ラベルを使用)。

17.13.4. PolicyGenTemplate CR を使用してワーカーノードポリシーをワーカーノードに適用する

ワーカーノードのポリシーを作成できます。

手順

  1. 次のポリシーテンプレートを作成します。

    apiVersion: ran.openshift.io/v1
    kind: PolicyGenTemplate
    metadata:
      name: "example-sno-workers"
      namespace: "example-sno"
    spec:
      bindingRules:
        sites: "example-sno" 1
      mcp: "worker" 2
      sourceFiles:
        - fileName: MachineConfigGeneric.yaml 3
          policyName: "config-policy"
          metadata:
            labels:
              machineconfiguration.openshift.io/role: worker
            name: enable-workload-partitioning
          spec:
            config:
              storage:
                files:
                - contents:
                    source: data:text/plain;charset=utf-8;base64,W2NyaW8ucnVudGltZS53b3JrbG9hZHMubWFuYWdlbWVudF0KYWN0aXZhdGlvbl9hbm5vdGF0aW9uID0gInRhcmdldC53b3JrbG9hZC5vcGVuc2hpZnQuaW8vbWFuYWdlbWVudCIKYW5ub3RhdGlvbl9wcmVmaXggPSAicmVzb3VyY2VzLndvcmtsb2FkLm9wZW5zaGlmdC5pbyIKcmVzb3VyY2VzID0geyAiY3B1c2hhcmVzIiA9IDAsICJjcHVzZXQiID0gIjAtMyIgfQo=
                  mode: 420
                  overwrite: true
                  path: /etc/crio/crio.conf.d/01-workload-partitioning
                  user:
                    name: root
                - contents:
                    source: data:text/plain;charset=utf-8;base64,ewogICJtYW5hZ2VtZW50IjogewogICAgImNwdXNldCI6ICIwLTMiCiAgfQp9Cg==
                  mode: 420
                  overwrite: true
                  path: /etc/kubernetes/openshift-workload-pinning
                  user:
                    name: root
        - fileName: PerformanceProfile.yaml
          policyName: "config-policy"
          metadata:
            name: openshift-worker-node-performance-profile
          spec:
            cpu: 4
              isolated: "4-47"
              reserved: "0-3"
            hugepages:
              defaultHugepagesSize: 1G
              pages:
                - size: 1G
                  count: 32
            realTimeKernel:
              enabled: true
        - fileName: TunedPerformancePatch.yaml
          policyName: "config-policy"
          metadata:
            name: performance-patch-worker
          spec:
            profile:
              - name: performance-patch-worker
                data: |
                  [main]
                  summary=Configuration changes profile inherited from performance created tuned
                  include=openshift-node-performance-openshift-worker-node-performance-profile
                  [bootloader]
                  cmdline_crash=nohz_full=4-47 5
                  [sysctl]
                  kernel.timer_migration=1
                  [scheduler]
                  group.ice-ptp=0:f:10:*:ice-ptp.*
                  [service]
                  service.stalld=start,enable
                  service.chronyd=stop,disable
            recommend:
            - profile: performance-patch-worker
    1
    ポリシーは、このラベルを持つすべてのクラスターに適用されます。
    2
    MCP フィールドは worker に設定する必要があります。
    3
    この汎用の MachineConfig CR は、ワーカーノードでワークロードの分割を設定するために使用されます。
    4
    cpu.isolated および cpu.reserved フィールドは、特定のハードウェアプラットフォームごとに設定する必要があります。
    5
    cmdline_crash CPU セットは、PerformanceProfile セクションの cpu.isolated セットと一致する必要があります。

    汎用の MachineConfig CR を使用して、ワーカーノードでワークロードパーティションを設定します。crio および kubelet 設定ファイルのコンテンツを生成できます。

  2. 作成したポリシーテンプレートを、ArgoCD policies アプリケーションによってモニターされている Git リポジトリーに追加します。
  3. ポリシーを kustomization.yaml ファイルに追加します。
  4. Git で変更をコミットし、GitOps ZTP ArgoCD アプリケーションによって監視されている Git リポジトリーにプッシュします。
  5. 新しいポリシーをスポーククラスターに修正するには、TALM カスタムリソースを作成します。

    $ cat <<EOF | oc apply -f -
    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: example-sno-worker-policies
      namespace: default
    spec:
      backup: false
      clusters:
      - example-sno
      enable: true
      managedPolicies:
      - group-du-sno-config-policy
      - example-sno-workers-config-policy
      - example-sno-config-policy
      preCaching: false
      remediationStrategy:
        maxConcurrency: 1
    EOF

17.13.5. GitOps ZTP を使用して単一ノードの OpenShift クラスターにワーカーノードを追加する

1 つ以上のワーカーノードを既存の単一ノード OpenShift クラスターに追加して、クラスターで使用可能な CPU リソースを増やすことができます。

前提条件

  • OpenShift Container Platform 4.11 以降のベアメタルハブクラスターに RHACM 2.6 以降をインストールして設定する
  • ハブクラスターに Topology Aware Lifecycle Manager をインストールする
  • ハブクラスターに Red Hat OpenShift GitOps をインストールする
  • GitOps ZTP ztp-site-generate コンテナーイメージバージョン 4.12 以降を使用する
  • GitOps ZTP を使用して管理対象の単一ノード OpenShift クラスターをデプロイする
  • RHACM ドキュメントの説明に従って、中央インフラストラクチャー管理を設定する
  • 内部 API エンドポイント api-int.<cluster_name>.<base_domain> を解決するようにクラスターにサービスを提供する DNS を設定する

手順

  1. example-sno.yaml SiteConfig マニフェストを使用してクラスターをデプロイした場合は、新しいワーカーノードを spec.clusters['example-sno'].nodes リストに追加します。

    nodes:
    - hostName: "example-node2.example.com"
      role: "worker"
      bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1"
      bmcCredentialsName:
        name: "example-node2-bmh-secret"
      bootMACAddress: "AA:BB:CC:DD:EE:11"
      bootMode: "UEFI"
      nodeNetwork:
        interfaces:
          - name: eno1
            macAddress: "AA:BB:CC:DD:EE:11"
        config:
          interfaces:
            - name: eno1
              type: ethernet
              state: up
              macAddress: "AA:BB:CC:DD:EE:11"
              ipv4:
                enabled: false
              ipv6:
                enabled: true
                address:
                - ip: 1111:2222:3333:4444::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
  2. SiteConfig ファイルの spec.nodes セクションの bmcCredentialsName フィールドで参照されるように、新しいホストの BMC 認証シークレットを作成します。

    apiVersion: v1
    data:
      password: "password"
      username: "username"
    kind: Secret
    metadata:
      name: "example-node2-bmh-secret"
      namespace: example-sno
    type: Opaque
  3. Git で変更をコミットし、GitOps ZTP ArgoCD アプリケーションによって監視されている Git リポジトリーにプッシュします。

    ArgoCD cluster アプリケーションが同期すると、ZTP プラグインによって生成されたハブクラスターに 2 つの新しいマニフェストが表示されます。

    • BareMetalHost
    • NMStateConfig

      重要

      cpuset フィールドは、ワーカーノードに対して設定しないでください。ワーカーノードのワークロードパーティショニングは、ノードのインストールが完了した後、管理ポリシーを通じて追加されます。

検証

インストールプロセスは、いくつかの方法でモニターできます。

  • 次のコマンドを実行して、事前プロビジョニングイメージが作成されているかどうかを確認します。

    $ oc get ppimg -n example-sno

    出力例

    NAMESPACE       NAME            READY   REASON
    example-sno     example-sno     True    ImageCreated
    example-sno     example-node2   True    ImageCreated

  • ベアメタルホストの状態を確認します。

    $ oc get bmh -n example-sno

    出力例

    NAME            STATE          CONSUMER   ONLINE   ERROR   AGE
    example-sno     provisioned               true             69m
    example-node2   provisioning              true             4m50s 1

    1
    provisioning ステータスは、インストールメディアからのノードの起動が進行中であることを示します。
  • インストールプロセスを継続的に監視します。

    1. 次のコマンドを実行して、エージェントのインストールプロセスを監視します。

      $ oc get agent -n example-sno --watch

      出力例

      NAME                                   CLUSTER   APPROVED   ROLE     STAGE
      671bc05d-5358-8940-ec12-d9ad22804faa   example-sno   true       master   Done
      [...]
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Starting installation
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Installing
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Writing image to disk
      [...]
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Waiting for control plane
      [...]
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Rebooting
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Done

    2. ワーカーノードのインストールが完了すると、ワーカーノードの証明書が自動的に承認されます。この時点で、ワーカーは ManagedClusterInfo ステータスで表示されます。次のコマンドを実行して、ステータスを確認します。

      $ oc get managedclusterinfo/example-sno -n example-sno -o \
      jsonpath='{range .status.nodeList[*]}{.name}{"\t"}{.conditions}{"\t"}{.labels}{"\n"}{end}'

      出力例

      example-sno	[{"status":"True","type":"Ready"}]	{"node-role.kubernetes.io/master":"","node-role.kubernetes.io/worker":""}
      example-node2	[{"status":"True","type":"Ready"}]	{"node-role.kubernetes.io/worker":""}