Red Hat Summit2.3. z/VM を使用したクラスターの IBM Z および IBM IBM® LinuxONE へのインストール
OpenShift Container Platform バージョン 4.17 では、独自にプロビジョニングする IBM Z® または IBM® LinuxONE インフラストラクチャーに、クラスターをインストールできます。
このドキュメントは IBM Z® のみを参照しますが、これに含まれるすべての情報は IBM® LinuxONE にも適用されます。
2.3.1. 前提条件
- user-provisioned infrastructure を使用して IBM Z にクラスターをインストールする準備 のタスクを完了した。
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- インストールプロセスを開始する前に、既存のインストールファイルを取り除く必要があります。これにより、インストールプロセス時に必要なインストールファイルが作成され、更新されます。
-
永続ストレージを OpenShift Data Foundation またはその他のサポートされているクラスター用ストレージプロトコルを使用してプロビジョニングした。プライベートイメージレジストリーをデプロイするには、
ReadWriteManyのアクセスモードで永続ストレージを設定する必要があります。 - ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
プロキシーを設定する場合は、このサイトリストも確認してください。
2.3.2. user-provisioned infrastructure の準備
user-provisioned infrastructure に OpenShift Container Platform をインストールする前に、基礎となるインフラストラクチャーを準備する必要があります。
このセクションでは、OpenShift Container Platform インストールの準備としてクラスターインフラストラクチャーを設定するために必要な手順の概要を説明します。これには、クラスターノード用の IP ネットワークおよびネットワーク接続の設定、Ignition ファイルの Web サーバーの準備、ファイアウォール経由での必要なポートの有効化、必要な DNS および負荷分散インフラストラクチャーの設定が含まれます。
準備後、クラスターインフラストラクチャーは、user-provisioned infrastructure を使用したクラスターの要件 セクションで説明されている要件を満たす必要があります。
前提条件
- OpenShift Container Platform 4.x Tested Integrations ページを確認した。
- user-provisioned infrastructure を使用したクラスターの要件 セクションで説明されているインフラストラクチャーの要件を確認した。
手順
- 静的 IP アドレスをセットアップします。
- HTTP または HTTPS サーバーを設定し、Ignition ファイルをクラスターノードに提供します。
- ネットワークインフラストラクチャーがクラスターコンポーネント間の必要なネットワーク接続を提供することを確認します。要件に関する詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
OpenShift Container Platform クラスターコンポーネントで通信するために必要なポートを有効にするようにファイアウォールを設定します。必要なポートの詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
重要デフォルトで、ポート
1936は OpenShift Container Platform クラスターにアクセスできます。これは、各コントロールプレーンノードがこのポートへのアクセスを必要とするためです。Ingress ロードバランサーを使用してこのポートを公開しないでください。これを実行すると、Ingress コントローラーに関連する統計やメトリクスなどの機密情報が公開される可能性があるためです。
クラスターに必要な DNS インフラストラクチャーを設定します。
- Kubernetes API、アプリケーションワイルドカード、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの DNS 名前解決を設定します。
Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの逆引き DNS 解決を設定します。
OpenShift Container Platform DNS 要件の詳細は、user-provisioned DNS 要件 のセクションを参照してください。
DNS 設定を検証します。
- インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答の IP アドレスが正しいコンポーネントに対応することを確認します。
インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答のレコード名が正しいコンポーネントに対応することを確認します。
DNS 検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。
- 必要な API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングします。要件に関する詳細は、user-provisioned infrastructure の負荷分散要件 のセクションを参照してください。
一部の負荷分散ソリューションでは、負荷分散を初期化する前に、クラスターノードの DNS 名前解決を有効化する必要があります。
2.3.3. インストール設定ファイルの手動作成
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- インストールプログラムで使用するための SSH 公開鍵がローカルマシン上に存在する。この鍵は、デバッグや障害復旧のために、クラスターノードへの SSH 認証に使用できます。
- OpenShift Container Platform インストールプログラムとクラスターのプルシークレットを取得している。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
$ mkdir <installation_directory>重要このディレクトリーは必ず作成してください。ブートストラップ X.509 証明書などの一部のインストールアセットは、有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
提供されているサンプルの
install-config.yamlファイルテンプレートをカスタマイズし、ファイルを<installation_directory>に保存します。注記この設定ファイルの名前を
install-config.yamlと付ける必要があります。多くのクラスターのインストールに使用できるように、
install-config.yamlファイルをバックアップします。重要インストールプロセスの次のステップで
install-config.yamlファイルを使用するため、今すぐこのファイルをバックアップしてください。
2.3.3.1. IBM Z のサンプル install-config.yaml ファイル
install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
apiVersion: v1
baseDomain: example.com
compute:
- hyperthreading: Enabled
name: worker
replicas: 0
architecture: s390x
controlPlane:
hyperthreading: Enabled
name: master
replicas: 3
architecture: s390x
metadata:
name: test
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
networkType: OVNKubernetes
serviceNetwork:
- 172.30.0.0/16
platform:
none: {}
fips: false
pullSecret: '{"auths": ...}'
sshKey: 'ssh-ed25519 AAAA...' - 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.3.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)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。
手順
install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port>1 httpsProxy: https://<username>:<pswd>@<ip>:<port>2 noProxy: example.com3 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-confignamespace に生成します。次に 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コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。$ ./openshift-install wait-for install-complete --log-level debug- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
2.3.3.3. 3 ノードクラスターの設定
オプションで、3 台のコントロールプレーンマシンのみで構成される最小の 3 つのノードクラスターにゼロコンピュートマシンをデプロイできます。これにより、テスト、開発、および実稼働に使用するための小規模なリソース効率の高いクラスターが、クラスター管理者および開発者に提供されます。
3 ノードの OpenShift Container Platform 環境では、3 つのコントロールプレーンマシンがスケジュール対象となります。つまり、アプリケーションのワークロードがそれらで実行されるようにスケジュールされます。
前提条件
-
既存の
install-config.yamlファイルがある。
手順
以下の
computeスタンザに示されるように、コンピュートレプリカの数がinstall-config.yamlファイルで0に設定されることを確認します。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.3.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.3.4.1. Cluster Network Operator 設定オブジェクト
Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CNO オブジェクトの名前。この名前は常に |
|
|
| Pod IP アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。 |
|
|
| サービスの IP アドレスのブロック。OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。以下に例を示します。
マニフェストを作成する前に、このフィールドを |
|
|
| クラスターネットワークのネットワークプラグインを設定します。 |
|
|
| このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。 |
複数のネットワークにオブジェクトをデプロイする必要があるクラスターの場合は、install-config.yaml ファイルで定義されている各ネットワークタイプの clusterNetwork.hostPrefix パラメーターに、必ず同じ値を指定してください。clusterNetwork.hostPrefix パラメーターにそれぞれ異なる値を設定すると、OVN-Kubernetes ネットワークプラグインに影響が及び、異なるノード間のオブジェクトトラフィックをプラグインが効果的にルーティングできなくなる可能性があります。
2.3.4.1.1. defaultNetwork オブジェクト設定
defaultNetwork オブジェクトの値は、以下の表で定義されます。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
注記 OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。OpenShift SDN は、新しいクラスターのインストールの選択肢として利用できなくなりました。 |
|
|
| このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。 |
2.3.4.1.1.1. OVN-Kubernetes ネットワークプラグインの設定
次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU をオーバーライドする必要はありません。 自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。
クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも |
|
|
|
すべての Geneve パケットに使用するポート。デフォルト値は |
|
|
| IPsec 設定をカスタマイズするための設定オブジェクトを指定します。 |
|
|
| IPv4 設定の設定オブジェクトを指定します。 |
|
|
| IPv6 設定の設定オブジェクトを指定します。 |
|
|
| ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。 |
|
|
|
オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。有効な値は 注記 Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。 |
| フィールド | 型 | 説明 |
|---|---|---|
|
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
|
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
| フィールド | 型 | 説明 |
|---|---|---|
|
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
|
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
| フィールド | 型 | 説明 |
|---|---|---|
|
| integer |
ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり |
|
| integer |
監査ログの最大サイズ (バイト単位)。デフォルト値は |
|
| integer | 保持されるログファイルの最大数。 |
|
| string | 以下の追加の監査ログターゲットのいずれかになります。
|
|
| string |
RFC5424 で定義される |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを
このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを |
|
|
|
注記
デフォルト値の |
|
|
| オプション: IPv4 アドレスのホストからサービスへのトラフィック用の内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。 |
|
|
| オプション: IPv6 アドレスのホストからサービスへのトラフィックの内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。 |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv4 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は 重要
OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv6 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は 重要
OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| IPsec 実装の動作を指定します。次の値のいずれかである必要があります。
|
IPSec が有効な OVN-Kubernetes 設定の例
defaultNetwork:
type: OVNKubernetes
ovnKubernetesConfig:
mtu: 1400
genevePort: 6081
ipsecConfig:
mode: Full2.3.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インストール設定ファイルを作成していること。
手順
OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
$ ./openshift-install create manifests --dir <installation_directory>1 - 1
<installation_directory>には、作成したinstall-config.yamlファイルが含まれるインストールディレクトリーを指定します。
警告3 ノードクラスターをインストールしている場合は、以下の手順を省略してコントロールプレーンノードをスケジュール対象にします。
重要コントロールプレーンノードをデフォルトのスケジュール不可からスケジュール可に設定するには、追加のサブスクリプションが必要です。これは、コントロールプレーンノードがコンピュートノードになるためです。
<installation_directory>/manifests/cluster-scheduler-02-config.ymlKubernetes マニフェストファイルのmastersSchedulableパラメーターがfalseに設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。-
<installation_directory>/manifests/cluster-scheduler-02-config.ymlファイルを開きます。 -
mastersSchedulableパラメーターを見つけ、これがfalseに設定されていることを確認します。 - ファイルを保存し、終了します。
-
Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。
$ ./openshift-install create ignition-configs --dir <installation_directory>1 - 1
<installation_directory>には、同じインストールディレクトリーを指定します。
Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。
kubeadmin-passwordおよびkubeconfigファイルが./<installation_directory>/authディレクトリーに作成されます。. ├── auth │ ├── kubeadmin-password │ └── kubeconfig ├── bootstrap.ign ├── master.ign ├── metadata.json └── worker.ign
2.3.6. IBM Z または IBM& LinuxONE 環境での静的 IP を使用した NBDE の設定
IBM Z® または IBM® LinuxONE 環境で NBDE ディスク暗号化を有効にするには、追加の手順が必要です。このセクションで詳しく説明します。
前提条件
- 外部 Tang サーバーをセットアップした。手順は、Network-Bound Disk Encryption を参照してください。
-
butaneユーティリティーをインストールした。 - Butane でマシン設定を作成する手順を確認した。
手順
コントロールプレーンとコンピュートノードの Butane 設定ファイルを作成します。
次のコントロールプレーンノードの Butane 設定の例では、ディスク暗号化用に
master-storage.buという名前のファイルを作成します。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/root2 label: luks-root name: root wipe_volume: true filesystems: - device: /dev/mapper/root format: xfs label: root wipe_filesystem: true openshift: fips: true3 - 1
- 暗号オプションは、FIPS モードが有効な場合にのみ必要です。FIPS が無効になっている場合は、エントリーを省略します。
- 2
- DASD タイプのディスクにインストールする場合は、
device:/dev/disk/by-label/rootに置き換えます。 - 3
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
次のコマンドを実行して、マシンを起動するためのカスタマイズされた initramfs ファイルを作成します。
$ 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 カーネルパラメーターを追加する必要があります。
ignition.platform.id=metalおよびignition.firstbootを含むパラメーターファイルを作成します。コントロールプレーンマシンのカーネルパラメーターファイルの例
cio_ignore=all,!condev rd.neednet=1 \ console=ttysclp0 \ coreos.inst.install_dev=/dev/<block_device> \1 ignition.firstboot ignition.platform.id=metal \ coreos.inst.ignition_url=http://<http_server>/master.ign \2 coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \3 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 \4 zfcp.allow_lun_scan=0- 1
- ブロックデバイスタイプを指定します。DASD タイプのディスクにインストールする場合は、
/dev/dasdaを指定します。FCP タイプのディスクにインストールする場合は、/dev/sdaを指定します。 - 2
- Ignition 設定ファイルの場所を指定します。
master.ignまたはworker.ignを使用します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。 - 3
- 起動する
kernelとinitramfsのrootfsアーティファクトの場所を指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。 - 4
- DASD タイプのディスクにインストールする場合は、
rd.dasd=0.0.xxxxに置き換えて DASD デバイスを指定します。
注記パラメーターファイルのすべてのオプションを 1 行で記述し、改行文字がないことを確認します。
2.3.7. RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始
OpenShift Container Platform を独自にプロビジョニングする IBM Z® インフラストラクチャーにインストールするには、Red Hat Enterprise Linux CoreOS (RHCOS) を z/VM ゲスト仮想マシンにインストールする必要があります。RHCOS のインストール時に、インストールするマシンのタイプに、OpenShift Container Platform インストールプログラムによって生成された Ignition 設定ファイルを指定する必要があります。適切なネットワーク、DNS、および負荷分散インフラストラクチャーが設定されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS z/VM ゲスト仮想マシンの再起動後に自動的に開始されます。
マシンを作成するには、以下の手順を実行します。
前提条件
- 作成するマシンがアクセスできるプロビジョニングマシンで稼働している HTTP または HTTPS サーバー。
- セキュアブートを有効にする場合は、適切な Product Signing Key を取得し、IBM ドキュメントの Secure boot on IBM Z and IBM LinuxONE を確認した。
手順
- プロビジョニングマシンで Linux にログインします。
RHCOS イメージミラー から Red Hat Enterprise Linux CoreOS (RHCOS) カーネル、initramfs および rootfs ファイルを取得します。
重要RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。この手順で説明されている適切な kernel、initramfs、および rootfs アーティファクトのみを使用します。
ファイル名には、OpenShift Container Platform のバージョン番号が含まれます。以下の例のようになります。
-
kernel:
rhcos-<version>-live-kernel-<architecture> -
initramfs:
rhcos-<version>-live-initramfs.<architecture>.img rootfs:
rhcos-<version>-live-rootfs.<architecture>.img注記rootfs イメージは FCP および DASD の場合と同じです。
-
kernel:
パラメーターファイルを作成します。以下のパラメーターは特定の仮想マシンに固有のものです。
ip=には、以下の 7 つのエントリーを指定します。- マシンの IP アドレス。
- 空の文字列。
- ゲートウェイ。
- ネットマスク。
-
hostname.domainname形式のマシンホストおよびドメイン名。この値を省略すると、RHCOS が逆引き DNS ルックアップによりホスト名を取得します。 - ネットワークインターフェイス名。この値を省略すると、RHCOS が利用可能なすべてのインターフェイスに IP 設定を適用します。
-
静的 IP アドレスを使用する場合、
noneを指定します。
-
coreos.inst.ignition_url=の場合、マシンロールの Ignition ファイルを指定します。bootstrap.ign、master.ign、またはworker.ignを使用します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。 -
coreos.live.rootfs_url=の場合、起動しているカーネルおよび initramfs の一致する rootfs アーティファクトを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。 -
オプション: セキュアブートを有効にするには、
coreos.inst.secure_iplを追加します。 DASD タイプのディスクへのインストールには、以下のタスクを実行します。
-
coreos.inst.install_dev=には、/dev/disk/by-path/ccw-<device_id>を指定します。<device_id> には、たとえば0.0.1000を指定します。 -
rd.dasd=を使用して、RHCOS がインストールされる DASD を指定します。 その他のパラメーターはすべて変更しません。
ブートストラップマシンのパラメーターファイルのサンプル
bootstrap-0.parm:cio_ignore=all,!condev rd.neednet=1 \ console=ttysclp0 \ coreos.inst.install_dev=/dev/disk/by-id/scsi-<serial_number> \1 coreos.inst.ignition_url=http://<http_server>/bootstrap.ign \2 coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \3 coreos.inst.secure_ipl \4 ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \ rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \ rd.dasd=0.0.3490- 1
- ディスクの種類に応じて一意の完全修飾パスを指定します。これは、DASD タイプまたは FCP タイプのディスクのいずれかです。
- 2
- Ignition 設定ファイルの場所を指定します。
bootstrap.ign、master.ign、またはworker.ignを使用します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。 - 3
- 起動する
kernelとinitramfsのrootfsアーティファクトの場所を指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。 - 4
- オプション: セキュアブートを有効にするには、
coreos.inst.secure_iplを追加します。
パラメーターファイルのすべてのオプションを 1 行で記述し、改行文字がないことを確認します。
-
FCP タイプのディスクへのインストールには、以下のタスクを実行します。
rd.zfcp=<adapter>,<wwpn>,<lun>を使用して RHCOS がインストールされる FCP ディスクを指定します。マルチパスの場合、それぞれの追加のステップでこのステップを繰り返します。注記複数のパスを使用してインストールする場合は、問題が発生する可能性があるため、後でではなくインストールの直後にマルチパスを有効にする必要があります。
-
インストールデバイスを
coreos.inst.install_dev=/dev/disk/by-id/scsi-<serial_number>として設定します。
オプション:
generic.insファイルを作成します。インストール方法によっては、Hardware Management Console (HMC)、DVD、または FTP サーバーのファイルシステム内のインストールデータの場所と、データがコピーされるメモリー位置のマッピングを含む
generic.insファイルも必要です。サンプルのgeneric.insファイルが、RHEL インストールメディアに付属しています。ファイルには、初期 RAM ディスク (initrd.img)、カーネルイメージ (kernel.img)、およびパラメーター (generic.prm) ファイルのファイル名と、各ファイルのメモリー位置が含まれています。generic.insファイルの例images/kernel.img 0x00000000 images/initrd.img 0x02000000 images/genericdvd.prm 0x00010480 images/initrd.addrsize 0x00010408その他のパラメーターはすべて変更しません。
重要マルチパスを完全に有効にするには、インストール後の追加の手順が必要です。詳細は、マシン設定 の「RHCOS のカーネル引数でのマルチパスの有効化」を参照してください。
以下は、マルチパスが設定されたコンピュートノードのパラメーターファイルのサンプル
worker-1.parmです。cio_ignore=all,!condev rd.neednet=1 \ console=ttysclp0 \ coreos.inst.install_dev=/dev/disk/by-id/scsi-<serial_number> \ coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \ coreos.inst.ignition_url=http://<http_server>/worker.ign \ ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \ rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \ rd.zfcp=0.0.1987,0x50050763070bc5e3,0x4008400B00000000 \ rd.zfcp=0.0.19C7,0x50050763070bc5e3,0x4008400B00000000 \ rd.zfcp=0.0.1987,0x50050763071bc5e3,0x4008400B00000000 \ rd.zfcp=0.0.19C7,0x50050763071bc5e3,0x4008400B00000000パラメーターファイルのすべてのオプションを 1 行で記述し、改行文字がないことを確認します。
- FTP などを使用し、initramfs、kernel、パラメーターファイル、および RHCOS イメージを z/VM に転送します。FTP を使用してファイルを転送し、仮想リーダーから起動する方法の詳細は、IBM Z® でインストールを起動して z/VM に RHEL をインストールする を参照してください。
ブートストラップノードになる z/VM ゲスト仮想マシンの仮想リーダーに対してファイルの punch を実行します。
PUNCH (IBM® ドキュメント) を参照してください。
ヒントCP PUNCH コマンドを使用するか、Linux を使用している場合は、vmur コマンドを使用して 2 つの z/VM ゲスト仮想マシン間でファイルを転送できます。
- ブートストラップマシンで CMS にログインします。
リーダーからブートストラップマシンに対して IPL を実行します。
$ ipl cIPL (IBM® ドキュメント) を参照してください。
- クラスター内の他のマシンに、この手順を繰り返します。
2.3.7.1. 詳細の RHCOS インストールリファレンス
このセクションでは、Red Hat Enterprise Linux CoreOS (RHCOS) の手動インストールプロセスを変更できるようにするネットワーク設定および他の高度なオプションを説明します。以下の表では、RHCOS ライブインストーラーおよび coreos-installer コマンドで使用できるカーネル引数およびコマンドラインのオプションを説明します。
2.3.7.1.1. ISO インストールのネットワークおよびボンディングのオプション
ISO イメージから RHCOS をインストールする場合、そのイメージを起動してノードのネットワークを設定する際に手動でカーネル引数を追加できます。ネットワークの引数が指定されていない場合、RHCOS が Ignition 設定ファイルを取得するためにネットワークが必要であることを検知する際に、DHCP が initramfs でアクティベートされます。
ネットワーク引数を手動で追加する場合は、rd.neednet=1 カーネル引数を追加して、ネットワークを initramfs で有効にする必要があります。
以下の情報は、ISO インストール用に RHCOS ノードでネットワークおよびボンディングを設定する例を示しています。この例では、ip=、nameserver=、および bond= カーネル引数の使用方法を説明しています。
順序は、カーネル引数の ip=、nameserver=、および bond= を追加する場合に重要です。
ネットワークオプションは、システムの起動時に dracut ツールに渡されます。dracut でサポートされるネットワークオプションの詳細は、dracut.cmdline man ページ を参照してください。
次の例は、ISO インストールのネットワークオプションです。
2.3.7.1.1.1. 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 ネットワークが静的に設定されている場合には、自動設定は必要ありません。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
nameserver=4.4.4.41DHCP を使用して RHCOS マシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP ベースのデプロイメントの場合、DHCP サーバー設定を使用して RHCOS ノードが使用する DNS サーバーアドレスを定義できます。
2.3.7.1.1.2. 静的ホスト名を使用しない 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 ネットワークが静的に設定されている場合には、自動設定は必要ありません。
ip=10.10.10.2::10.10.10.254:255.255.255.0::enp1s0:none
nameserver=4.4.4.412.3.7.1.1.3. 複数のネットワークインターフェイスの指定
複数の ip= エントリーを設定することで、複数のネットワークインターフェイスを指定できます。
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:none2.3.7.1.1.4. デフォルトゲートウェイとルートの設定
オプション: rd.route= value を設定して、追加のネットワークへのルートを設定できます。
1 つまたは複数のネットワークを設定する場合、1 つのデフォルトゲートウェイが必要です。追加のネットワークゲートウェイがプライマリーネットワークゲートウェイと異なる場合、デフォルトゲートウェイはプライマリーネットワークゲートウェイである必要があります。
次のコマンドを実行して、デフォルトゲートウェイを設定します。
ip=::10.10.10.254::::次のコマンドを入力して、追加ネットワークのルートを設定します。
rd.route=20.20.20.0/24:20.20.20.254:enp2s0
2.3.7.1.1.5. 単一インターフェイスでの DHCP の無効化
2 つ以上のネットワークインターフェイスがあり、1 つのインターフェイスのみが使用される場合などに、1 つのインターフェイスで DHCP を無効にします。この例では、enp1s0 インターフェイスには静的ネットワーク設定があり、使用されていない enp2s0 では DHCP が無効になっています。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=::::core0.example.com:enp2s0:none2.3.7.1.1.6. DHCP と静的 IP 設定の組み合わせ
以下のように、複数のネットワークインターフェイスを持つシステムで、DHCP および静的 IP 設定を組み合わせることができます。
ip=enp1s0:dhcp
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none2.3.7.1.1.7. 個々のインターフェイスでの VLAN の設定
オプション: vlan= パラメーターを使用して、個別のインターフェイスに VLAN を設定できます。
ネットワークインターフェイスで VLAN を設定し、静的 IP アドレスを使用するには、次のコマンドを実行します。
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 を使用するには、次のコマンドを実行します。
ip=enp2s0.100:dhcp vlan=enp2s0.100:enp2s0
2.3.7.1.1.8. 複数の DNS サーバーの指定
以下のように、各サーバーに nameserver= エントリーを追加して、複数の DNS サーバーを指定できます。
nameserver=1.1.1.1
nameserver=8.8.8.82.3.7.1.1.9. 複数のネットワークインターフェイスの単一インターフェイスへのボンディング
オプション: bond= オプションを使用して、複数のネットワークインターフェイスを単一のインターフェイスにボンディングできます。次の例を参照してください。
ボンディングされたインターフェイスを設定するための構文は、
bond=<name>[:<network_interfaces>][:options]です。<name>はボンディングデバイス名 (bond0)、<network_interfaces>は物理 (イーサネット) インターフェイスのコンマ区切りのリスト (em1,em2) を表し、options はボンディングオプションのコンマ区切りのリストです。modinfo bondingを入力して、利用可能なオプションを表示します。bond=を使用してボンディングされたインターフェイスを作成する場合は、ボンディングされたインターフェイスの IP アドレスの割り当て方法やその他の情報を指定する必要があります。DHCP を使用するようにボンディングされたインターフェイスを設定するには、ボンドの IP アドレスを
dhcpに設定します。以下に例を示します。bond=bond0:em1,em2:mode=active-backup ip=bond0:dhcp- 静的 IP アドレスを使用するようにボンディングされたインターフェイスを設定するには、必要な特定の IP アドレスと関連情報を入力します。以下に例を示します。
bond=bond0:em1,em2:mode=active-backup,fail_over_mac=1
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
共有 OSA/RoCE カードを使用する場合の問題を回避するために、常にアクティブバックアップモードで fail_over_mac=1 オプションを設定してください。
2.3.7.1.1.10. 複数のネットワークインターフェイスの単一インターフェイスへのボンディング
任意: 以下のように、vlan= パラメーターを指定して、DHCP を使用して、ボンディングされたインターフェイスで VLAN を設定できます。
ip=bond0.100:dhcp
bond=bond0:em1,em2:mode=active-backup
vlan=bond0.100:bond0次の例を使用して、VLAN でボンディングされたインターフェイスを設定し、静的 IP アドレスを使用します。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0.100:none
bond=bond0:em1,em2:mode=active-backup
vlan=bond0.100:bond02.3.7.1.1.11. ネットワークチーミングの使用
任意: team= パラメーターを指定して、ボンディングの代わりにネットワークチーミングを使用できます。
チームインターフェイス設定の構文は
team=name[:network_interfaces]です。name はチームデバイス名 (
team0)、network_interfaces は物理 (イーサネット) インターフェイス (em1, em2) のコンマ区切りリストを表します。
RHCOS が次のバージョンの RHEL に切り替わると、チーミングは非推奨になる予定です。詳細は、こちらの Red Hat ナレッジベース記事 を参照してください。
次の例を使用して、ネットワークチームを設定します。
team=team0:em1,em2
ip=team0:dhcp2.3.8. ブートストラッププロセスの完了まで待機する
OpenShift Container Platform ブートストラッププロセスは、初回のクラスターノードのディスクにインストールされている永続的な RHCOS 環境での起動後に開始します。Ignition 設定ファイルで指定される設定情報は、ブートストラッププロセスを初期化し、マシンに OpenShift Container Platform をインストールするために使用されます。ブートストラッププロセスが完了するまで待機する必要があります。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
- インストールプログラムを取得し、クラスターの Ignition 設定ファイルを生成している。
- RHCOS をクラスターマシンにインストールし、OpenShift Container Platform インストールプログラムで生成される Ignition 設定ファイルを指定している。
- お使いのマシンでインターネットに直接アクセスできるか、HTTP または HTTPS プロキシーが利用できる。
手順
ブートストラッププロセスをモニターします。
$ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \1 --log-level=info2 出力例
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 resourcesKubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。
ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。
重要この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、ブートストラップマシン自体を削除し、再フォーマットすることができます。
2.3.9. CLI の使用によるクラスターへのログイン
クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
OpenShift CLI (
oc) がインストールされている。
手順
次のコマンドを実行して、
kubeadmin認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig1 - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
次のコマンドを実行し、エクスポートされた設定を使用して
ocコマンドを正常に実行できることを確認します。$ oc whoami出力例
system:admin
2.3.10. マシンの証明書署名要求の承認
マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。
前提条件
- マシンがクラスターに追加されています。
手順
クラスターがマシンを認識していることを確認します。
$ oc get nodes出力例
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 が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。
保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に
PendingまたはApprovedステータスが表示されていることを確認します。$ oc get csr出力例
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追加したマシンの保留中の 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サービスアカウントによって提出されていることを確認し、ノードの ID を確認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
$ oc adm certificate approve <csr_name>1 - 1
<csr_name>は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
$ 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 が承認されるまで利用できない可能性があります。
クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。
$ oc get csr出力例
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 ...残りの CSR が承認されず、それらが
Pendingステータスにある場合、クラスターマシンの CSR を承認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
$ oc adm certificate approve <csr_name>1 - 1
<csr_name>は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが
Readyになります。以下のコマンドを実行して、これを確認します。$ oc get nodes出力例
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.3.11. Operator の初期設定
コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。
前提条件
- コントロールプレーンが初期化されています。
手順
クラスターコンポーネントがオンラインになることを確認します。
$ watch -n5 oc get clusteroperators出力例
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- 利用不可の Operator を設定します。
2.3.11.1. イメージレジストリーストレージの設定
Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。
実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。
アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。
2.3.11.1.1. IBM Z の場合のレジストリーストレージの設定
クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - IBM Z® にクラスターがある。
Red Hat OpenShift Data Foundation などのクラスターのプロビジョニングされた永続ストレージがある。
重要OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの
ReadWriteOnceアクセスをサポートします。ReadWriteOnceアクセスでは、レジストリーがRecreateロールアウト戦略を使用する必要もあります。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteManyアクセスが必要です。- 100 Gi の容量がある。
手順
レジストリーをストレージを使用できるように設定するには、
configs.imageregistry/clusterリソースのspec.storage.pvcを変更します。注記共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。
レジストリー Pod がないことを確認します。
$ oc get pod -n openshift-image-registry -l docker-registry=default出力例
No resources found in openshift-image-registry namespace注記出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。
レジストリー設定を確認します。
$ oc edit configs.imageregistry.operator.openshift.io出力例
storage: pvc: claim:claimフィールドを空のままにし、image-registry-storagePVC の自動作成を可能にします。clusteroperatorステータスを確認します。$ oc get clusteroperator image-registry出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.17 True False False 6h50mイメージのビルドおよびプッシュを有効にするためにレジストリーが managed に設定されていることを確認します。
以下を実行します。
$ oc edit configs.imageregistry/cluster次に、行を変更します。
managementState: Removed次のように変更してください。
managementState: Managed
2.3.11.1.2. 実稼働以外のクラスターでのイメージレジストリーのストレージの設定
Image Registry Operator のストレージを設定する必要があります。実稼働用以外のクラスターの場合、イメージレジストリーは空のディレクトリーに設定することができます。これを実行する場合、レジストリーを再起動するとすべてのイメージが失われます。
手順
イメージレジストリーストレージを空のディレクトリーに設定するには、以下を実行します。
$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'警告実稼働用以外のクラスターにのみこのオプションを設定します。
Image Registry Operator がそのコンポーネントを初期化する前にこのコマンドを実行する場合、
oc patchコマンドは以下のエラーを出して失敗します。Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found数分待機した後に、このコマンドを再び実行します。
2.3.12. user-provisioned infrastructure でのインストールの完了
Operator の設定が完了したら、独自に提供するインフラストラクチャーへのクラスターのインストールを完了できます。
前提条件
- コントロールプレーンが初期化されています。
- Operator の初期設定を完了済みです。
手順
以下のコマンドを使用して、すべてのクラスターコンポーネントがオンラインであることを確認します。
$ watch -n5 oc get clusteroperators出力例
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あるいは、以下のコマンドを使用すると、すべてのクラスターが利用可能な場合に通知されます。また、このコマンドは認証情報を取得して表示します。
$ ./openshift-install --dir <installation_directory> wait-for install-complete1 - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
出力例
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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
Kubernetes API サーバーが Pod と通信していることを確認します。
すべての Pod のリストを表示するには、以下のコマンドを使用します。
$ oc get pods --all-namespaces出力例
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以下のコマンドを使用して、直前のコマンドの出力にリスト表示される Pod のログを表示します。
$ oc logs <pod_name> -n <namespace><namespace>: 前のコマンドの出力に示されているように、Pod 名と namespace を指定します。Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。
FCP (Fibre Channel Protocol) を使用したインストールでは、マルチパスを有効にするために追加の手順が必要です。インストール時にマルチパスを有効にしないでください。
詳細は、インストール後のマシン設定タスク ドキュメントで、「RHCOS でのカーネル引数を使用したマルチパスの有効化」を参照してください。
検証
OpenShift Container Platform のブートストラッププロセス中にセキュアブートを有効にした場合は、次の検証手順が必要です。
次のコマンドを実行してノードをデバッグします。
$ oc debug node/<node_name>出力例
chroot /host次のコマンドを実行して、セキュアブートが有効になっていることを確認します。出力例の
1はセキュアブートが有効になっていることを、0はセキュアブートが有効になっていないことを示します。$ cat /sys/firmware/ipl/secure
2.3.13. 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 サブスクリプションを追跡します。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}