4.5. SiteConfig と GitOps ZTP を使用したマネージドクラスターのデプロイ
次の手順を使用して、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 を手動で作成します。
手順
ハブクラスターで必要なマネージドクラスターシークレットを作成します。これらのリソースは、クラスター名と一致する名前を持つネームスペースに存在する必要があります。たとえば、
out/argocd/example/siteconfig/example-sno.yaml
では、クラスター名と namespace がexample-sno
になっています。次のコマンドを実行して、クラスター namespace をエクスポートします。
$ export CLUSTERNS=example-sno
namespace を作成します。
$ oc create namespace $CLUSTERNS
マネージドクラスターのプルシークレットと BMC
Secret
CR を作成します。プルシークレットには、OpenShift Container Platform のインストールに必要なすべての認証情報と、必要なすべての Operator を含める必要があります。詳細は、「マネージドベアメタルホストシークレットの作成」を参照してください。注記シークレットは、名前で
SiteConfig
カスタムリソース (CR) から参照されます。namespace はSiteConfig
namespace と一致する必要があります。Git リポジトリーのローカルクローンに、クラスターの
SiteConfig
CR を作成します。out/argocd/example/siteconfig/
フォルダーから CR の適切な例を選択します。フォルダーには、シングルノード、3 ノード、標準クラスターのサンプルファイルが含まれます。-
example-sno.yaml
-
example-3node.yaml
-
example-standard.yaml
-
サンプルファイルのクラスターおよびホスト詳細を、必要なクラスタータイプに一致するように変更します。以下に例を示します。
シングルノード 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: "UEFISecureBoot" 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
フィールドが展開されています。-
out/argocd/extra-manifest
で extra-manifestMachineConfig
CR のデフォルトセットを検査できます。これは、インストール時にクラスターに自動的に適用されます。 オプション: プロビジョニングされたクラスターに追加のインストール時マニフェストをプロビジョニングするには、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 パイプラインでの追加インストールマニフェストのカスタマイズ」を参照してください。
-
out/argocd/example/siteconfig/kustomization.yaml
に示す例のように、generators
セクションのkustomization.yaml
ファイルにSiteConfig
CR を追加してください。 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
リソースが更新され、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 証明書がある。
手順
-
ztp-site-generate
コンテナーソースの最新バージョンを抽出し、カスタムサイト設定データを管理するリポジトリーとマージします。 クラスター内の IPsec を設定するために必要な値を使用して、
optional-extra-manifest/ipsec/ipsec-endpoint-config.yaml
を設定します。以下に例を示します。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
次の証明書を
optional-extra-manifest/ipsec
フォルダーに追加します。-
left_server.p12
: IPsec エンドポイントの証明書バンドル ca.pem
: 証明書に署名した認証局証明書ファイルは、各ホストのネットワークセキュリティーサービス (NSS) データベースで必要です。これらのファイルは、後の手順で Butane 設定の一部としてインポートされます。
-
-
カスタムサイト設定データを保持する Git リポジトリーの
optional-extra-manifest/ipsec
フォルダーでシェルプロンプトを開きます。 必要な Butane および
MachineConfig
CR ファイルを生成するには、optional-extra-manifest/ipsec/build.sh
スクリプトを実行します。PKCS#12 証明書がパスワードで保護されている場合は、
-W
引数を設定します。出力例
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
カスタムサイト設定データを管理するリポジトリーに
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
SiteConfig
CR で、extraManifests.searchPaths
フィールドにcustom-manifest/
ディレクトリーを追加します。以下に例を示します。clusters: - clusterName: "site1-sno-du" networkType: "OVNKubernetes" extraManifests: searchPaths: - extra-manifest/ - custom-manifest/
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 がインストールされている。
手順
-
ztp-site-generate
コンテナーソースの最新バージョンを抽出し、カスタムサイト設定データを管理するリポジトリーとマージします。 クラスター内の IPsec を設定するために必要な値を使用して、
optional-extra-manifest/ipsec/ipsec-config-policy.yaml
ファイルを設定します。IPsec 設定を作成するための
ConfigurationPolicy
オブジェクト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
次の証明書を
optional-extra-manifest/ipsec
フォルダーに追加します。-
left_server.p12
: IPsec エンドポイントの証明書バンドル ca.pem
: 証明書に署名した認証局証明書ファイルは、各ホストのネットワークセキュリティーサービス (NSS) データベースで必要です。これらのファイルは、後の手順で Butane 設定の一部としてインポートされます。
-
-
カスタムサイト設定データを保持する Git リポジトリーの
optional-extra-manifest/ipsec
フォルダーでシェルプロンプトを開きます。 optional-extra-manifest/ipsec/import-certs.sh
スクリプトを実行して、外部証明書をインポートするために必要な Butane およびMachineConfig
CR を生成します。PKCS#12 証明書がパスワードで保護されている場合は、
-W
引数を設定します。出力例
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
カスタムのサイト設定データを管理するリポジトリーに
custom-manifest/
フォルダーを作成し、enable-ipsec.yaml
および99-ipsec-*
YAML ファイルをディレクトリーに追加します。siteconfig
ディレクトリーの例siteconfig ├── site1-mno-du.yaml ├── extra-manifest/ └── custom-manifest ├── enable-ipsec.yaml ├── 99-ipsec-master-import-certs.yaml └── 99-ipsec-worker-import-certs.yaml
SiteConfig
CR で、次の例のように、extraManifests.searchPaths
フィールドにcustom-manifest/
ディレクトリーを追加します。clusters: - clusterName: "site1-mno-du" networkType: "OVNKubernetes" extraManifests: searchPaths: - extra-manifest/ - custom-manifest/
-
GitOps の
source-crs
ディレクトリーにipsec-config-policy.yaml
設定ポリシーファイルを格納し、PolicyGenerator
CR の 1 つでそのファイルを参照します。 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 暗号化が設定されている。
手順
次のコマンドを実行して、マネージドクラスターのデバッグ Pod を起動します。
$ oc debug node/<node_name>
次のコマンドを実行して、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
次のコマンドを実行して、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
次のコマンドを実行して、外部ホストサブネット内の既知の IP を ping します。たとえば、
ipsec/ipsec-endpoint-config.yaml
ファイルで設定したrightsubnet
範囲内の IP アドレスを ping します。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.5. シングルノード OpenShift SiteConfig CR インストールリファレンス
SiteConfig CR フィールド | 説明 |
---|---|
|
注記
|
|
|
|
サイト内のすべてのクラスターのハブクラスターで使用できるイメージセットを設定します。ハブクラスターでサポートされるバージョンの一覧を表示するには、 |
|
クラスターのインストール前に、 重要
|
|
個々のクラスターをデプロイするために使用されるクラスターイメージセットを指定します。定義されている場合、サイトレベルで |
|
定義した
たとえば、 |
|
オプション: |
| このフィールドを設定すると、Trusted Platform Module (TPM) と Platform Configuration Register (PCR) 保護によるディスク暗号化が有効になります。詳細は、「TPM と PCR の保護によるディスク暗号化について」を参照してください。 注記
|
|
ディスク暗号化タイプを |
| ディスク暗号化用の Platform Configuration Register (PCR) 保護を設定します。 |
| ディスク暗号化に使用する Platform Configuration Register (PCR) のリストを設定します。PCR レジスター 1 と 7 を使用する必要があります。 |
|
シングルノードの導入では、単一のホストを定義します。3 ノードのデプロイメントの場合、3 台のホストを定義します。標準のデプロイメントでは、 |
| マネージドクラスター内のノードのカスタムロールを指定します。これらは追加のロールであり、OpenShift Container Platform コンポーネントでは使用されず、ユーザーによってのみ使用されます。カスタムロールを追加すると、そのロールの特定の設定を参照するカスタムマシン設定プールに関連付けることができます。インストール中にカスタムラベルまたはロールを追加すると、デプロイメントプロセスがより効率的になり、インストール完了後に追加の再起動が必要なくなります。 |
|
オプション: コメントを解除して値を |
| ホストへのアクセスに使用する BMC アドレス。すべてのクラスタータイプに適用されます。GitOps ZTP は、Redfish または IPMI プロトコルを使用して iPXE および仮想メディアの起動をサポートします。iPXE ブートを使用するには、RHACM 2.8 以降を使用する必要があります。BMC アドレッシングの詳細は、「関連情報」セクションを参照してください。 |
| ホストへのアクセスに使用する BMC アドレス。すべてのクラスタータイプに適用されます。GitOps ZTP は、Redfish または IPMI プロトコルを使用して iPXE および仮想メディアの起動をサポートします。iPXE ブートを使用するには、RHACM 2.8 以降を使用する必要があります。BMC アドレッシングの詳細は、「関連情報」セクションを参照してください。 注記 ファーエッジ通信会社のユースケースでは、GitOps ZTP では仮想メディアの使用のみがサポートされます。 |
|
ホスト BMC 認証情報を使用して、別途作成した |
|
ホストのブートモードを |
|
導入するデバイスを指定します。再起動後も安定した識別子が推奨されます。たとえば、 |
| オプション: このフィールドを使用して、永続ストレージのパーティションを割り当てます。ディスク ID とサイズを特定のハードウェアに合わせて調整します。 |
| ノードのネットワーク設定を行います。 |
| ホストの IPv6 アドレスを設定します。静的 IP アドレスを持つシングルノード OpenShift クラスターの場合、ノード固有の API と Ingress IP は同じである必要があります。 |