検索

4.5. SiteConfig と GitOps ZTP を使用したマネージドクラスターのデプロイ

download PDF

次の手順を使用して、SiteConfig カスタムリソース (CR) と関連ファイルを作成し、GitOps Zero Touch Provisioning (ZTP) クラスターのデプロイメントを開始します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • 必要なインストール CR とポリシー CR を生成するためにハブクラスターを設定している。
  • カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセスできる必要があり、ArgoCD アプリケーションのソースリポジトリーとして設定する必要があります。詳細は、「GitOps ZTP サイト設定リポジトリーの準備」を参照してください。

    注記

    ソースリポジトリーを作成するときは、ztp-site-generate コンテナーから抽出した argocd/deployment/argocd-openshift-gitops-patch.json パッチファイルを使用して ArgoCD アプリケーションにパッチを適用してください。「ArgoCD を使用したハブクラスターの設定」を参照してください。

  • マネージドクラスターをプロビジョニングする準備を整えるには、各ベアメタルホストごとに次のものが必要です。

    ネットワーク接続
    ネットワークには DNS が必要です。マネージドクラスターホストは、ハブクラスターから到達可能である必要があります。ハブクラスターとマネージドクラスターホストの間にレイヤー 3 接続が存在することを確認します。
    Baseboard Management Controller (BMC) の詳細
    GitOps ZTP は、BMC のユーザー名とパスワードの詳細を使用して、クラスターのインストール中に BMC に接続します。GitOps ZTP プラグインは、サイトの Git リポジトリーの SiteConfig CR に基づいて、ハブクラスター上の ManagedCluster CR を管理します。ホストごとに個別の BMCSecret CR を手動で作成します。

    手順

    1. ハブクラスターで必要なマネージドクラスターシークレットを作成します。これらのリソースは、クラスター名と一致する名前を持つネームスペースに存在する必要があります。たとえば、out/argocd/example/siteconfig/example-sno.yaml では、クラスター名と namespace が example-sno になっています。

      1. 次のコマンドを実行して、クラスター namespace をエクスポートします。

        $ export CLUSTERNS=example-sno
      2. namespace を作成します。

        $ oc create namespace $CLUSTERNS
    2. マネージドクラスターのプルシークレットと BMC Secret CR を作成します。プルシークレットには、OpenShift Container Platform のインストールに必要なすべての認証情報と、必要なすべての Operator を含める必要があります。詳細は、「マネージドベアメタルホストシークレットの作成」を参照してください。

      注記

      シークレットは、名前で SiteConfig カスタムリソース (CR) から参照されます。namespace は SiteConfig namespace と一致する必要があります。

    3. Git リポジトリーのローカルクローンに、クラスターの SiteConfig CR を作成します。

      1. out/argocd/example/siteconfig/ フォルダーから CR の適切な例を選択します。フォルダーには、シングルノード、3 ノード、標準クラスターのサンプルファイルが含まれます。

        • example-sno.yaml
        • example-3node.yaml
        • example-standard.yaml
      2. サンプルファイルのクラスターおよびホスト詳細を、必要なクラスタータイプに一致するように変更します。以下に例を示します。

        シングルノード OpenShift SiteConfig 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.16"
          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 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
              # - Ingress is needed for 4.16 and later
              installConfigOverrides: |
                {
                  "capabilities": {
                    "baselineCapabilitySet": "None",
                    "additionalEnabledCapabilities": [
                      "NodeTuning",
                      "OperatorLifecycleManager",
                      "Ingress"
                    ]
                  }
                }
              # 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-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62",
                            "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

        注記

        BMC アドレッシングの詳細は、「関連情報」セクションを参照してください。この例では、読みやすくするために、installConfigOverrides フィールドと ignitionConfigOverride フィールドが展開されています。

      3. out/argocd/extra-manifest で extra-manifest MachineConfig CR のデフォルトセットを検査できます。これは、インストール時にクラスターに自動的に適用されます。
      4. オプション: プロビジョニングされたクラスターに追加のインストール時マニフェストをプロビジョニングするには、Git リポジトリーに sno-extra-manifest/ などのディレクトリーを作成し、このディレクトリーにカスタムマニフェストの CR を追加します。SiteConfig.yamlextraManifestPath フィールドでこのディレクトリーを参照する場合、この参照ディレクトリーの CR はすべて、デフォルトの追加マニフェストセットに追加されます。

        crun OCI コンテナーランタイムの有効化

        クラスターのパフォーマンスを最適化するには、シングルノード OpenShift、追加のワーカーノードを備えたシングルノード OpenShift、3 ノード OpenShift、および標準クラスターのマスターノードとワーカーノードで crun を有効にします。

        クラスターの再起動を回避するには、追加の Day 0 インストール時マニフェストとして ContainerRuntimeConfig CR で crun を有効にします。

        enable-crun-master.yaml および enable-crun-worker.yaml CR ファイルは、ztp-site-generate コンテナーから抽出できる out/source-crs/optional-extra-manifest/ フォルダーにあります。詳細は、「GitOps ZTP パイプラインでの追加インストールマニフェストのカスタマイズ」を参照してください。

    4. out/argocd/example/siteconfig/kustomization.yaml に示す例のように、generators セクションの kustomization.yaml ファイルに SiteConfig CR を追加してください。
    5. SiteConfig CR と関連する kustomization.yaml の変更を Git リポジトリーにコミットし、変更をプッシュします。

      ArgoCD パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。

検証

  • ノードのデプロイ後にカスタムのロールとラベルが適用されていることを確認します。

    $ oc describe node example-node.example.com

出力例

Name:   example-node.example.com
Roles:  control-plane,example-label,master,worker
Labels: beta.kubernetes.io/arch=amd64
        beta.kubernetes.io/os=linux
        custom-label/parameter1=true
        kubernetes.io/arch=amd64
        kubernetes.io/hostname=cnfdf03.telco5gran.eng.rdu2.redhat.com
        kubernetes.io/os=linux
        node-role.kubernetes.io/control-plane=
        node-role.kubernetes.io/example-label= 1
        node-role.kubernetes.io/master=
        node-role.kubernetes.io/worker=
        node.openshift.io/os_id=rhcos

1
カスタムラベルがノードに適用されます。

4.5.1. GitOps ZTP の高速プロビジョニング

重要

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

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

シングルノード OpenShift 用の GitOps ZTP の高速プロビジョニングを使用すると、クラスターのインストールにかかる時間を短縮できます。高速 ZTP は、ポリシーから派生した Day 2 マニフェストを早い段階で適用することで、インストールを高速化します。

重要

GitOps ZTP の高速プロビジョニングは、Assisted Installer を使用してシングルノード OpenShift をインストールする場合にのみサポートされます。これ以外の場合は、このインストール方法は失敗します。

4.5.1.1. 高速 ZTP のアクティブ化

以下の例のように、spec.clusters.clusterLabels.accelerated-ztp ラベルを使用して高速 ZTP をアクティブ化できます。

高速 ZTP SiteConfig CR の例。

apiVersion: ran.openshift.io/v2
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:
  # ...
    clusterLabels:
        common: true
        group-du-sno: ""
        sites : "example-sno"
        accelerated-ztp: full

accelerated-ztp: full を使用すると、高速化プロセスを完全に自動化できます。GitOps ZTP は、高速 GitOps ZTP ConfigMap への参照を使用して AgentClusterInstall リソースを更新します。また、GitOps ZTP には TALM によってポリシーから抽出されたリソースと高速 ZTP ジョブマニフェストが含まれています。

accelerated-ztp: partial を使用する場合、GitOps ZTP には高速ジョブマニフェストは含まれませんが、以下の kind タイプのクラスターのインストール中に作成されたポリシーに基づくオブジェクトが含まれます。

  • PerformanceProfile.performance.openshift.io
  • Tuned.tuned.openshift.io
  • Namespace
  • CatalogSource.operators.coreos.com
  • ContainerRuntimeConfig.machineconfiguration.openshift.io

この部分的な高速化により、Performance ProfileTuned、および ContainerRuntimeConfig などの kind のリソースを適用するときに、ノードによって実行される再起動の回数を減らすことができます。TALM は、RHACM がクラスターのインポートを完了した後、標準の GitOps ZTP と同じフローに従って、ポリシーに基づく Operator サブスクリプションをインストールします。

高速 ZTP の利点は、デプロイメントの規模に応じて増大します。accelerated-ztp: full を使用すると、多数のクラスターでより大きなメリットをもたらします。クラスターの数が少ない場合、インストール時間の短縮はそれほど大きくありません。完全な高速 ZTP では、スポーク上に namespace と完了したジョブが残るため、手動で削除する必要があります。

accelerated-ztp: partial を使用する利点の 1 つは、ストック実装で問題が発生した場合やカスタム機能が必要な場合に、オンスポークジョブの機能をオーバーライドできることです。

4.5.1.2. 加速 ZTP プロセス

高速 ZTP は追加の ConfigMap を使用して、スポーククラスターのポリシーに基づくリソースを作成します。標準の ConfigMap には、GitOps ZTP ワークフローがクラスターのインストールをカスタマイズするために使用するマニフェストが含まれています。

TALM は accelerated-ztp ラベルが設定されていることを検出後、2 番目の ConfigMap を作成します。高速 ZTP の一部として、SiteConfig ジェネレーターは、命名規則 <spoke-cluster-name>-aztp を使用して、2 番目の ConfigMap への参照を追加します。

TALM は 2 番目の ConfigMap を作成した後、マネージドクラスターにバインドされているすべてのポリシーを検出し、GitOps ZTP プロファイル情報を抽出します。TALM は、GitOps ZTP プロファイル情報を <spoke-cluster-name>-aztp ConfigMap カスタムリソース (CR) に追加し、その CR をハブクラスター API に適用します。

4.5.2. GitOps ZTP および SiteConfig リソースを使用したシングルノード OpenShift クラスターの IPsec 暗号化の設定

GitOps ZTP と Red Hat Advanced Cluster Management (RHACM) を使用してインストールするシングルノード OpenShift マネージドクラスターで IPsec 暗号化を有効にできます。マネージドクラスターの外部にある Pod と IPsec エンドポイント間の外部トラフィックを暗号化できます。OVN-Kubernetes クラスターネットワーク上のノード間のすべての Pod 間ネットワークトラフィックが、Transport モードの IPsec で暗号化されます。

注記

OpenShift Container Platform 4.16 では、GitOps ZTP と RHACM を使用した IPsec 暗号化のデプロイは、シングルノード OpenShift クラスターに対してのみ検証されます。

GitOps ZTP IPsec 実装では、リソースが制限されたプラットフォームにデプロイすることを前提としています。そのため、シングル MachineConfig CR のみを使用してこの機能をインストールし、前提条件としてシングルノード OpenShift クラスターに NMState Operator をインストールする必要はありません。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • マネージドクラスターに必要なインストールおよびポリシーカスタムリソース (CR) を生成するために、RHACM とハブクラスターを設定している。
  • カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。
  • butane ユーティリティー (バージョン 0.20.0 以降) がインストールされている。
  • IPsec エンドポイント用の PKCS#12 証明書と PEM 形式の CA 証明書がある。

手順

  1. ztp-site-generate コンテナーソースの最新バージョンを抽出し、カスタムサイト設定データを管理するリポジトリーとマージします。
  2. クラスター内の IPsec を設定するために必要な値を使用して、optional-extra-manifest/ipsec/ipsec-endpoint-config.yaml を設定します。以下に例を示します。

    interfaces:
    - name: hosta_conn
      type: ipsec
      libreswan:
        left: <cluster_node> 1
        leftid: '%fromcert'
        leftmodecfgclient: false
        leftcert: <left_cert> 2
        leftrsasigkey: '%cert'
        right: <external_host> 3
        rightid: '%fromcert'
        rightrsasigkey: '%cert'
        rightsubnet: <external_address> 4
        ikev2: insist 5
        type: tunnel
    1
    <cluster_node> を、クラスター側 IPsec トンネルのクラスターノードの IP アドレスまたは DNS ホスト名に置き換えます。
    2
    <left_cert> を IPsec 証明書のニックネームに置き換えます。
    3
    <external_host> を外部ホストの IP アドレスまたは DNS ホスト名に置き換えます。
    4
    <external_address> を、IPsec トンネルの反対側にある外部ホストの IP アドレスまたはサブネットに置き換えます。
    5
    IKEv2 VPN 暗号化プロトコルのみを使用します。IKEv1 は使用しないでください。これは非推奨となっています。
  3. ca.pem および left_server.p12 証明書を optional-extra-manifest/ipsec フォルダーに追加します。証明書ファイルは、各ホストのネットワークセキュリティーサービス (NSS) データベースで必要です。これらのファイルは、後の手順で Butane 設定の一部としてインポートされます。

    1. left_server.p12: IPsec エンドポイントの証明書バンドル
    2. ca.pem: 証明書に署名した認証局
  4. カスタムサイト設定データを保持する Git リポジトリーの optional-extra-manifest/ipsec フォルダーでシェルプロンプトを開きます。
  5. 必要な Butane および MachineConfig CR ファイルを生成するには、optional-extra-manifest/ipsec/build.sh スクリプトを実行します。

    出力例

    out
     └── argocd
          └── example
               └── optional-extra-manifest
                    └── ipsec
                         ├── 99-ipsec-master-endpoint-config.bu 1
                         ├── 99-ipsec-master-endpoint-config.yaml
                         ├── 99-ipsec-worker-endpoint-config.bu
                         ├── 99-ipsec-worker-endpoint-config.yaml
                         ├── build.sh
                         ├── ca.pem 2
                         ├── left_server.p12
                         ├── enable-ipsec.yaml
                         ├── ipsec-endpoint-config.yml
                         └── README.md

    1
    ipsec/build.sh スクリプトは、Butane およびエンドポイント設定 CR を生成します。
    2
    ネットワークに関連する ca.pem および left_server.p12 証明書ファイルを提供します。
  6. カスタムサイト設定データを管理するリポジトリーに custom-manifest/ フォルダーを作成します。enable-ipsec.yaml および 99-ipsec-* YAML ファイルをディレクトリーに追加します。以下に例を示します。

    siteconfig
      ├── site1-sno-du.yaml
      ├── extra-manifest/
      └── custom-manifest
            ├── enable-ipsec.yaml
            ├── 99-ipsec-worker-endpoint-config.yaml
            └── 99-ipsec-master-endpoint-config.yaml
  7. SiteConfig CR で、extraManifests.searchPaths フィールドに custom-manifest/ ディレクトリーを追加します。以下に例を示します。

    clusters:
    - clusterName: "site1-sno-du"
      networkType: "OVNKubernetes"
      extraManifests:
        searchPaths:
          - extra-manifest/
          - custom-manifest/
  8. SiteConfig CR の変更と更新されたファイルを Git リポジトリーにコミットし、変更をプッシュしてマネージドクラスターをプロビジョニングし、IPsec 暗号化を設定します。

    Argo CD パイプラインが変更を検出し、マネージドクラスターのデプロイメントを開始します。

    クラスターのプロビジョニング中に、GitOps ZTP パイプラインは、/custom-manifest ディレクトリー内の CR を、extra-manifest/ に保存されている追加マニフェストのデフォルトのセットに追加します。

検証

シングルノード OpenShift のマネージドクラスターに IPsec 暗号化が正常に適用されていることを確認するには、次の手順を実行します。

  1. 次のコマンドを実行して、マネージドクラスターのデバッグ Pod を起動します。

    $ oc debug node/<node_name>
  2. クラスターノードに IPsec ポリシーが適用されていることを確認します。

    sh-5.1# ip xfrm policy

    出力例

    src 172.16.123.0/24 dst 10.1.232.10/32
      dir out priority 1757377 ptype main
      tmpl src 10.1.28.190 dst 10.1.232.10
        proto esp reqid 16393 mode tunnel
    src 10.1.232.10/32 dst 172.16.123.0/24
      dir fwd priority 1757377 ptype main
      tmpl src 10.1.232.10 dst 10.1.28.190
        proto esp reqid 16393 mode tunnel
    src 10.1.232.10/32 dst 172.16.123.0/24
      dir in priority 1757377 ptype main
      tmpl src 10.1.232.10 dst 10.1.28.190
        proto esp reqid 16393 mode tunnel

  3. IPsec トンネルが稼働し、接続されていることを確認します。

    sh-5.1# ip xfrm state

    出力例

    src 10.1.232.10 dst 10.1.28.190
      proto esp spi 0xa62a05aa reqid 16393 mode tunnel
      replay-window 0 flag af-unspec esn
      auth-trunc hmac(sha1) 0x8c59f680c8ea1e667b665d8424e2ab749cec12dc 96
      enc cbc(aes) 0x2818a489fe84929c8ab72907e9ce2f0eac6f16f2258bd22240f4087e0326badb
      anti-replay esn context:
       seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x0
       replay_window 128, bitmap-length 4
       00000000 00000000 00000000 00000000
    src 10.1.28.190 dst 10.1.232.10
      proto esp spi 0x8e96e9f9 reqid 16393 mode tunnel
      replay-window 0 flag af-unspec esn
      auth-trunc hmac(sha1) 0xd960ddc0a6baaccb343396a51295e08cfd8aaddd 96
      enc cbc(aes) 0x0273c02e05b4216d5e652de3fc9b3528fea94648bc2b88fa01139fdf0beb27ab
      anti-replay esn context:
       seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x0
       replay_window 128, bitmap-length 4
       00000000 00000000 00000000 00000000

  4. 外部ホストサブネット内の既知の IP に ping を実行します。たとえば、ipsec/ipsec-endpoint-config.yaml で設定した rightsubnet 範囲内の IP に ping を実行します。

    sh-5.1# ping 172.16.110.8

    出力例

    sh-5.1# ping 172.16.110.8
    PING 172.16.110.8 (172.16.110.8) 56(84) bytes of data.
    64 bytes from 172.16.110.8: icmp_seq=1 ttl=64 time=153 ms
    64 bytes from 172.16.110.8: icmp_seq=2 ttl=64 time=155 ms

4.5.3. シングルノード OpenShift SiteConfig CR インストールリファレンス

表4.1 シングルノード OpenShift クラスター用の SiteConfig CR インストールオプション
SiteConfig CR フィールド説明

spec.cpuPartitioningMode

cpuPartitioningMode の値を AllNodes に設定して、ワークロードパーティショニングを設定します。設定を完了するには、PerformanceProfile CR で isolated および reserved CPU を指定します。

注記

SiteConfig CR の cpuPartitioningMode フィールドを使用したワークロードパーティショニングの設定は、OpenShift Container Platform 4.13 のテクノロジープレビュー機能です。

metadata.name

nameassisted-deployment-pull-secret に設定し、SiteConfig CR と同じ namespace に assisted-deployment-pull-secret CR を作成します。

spec.clusterImageSetNameRef

サイト内のすべてのクラスターのハブクラスターで使用できるイメージセットを設定します。ハブクラスターでサポートされるバージョンの一覧を表示するには、oc get clusterimagesets を実行します。

installConfigOverrides

クラスターのインストール前に、installConfigOverrides フィールドを設定して、オプションのコンポーネントを有効または無効にします。

重要

SiteConfig CR の例で指定されている参照設定を使用します。追加のコンポーネントをシステムに再度追加するには、追加の予約済み CPU 容量が必要になる場合があります。

spec.clusters.clusterImageSetNameRef

個々のクラスターをデプロイするために使用されるクラスターイメージセットを指定します。定義されている場合、サイトレベルで spec.clusterImageSetNameRef をオーバーライドします。

spec.clusters.clusterLabels

定義した PolicyGenerator または PolicyGentemplate CR のバインディングルールに対応するようにクラスターラベルを設定します。PolicyGenerator CR は policyDefaults.placement.labelSelector フィールドを使用します。PolicyGentemplate CR は spec.bindingRules フィールドを使用します。

たとえば、acmpolicygenerator/acm-common-ranGen.yamlcommon: true が設定されているすべてのクラスターに適用され、acmpolicygenerator/acm-group-du-sno-ranGen.yamlgroup-du-sno: "" が設定されているすべてのクラスターに適用されます。

spec.clusters.crTemplates.KlusterletAddonConfig

オプション: KlusterletAddonConfig を、クラスター用に作成された KlusterletAddonConfigOverride.yaml to override the default `KlusterletAddonConfig に設定します。

spec.clusters.nodes.hostName

シングルノードの導入では、単一のホストを定義します。3 ノードのデプロイメントの場合、3 台のホストを定義します。標準のデプロイメントでは、role: master と、role: worker で定義される 2 つ以上のホストを持つ 3 つのホストを定義します。

spec.clusters.nodes.nodeLabels

マネージドクラスター内のノードのカスタムロールを指定します。これらは追加のロールであり、OpenShift Container Platform コンポーネントでは使用されず、ユーザーによってのみ使用されます。カスタムロールを追加すると、そのロールの特定の設定を参照するカスタムマシン設定プールに関連付けることができます。インストール中にカスタムラベルまたはロールを追加すると、デプロイメントプロセスがより効率的になり、インストール完了後に追加の再起動が必要なくなります。

spec.clusters.nodes.automatedCleaningMode

オプション: コメントを解除して値を metadata に設定すると、ディスクを完全にワイプせずに、ディスクのパーティションテーブルのみを削除できるようになります。デフォルト値は、disabled です。

spec.clusters.nodes.bmcAddress

ホストへのアクセスに使用する BMC アドレス。すべてのクラスタータイプに適用されます。GitOps ZTP は、Redfish または IPMI プロトコルを使用して iPXE および仮想メディアの起動をサポートします。iPXE ブートを使用するには、RHACM 2.8 以降を使用する必要があります。BMC アドレッシングの詳細は、「関連情報」セクションを参照してください。

spec.clusters.nodes.bmcAddress

ホストへのアクセスに使用する BMC アドレス。すべてのクラスタータイプに適用されます。GitOps ZTP は、Redfish または IPMI プロトコルを使用して iPXE および仮想メディアの起動をサポートします。iPXE ブートを使用するには、RHACM 2.8 以降を使用する必要があります。BMC アドレッシングの詳細は、「関連情報」セクションを参照してください。

注記

ファーエッジ通信会社のユースケースでは、GitOps ZTP では仮想メディアの使用のみがサポートされます。

spec.clusters.nodes.bmcCredentialsName

ホスト BMC 認証情報を使用して、別途作成した bmh-secret CR を設定します。bmh-secret CR を作成するときは、ホストをプロビジョニングする SiteConfig CR と同じ namespace を使用します。

spec.clusters.nodes.bootMode

ホストのブートモードを UEFI に設定します。デフォルト値は UEFI です。UEFISecureBoot を使用して、ホストでセキュアブートを有効にします。

spec.clusters.nodes.rootDeviceHints

導入するデバイスを指定します。再起動後も安定した識別子が推奨されます。たとえば、wwn: <disk_wwn> または deviceName: /dev/disk/by-path/<device_path> です。<by-path> 値が推奨されます。安定した識別子の詳細なリストは、「ルートデバイスヒントについて」セクションを参照してください。

spec.clusters.nodes.ignitionConfigOverride

オプション: このフィールドを使用して、永続ストレージのパーティションを割り当てます。ディスク ID とサイズを特定のハードウェアに合わせて調整します。

spec.clusters.nodes.nodeNetwork

ノードのネットワーク設定を行います。

spec.clusters.nodes.nodeNetwork.config.interfaces.ipv6

ホストの IPv6 アドレスを設定します。静的 IP アドレスを持つシングルノード OpenShift クラスターの場合、ノード固有の API と Ingress IP は同じである必要があります。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.