Red Hat Summit第2章 user-provisioned infrastructure
2.1. IBM Z および IBM LinuxONE インフラストラクチャーのインストール要件
IBM Z® インフラストラクチャーへのインストールを開始する前に、IBM Z® 環境が次のインストール要件を満たしていることを確認してください。
user-provisioned infrastructure を含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。
2.1.1. クラスターのインストールに必要なマシン
最小の OpenShift Container Platform クラスターでは以下のホストが必要です。
| ホスト | 説明 |
|---|---|
| 1 つの一時的なブートストラップマシン | クラスターでは、ブートストラップマシンが OpenShift Container Platform クラスターを 3 つのコントロールプレーンマシンにデプロイする必要があります。クラスターのインストール後にブートストラップマシンを削除できます。 |
| 3 つのコントロールプレーンマシン | コントロールプレーンマシンは、コントロールプレーンを設定する Kubernetes および OpenShift Container Platform サービスを実行します。 |
| 少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。 | OpenShift Container Platform ユーザーが要求するワークロードは、コンピュートマシンで実行されます。 |
クラスターの高可用性を向上させるには、少なくとも 2 台の物理マシン上の異なるハイパーバイザーインスタンスにコントロールプレーンマシンを分散してください。
ブートストラップ、コントロールプレーンおよびコンピュートマシンでは、Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングシステムとして使用する必要があります。
RHCOS は Red Hat Enterprise Linux (RHEL) 9.2 をベースとしており、そのハードウェア認定および要件が継承されることに注意してください。Red Hat Enterprise Linux テクノロジーの機能と制限 を参照してください。
2.1.1.1. クラスターインストールの最小リソース要件
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
| マシン | オペレーティングシステム | vCPU [1] | 仮想 RAM | ストレージ | 1 秒あたりの入出力 (IOPS) |
|---|---|---|---|---|---|
| ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 該当なし |
| コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 該当なし |
| Compute | RHCOS | 2 | 8 GB | 100 GB | 該当なし |
- 1 つの物理コア (IFL) は、SMT-2 が有効な場合に 2 つの論理コア (スレッド) を提供します。ハイパーバイザーは、2 つ以上の vCPU を提供できます。
OpenShift Container Platform バージョン 4.18 の場合、RHCOS は RHEL バージョン 9.4 に基づいており、マイクロアーキテクチャー要件が更新されています。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。
- x86-64 アーキテクチャーには x86-64-v2 ISA が必要
- ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
- IBM Power アーキテクチャーには Power 9 ISA が必要
- s390x アーキテクチャーには z14 ISA が必要
詳細は、アーキテクチャー (RHEL ドキュメント) を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
関連情報
- IBM® ドキュメントの Bridging a HiperSockets LAN with a z/VM Virtual Switch を参照してください。
- パフォーマンスの最適化については、Scaling HyperPAV alias devices on Linux guests on z/VM を参照してください。
- PR/SM モードの考慮事項は、IBM® Documentation の Processors Resource/Systems Manager Planning Guide を参照してください。
- DPM モードの考慮事項は、IBM® Documentation の IBM Dynamic Partition Manager (DPM) Guide を参照してください。
- LPAR のウェイト管理とエンタイトルメントについては、Topics in LPAR Performance を参照してください。
- IBM Z® および IBM® LinuxONE 環境に推奨されるホストプラクティス
2.1.1.2. 最小の IBM Z システム環境
OpenShift Container Platform バージョン 4.18 では、次の IBM® ハードウェアがサポートされています。
| z/VM | LPAR [1] | RHEL KVM [2] | |
|---|---|---|---|
| IBM® z16 (全モデル) | supported | supported | supported |
| IBM® z15 (全モデル) | supported | supported | supported |
| IBM® z14 (全モデル) | supported | supported | supported |
| IBM® LinuxONE 4 (全モデル) | supported | supported | supported |
| IBM® LinuxONE III (全モデル) | supported | supported | supported |
| IBM® LinuxONE Emperor II | supported | supported | supported |
| IBM® LinuxONE Rockhopper II | supported | supported | supported |
- ハイパーバイザーなしで IBM Z® 上で OpenShift Container Platform を実行する場合は、Dynamic Partition Manager (DPM) を使用してマシンを管理します。
- OpenShift Container Platform 環境用に計画している仮想マシンをホストするには、ご使用の環境内の RHEL KVM ホストが特定の要件を満たしている必要があります。仮想化の使用開始 を参照してください。
ハードウェア要件
- クラスターごとに、SMT2 対応の 6 つの Integrated Facilities for Linux (IFL) に相当します。
-
最低でもネットワーク接続 1 つ。これで、
LoadBalancerサービスに接続するだけでなく、クラスター外のトラッフィクに関するデータを提供します。
- 専用または共有 IFL を使用して、十分なコンピューティングリソースを割り当てることができます。リソース共有は IBM Z® の重要な強みの 1 つです。ただし、各ハイパーバイザーレイヤーで容量を正しく調整し、すべての OpenShift Container Platform クラスターに十分なリソースがあることを確認する必要があります。
- クラスターの全体的なパフォーマンスに影響を与える可能性があるため、OpenShift Container Platform クラスターの設定に使用される LPAR には十分なコンピューティング能力が必要です。このコンテキストでは、ハイパーバイザーレベルでの LPAR のウェイト管理、エンタイトルメント、および CPU 共有が重要な役割を果たします。詳細は、「IBM Z および IBM LinuxONE 環境での推奨されるホストプラクティス」を参照してください。
IBM Z オペレーティングシステム要件
| z/VM | LPAR | RHEL KVM | |
|---|---|---|---|
| ハイパーバイザー | z/VM 7.2 以降の 1 インスタンス | IBM® z14 以降 (DPM または PR/SM 搭載) | libvirt で管理される、KVM を使用する RHEL 8.6 以降で実行する 1 つの LPAR。 |
| OpenShift Container Platform コントロールプレーンマシン | 3 つのゲスト仮想マシン | 3 つの LPAR | 3 つのゲスト仮想マシン |
| OpenShift Container Platform コンピュートマシン | 2 つのゲスト仮想マシン | 2 つの LPAR | 2 つのゲスト仮想マシン |
| 一時的な OpenShift Container Platform ブートストラップマシン | 1 つのマシン | 1 つのマシン | 1 つのマシン |
IBM Z のネットワーク接続
| z/VM | LPAR | RHEL KVM | |
|---|---|---|---|
| ネットワークインターフェイスカード (NIC) | レイヤー 2 モードの単一の z/VM 仮想 NIC | - | - |
| 仮想スイッチ (vSwitch) | レイヤー 2 イーサネットモードの z/VM VSWITCH | - | - |
| ネットワークアダプター | 直接アタッチされた OSA、RoCE、または HiperSockets | 直接アタッチされた OSA、RoCE、または HiperSockets | OSA、RoCE、または HiperSockets を使用して設定された RHEL KVM ホスト libvirt または MacVTap のブリッジネットワークを使用してネットワークをゲストに接続するように設定されているいずれかの RHEL KVM ホスト。 仮想ネットワーク接続の種類 を参照してください。 |
ディスクストレージ
| z/VM | LPAR | RHEL KVM | |
|---|---|---|---|
| ファイバー接続 (FICON) | z/VM ミニディスク、フルパックミニディスク、または専用の DASD。これらはすべて、デフォルトの CDL 形式でフォーマットされている必要があります。Red Hat Enterprise Linux CoreOS (RHCOS) インストールに必要な最低限の DASD サイズに達するには、拡張アドレスボリューム (EAV) が必要です。利用可能な場合は、HyperPAV を使用して最適なパフォーマンスを確保します。 | デフォルトの CDL 形式でフォーマットされている必要がある専用の DASD。Red Hat Enterprise Linux CoreOS (RHCOS) インストールに必要な最低限の DASD サイズに達するには、拡張アドレスボリューム (EAV) が必要です。利用可能な場合は、HyperPAV を使用して最適なパフォーマンスを確保します。 | 仮想ブロックデバイス |
| ファイバーチャネルプロトコル (FCP) | 専用の FCP または EDEV | 専用の FCP または EDEV | 仮想ブロックデバイス |
| QCOW | サポート対象外 | サポート対象外 | サポート対象 |
| NVMe | サポート対象外 | サポート対象 | 仮想ブロックデバイス |
2.1.1.3. 推奨される IBM Z システム環境
IBM Z® ハードウェア上で OpenShift Container Platform バージョン 4.18 を実行するための推奨システム環境は次のとおりです。
ハードウェア要件
- 各クラスターには、SMT2 対応の 6 つの Integrated Facilities for Linux (IFL) に相当する 3 つの論理パーティション (LPAR) があります。
-
ネットワーク接続 2 つ。これで、
LoadBalancerサービスに接続するだけでなく、クラスター外のトラッフィクに関するデータを提供します。 HiperSocket。デバイスとしてノードに直接割り当てたもの。HiperSockets をノードに直接接続するには、RHEL 8 ゲストを介して外部ネットワークへのゲートウェイをセットアップし、HiperSockets ネットワークにブリッジする必要があります。
注記z/VM 環境にインストールする場合、HiperSockets を 1 つの z/VM VSWITCH にブリッジ接続して、z/VM ゲストに対して透過的にすることもできます。
IBM Z オペレーティングシステム要件
| z/VM [1] | LPAR | RHEL KVM | |
|---|---|---|---|
| ハイパーバイザー | z/VM 7.2 以降の 1 インスタンス | IBM® z14 以降 (DPM または PR/S 搭載) | libvirt で管理される、KVM を使用する RHEL 8.6 以降で実行する 1 つの LPAR。 |
| OpenShift Container Platform コントロールプレーンマシン | 3 つのゲスト仮想マシン | 3 つの LPAR | 3 つのゲスト仮想マシン |
| OpenShift Container Platform コンピュートマシン | 6 つのゲスト仮想マシン | 6 つの LPAR | 6 つのゲスト仮想マシン |
| 一時的な OpenShift Container Platform ブートストラップマシン | 1 つのマシン | 1 つのマシン | 1 つのマシン |
-
オーバーコミット環境で必須コンポーネントの可用性を確保するには、CP コマンドの
SET SHAREを使用してコントロールプレーンの優先度を引き上げます。インフラストラクチャーノードが存在する場合は、同じ操作を行います。SET SHARE (IBM® ドキュメント) を参照してください。
関連情報
2.1.1.4. 証明書署名要求の管理
ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager は kubelet クライアント CSR のみを承認します。machine-approver は、kubelet 認証情報を使用して要求される提供証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。
2.1.1.5. user-provisioned infrastructure のネットワーク要件
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs でネットワークを設定し、Ignition 設定ファイルをフェッチする必要があります。
初回の起動時に、マシンには DHCP サーバーを使用して設定される IP アドレス設定、または必要な起動オプションを指定して静的に設定される IP アドレス設定が必要です。ネットワーク設定の確立後に、マシンは HTTP または HTTPS サーバーから Ignition 設定ファイルをダウンロードします。その後、Ignition 設定ファイルは各マシンの正確な状態を設定するために使用されます。Machine Config Operator はインストール後に、新しい証明書やキーの適用など、マシンへの追加の変更を完了します。
- クラスターマシンの長期管理に DHCP サーバーを使用することが推奨されます。DHCP サーバーが永続 IP アドレス、DNS サーバー情報、およびホスト名をクラスターマシンに提供するように設定されていることを確認します。
- DHCP サービスが user-provisioned infrastructure で利用できない場合は、IP ネットワーク設定および DNS サーバーのアドレスを RHCOS のインストール時にノードに提供することができます。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始のセクションを参照してください。
Kubernetes API サーバーはクラスターマシンのノード名を解決できる必要があります。API サーバーおよびワーカーノードが異なるゾーンに置かれている場合、デフォルトの DNS 検索ゾーンを、API サーバーでノード名を解決できるように設定することができます。もう 1 つの実行可能な方法として、ノードオブジェクトとすべての DNS 要求の両方において、ホストを完全修飾ドメイン名で常に参照します。
2.1.1.5.1. DHCP を使用したクラスターノードのホスト名の設定
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、ホスト名は NetworkManager 経由で設定されます。デフォルトでは、マシンは DHCP 経由でホスト名を取得します。ホスト名が DHCP によって提供されない場合、カーネル引数を介して静的に設定される場合、または別の方法でホスト名が取得される場合は、逆引き DNS ルックアップによって取得されます。逆引き DNS ルックアップは、ネットワークがノードで初期化された後に発生し、解決に時間がかかる場合があります。その他のシステムサービスは、これより前に起動し、ホスト名を localhost または同様のものとして検出できます。これを回避するには、DHCP を使用して各クラスターノードのホスト名を指定できます。
また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
2.1.1.5.2. ネットワーク接続の要件
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
このセクションでは、必要なポートの詳細を説明します。
接続された OpenShift Container Platform 環境では、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供するために、すべてのノードにインターネットへのアクセスが必要です。
| プロトコル | ポート | 説明 |
|---|---|---|
| ICMP | 該当なし | ネットワーク到達性のテスト |
| TCP |
| メトリック |
|
|
ホストレベルのサービス。ポート | |
|
| Kubernetes が予約するデフォルトポート | |
| UDP |
| VXLAN |
|
| Geneve | |
|
|
ポート | |
|
| IPsec IKE パケット | |
|
| IPsec NAT-T パケット | |
|
|
UDP ポート
外部 NTP タイムサーバーが設定されている場合は、UDP ポート | |
| TCP/UDP |
| Kubernetes ノードポート |
| ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
| プロトコル | ポート | 説明 |
|---|---|---|
| TCP |
| Kubernetes API |
| プロトコル | ポート | 説明 |
|---|---|---|
| TCP |
| etcd サーバーおよびピアポート |
user-provisioned infrastructure の NTP 設定
OpenShift Container Platform クラスターは、デフォルトでパブリック Network Time Protocol (NTP) サーバーを使用するように設定されます。ローカルのエンタープライズ NTP サーバーを使用する必要があるか、クラスターが切断されたネットワークにデプロイされている場合は、特定のタイムサーバーを使用するようにクラスターを設定できます。詳細は、chrony タイムサービスの設定 のドキュメントを参照してください。
DHCP サーバーが NTP サーバー情報を提供する場合、Red Hat Enterprise Linux CoreOS (RHCOS) マシンの chrony タイムサービスは情報を読み取り、NTP サーバーとクロックを同期できます。
関連情報
2.1.1.6. user-provisioned DNS 要件
OpenShift Container Platform のデプロイメントでは、以下のコンポーネントに DNS 名前解決が必要です。
- The Kubernetes API
- OpenShift Container Platform のアプリケーションワイルドカード
- ブートストラップ、コントロールプレーンおよびコンピュートマシン
また、Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンに逆引き DNS 解決も必要です。
DNS A/AAAA または CNAME レコードは名前解決に使用され、PTR レコードは逆引き名前解決に使用されます。ホスト名が DHCP によって提供されていない場合は、Red Hat Enterprise Linux CoreOS (RHCOS) は逆引きレコードを使用してすべてのノードのホスト名を設定するため、逆引きレコードは重要です。さらに、逆引きレコードは、OpenShift Container Platform が動作するために必要な証明書署名要求 (CSR) を生成するために使用されます。
各クラスターノードにホスト名を提供するために DHCP サーバーを使用することが推奨されます。詳細は、user-provisioned infrastructure に関する DHCP の推奨事項 のセクションを参照してください。
以下の DNS レコードは、user-provisioned OpenShift Container Platform クラスターに必要で、これはインストール前に設定されている必要があります。各レコードで、<cluster_name> はクラスター名で、<base_domain> は、install-config.yaml ファイルに指定するベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>. の形式を取ります。
| コンポーネント | レコード | 説明 |
|---|---|---|
| Kubernetes API |
| API ロードバランサーを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
|
| API ロードバランサーを内部的に識別するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のすべてのノードで解決できる必要があります。 重要 API サーバーは、Kubernetes に記録されるホスト名でワーカーノードを解決できる必要があります。API サーバーがノード名を解決できない場合、プロキシーされる API 呼び出しが失敗し、Pod からログを取得できなくなる可能性があります。 | |
| ルート |
| アプリケーション Ingress ロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコード。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。
たとえば、 |
| ブートストラップマシン |
| ブートストラップマシンを識別するための DNS A / AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
| コントロールプレーンマシン |
| ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコードおよび DNS PTR レコードこれらのレコードは、クラスター内のノードで解決できる必要があります。 |
| コンピュートマシン |
| ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
OpenShift Container Platform 4.4 以降では、DNS 設定で etcd ホストおよび SRV レコードを指定する必要はありません。
dig コマンドを使用して、名前および逆引き名前解決を確認することができます。検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。
2.1.1.6.1. user-provisioned クラスターの DNS 設定の例
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイするための DNS 要件を満たす A および PTR レコード設定サンプルを提供します。サンプルは、特定の DNS ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、クラスター名は ocp4 で、ベースドメインは example.com です。
user-provisioned クラスターの DNS A レコードの設定例
BIND ゾーンファイルの以下の例は、user-provisioned クラスターの名前解決の A レコードの例を示しています。
例2.1 DNS ゾーンデータベースのサンプル
$TTL 1W @ IN SOA ns1.example.com. root ( 2019070700 ; serial 3H ; refresh (3 hours) 30M ; retry (30 minutes) 2W ; expiry (2 weeks) 1W ) ; minimum (1 week) IN NS ns1.example.com. IN MX 10 smtp.example.com. ; ; ns1.example.com. IN A 192.168.1.5 smtp.example.com. IN A 192.168.1.5 ; helper.example.com. IN A 192.168.1.5 helper.ocp4.example.com. IN A 192.168.1.5 ; api.ocp4.example.com. IN A 192.168.1.5 1 api-int.ocp4.example.com. IN A 192.168.1.5 2 ; *.apps.ocp4.example.com. IN A 192.168.1.5 3 ; bootstrap.ocp4.example.com. IN A 192.168.1.96 4 ; control-plane0.ocp4.example.com. IN A 192.168.1.97 5 control-plane1.ocp4.example.com. IN A 192.168.1.98 6 control-plane2.ocp4.example.com. IN A 192.168.1.99 7 ; compute0.ocp4.example.com. IN A 192.168.1.11 8 compute1.ocp4.example.com. IN A 192.168.1.7 9 ; ;EOF
- 1
- Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照します。
- 2
- Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照し、内部クラスター通信に使用されます。
- 3
- ワイルドカードルートの名前解決を提供します。レコードは、アプリケーション Ingress ロードバランサーの IP アドレスを参照します。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
- 4
- ブートストラップマシンの名前解決を提供します。
- 5 6 7
- コントロールプレーンマシンの名前解決を提供します。
- 8 9
- コンピュートマシンの名前解決を提供します。
user-provisioned クラスターの DNS PTR レコードの設定例
以下の BIND ゾーンファイルの例では、user-provisioned クラスターの逆引き名前解決の PTR レコードの例を示しています。
例2.2 逆引きレコードの DNS ゾーンデータベースの例
$TTL 1W @ IN SOA ns1.example.com. root ( 2019070700 ; serial 3H ; refresh (3 hours) 30M ; retry (30 minutes) 2W ; expiry (2 weeks) 1W ) ; minimum (1 week) IN NS ns1.example.com. ; 5.1.168.192.in-addr.arpa. IN PTR api.ocp4.example.com. 1 5.1.168.192.in-addr.arpa. IN PTR api-int.ocp4.example.com. 2 ; 96.1.168.192.in-addr.arpa. IN PTR bootstrap.ocp4.example.com. 3 ; 97.1.168.192.in-addr.arpa. IN PTR control-plane0.ocp4.example.com. 4 98.1.168.192.in-addr.arpa. IN PTR control-plane1.ocp4.example.com. 5 99.1.168.192.in-addr.arpa. IN PTR control-plane2.ocp4.example.com. 6 ; 11.1.168.192.in-addr.arpa. IN PTR compute0.ocp4.example.com. 7 7.1.168.192.in-addr.arpa. IN PTR compute1.ocp4.example.com. 8 ; ;EOF
PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。
2.1.1.7. user-provisioned infrastructure の負荷分散要件
OpenShift Container Platform をインストールする前に、API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングする必要があります。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
Red Hat Enterprise Linux (RHEL) インスタンスを使用して API およびアプリケーションイングレスロードバランサーをデプロイする場合は、RHEL サブスクリプションを別途購入する必要があります。
負荷分散インフラストラクチャーは以下の要件を満たす必要があります。
API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
- ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
重要API ロードバランサーのセッションの永続性は設定しないでください。Kubernetes API サーバーのセッション永続性を設定すると、OpenShift Container Platform クラスターとクラスター内で実行される Kubernetes API の過剰なアプリケーショントラフィックによりパフォーマンスの問題が発生する可能性があります。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
表2.12 API ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 6443ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。API サーバーのヘルスチェックプローブの
/readyzエンドポイントを設定する必要があります。X
X
Kubernetes API サーバー
22623ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。
X
マシン設定サーバー
注記ロードバランサーは、API サーバーが
/readyzエンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyzの後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとにプローブし、2 つの正常な要求が正常な状態になり、3 つの要求が正常な状態になりません。これらは十分にテストされた値です。Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。
以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
- 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
ヒントクライアントの実際の IP アドレスがアプリケーション Ingress ロードバランサーによって確認できる場合、ソースの IP ベースのセッション永続化を有効にすると、エンドツーエンドの TLS 暗号化を使用するアプリケーションのパフォーマンスを強化できます。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
表2.13 アプリケーション Ingress ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 443デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTPS トラフィック
80デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTP トラフィック
注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
2.1.1.7.1. user-provisioned クラスターのロードバランサーの設定例
このセクションでは、user-provisioned クラスターの負荷分散要件を満たす API およびアプリケーション Ingress ロードバランサーの設定例を説明します。この例は、HAProxy ロードバランサーの /etc/haproxy/haproxy.cfg 設定です。この例では、特定の負荷分散ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
HAProxy をロードバランサーとして使用し、SELinux が enforcing に設定されている場合は、setsebool -P haproxy_connect_any=1 を実行して、HAProxy サービスが設定済みの TCP ポートにバインドできることを確認する必要があります。
例2.3 API およびアプリケーション Ingress ロードバランサーの設定例
global log 127.0.0.1 local2 pidfile /var/run/haproxy.pid maxconn 4000 daemon defaults mode http log global option dontlognull option http-server-close option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 3000 listen api-server-6443 1 bind *:6443 mode tcp option httpchk GET /readyz HTTP/1.0 option log-health-checks balance roundrobin server bootstrap bootstrap.ocp4.example.com:6443 verify none check check-ssl inter 10s fall 2 rise 3 backup 2 server master0 master0.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3 server master1 master1.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3 server master2 master2.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3 listen machine-config-server-22623 3 bind *:22623 mode tcp server bootstrap bootstrap.ocp4.example.com:22623 check inter 1s backup 4 server master0 master0.ocp4.example.com:22623 check inter 1s server master1 master1.ocp4.example.com:22623 check inter 1s server master2 master2.ocp4.example.com:22623 check inter 1s listen ingress-router-443 5 bind *:443 mode tcp balance source server compute0 compute0.ocp4.example.com:443 check inter 1s server compute1 compute1.ocp4.example.com:443 check inter 1s listen ingress-router-80 6 bind *:80 mode tcp balance source server compute0 compute0.ocp4.example.com:80 check inter 1s server compute1 compute1.ocp4.example.com:80 check inter 1s
- 1
- ポート
6443は Kubernetes API トラフィックを処理し、コントロールプレーンマシンを参照します。 - 2 4
- ブートストラップエントリーは、OpenShift Container Platform クラスターのインストール前に有効にし、ブートストラッププロセスの完了後にそれらを削除する必要があります。
- 3
- ポート
22623はマシン設定サーバートラフィックを処理し、コントロールプレーンマシンを参照します。 - 5
- ポート
443は HTTPS トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。 - 6
- ポート
80は HTTP トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
HAProxy をロードバランサーとして使用する場合は、HAProxy ノードで netstat -nltupe を実行して、ポート 6443、22623、443、および 80 で haproxy プロセスがリッスンしていることを確認することができます。
