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

3.2. OpenShift Container Platform を RHOSP にインストールするリソースのガイドライン

OpenShift Container Platform のインストールをサポートするために、Red Hat OpenStack Platform (RHOSP) クォータは以下の要件を満たす必要があります。

Expand
表3.1 RHOSP のデフォルトの OpenShift Container Platform クラスターに関する推奨リソース
リソース値

Floating IP アドレス

3

ポート

15

ルーター

1

サブネット

1

RAM

88 GB

vCPU

22

ボリュームストレージ

275 GB

インスタンス

7

セキュリティーグループ

3

セキュリティーグループルール

60

サーバーグループ

2 - 各マシンプールの追加のアベイラビリティーゾーンごとに 1 つ追加

クラスターは推奨されるリソースよりもリソースが少ない場合にも機能する場合がありますが、その場合のパフォーマンスは保証されません。

重要

RHOSP オブジェクトストレージ (Swift) が利用可能で、swiftoperator ロールを持つユーザーアカウントによって操作されている場合、これは OpenShift Container Platform イメージレジストリーのデフォルトバックエンドとして使用されます。この場合、ボリュームストレージ要件は 175 GB です。Swift 領域要件は、イメージレジストリーのサイズによって異なります。

注記

デフォルトで、セキュリティーグループおよびセキュリティーグループルールのクォータは低く設定される可能性があります。問題が生じた場合には、管理者として openstack quota set --secgroups 3 --secgroup-rules 60 <project> を実行して値を増やします。

OpenShift Container Platform デプロイメントは、コントロールプレーンマシン、コンピュートマシン、およびブートストラップマシンで構成されます。

3.2.1. コントロールプレーンマシン
リンクのコピー

デフォルトでは、OpenShift Container Platform インストールプロセスは 3 つのコントロールプレーンマシンを作成します。

それぞれのマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 16 GB のメモリーと 4 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量

3.2.2. コンピュートマシン
リンクのコピー

デフォルトでは、OpenShift Container Platform インストールプロセスは 3 つのコンピューティングマシンを作成します。

それぞれのマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 8 GB のメモリーと 2 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量
ヒント

コンピュートマシンは、OpenShift Container Platform で実行されるアプリケーションをホストします。できるだけ多くのアプリケーションを実行することが意図されています。

3.2.3. ブートストラップマシン
リンクのコピー

インストール時に、ブートストラップマシンは一時的にプロビジョニングされ、コントロールプレーンを初期化します。実稼働環境用のコントロールプレーンの準備ができた後に、ブートストラップマシンのプロビジョニングは解除されます。

ブートストラップマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 16 GB のメモリーと 4 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量

3.2.4. user-provisioned infrastructure の負荷分散要件
リンクのコピー

OpenShift Container Platform をインストールする前に、デフォルトの内部ロードバランシングソリューションの代わりに使用する独自の API およびアプリケーション Ingress ロードバランシングインフラストラクチャーをプロビジョニングできます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。

注記

Red Hat Enterprise Linux (RHEL) インスタンスを使用して API およびアプリケーションイングレスロードバランサーをデプロイする場合は、RHEL サブスクリプションを別途購入する必要があります。

負荷分散インフラストラクチャーは以下の要件を満たす必要があります。

  1. API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。

    • Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
    • ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
    重要

    API ロードバランサーのセッションの永続性は設定しないでください。Kubernetes API サーバーのセッション永続性を設定すると、OpenShift Container Platform クラスターとクラスター内で実行される Kubernetes API の過剰なアプリケーショントラフィックによりパフォーマンスの問題が発生する可能性があります。

    ロードバランサーのフロントとバックの両方で以下のポートを設定します。

    Expand
    表3.2 API ロードバランサー
    ポートバックエンドマシン (プールメンバー)内部外部説明

    6443

    ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。API サーバーのヘルスチェックプローブの /readyz エンドポイントを設定する必要があります。

    X

    X

    Kubernetes API サーバー

    22623

    ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。

    X

    		 

    マシン設定サーバー

    注記

    ロードバランサーは、API サーバーが /readyz エンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyz の後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとにプローブし、2 つの正常な要求が正常な状態になり、3 つの要求が正常な状態になりません。これらは十分にテストされた値です。

  2. Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。

    以下の条件を設定します。

    • Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
    • 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
    ヒント

    クライアントの実際の IP アドレスがアプリケーション Ingress ロードバランサーによって確認できる場合、ソースの IP ベースのセッション永続化を有効にすると、エンドツーエンドの TLS 暗号化を使用するアプリケーションのパフォーマンスを強化できます。

    ロードバランサーのフロントとバックの両方で以下のポートを設定します。

    Expand
    表3.3 アプリケーション Ingress ロードバランサー
    ポートバックエンドマシン (プールメンバー)内部外部説明

    443

    デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。

    X

    X

    HTTPS トラフィック

    80

    デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。

    X

    X

    HTTP トラフィック

    注記

    ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。

このセクションでは、ユーザー管理のロードバランサーを使用してデプロイされたクラスターのロードバランシング要件を満たす API およびアプリケーションの Ingress load balancer 設定の例を示します。この例は、HAProxy ロードバランサーの /etc/haproxy/haproxy.cfg 設定です。この例では、特定の負荷分散ソリューションを選択するためのアドバイスを提供することを目的としていません。

この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。

注記

HAProxy をロードバランサーとして使用し、SELinux が enforcing に設定されている場合は、setsebool -P haproxy_connect_any=1 を実行して、HAProxy サービスが設定済みの TCP ポートにバインドできることを確認する必要があります。

例3.1 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 プロセスがリッスンしていることを確認することができます。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hatトップに戻る