Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

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

重要

SiteConfig v1 は、OpenShift Container Platform バージョン 4.18 以降では非推奨になります。ClusterInstance カスタムリソースを使用する SiteConfig Operator を通じて、同等の改良された機能が利用できるようになりました。詳細は、Procedure to transition from SiteConfig CRs to the ClusterInstance API を参照してください。

SiteConfig Operator の詳細は、SiteConfig を参照してください。

前提条件

  • 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 をエクスポートします。

        Copy to Clipboard Toggle word wrap 
        $ export CLUSTERNS=example-sno

      2. namespace を作成します。

        Copy to Clipboard Toggle word wrap 
        $ 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 の例

        Copy to Clipboard Toggle word wrap 
        # 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.18"
  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: "UEFISecureBoot"
          rootDeviceHints:
            deviceName: "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0"
          #crTemplates:
          #  BareMetalHost: "bmhOverride.yaml"
          # 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 フィールドが展開されています。

        注記

        ノードのデフォルトの BareMetalHost CR をオーバーライドするには、SiteConfig CR のノードレベルの crTemplates フィールドでオーバーライド用の CR を参照できます。オーバーライド用の BareMetalHost CR で、必ず argocd.argoproj.io/sync-wave: "3" アノテーションを設定してください。

      3. out/argocd/extra-manifest で extra-manifest MachineConfig CR のデフォルトセットを検査できます。これは、インストール時にクラスターに自動的に適用されます。

      4. オプション: プロビジョニングされたクラスターに追加のインストール時マニフェストをプロビジョニングするには、Git リポジトリーに sno-extra-manifest/ などのディレクトリーを作成し、このディレクトリーにカスタムマニフェストの CR を追加します。SiteConfig.yaml が extraManifestPath フィールドでこのディレクトリーを参照する場合、この参照ディレクトリーの 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 パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。

検証

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

    Copy to Clipboard Toggle word wrap 
    $ oc describe node example-node.example.com

出力例

Copy to Clipboard Toggle word wrap 
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 の例。

Copy to Clipboard Toggle word wrap 
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.18"
  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 リソースが更新され、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 Profile、Tuned、および 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 暗号化を有効にできます。マネージドクラスターと、マネージドクラスター外の IPsec エンドポイント間のトラフィックを暗号化できます。OVN-Kubernetes クラスターネットワーク上のノード間のすべてのネットワークトラフィックが、Transport モードの IPsec で暗号化されます。

重要

次の手順に従って、追加のワーカーノードを備えたシングルノード OpenShift クラスターの IPsec 暗号化を設定することもできます。シングルノード OpenShift クラスターおよび追加のワーカーノードを備えたシングルノード OpenShift クラスターの IPsec 暗号化を設定する際には、リソースの可用性が低いため、MachineConfig カスタムリソース (CR) を使用することを推奨します。

前提条件

  • 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 を設定します。以下に例を示します。

    Copy to Clipboard Toggle word wrap 
    interfaces:
- name: hosta_conn
  type: ipsec
  libreswan:
    left: '%defaultroute'
    leftid: '%fromcert'
    leftmodecfgclient: false
    leftcert: left_server
    1 
    
    leftrsasigkey: '%cert'
    right: <external_host>
    2 
    
    rightid: '%fromcert'
    rightrsasigkey: '%cert'
    rightsubnet: <external_address>
    3 
    
    ikev2: insist
    4 
    
    type: tunnel
    1
    このフィールドの値は、リモートシステムで使用される証明書の名前と一致する必要があります。
    2
    <external_host> は、外部ホストの IP アドレスまたは DNS ホスト名に置き換えます。
    3
    <external_address> は、IPsec トンネルの反対側にある外部ホストの IP サブネットに置き換えます。
    4
    IKEv2 VPN 暗号化プロトコルのみを使用します。IKEv1 は使用しないでください。これは非推奨となっています。

  3. 次の証明書を optional-extra-manifest/ipsec フォルダーに追加します。

    • left_server.p12: IPsec エンドポイントの証明書バンドル

    • ca.pem: 証明書に署名した認証局

      証明書ファイルは、各ホストのネットワークセキュリティーサービス (NSS) データベースで必要です。これらのファイルは、後の手順で Butane 設定の一部としてインポートされます。

  4. カスタムサイト設定データを保持する Git リポジトリーの optional-extra-manifest/ipsec フォルダーでシェルプロンプトを開きます。

  5. 必要な Butane および MachineConfig CR ファイルを生成するには、optional-extra-manifest/ipsec/build.sh スクリプトを実行します。

    PKCS#12 証明書がパスワードで保護されている場合は、-W 引数を設定します。

    出力例

    Copy to Clipboard Toggle word wrap 
    out
 └── argocd
      └── example
           └── optional-extra-manifest
                └── ipsec
                     ├── 99-ipsec-master-endpoint-config.bu
    1 
    
                     ├── 99-ipsec-master-endpoint-config.yaml
    2 
    
                     ├── 99-ipsec-worker-endpoint-config.bu
    3 
    
                     ├── 99-ipsec-worker-endpoint-config.yaml
    4 
    
                     ├── build.sh
                     ├── ca.pem
    5 
    
                     ├── left_server.p12
    6 
    
                     ├── enable-ipsec.yaml
                     ├── ipsec-endpoint-config.yml
                     └── README.md

    1 2 3 4
    ipsec/build.sh スクリプトは、Butane およびエンドポイント設定 CR を生成します。
    5 6
    ネットワークに関連する ca.pem および left_server.p12 証明書ファイルを提供します。

  6. カスタムサイト設定データを管理するリポジトリーに custom-manifest/ フォルダーを作成します。enable-ipsec.yaml および 99-ipsec-* YAML ファイルをディレクトリーに追加します。以下に例を示します。

    Copy to Clipboard Toggle word wrap 
    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/ ディレクトリーを追加します。以下に例を示します。

    Copy to Clipboard Toggle word wrap 
    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/ ディレクトリーに保存されているデフォルトの追加マニフェストのセットに追加します。

検証

IPsec 暗号化の検証は、「IPsec 暗号化の検証」を参照してください。

関連情報

4.5.3. GitOps ZTP および SiteConfig リソースを使用したマルチノードクラスターの IPsec 暗号化の設定

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

前提条件

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

手順

  1. ztp-site-generate コンテナーソースの最新バージョンを抽出し、カスタムサイト設定データを管理するリポジトリーとマージします。

  2. クラスター内の IPsec を設定するために必要な値を使用して、optional-extra-manifest/ipsec/ipsec-config-policy.yaml ファイルを設定します。

    IPsec 設定を作成するための ConfigurationPolicy オブジェクト

    Copy to Clipboard Toggle word wrap 
    apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
  name: policy-config
spec:
  namespaceSelector:
    include: ["default"]
    exclude: []
    matchExpressions: []
    matchLabels: {}
  remediationAction: inform
  severity: low
  evaluationInterval:
    compliant:
    noncompliant:
  object-templates-raw: |
    {{- range (lookup "v1" "Node" "" "").items }}
    - complianceType: musthave
      objectDefinition:
        kind: NodeNetworkConfigurationPolicy
        apiVersion: nmstate.io/v1
        metadata:
          name: {{ .metadata.name }}-ipsec-policy
        spec:
          nodeSelector:
            kubernetes.io/hostname: {{ .metadata.name }}
          desiredState:
            interfaces:
            - name: hosta_conn
              type: ipsec
              libreswan:
                left: '%defaultroute'
                leftid: '%fromcert'
                leftmodecfgclient: false
                leftcert: left_server
    1 
    
                leftrsasigkey: '%cert'
                right: <external_host>
    2 
    
                rightid: '%fromcert'
                rightrsasigkey: '%cert'
                rightsubnet: <external_address>
    3 
    
                ikev2: insist
    4 
    
                type: tunnel

    1
    このフィールドの値は、リモートシステムで使用される証明書の名前と一致する必要があります。
    2
    <external_host> は、外部ホストの IP アドレスまたは DNS ホスト名に置き換えます。
    3
    <external_address> は、IPsec トンネルの反対側にある外部ホストの IP サブネットに置き換えます。
    4
    IKEv2 VPN 暗号化プロトコルのみを使用します。IKEv1 は使用しないでください。これは非推奨となっています。

  3. 次の証明書を optional-extra-manifest/ipsec フォルダーに追加します。

    • left_server.p12: IPsec エンドポイントの証明書バンドル

    • ca.pem: 証明書に署名した認証局

      証明書ファイルは、各ホストのネットワークセキュリティーサービス (NSS) データベースで必要です。これらのファイルは、後の手順で Butane 設定の一部としてインポートされます。

  4. カスタムサイト設定データを保持する Git リポジトリーの optional-extra-manifest/ipsec フォルダーでシェルプロンプトを開きます。

  5. optional-extra-manifest/ipsec/import-certs.sh スクリプトを実行して、外部証明書をインポートするために必要な Butane および MachineConfig CR を生成します。

    PKCS#12 証明書がパスワードで保護されている場合は、-W 引数を設定します。

    出力例

    Copy to Clipboard Toggle word wrap 
    out
 └── argocd
      └── example
           └── optional-extra-manifest
                └── ipsec
                     ├── 99-ipsec-master-import-certs.bu
    1 
    
                     ├── 99-ipsec-master-import-certs.yaml
    2 
    
                     ├── 99-ipsec-worker-import-certs.bu
    3 
    
                     ├── 99-ipsec-worker-import-certs.yaml
    4 
    
                     ├── import-certs.sh
                     ├── ca.pem
    5 
    
                     ├── left_server.p12
    6 
    
                     ├── enable-ipsec.yaml
                     ├── ipsec-config-policy.yaml
                     └── README.md

    1 2 3 4
    ipsec/import-certs.sh スクリプトは、Butane およびエンドポイント設定 CR を生成します。
    5 6
    ネットワークに関連する ca.pem および left_server.p12 証明書ファイルを追加します。

  6. カスタムのサイト設定データを管理するリポジトリーに custom-manifest/ フォルダーを作成し、enable-ipsec.yaml および 99-ipsec-* YAML ファイルをディレクトリーに追加します。

    siteconfig ディレクトリーの例

    Copy to Clipboard Toggle word wrap 
    siteconfig
  ├── site1-mno-du.yaml
  ├── extra-manifest/
  └── custom-manifest
        ├── enable-ipsec.yaml
        ├── 99-ipsec-master-import-certs.yaml
        └── 99-ipsec-worker-import-certs.yaml

  7. SiteConfig CR で、次の例のように、extraManifests.searchPaths フィールドに custom-manifest/ ディレクトリーを追加します。

    Copy to Clipboard Toggle word wrap 
    clusters:
- clusterName: "site1-mno-du"
  networkType: "OVNKubernetes"
  extraManifests:
    searchPaths:
      - extra-manifest/
      - custom-manifest/
  8. GitOps の source-crs ディレクトリーに ipsec-config-policy.yaml 設定ポリシーファイルを格納し、PolicyGenerator CR の 1 つでそのファイルを参照します。

  9. SiteConfig CR の変更と更新されたファイルを Git リポジトリーにコミットし、変更をプッシュしてマネージドクラスターをプロビジョニングし、IPsec 暗号化を設定します。

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

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

検証

IPsec 暗号化の検証は、「IPsec 暗号化の検証」を参照してください。

関連情報

4.5.4. IPsec 暗号化の検証

OpenShift Container Platform マネージドクラスターで IPsec 暗号化が正常に適用されていることを確認できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • IPsec 暗号化が設定されている。

手順

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

    Copy to Clipboard Toggle word wrap 
    $ oc debug node/<node_name>

  2. 次のコマンドを実行して、IPsec ポリシーがクラスターノードに適用されていることを確認します。

    Copy to Clipboard Toggle word wrap 
    sh-5.1# ip xfrm policy

    出力例

    Copy to Clipboard Toggle word wrap 
    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 トンネルが起動し接続されていることを確認します。

    Copy to Clipboard Toggle word wrap 
    sh-5.1# ip xfrm state

    出力例

    Copy to Clipboard Toggle word wrap 
    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 します。

    Copy to Clipboard Toggle word wrap 
    sh-5.1# ping 172.16.110.8

    出力例

    Copy to Clipboard Toggle word wrap 
    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.5. シングルノード OpenShift SiteConfig CR インストールリファレンス

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

spec.cpuPartitioningMode

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

metadata.name

name を assisted-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.yaml は common: true が設定されているすべてのクラスターに適用され、acmpolicygenerator/acm-group-du-sno-ranGen.yaml は group-du-sno: "" が設定されているすべてのクラスターに適用されます。

spec.clusters.crTemplates.KlusterletAddonConfig

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

spec.clusters.diskEncryption

このフィールドを設定すると、Trusted Platform Module (TPM) と Platform Configuration Register (PCR) 保護によるディスク暗号化が有効になります。詳細は、「TPM と PCR の保護によるディスク暗号化について」を参照してください。

注記

SiteConfig CR の diskEncryption フィールドを使用したディスク暗号化の設定は、OpenShift Container Platform 4.18 のテクノロジープレビュー機能です。

spec.clusters.diskEncryption.type

ディスク暗号化タイプを tpm2 に設定します。

spec.clusters.diskEncryption.tpm2

ディスク暗号化用の Platform Configuration Register (PCR) 保護を設定します。

spec.clusters.diskEncryption.tpm2.pcrList

ディスク暗号化に使用する Platform Configuration Register (PCR) のリストを設定します。PCR レジスター 1 と 7 を使用する必要があります。

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

Theme

© 2025 Red Hat, Inc.