【2025年最新版】OpenShiftクラスタ構成・設計の基礎を図解で解説｜サーバ・ネットワーク・リソース要件まとめ　Vol.1

みなさん、こんにちは。Red Hat OpenShift（以下OpenShift）のプリセールス、構築を担当している古野です。 

はじめに

本連載では、OpenShift 環境の導入・運用・設計に携わるエンジニアに向けて、 

目的別・レベル別に構成図を描くための考え方と実践例を紹介します。 

案件の企画段階でも、ある程度の価格感を見積もるために、大まかな構成を理解しておくことが重要となりますので、参考までに読んでいただけますと幸いです。

今回含めて構成図に関するブログを3部構成で投稿予定です。

今回は、インフラ層に何を選択するか、についてはボリュームの関係で触れませんが、ベアメタル、ハイパーバイザー（vSphere, Nutanixなど）、パブリッククラウド（AWS（ROSA）、Azure（ARO）、GCPなど）、プライベートクラウド、Edgeなど様々な選択肢があります。

バージョンアップするごとに選択肢が増えて行っているので、用途に合わせて選定していただくのが良いと思います。

1．OpenShiftクラスタ構成図（基礎編）

以下の図は、標準的なOpenShift クラスタ構成（Control Plane Node x3台、Infra Node x2台以上、Compute Node x2台以上）を表しています。 

また、例として、クラスタ外で利用されるサーバについても挙げております。

図１：OpenShiftクラスタ構成例

2．各サーバの役割

各サーバの役割を説明します。

表１：各サーバの役割

3．ネットワーク構成の概要

OpenShift の通信経路は大きく4つに分かれています。

1). 運用時のアクセス

運用者がocコマンドを使ったり、Webコンソールにログインしたりするための、クラスタの管理用アクセス経路。  

経路：運用者/CI/CD → DNS → LB → API VIP (api.<cluster_name>.<base_domain>) → Master Node → API Server

2).クラスタ外からのアクセス

WebサイトやAPIなど、ユーザーが利用するアプリケーションへのアクセス経路。

経路：エンドユーザー → DNS → LB → Ingress VIP (*.apps.<cluster_name>.<base_domain>) → Compute Node → Router Pod → アプリケーションPod

3.) クラスタ内部のアクセス（Control Plane ⇔ Infra ⇔ Compute）

Kubernetes Pod、Service、etcd の通信経路。 

Kubernetesクラスタ内で稼働するPod同士の通信。OVN-KubernetesなどのCNIプラグインが提供するオーバーレイネットワーク上で実現される。アプリケーションPodからデータベースPodへの接続などがこれにあたる。my-service.my-project.svc.cluster.local のような内部DNS名（Service名）でPod間の通信が行われる。

経路：Pod ⇔ Service ⇔ Pod

4). クラスタ内からクラスタ外へのアクセス

クラスタ内のPodが、外部のコンポーネント（DNS、ミラーレジストリ、IdP、外部DBなど）にアクセスするための外向きの通信。

経路：Pod → Worker/Master Node → デフォルトゲートウェイ → 外部リソース

例として簡易的なネットワーク構成図を作成してみました。

図では、1)の通信を行うためのネットワークを運用NW、2)~4)の通信を行うためのネットワークを業務NWとしています。4)の通信のうち、ストレージ機器や外部ストレージとの通信を行うNWはパフォーマンスやセキュリティの観点から分けるケースがありますので明示的にストレージNWとして分けて表現しています。

図2：ネットワーク構成例

4．クラスタ構成パターン別の特徴

OpenShift は要件に応じてさまざまな構成パターンを選択できます。 

以下に代表的な３ パターンを挙げ、それぞれのメリット・デメリットを整理します。

可用性、拡張性を考慮すると、1). Standard Cluster（Control Plane 3 台 ＋Compute 2 台以上）がおすすめですが、コストがかかるので、クラスタの利用用途に合わせて構成を選択してくのがポイントです。

1). Standard Cluster（Control Plane 3 台 ＋Compute 2 台以上）　★推奨構成

本番運用を前提とした標準構成。制御系と実行系を完全分離。

エンタープライズ本番環境／中～大規模クラスタ構成で利用。

Control Plane 専用3 台 ＋ Compute (Worker) 2 台以上 ＋ Infra ノード オプション。

＜メリット＞

・制御系と実行系が独立し安定。

・スケールアウト容易。

・ノード障害やメンテナンス時にも影響を最小化。

・DR 設計・アップグレード設計に適す。

＜デメリット＞

・初期構築コストとリソース要件が高い。

・ノード数が多く運用設計がやや複雑。

2).  Single Node OpenShift（SNO）

最小限の1 台構成のクラスタ。エッジ環境や小規模検証環境で利用。

Control Plane + Compute + Infra 要素を1 台に統合。

<メリット>

・導入・構築が非常に容易。

・リソース消費が最小限。

・検証・開発・PoC用途に最適。

＜デメリット＞

・可用性がなく、ノード障害時に停止。

・スケールアウト不可。

・etcd ・ API ・ アプリが同一ノード上で競合しやすい。

3).  3 Node Cluster

Control Plane × 3（兼 Compute）による高可用クラスタ。比較的小規模の環境で利用。

3 台すべてが Control Plane + Compute 兼任。etcd のクォーラムを3 台で確保。

＜メリット＞

・最小限の台数で高可用構成（etcd 冗長化可）。

・小規模でも本番運用可能。

・ノード障害時もサービス継続。

＜デメリット＞

・ワーカー兼任のためリソース競合が発生。

・Compute リソース拡張に制約。

・ロード時に負荷上昇の恐れ。

5．ノード数と最小リソース要件（参考値）

1). Standard Cluster（Control Plane 3 台 ＋Compute 2 台以上）

Red Hat社がドキュメントで提示している各ノードの最小リソース要件をのせておきます。バージョンやクラスタの構成により変動しますので、参考値として、v4.20の任意のプラットフォームへのインストール時の最小リソース要件を載せておきます。

参照ドキュメント：クラスターインストールの最小リソース要件

表２：Standard Cluster（Control Plane 3 台 ＋Compute 2 台以上）の最小リソース要件

Computeノードでは最小リソース要件に加えて、ノード上で稼働するアプリケーションのリソース要件を反映してサイジングしていきます。そのため、ある程度コンテナで動かすアプリケーションの規模を想定しておくと整理しやすいです。

ノードのスペックが足りなくなった場合はComputeノードを追加することができますので、初期でどのくらいのスペックを見込んでおくかが決められれば、将来的には拡張して運用していくことが可能です。

また、ノード障害で1ノード機能しなくなった場合には、特別な設定をしていない限り正常に稼働しているノードにPODが割り振られることになりますので、その分を見込んだサイジングも必要となります。

2)3).  Single Node OpenShift（SNO）/ 3 Node Cluster

シングルノード構成と3ノード構成の場合の最小要件はこちらです。

3ノード構成の情報は、Red HatドキュメントではAgent-Baseインストールをベアメタルノードにインストールする場合の最小リソース要件が記載されておりましたので、そちらを参照しております。

参照ドキュメント：単一ノードに OpenShift をインストールするための要件

表3：Single Node OpenShift / 3Node Clusterの最小リソース要件

6．まとめ

ここまで、構成を検討するにあたって考えるポイントとなる基礎的な部分を説明しました。汎用的なお話になるので、要件に合わせて詳細を詰めていく必要もありますが、基本的な考え方としては参考にしていただけると思います。

これ以外にも、バージョンアップの考え方や、災害対策環境の構成についても今後触れていきたいと考えております。

次回、VersionUP編では、VersionUPの対応方法や対応方法ごとの想定されるクラスタ構成について触れる予定です。

考えることが多くてめげてしまいそうですが、導入することによるメリットも大きいので根気強く頑張っていきましょう！