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

2.5. RHEL KVM を使用したクラスターの IBM Z および IBM LinuxONE へのインストール

OpenShift Container Platform バージョン 4.17 では、独自にプロビジョニングする IBM Z® または IBM® LinuxONE インフラストラクチャーに、クラスターをインストールできます。

注記

このドキュメントは IBM Z® のみを参照しますが、これに含まれるすべての情報は IBM® LinuxONE にも適用されます。

2.5.1. 前提条件

2.5.2. user-provisioned infrastructure の準備

user-provisioned infrastructure に OpenShift Container Platform をインストールする前に、基礎となるインフラストラクチャーを準備する必要があります。

このセクションでは、OpenShift Container Platform インストールの準備としてクラスターインフラストラクチャーを設定するために必要な手順の概要を説明します。これには、クラスターノード用の IP ネットワークおよびネットワーク接続を設定し、ファイアウォール経由で必要なポートを有効にし、必要な DNS および負荷分散インフラストラクチャーの設定が含まれます。

準備後、クラスターインフラストラクチャーは、user-provisioned infrastructure を使用したクラスターの要件 セクションで説明されている要件を満たす必要があります。

前提条件

手順

  1. DHCP を使用して IP ネットワーク設定をクラスターノードに提供する場合は、DHCP サービスを設定します。

    1. ノードの永続 IP アドレスを DHCP サーバー設定に追加します。設定で、関連するネットワークインターフェイスの MAC アドレスを、各ノードの目的の IP アドレスと一致させます。

    2. DHCP を使用してクラスターマシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP サーバー設定を介してクラスターノードが使用する永続 DNS サーバーアドレスを定義します。

      注記

      DHCP サービスを使用しない場合、IP ネットワーク設定と DNS サーバーのアドレスを RHCOS インストール時にノードに指定する必要があります。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始 のセクションを参照してください。

    3. DHCP サーバー設定でクラスターノードのホスト名を定義します。ホスト名に関する考慮事項は、DHCP を使用したクラスターノードのホスト名の設定 参照してください。

      注記

      DHCP サービスを使用しない場合、クラスターノードは逆引き DNS ルックアップを介してホスト名を取得します。

  2. Red Hat Enterprise Linux CoreOS (RHCOS) の高速インストールまたは Red Hat Enterprise Linux CoreOS (RHCOS) のフルインストールのいずれかの実行を選択します。フルインストールでは、HTTP または HTTPS サーバーを設定し、Ignition ファイルを提供し、イメージをクラスターノードにインストールする必要があります。高速インストールの場合、HTTP または HTTPS サーバーは必要はありませんが、DHCP サーバーが必要です。「高速インストール: Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成」および「フルインストール: Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成」のセクションを参照してください。
  3. ネットワークインフラストラクチャーがクラスターコンポーネント間の必要なネットワーク接続を提供することを確認します。要件に関する詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。

  4. OpenShift Container Platform クラスターコンポーネントで通信するために必要なポートを有効にするようにファイアウォールを設定します。必要なポートの詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。

    重要

    デフォルトで、ポート 1936 は OpenShift Container Platform クラスターにアクセスできます。これは、各コントロールプレーンノードがこのポートへのアクセスを必要とするためです。

    Ingress ロードバランサーを使用してこのポートを公開しないでください。これを実行すると、Ingress コントローラーに関連する統計やメトリクスなどの機密情報が公開される可能性があるためです。

  5. クラスターに必要な DNS インフラストラクチャーを設定します。

    1. Kubernetes API、アプリケーションワイルドカード、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの DNS 名前解決を設定します。

    2. Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの逆引き DNS 解決を設定します。

      OpenShift Container Platform DNS 要件の詳細は、user-provisioned DNS 要件 のセクションを参照してください。

  6. DNS 設定を検証します。

    1. インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答の IP アドレスが正しいコンポーネントに対応することを確認します。

    2. インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答のレコード名が正しいコンポーネントに対応することを確認します。

      DNS 検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。

  7. 必要な API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングします。要件に関する詳細は、user-provisioned infrastructure の負荷分散要件 のセクションを参照してください。
注記

一部の負荷分散ソリューションでは、負荷分散を初期化する前に、クラスターノードの DNS 名前解決を有効化する必要があります。

2.5.3. インストール設定ファイルの手動作成

クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。

前提条件

  • ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。

手順

  1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

    Copy to Clipboard Toggle word wrap 
    $ mkdir <installation_directory>
    重要

    ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

  2. 提供されるサンプルの install-config.yaml ファイルテンプレートをカスタマイズし、これを <installation_directory> に保存します。

    注記

    この設定ファイルの名前を install-config.yaml と付ける必要があります。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

関連情報

2.5.3.1. IBM Z のサンプル install-config.yaml ファイル

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。

Copy to Clipboard Toggle word wrap 
apiVersion: v1
baseDomain: example.com
1 

compute:
2 

- hyperthreading: Enabled
3 

  name: worker
  replicas: 0
4 

  architecture: s390x
controlPlane:
5 

  hyperthreading: Enabled
6 

  name: master
  replicas: 3
7 

  architecture: s390x
metadata:
  name: test
8 

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
9 

    hostPrefix: 23
10 

  networkType: OVNKubernetes
11 

  serviceNetwork:
12 

  - 172.30.0.0/16
platform:
  none: {}
13 

fips: false
14 

pullSecret: '{"auths": ...}'
15 

sshKey: 'ssh-ed25519 AAAA...'
16
1
クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
2 5
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
3 6
同時マルチスレッド (SMT) またはハイパースレッディングを有効/無効にするかどうかを指定します。デフォルトでは、SMT はマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。SMT を無効にする場合、これをすべてのクラスターマシンで無効にする必要があります。これにはコントロールプレーンとコンピュートマシンの両方が含まれます。
注記

同時マルチスレッド (SMT) はデフォルトで有効になっています。SMT が OpenShift Container Platform ノードで利用できない場合、hyperthreading パラメーターは影響を受けません。

重要

OpenShift Container Platform ノードまたは install-config.yaml ファイルであるかに関係なく hyperthreading を無効にする場合、容量計画においてマシンのパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

4
OpenShift Container Platform を user-provisioned infrastructure にインストールする場合は、この値を 0 に設定する必要があります。installer-provisioned installation では、パラメーターはクラスターが作成し、管理するコンピュートマシンの数を制御します。user-provisioned installation では、クラスターのインストールの終了前にコンピュートマシンを手動でデプロイする必要があります。
注記

3 ノードクラスターをインストールする場合は、Red Hat Enterprise Linux CoreOS (RHCOS) マシンをインストールする際にコンピュートマシンをデプロイしないでください。

7
クラスターに追加するコントロールプレーンマシンの数。クラスターをこれらの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
8
DNS レコードに指定したクラスター名。
9
Pod IP アドレスの割り当てに使用する IP アドレスのブロック。このブロックは既存の物理ネットワークと重複できません。これらの IP アドレスは Pod ネットワークに使用されます。外部ネットワークから Pod にアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定する必要があります。
注記

クラス E の CIDR 範囲は、将来の使用のために予約されています。クラス E CIDR 範囲を使用するには、ネットワーク環境がクラス E CIDR 範囲内の IP アドレスを受け入れるようにする必要があります。

10
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix が 23 に設定されている場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。これにより、510 (2^(32 - 23) - 2) Pod IP アドレスが許可されます。外部ネットワークからのノードへのアクセスを提供する必要がある場合には、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
11
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
12
サービス IP アドレスに使用する IP アドレスプール。1 つの IP アドレスプールのみを入力できます。このブロックは既存の物理ネットワークと重複できません。外部ネットワークからサービスにアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
13
プラットフォームを none に設定する必要があります。IBM Z® インフラストラクチャー用に追加のプラットフォーム設定変数を指定できません。
重要

プラットフォームタイプ none でインストールされたクラスターは、Machine API を使用したコンピューティングマシンの管理など、一部の機能を使用できません。この制限は、クラスターに接続されている計算マシンが、通常はこの機能をサポートするプラットフォームにインストールされている場合でも適用されます。このパラメーターは、インストール後に変更することはできません。

14
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。

FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

15
Red Hat OpenShift Cluster Manager からのプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
16
Red Hat Enterprise Linux CoreOS (RHCOS) の core ユーザーの SSH 公開鍵。
注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

2.5.3.2. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。

  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、および networking.serviceNetwork[] フィールドの値が設定されます。

    Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、Proxy オブジェクトの status.noProxy フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: v1
baseDomain: my.domain.com
proxy:
  httpProxy: http://<username>:<pswd>@<ip>:<port>
    1 
    
  httpsProxy: https://<username>:<pswd>@<ip>:<port>
    2 
    
  noProxy: example.com
    3 
    
additionalTrustBundle: |
    4 
    
    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle>
    5
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.com は x.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。
    4
    指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは Proxy オブジェクトの trustedCA フィールドで参照されます。additionalTrustBundle フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
    5
    オプション: trustedCA フィールドの user-ca-bundle 設定マップを参照する Proxy オブジェクトの設定を決定するポリシー。許可される値は Proxyonly および Always です。Proxyonly を使用して、http/https プロキシーが設定されている場合にのみ user-ca-bundle 設定マップを参照します。Always を使用して、常に user-ca-bundle 設定マップを参照します。デフォルト値は Proxyonly です。
    注記

    インストールプログラムは、プロキシーの readinessEndpoints フィールドをサポートしません。

    注記

    インストーラーがタイムアウトした場合は、インストーラーの wait-for コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

    Copy to Clipboard Toggle word wrap 
    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

2.5.3.3. 3 ノードクラスターの設定

オプションで、3 台のコントロールプレーンマシンのみで構成される最小の 3 つのノードクラスターにゼロコンピュートマシンをデプロイできます。これにより、テスト、開発、および実稼働に使用するための小規模なリソース効率の高いクラスターが、クラスター管理者および開発者に提供されます。

3 ノードの OpenShift Container Platform 環境では、3 つのコントロールプレーンマシンがスケジュール対象となります。つまり、アプリケーションのワークロードがそれらで実行されるようにスケジュールされます。

前提条件

  • 既存の install-config.yaml ファイルがある。

手順

  • 以下の compute スタンザに示されるように、コンピュートレプリカの数が install-config.yaml ファイルで 0 に設定されることを確認します。

    Copy to Clipboard Toggle word wrap 
    compute:
- name: worker
  platform: {}
  replicas: 0
    注記

    デプロイするコンピュートマシンの数にかかわらず、OpenShift Container Platform を user-provisioned infrastructure にインストールする際に、コンピュートマシンの replicas パラメーターの値を 0 に設定する必要があります。installer-provisioned installation では、パラメーターはクラスターが作成し、管理するコンピュートマシンの数を制御します。これは、コンピュートマシンが手動でデプロイされる、user-provisioned installation には適用されません。

    注記

    コントロールプレーンノードの推奨リソースは 6 vCPU および 21 GB です。コントロールプレーンノードが 3 つの場合には、これは最小の 5 ノードクラスターと同等のメモリー + vCPU です。3 つのノードをバックする必要があります。それぞれに、SMT2 が有効な IFL が 3 つ含まれる 120 GB ディスクにインストールします。各コントロールプレーンノードのテスト済みの最小設定とは、120 GB ディスクに 3 つの vCPU および 10 GB が指定された設定です。

3 ノードのクラスターのインストールで、以下の手順を実行します。

  • ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。詳細は、user-provisioned infrastructure の負荷分散要件 のセクションを参照してください。
  • 以下の手順で Kubernetes マニフェストファイルを作成する際に、<installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルの mastersSchedulable パラメーターが true に設定されていることを確認します。これにより、アプリケーションのワークロードがコントロールプレーンノードで実行できます。
  • Red Hat Enterprise Linux CoreOS (RHCOS) マシンを作成する際にはコンピュートノードをデプロイしないでください。

2.5.4. Cluster Network Operato の設定

クラスターネットワークの設定は、Cluster Network Operator (CNO) 設定の一部として指定され、cluster という名前のカスタムリソース (CR) オブジェクトに保存されます。CR は operator.openshift.io API グループの Network API のフィールドを指定します。

CNO 設定は、Network.config.openshift.io API グループの Network API からクラスターのインストール時に以下のフィールドを継承します。

clusterNetwork
Pod IP アドレスの割り当てに使用する IP アドレスプール。
serviceNetwork
サービスの IP アドレスプール。
defaultNetwork.type
クラスターネットワークプラグイン。OVNKubernetes は、インストール時にサポートされる唯一のプラグインです。

defaultNetwork オブジェクトのフィールドを cluster という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。

2.5.4.1. Cluster Network Operator 設定オブジェクト

Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。

表2.34 Cluster Network Operator 設定オブジェクト
フィールド型説明

metadata.name

string

CNO オブジェクトの名前。この名前は常に cluster です。

spec.clusterNetwork

array

Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。

Copy to Clipboard Toggle word wrap 
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23

spec.serviceNetwork

array

サービスの IP アドレスのブロック。OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。以下に例を示します。

Copy to Clipboard Toggle word wrap 
spec:
  serviceNetwork:
  - 172.30.0.0/14

マニフェストを作成する前に、このフィールドを install-config.yaml ファイルでのみカスタマイズすることができます。この値は、マニフェストファイルでは読み取り専用です。

spec.defaultNetwork

object

クラスターネットワークのネットワークプラグインを設定します。

spec.kubeProxyConfig

object

このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。

重要

複数のネットワークにオブジェクトをデプロイする必要があるクラスターの場合は、install-config.yaml ファイルで定義されている各ネットワークタイプの clusterNetwork.hostPrefix パラメーターに、必ず同じ値を指定してください。clusterNetwork.hostPrefix パラメーターにそれぞれ異なる値を設定すると、OVN-Kubernetes ネットワークプラグインに影響が及び、異なるノード間のオブジェクトトラフィックをプラグインが効果的にルーティングできなくなる可能性があります。

defaultNetwork オブジェクト設定

defaultNetwork オブジェクトの値は、以下の表で定義されます。

表2.35 defaultNetwork オブジェクト
フィールド型説明

type

string

OVNKubernetes。Red Hat OpenShift Networking ネットワークプラグインは、インストール中に選択されます。この値は、クラスターのインストール後は変更できません。

注記

OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。OpenShift SDN は、新しいクラスターのインストールの選択肢として利用できなくなりました。

ovnKubernetesConfig

object

このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。

OVN-Kubernetes ネットワークプラグインの設定

次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。

表2.36 ovnKubernetesConfig オブジェクト
フィールド型説明

mtu

integer

Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 100 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。

genevePort

integer

すべての Geneve パケットに使用するポート。デフォルト値は 6081 です。この値は、クラスターのインストール後は変更できません。

ipsecConfig

object

IPsec 設定をカスタマイズするための設定オブジェクトを指定します。

ipv4

object

IPv4 設定の設定オブジェクトを指定します。

ipv6

object

IPv6 設定の設定オブジェクトを指定します。

policyAuditConfig

object

ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。

gatewayConfig

object

オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。有効な値は Shared と Local です。デフォルト値は Shared です。デフォルト設定では、Open vSwitch (OVS) がトラフィックをノード IP インターフェイスに直接出力します。Local 設定では、トラフィックがホストネットワークを通過し、その結果、ホストのルーティングテーブルに適用されます。

注記

Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。

表2.37 ovnKubernetesConfig.ipv4 object
フィールド型説明

internalTransitSwitchSubnet

string

既存のネットワークインフラストラクチャーが 100.88.0.0/16 IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。東西トラフィックを可能にする分散トランジットスイッチのサブネット。このサブネットは、OVN-Kubernetes またはホスト自体で使用される他のサブネットと重複することはできません。クラスター内のノードごとに 1 つの IP アドレスを収容できる必要があります。

デフォルト値は 100.88.0.0/16 です。

internalJoinSubnet

string

既存のネットワークインフラストラクチャーが 100.64.0.0/16 IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。たとえば、clusterNetwork.cidr 値が 10.128.0.0/14 で、clusterNetwork.hostPrefix 値が /23 の場合、ノードの最大数は 2^(23-14)=512 です。

デフォルト値は 100.64.0.0/16 です。

表2.38 ovnKubernetesConfig.ipv6 object
フィールド型説明

internalTransitSwitchSubnet

string

既存のネットワークインフラストラクチャーが fd97::/64 IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。東西トラフィックを可能にする分散トランジットスイッチのサブネット。このサブネットは、OVN-Kubernetes またはホスト自体で使用される他のサブネットと重複することはできません。クラスター内のノードごとに 1 つの IP アドレスを収容できる必要があります。

デフォルト値は fd97::/64 です。

internalJoinSubnet

string

既存のネットワークインフラストラクチャーが fd98::/64 IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。

デフォルト値は fd98::/64 です。

表2.39 policyAuditConfig オブジェクト
フィールド型説明

rateLimit

integer

ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり 20 メッセージです。

maxFileSize

integer

監査ログの最大サイズ (バイト単位)。デフォルト値は 50000000 (50MB) です。

maxLogFiles

integer

保持されるログファイルの最大数。

比較先

string

以下の追加の監査ログターゲットのいずれかになります。

libc
ホスト上の journald プロセスの libc syslog() 関数。
udp:<host>:<port>
syslog サーバー。<host>:<port> を syslog サーバーのホストおよびポートに置き換えます。
unix:<file>
<file> で指定された Unix ドメインソケットファイル。
null
監査ログを追加のターゲットに送信しないでください。

syslogFacility

string

RFC5424 で定義される kern などの syslog ファシリティー。デフォルト値は local0 です。

表2.40 gatewayConfig オブジェクト
フィールド型説明

routingViaHost

boolean

Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを true に設定します。インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、Egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、Egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は false です。

このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを true に設定すると、Egress トラフィックがホストネットワークスタックで処理されるため、パフォーマンス的に、オフロードによる利点は得られません。

ipForwarding

object

Network リソースの ipForwarding 仕様を使用して、OVN-Kubernetes マネージドインターフェイス上のすべてのトラフィックの IP フォワーディングを制御できます。Kubernetes 関連のトラフィックの IP フォワーディングのみを許可するには、Restricted を指定します。すべての IP トラフィックの転送を許可するには、Global を指定します。新規インストールの場合、デフォルトは Restricted です。OpenShift Container Platform 4.14 以降に更新する場合、デフォルトは Global です。

注記

デフォルト値の Restricted では、IP 転送がドロップされるように設定されます。

ipv4

object

オプション: IPv4 アドレスのホストからサービスへのトラフィック用の内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。

ipv6

object

オプション: IPv6 アドレスのホストからサービスへのトラフィックの内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。

表2.41 gatewayConfig.ipv4 object
フィールド型説明

internalMasqueradeSubnet

string

ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv4 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は 169.254.169.0/29 です。

重要

OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして 169.254.0.0/17 を使用します。アップグレードされたクラスターの場合は、デフォルトのマスカレードサブネットに変更がありません。

表2.42 gatewayConfig.ipv6 object
フィールド型説明

internalMasqueradeSubnet

string

ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv6 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は fd69::/125 です。

重要

OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして fd69::/112 を使用します。アップグレードされたクラスターの場合は、デフォルトのマスカレードサブネットに変更がありません。

表2.43 ipsecConfig オブジェクト
フィールド型説明

mode

string

IPsec 実装の動作を指定します。次の値のいずれかである必要があります。

  • Disabled: クラスターノードで IPsec が有効になりません。
  • External: 外部ホストとのネットワークトラフィックに対して IPsec が有効になります。
  • Full: Pod トラフィックおよび外部ホストとのネットワークトラフィックに対して IPsec が有効になります。

IPSec が有効な OVN-Kubernetes 設定の例

Copy to Clipboard Toggle word wrap 
defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig:
      mode: Full

2.5.5. Kubernetes マニフェストおよび Ignition 設定ファイルの作成

一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。

重要
  • OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
注記

マニフェストおよび Ignition ファイルを生成するインストールプログラムはアーキテクチャー固有であり、クライアントイメージミラー から取得できます。インストールプログラムの Linux バージョンは s390x でのみ実行されます。このインストーラープログラムは、Mac OS バージョンとしても利用できます。

前提条件

  • OpenShift Container Platform インストールプログラムを取得していること。
  • install-config.yaml インストール設定ファイルを作成していること。

手順

  1. OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。

    Copy to Clipboard Toggle word wrap 
    $ ./openshift-install create manifests --dir <installation_directory>
    1
    1
    <installation_directory> には、作成した install-config.yaml ファイルが含まれるインストールディレクトリーを指定します。
    警告

    3 ノードクラスターをインストールしている場合は、以下の手順を省略してコントロールプレーンノードをスケジュール対象にします。

    重要

    コントロールプレーンノードをデフォルトのスケジュール不可からスケジュール可に設定するには、追加のサブスクリプションが必要です。これは、コントロールプレーンノードがコンピュートノードになるためです。

  2. <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルの mastersSchedulable パラメーターが false に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。

    1. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
    2. mastersSchedulable パラメーターを見つけ、これが false に設定されていることを確認します。
    3. ファイルを保存し、終了します。

  3. Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ ./openshift-install create ignition-configs --dir <installation_directory>
    1
    1
    <installation_directory> には、同じインストールディレクトリーを指定します。

    Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。kubeadmin-password および kubeconfig ファイルが ./<installation_directory>/auth ディレクトリーに作成されます。

    Copy to Clipboard Toggle word wrap 
    .
├── auth
│   ├── kubeadmin-password
│   └── kubeconfig
├── bootstrap.ign
├── master.ign
├── metadata.json
└── worker.ign

2.5.6. RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始

OpenShift Container Platform をプロビジョニングする IBM Z® インフラストラクチャーにインストールするには、Red Hat Enterprise Linux CoreOS (RHCOS) を Red Hat Enterprise Linux (RHEL) ゲスト仮想マシンとしてインストールする必要があります。RHCOS のインストール時に、インストールするマシンのタイプに、OpenShift Container Platform インストールプログラムによって生成された Ignition 設定ファイルを指定する必要があります。適切なネットワーク、DNS、および負荷分散インフラストラクチャーが設定されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS マシンの再起動後に自動的に開始されます。

事前にパッケージ化された QEMU コピーオンライト (QCOW2) ディスクイメージを使用する RHCOS の高速インストールを実行できます。または、新規の QCOW2 ディスクイメージでフルインストールを実行できます。

システムのセキュリティーをさらに強化するために、ファストトラックインストールに進む前に、オプションで IBM® Secure Execution を使用して RHCOS をインストールできます。

2.5.6.1. IBM Secure Execution を使用した RHCOS のインストール

IBM® Secure Execution を使用して RHCOS をインストールする前に、基礎となるインフラストラクチャーを準備する必要があります。

前提条件

  • IBM® z15 以降、または IBM® LinuxONE III 以降。
  • Red Hat Enterprise Linux (RHEL) 8 以降
  • ブートストラップ Ignition ファイルがあります。ファイルは保護されていないため、他のユーザーが表示および編集できます。
  • インストール後にブートイメージが変更されていないことを確認しました。
  • すべてのノードを IBM® Secure Execution ゲストとして実行する必要があります。

手順

  1. RHEL KVM ホストを準備して、IBM® Secure Execution をサポートします。

    • デフォルトでは、KVM ホストは IBM® Secure Execution モードのゲストをサポートしません。ゲストを IBM® Secure Execution モードでサポートするには、KVM ホストを LPAR モードで起動し、カーネルパラメーターを prot_virt=1 に指定する必要があります。RHEL 8 で prot_virt=1 を有効にするには、次の手順に従います。

      1. /boot/loader/entries/ に移動して、ブートローダー設定ファイル *.conf を変更します。
      2. カーネルコマンドラインパラメーター prot_virt=1 を追加します。

      3. zipl コマンドを実行し、システムを再起動します。

        IBM® Secure Execution for Linux のサポートを使用して正常に始動する KVM ホストは、次のカーネルメッセージを発行します。

        Copy to Clipboard Toggle word wrap 
        prot_virt: Reserving <amount>MB as ultravisor base storage.

      4. KVM ホストが IBM® Secure Execution をサポートするようになったことを確認するには、次のコマンドを実行します。

        Copy to Clipboard Toggle word wrap 
        # cat /sys/firmware/uv/prot_virt_host

        出力例

        Copy to Clipboard Toggle word wrap 
        1

        環境がセキュアホストの環境と一致していると検出された Linux インスタンスの場合、この属性の値は 1 です。他のインスタンスの場合、値は 0 です。

  2. Ignition を介して KVM ゲストにホストキーを追加します。

    最初の起動時に、RHCOS はホストキーを探して、それを使用して自身を再暗号化します。RHCOS は、/etc/se-hostkeys ディレクトリーで ibm-z-hostkey- で始まるファイルを検索します。クラスターが実行されている各マシンのすべてのホストキーは、管理者がディレクトリーにロードする必要があります。最初の起動後、他のマシンで VM を実行することはできません。

    注記

    安全なシステムで Ignition ファイルを準備する必要があります。例えば、別の IBM® Secure Execution ゲストです。

    以下に例を示します。

    Copy to Clipboard Toggle word wrap 
    {
  "ignition": { "version": "3.0.0" },
  "storage": {
    "files": [
      {
        "path": "/etc/se-hostkeys/ibm-z-hostkey-<your-hostkey>.crt",
        "contents": {
          "source": "data:;base64,<base64 encoded hostkey document>"
        },
        "mode": 420
      },
      {
        "path": "/etc/se-hostkeys/ibm-z-hostkey-<your-hostkey>.crt",
        "contents": {
          "source": "data:;base64,<base64 encoded hostkey document>"
        },
        "mode": 420
      }
    ]
  }
}
```
    注記

    ノードを複数の IBM Z® マシンで実行できるようにする場合は、必要な数のホストキーを追加できます。

  3. Base64 でエンコードされた文字列を生成するには、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    base64 <your-hostkey>.crt

    IBM® Secure Execution を実行していないゲストと比較すると、イグニションフェーズの前にイメージ全体がランダムに生成された LUKS パスフレーズで暗号化されるため、マシンの最初のブートに時間がかかります。

  4. Ignition 保護の追加

    Ignition 設定ファイルに保存されているシークレットが読み取られたり変更されたりしないようにするには、Ignition 設定ファイルを暗号化する必要があります。

    注記

    必要なセキュリティーを実現するために、IBM® Secure Execution の実行時は、Ignition ロギングとローカルログインがデフォルトで無効になります。

    1. 次のコマンドを実行して、secex-qemu.qcow2 イメージの公開 GPG キーを取得し、そのキーを使用して Ignition 設定を暗号化します。

      Copy to Clipboard Toggle word wrap 
      gpg --recipient-file /path/to/ignition.gpg.pub --yes --output /path/to/config.ign.gpg --verbose --armor --encrypt /path/to/config.ign

  5. RHCOS の高速インストールに従って、IBM® Secure Execution QCOW イメージを使用してノードをインストールします。

    注記

    仮想マシンを起動する前に、serial=ignition を serial=ignition_crypted に置き換え、launchSecurity パラメーターを追加します。

検証

RHCOS の高速インストールが完了し、最初の起動時に Ignition が実行したら、復号化が成功したか確認します。

  • 復号化が成功すると、次の例のような出力が予想されます。

    出力例

    Copy to Clipboard Toggle word wrap 
    [    2.801433] systemd[1]: Starting coreos-ignition-setup-user.service - CoreOS Ignition User Config Setup...

[    2.803959] coreos-secex-ignition-decrypt[731]: gpg: key <key_name>: public key "Secure Execution (secex) 38.20230323.dev.0" imported
[    2.808874] coreos-secex-ignition-decrypt[740]: gpg: encrypted with rsa4096 key, ID <key_name>, created <yyyy-mm-dd>
[  OK  ] Finished coreos-secex-igni…S Secex Ignition Config Decryptor.

  • 復号化に失敗した場合は、次の例のような出力が予想されます。

    出力例

    Copy to Clipboard Toggle word wrap 
    Starting coreos-ignition-s…reOS Ignition User Config Setup...
[    2.863675] coreos-secex-ignition-decrypt[729]: gpg: key <key_name>: public key "Secure Execution (secex) 38.20230323.dev.0" imported
[    2.869178] coreos-secex-ignition-decrypt[738]: gpg: encrypted with RSA key, ID <key_name>
[    2.870347] coreos-secex-ignition-decrypt[738]: gpg: public key decryption failed: No secret key
[    2.870371] coreos-secex-ignition-decrypt[738]: gpg: decryption failed: No secret key

関連情報

2.5.6.2. IBM Z または IBM& LinuxONE 環境での静的 IP を使用した NBDE の設定

IBM Z® または IBM® LinuxONE 環境で NBDE ディスク暗号化を有効にするには、追加の手順が必要です。このセクションで詳しく説明します。

前提条件

  • 外部 Tang サーバーをセットアップした。手順は、Network-Bound Disk Encryption を参照してください。
  • butane ユーティリティーをインストールした。
  • Butane でマシン設定を作成する手順を確認した。

手順

  1. コントロールプレーンとコンピュートノードの Butane 設定ファイルを作成します。

    次のコントロールプレーンノードの Butane 設定の例では、ディスク暗号化用に master-storage.bu という名前のファイルを作成します。

    Copy to Clipboard Toggle word wrap 
    variant: openshift
version: 4.17.0
metadata:
  name: master-storage
  labels:
    machineconfiguration.openshift.io/role: master
storage:
  luks:
    - clevis:
        tang:
          - thumbprint: QcPr_NHFJammnRCA3fFMVdNBwjs
            url: http://clevis.example.com:7500
        options:
    1 
    
           - --cipher
           - aes-cbc-essiv:sha256
      device: /dev/disk/by-partlabel/root
      label: luks-root
      name: root
      wipe_volume: true
  filesystems:
    - device: /dev/mapper/root
      format: xfs
      label: root
      wipe_filesystem: true
openshift:
  fips: true
    2
    1
    暗号オプションは、FIPS モードが有効な場合にのみ必要です。FIPS が無効になっている場合は、エントリーを省略します。
    2
    FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。

  2. 次のコマンドを実行して、マシンを起動するためのカスタマイズされた initramfs ファイルを作成します。

    Copy to Clipboard Toggle word wrap 
    $ coreos-installer pxe customize \
    /root/rhcos-bootfiles/rhcos-<release>-live-initramfs.s390x.img \
    --dest-device /dev/disk/by-id/scsi-<serial_number> --dest-karg-append \
    ip=<ip_address>::<gateway_ip>:<subnet_mask>::<network_device>:none \
    --dest-karg-append nameserver=<nameserver_ip> \
    --dest-karg-append rd.neednet=1 -o \
    /root/rhcos-bootfiles/<node_name>-initramfs.s390x.img
    注記

    最初のブートの前に、クラスター内の各ノードの initramfs をカスタマイズし、PXE カーネルパラメーターを追加する必要があります。

  3. ignition.platform.id=metal および ignition.firstboot を含むパラメーターファイルを作成します。

    コントロールプレーンマシンのカーネルパラメーターファイルの例

    Copy to Clipboard Toggle word wrap 
    cio_ignore=all,!condev rd.neednet=1 \
console=ttysclp0 \
ignition.firstboot ignition.platform.id=metal \
coreos.inst.ignition_url=http://<http_server>/master.ign \
    1 
    
coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
    2 
    
ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
rd.znet=qeth,0.0.bdd0,0.0.bdd1,0.0.bdd2,layer2=1 \
rd.zfcp=0.0.5677,0x600606680g7f0056,0x034F000000000000 \
zfcp.allow_lun_scan=0

    1
    Ignition 設定ファイルの場所を指定します。master.ign または worker.ign を使用します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
    2
    起動する kernel と initramfs の rootfs アーティファクトの場所を指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
    注記

    パラメーターファイルのすべてのオプションを 1 行で記述し、改行文字がないことを確認します。

関連情報

2.5.6.3. 事前にパッケージ化された QCOW2 ディスクイメージを使用した高速インストール

Red Hat Enterprise Linux CoreOS (RHCOS) の高速インストールでマシンを作成するには、事前にパッケージ化された Red Hat Enterprise Linux CoreOS (RHCOS )QEMU コピーオンライト (QCOW2) ディスクイメージをインポートします。

前提条件

  • この手順では RHEL KVM ホストと呼ばれる、KVM を使用する RHEL 8.6 以降で実行されている少なくとも 1 つの LPAR。
  • KVM/QEMU ハイパーバイザーが RHEL KVM ホストにインストーされている
  • ノードのホスト名および逆引き参照を実行できるドメインネームサーバー (DNS)。
  • IP アドレスを提供する DHCP サーバー。

手順

  1. Red Hat カスタマーポータルの 製品のダウンロード ページまたは RHCOS イメージミラー ページから RHEL QEMU コピーオンライト (QCOW2) ディスクイメージファイルを取得します。

    重要

    RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。この手順で説明されている適切な RHCOS QCOW2 イメージのみを使用します。

  2. QCOW2 ディスクイメージおよび Ignition ファイルを RHEL KVM ホストの共通ディレクトリーにダウンロードします。

    例: /var/lib/libvirt/images

    注記

    Ignition ファイルは OpenShift Container Platform インストーラーによって生成されます。

  3. 各 KVM ゲストノードの QCOW2 ディスクイメージバッキングファイルで、新しいディスクイメージを作成します。

    Copy to Clipboard Toggle word wrap 
    $ qemu-img create -f qcow2 -F qcow2 -b /var/lib/libvirt/images/{source_rhcos_qemu} /var/lib/libvirt/images/{vmname}.qcow2 {size}

  4. Ignition ファイルと新規ディスクイメージを使用して、新規 KVM ゲストノードを作成します。

    Copy to Clipboard Toggle word wrap 
    $ virt-install --noautoconsole \
   --connect qemu:///system \
   --name <vm_name> \
   --memory <memory_mb> \
   --vcpus <vcpus> \
   --disk <disk> \
   --launchSecurity type="s390-pv" \
    1 
    
   --import \
   --network network=<virt_network_parm>,mac=<mac_address> \
   --disk path=<ign_file>,format=raw,readonly=on,serial=ignition,startup_policy=optional
    2
    1
    IBM® Secure Execution が有効な場合は、launchSecurity type="s390-pv" パラメーターを追加します。
    2
    IBM® Secure Execution が有効な場合は、serial=ignition を serial=ignition_crypted に置き換えます。

2.5.6.4. 新規 QCOW2 ディスクイメージへのフルインストール

新規 QEMU copy-on-write (QCOW2) ディスクイメージのフルインストールでマシンを作成するには、以下の手順を実施します。

前提条件

  • この手順では RHEL KVM ホストと呼ばれる、KVM を使用する RHEL 8.6 以降で実行されている少なくとも 1 つの LPAR。
  • KVM/QEMU ハイパーバイザーが RHEL KVM ホストにインストーされている
  • ノードのホスト名および逆引き参照を実行できるドメインネームサーバー (DNS)。
  • HTTP または HTTPS サーバーが設定されている。

手順

  1. Red Hat カスタマーポータルの 製品のダウンロード ページ、または RHCOS イメージミラー ページから RHEL カーネル、initramfs、および rootfs ファイルを取得します。

    重要

    RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。この手順で説明されている適切な RHCOS QCOW2 イメージのみを使用します。

    ファイル名には、OpenShift Container Platform のバージョン番号が含まれます。以下の例のようになります。

    • kernel: rhcos-<version>-live-kernel-<architecture>
    • initramfs: rhcos-<version>-live-initramfs.<architecture>.img
    • rootfs: rhcos-<version>-live-rootfs.<architecture>.img

  2. virt-install を起動する前に、ダウンロードした RHEL ライブカーネル、initramfs、および rootfs、および Ignition ファイルを HTTP または HTTPS サーバーに移動します。

    注記

    Ignition ファイルは OpenShift Container Platform インストーラーによって生成されます。

  3. RHEL カーネル、initramfs、および Ignition ファイル、新規ディスクイメージ、および調整された parm 引数を使用して、新規 KVM ゲストノードを作成します。

    Copy to Clipboard Toggle word wrap 
    $ virt-install \
   --connect qemu:///system \
   --name <vm_name> \
   --memory <memory_mb> \
   --vcpus <vcpus> \
   --location <media_location>,kernel=<rhcos_kernel>,initrd=<rhcos_initrd> \ /
    1 
    
   --disk <vm_name>.qcow2,size=<image_size>,cache=none,io=native \
   --network network=<virt_network_parm> \
   --boot hd \
   --extra-args "rd.neednet=1" \
   --extra-args "coreos.inst.install_dev=/dev/<block_device>" \
   --extra-args "coreos.inst.ignition_url=http://<http_server>/bootstrap.ign" \
    2 
    
   --extra-args "coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img" \
    3 
    
   --extra-args "ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns>" \
   --noautoconsole \
   --wait
    1
    --location パラメーターには、HTTP または HTTPS サーバー上の kernel/initrd の場所を指定します。
    2
    Ignition 設定ファイルの場所を指定します。bootstrap.ign、master.ign、または worker.ign を使用します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
    3
    起動する kernel と initramfs の rootfs アーティファクトの場所を指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。

2.5.6.5. 詳細の RHCOS インストールリファレンス

このセクションでは、Red Hat Enterprise Linux CoreOS (RHCOS) の手動インストールプロセスを変更できるようにするネットワーク設定および他の高度なオプションを説明します。以下の表では、RHCOS ライブインストーラーおよび coreos-installer コマンドで使用できるカーネル引数およびコマンドラインのオプションを説明します。

2.5.6.5.1. ISO インストールのネットワークオプション

ISO イメージから RHCOS をインストールする場合、そのイメージを起動してノードのネットワークを設定する際に手動でカーネル引数を追加できます。ネットワークの引数が指定されていない場合、RHCOS が Ignition 設定ファイルを取得するためにネットワークが必要であることを検知する際に、DHCP が initramfs でアクティベートされます。

重要

ネットワーク引数を手動で追加する場合は、rd.neednet=1 カーネル引数を追加して、ネットワークを initramfs で有効にする必要があります。

以下の表は、ISO インストール用に RHCOS ノードでネットワークおよびボンディングを設定する例を示しています。この例では、ip= および nameserver= カーネル引数の使用方法を説明します。

注記

カーネル引数 ( ip= and nameserver=) を追加するときは、順序付けが重要です。

ネットワークオプションは、システムの起動時に dracut ツールに渡されます。dracut でサポートされるネットワークオプションの詳細は、man ページの dracut.cmdline を参照してください。

次の例は、ISO インストールのネットワークオプションです。

DHCP または静的 IP アドレスの設定

IP アドレスを設定するには、DHCP (ip=dhcp) を使用するか、個別の静的 IP アドレス (ip=<host_ip>) を設定します。静的 IP を設定する場合、各ノードで DNS サーバー IP アドレス (nameserver=<dns_ip>) を特定する必要があります。次の例では、以下を設定します。

  • ノードの IP アドレス: 10.10.10.2
  • ゲートウェイアドレス: 10.10.10.254
  • ネットワーク: 255.255.255.0
  • ホスト名: core0.example.com
  • DNS サーバーアドレス: 4.4.4.41
  • auto-configuration の値を none に設定します。IP ネットワークが静的に設定されている場合には、自動設定は必要ありません。
Copy to Clipboard Toggle word wrap 
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
nameserver=4.4.4.41
注記

DHCP を使用して RHCOS マシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP ベースのデプロイメントの場合、DHCP サーバー設定を使用して RHCOS ノードが使用する DNS サーバーアドレスを定義できます。

静的ホスト名を使用しない IP アドレスの設定

静的ホスト名を割り当てずに IP アドレスを設定できます。静的ホスト名がユーザーによって設定されていない場合は、逆引き DNS ルックアップによって取得され、自動的に設定されます。静的ホスト名なしで IP アドレスを設定するには、次の例を参照してください。

  • ノードの IP アドレス: 10.10.10.2
  • ゲートウェイアドレス: 10.10.10.254
  • ネットワーク: 255.255.255.0
  • DNS サーバーアドレス: 4.4.4.41
  • auto-configuration の値を none に設定します。IP ネットワークが静的に設定されている場合には、自動設定は必要ありません。
Copy to Clipboard Toggle word wrap 
ip=10.10.10.2::10.10.10.254:255.255.255.0::enp1s0:none
nameserver=4.4.4.41
複数のネットワークインターフェイスの指定

複数の ip= エントリーを設定することで、複数のネットワークインターフェイスを指定できます。

Copy to Clipboard Toggle word wrap 
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=10.10.10.3::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
デフォルトゲートウェイとルートの設定

オプション: rd.route= value を設定して、追加のネットワークへのルートを設定できます。

注記

1 つまたは複数のネットワークを設定する場合、1 つのデフォルトゲートウェイが必要です。追加のネットワークゲートウェイがプライマリーネットワークゲートウェイと異なる場合、デフォルトゲートウェイはプライマリーネットワークゲートウェイである必要があります。

  • 次のコマンドを実行して、デフォルトゲートウェイを設定します。

    Copy to Clipboard Toggle word wrap 
    ip=::10.10.10.254::::

  • 次のコマンドを入力して、追加ネットワークのルートを設定します。

    Copy to Clipboard Toggle word wrap 
    rd.route=20.20.20.0/24:20.20.20.254:enp2s0
単一インターフェイスでの DHCP の無効化

2 つ以上のネットワークインターフェイスがあり、1 つのインターフェイスのみが使用される場合などに、1 つのインターフェイスで DHCP を無効にします。この例では、enp1s0 インターフェイスには静的ネットワーク設定があり、使用されていない enp2s0 では DHCP が無効になっています。

Copy to Clipboard Toggle word wrap 
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=::::core0.example.com:enp2s0:none
DHCP と静的 IP 設定の組み合わせ

以下のように、複数のネットワークインターフェイスを持つシステムで、DHCP および静的 IP 設定を組み合わせることができます。

Copy to Clipboard Toggle word wrap 
ip=enp1s0:dhcp
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
個々のインターフェイスでの VLAN の設定

オプション: vlan= パラメーターを使用して、個別のインターフェイスに VLAN を設定できます。

  • ネットワークインターフェイスで VLAN を設定し、静的 IP アドレスを使用するには、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0.100:none
vlan=enp2s0.100:enp2s0

  • ネットワークインターフェイスで VLAN を設定し、DHCP を使用するには、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    ip=enp2s0.100:dhcp
vlan=enp2s0.100:enp2s0
複数の DNS サーバーの指定

以下のように、各サーバーに nameserver= エントリーを追加して、複数の DNS サーバーを指定できます。

Copy to Clipboard Toggle word wrap 
nameserver=1.1.1.1
nameserver=8.8.8.8

2.5.7. ブートストラッププロセスの完了まで待機する

OpenShift Container Platform ブートストラッププロセスは、初回のクラスターノードのディスクにインストールされている永続的な RHCOS 環境での起動後に開始します。Ignition 設定ファイルで指定される設定情報は、ブートストラッププロセスを初期化し、マシンに OpenShift Container Platform をインストールするために使用されます。ブートストラッププロセスが完了するまで待機する必要があります。

前提条件

  • クラスターの Ignition 設定ファイルを作成している。
  • 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
  • インストールプログラムを取得し、クラスターの Ignition 設定ファイルを生成している。
  • RHCOS をクラスターマシンにインストールし、OpenShift Container Platform インストールプログラムで生成される Ignition 設定ファイルを指定している。
  • お使いのマシンでインターネットに直接アクセスできるか、HTTP または HTTPS プロキシーが利用できる。

手順

  1. ブートストラッププロセスをモニターします。

    Copy to Clipboard Toggle word wrap 
    $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \
    1 
    
    --log-level=info
    2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warn、debug、または error を指定します。

    出力例

    Copy to Clipboard Toggle word wrap 
    INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
INFO API v1.30.3 up
INFO Waiting up to 30m0s for bootstrapping to complete...
INFO It is now safe to remove the bootstrap resources

    Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。

  2. ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。

    重要

    この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、ブートストラップマシン自体を削除し、再フォーマットすることができます。

2.5.8. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI がインストールされている。

手順

  1. kubeadmin 認証情報をエクスポートします。

    Copy to Clipboard Toggle word wrap 
    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig
    1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc whoami

    出力例

    Copy to Clipboard Toggle word wrap 
    system:admin

2.5.9. マシンの証明書署名要求の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.30.3
master-1  Ready     master  63m  v1.30.3
master-2  Ready     master  64m  v1.30.3

    出力には作成したすべてのマシンがリスト表示されます。

    注記

    上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

  2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get csr

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME        AGE   REQUESTOR                                   CONDITION
csr-mddf5   20m   system:node:master-01.example.com   Approved,Issued
csr-z5rln   16m   system:node:worker-21.example.com   Approved,Issued

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

    注記

    ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc exec、oc rsh、および oc logs コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が system:node または system:admin グループの node-bootstrapper サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap 
      $ oc adm certificate approve <csr_name>
      1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。

    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap 
      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
      注記

      一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。

  4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

    Copy to Clipboard Toggle word wrap 
    $ oc get csr

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME        AGE     REQUESTOR                                                                   CONDITION
csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
...

  5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap 
      $ oc adm certificate approve <csr_name>
      1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。

    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap 
      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

  6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.30.3
master-1  Ready     master  73m  v1.30.3
master-2  Ready     master  74m  v1.30.3
worker-0  Ready     worker  11m  v1.30.3
worker-1  Ready     worker  11m  v1.30.3

    注記

    サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

関連情報

2.5.10. Operator の初期設定

コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。

前提条件

  • コントロールプレーンが初期化されています。

手順

  1. クラスターコンポーネントがオンラインになることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ watch -n5 oc get clusteroperators

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.17.0    True        False         False      19m
baremetal                                  4.17.0    True        False         False      37m
cloud-credential                           4.17.0    True        False         False      40m
cluster-autoscaler                         4.17.0    True        False         False      37m
config-operator                            4.17.0    True        False         False      38m
console                                    4.17.0    True        False         False      26m
csi-snapshot-controller                    4.17.0    True        False         False      37m
dns                                        4.17.0    True        False         False      37m
etcd                                       4.17.0    True        False         False      36m
image-registry                             4.17.0    True        False         False      31m
ingress                                    4.17.0    True        False         False      30m
insights                                   4.17.0    True        False         False      31m
kube-apiserver                             4.17.0    True        False         False      26m
kube-controller-manager                    4.17.0    True        False         False      36m
kube-scheduler                             4.17.0    True        False         False      36m
kube-storage-version-migrator              4.17.0    True        False         False      37m
machine-api                                4.17.0    True        False         False      29m
machine-approver                           4.17.0    True        False         False      37m
machine-config                             4.17.0    True        False         False      36m
marketplace                                4.17.0    True        False         False      37m
monitoring                                 4.17.0    True        False         False      29m
network                                    4.17.0    True        False         False      38m
node-tuning                                4.17.0    True        False         False      37m
openshift-apiserver                        4.17.0    True        False         False      32m
openshift-controller-manager               4.17.0    True        False         False      30m
openshift-samples                          4.17.0    True        False         False      32m
operator-lifecycle-manager                 4.17.0    True        False         False      37m
operator-lifecycle-manager-catalog         4.17.0    True        False         False      37m
operator-lifecycle-manager-packageserver   4.17.0    True        False         False      32m
service-ca                                 4.17.0    True        False         False      38m
storage                                    4.17.0    True        False         False      37m

  2. 利用不可の Operator を設定します。

2.5.10.1. イメージレジストリーストレージの設定

Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。

実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。

アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。

2.5.10.1.1. IBM Z の場合のレジストリーストレージの設定

クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • IBM Z® にクラスターがある。

  • Red Hat OpenShift Data Foundation などのクラスターのプロビジョニングされた永続ストレージがある。

    重要

    OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの ReadWriteOnce アクセスをサポートします。ReadWriteOnce アクセスでは、レジストリーが Recreate ロールアウト戦略を使用する必要もあります。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteMany アクセスが必要です。

  • 100 Gi の容量がある。

手順

  1. レジストリーをストレージを使用できるように設定するには、configs.imageregistry/cluster リソースの spec.storage.pvc を変更します。

    注記

    共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。

  2. レジストリー Pod がないことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get pod -n openshift-image-registry -l docker-registry=default

    出力例

    Copy to Clipboard Toggle word wrap 
    No resources found in openshift-image-registry namespace

    注記

    出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。

  3. レジストリー設定を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc edit configs.imageregistry.operator.openshift.io

    出力例

    Copy to Clipboard Toggle word wrap 
    storage:
  pvc:
    claim:

    claim フィールドを空のままにし、image-registry-storage PVC の自動作成を可能にします。

  4. clusteroperator ステータスを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get clusteroperator image-registry

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME             VERSION              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
image-registry   4.17                 True        False         False      6h50m

  5. イメージのビルドおよびプッシュを有効にするためにレジストリーが managed に設定されていることを確認します。

    • 以下を実行します。

      Copy to Clipboard Toggle word wrap 
      $ oc edit configs.imageregistry/cluster

      次に、行を変更します。

      Copy to Clipboard Toggle word wrap 
      managementState: Removed

      次のように変更してください。

      Copy to Clipboard Toggle word wrap 
      managementState: Managed
2.5.10.1.2. 実稼働以外のクラスターでのイメージレジストリーのストレージの設定

Image Registry Operator のストレージを設定する必要があります。実稼働用以外のクラスターの場合、イメージレジストリーは空のディレクトリーに設定することができます。これを実行する場合、レジストリーを再起動するとすべてのイメージが失われます。

手順

  • イメージレジストリーストレージを空のディレクトリーに設定するには、以下を実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
    警告

    実稼働用以外のクラスターにのみこのオプションを設定します。

    Image Registry Operator がそのコンポーネントを初期化する前にこのコマンドを実行する場合、oc patch コマンドは以下のエラーを出して失敗します。

    Copy to Clipboard Toggle word wrap 
    Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found

    数分待機した後に、このコマンドを再び実行します。

2.5.11. user-provisioned infrastructure でのインストールの完了

Operator の設定が完了したら、独自に提供するインフラストラクチャーへのクラスターのインストールを完了できます。

前提条件

  • コントロールプレーンが初期化されています。
  • Operator の初期設定を完了済みです。

手順

  1. 以下のコマンドを使用して、すべてのクラスターコンポーネントがオンラインであることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ watch -n5 oc get clusteroperators

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.17.0    True        False         False      19m
baremetal                                  4.17.0    True        False         False      37m
cloud-credential                           4.17.0    True        False         False      40m
cluster-autoscaler                         4.17.0    True        False         False      37m
config-operator                            4.17.0    True        False         False      38m
console                                    4.17.0    True        False         False      26m
csi-snapshot-controller                    4.17.0    True        False         False      37m
dns                                        4.17.0    True        False         False      37m
etcd                                       4.17.0    True        False         False      36m
image-registry                             4.17.0    True        False         False      31m
ingress                                    4.17.0    True        False         False      30m
insights                                   4.17.0    True        False         False      31m
kube-apiserver                             4.17.0    True        False         False      26m
kube-controller-manager                    4.17.0    True        False         False      36m
kube-scheduler                             4.17.0    True        False         False      36m
kube-storage-version-migrator              4.17.0    True        False         False      37m
machine-api                                4.17.0    True        False         False      29m
machine-approver                           4.17.0    True        False         False      37m
machine-config                             4.17.0    True        False         False      36m
marketplace                                4.17.0    True        False         False      37m
monitoring                                 4.17.0    True        False         False      29m
network                                    4.17.0    True        False         False      38m
node-tuning                                4.17.0    True        False         False      37m
openshift-apiserver                        4.17.0    True        False         False      32m
openshift-controller-manager               4.17.0    True        False         False      30m
openshift-samples                          4.17.0    True        False         False      32m
operator-lifecycle-manager                 4.17.0    True        False         False      37m
operator-lifecycle-manager-catalog         4.17.0    True        False         False      37m
operator-lifecycle-manager-packageserver   4.17.0    True        False         False      32m
service-ca                                 4.17.0    True        False         False      38m
storage                                    4.17.0    True        False         False      37m

    あるいは、以下のコマンドを使用すると、すべてのクラスターが利用可能な場合に通知されます。また、このコマンドは認証情報を取得して表示します。

    Copy to Clipboard Toggle word wrap 
    $ ./openshift-install --dir <installation_directory> wait-for install-complete
    1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    Copy to Clipboard Toggle word wrap 
    INFO Waiting up to 30m0s for the cluster to initialize...

    Cluster Version Operator が Kubernetes API サーバーから OpenShift Container Platform クラスターのデプロイを終了するとコマンドは成功します。

    重要
    • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
    • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

  2. Kubernetes API サーバーが Pod と通信していることを確認します。

    1. すべての Pod のリストを表示するには、以下のコマンドを使用します。

      Copy to Clipboard Toggle word wrap 
      $ oc get pods --all-namespaces

      出力例

      Copy to Clipboard Toggle word wrap 
      NAMESPACE                         NAME                                            READY   STATUS      RESTARTS   AGE
openshift-apiserver-operator      openshift-apiserver-operator-85cb746d55-zqhs8   1/1     Running     1          9m
openshift-apiserver               apiserver-67b9g                                 1/1     Running     0          3m
openshift-apiserver               apiserver-ljcmx                                 1/1     Running     0          1m
openshift-apiserver               apiserver-z25h4                                 1/1     Running     0          2m
openshift-authentication-operator authentication-operator-69d5d8bf84-vh2n8        1/1     Running     0          5m
...

    2. 以下のコマンドを使用して、直前のコマンドの出力にリスト表示される Pod のログを表示します。

      Copy to Clipboard Toggle word wrap 
      $ oc logs <pod_name> -n <namespace>
      1
      1
      直前のコマンドの出力にあるように、Pod 名および namespace を指定します。

      Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。

  3. FCP (Fibre Channel Protocol) を使用したインストールでは、マルチパスを有効にするために追加の手順が必要です。インストール時にマルチパスを有効にしないでください。

    詳細は、インストール後のマシン設定タスク ドキュメントで、「RHCOS でのカーネル引数を使用したマルチパスの有効化」を参照してください。

2.5.12. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.17 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

2.5.13. 次のステップ

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.