OpenShiftはなぜ3台必要なのか？ コントロールプレーンの仕組みと可用性を分かりやすく解説

みなさん、こんにちは。Red Hat OpenShiftの構築を担当している巻島です。

OpenShiftを触っていると、「クラスタはどのように可用性を保っているのか」「障害が発生したとき、どのコンポーネントがどのように動くのか」が気になる場面があります。

その仕組みを理解するうえで、まず押さえておきたいのがコントロールプレーンです。

アプリケーションのPodはWorker Node上で動作します。
しかし、Podの配置、クラスタ状態の管理、障害時の再調整、設定変更の反映などは、コントロールプレーンが担当しています。

この記事では、OpenShiftのコントロールプレーンを構成するAPI Server、etcd、Scheduler、Controller Managerを中心に、それぞれの役割と可用性の考え方を整理します。

１．コントロールプレーンとは何か

OpenShiftのコントロールプレーンは、クラスタ全体の状態を管理する役割を持ちます。
主な役割

• クラスタ全体の状態管理
• PodやNodeの配置判断
• 障害検知と復旧の指示
• 設定情報・状態情報の保存
• 利用者や運用者からの操作受付

API Server、etcd、Scheduler、Controller Manager、Operatorなどの複数コンポーネントが連携して動作します。 

ざっくりとした説明をすると、API Serverがクラスタ操作の入口になり、etcdが状態を保存し、SchedulerやController Managerがクラスタを望ましい状態に近づけていく、という構造です。 

全体像

２．コントロールプレーンを構成する主要コンポーネント

2-1. API Server

API Serverは、クラスタ操作の入口です。
oc や kubectl、各種Controller、Operatorなどは、基本的にAPI Serverを通じてクラスタ状態を取得・更新します。

主な役割

• 管理コマンドの受付
• クラスタリソースの読み書き
• 各コンポーネントへの状態通知
• 認証・認可の窓口

ここでいうクラスタリソースとは、Pod、Deployment、Service、ConfigMap、Secretなど、Kubernetes / OpenShift上で管理されるオブジェクトのことです。

API Serverが利用できない状態になると、既存Podがすぐに停止するとは限りませんが、新規デプロイやスケール変更、設定変更などの操作は難しくなります。

2-2. etcd

etcdは、Kubernetes / OpenShiftの状態情報を保持する分散Key-Valueストアです。
クラスタの現在状態を保存するデータベースで、Podが存在しているか、NodeがReadyか、ServiceがどのEndpointを持っているか、といった情報が保存されます。

主な役割

• Pod、Node、Service、ConfigMapなどの状態保存
• クラスタ構成情報の保存
• 各コンポーネントが参照する状態データの提供

etcdは複数メンバーで構成されます。

一般的な3台のコントロールプレーン構成では、etcdも3メンバーで動作します。

etcdでは、Leader と Follower という役割が選出されます。

書き込み処理はLeaderを中心に行われ、Followerへ複製されます。Leaderが停止した場合は、残ったメンバーの中から新しいLeaderが選ばれます。

もう1つ重要なのが、etcdクォーラムです。

etcdクォーラムとは、更新を確定するために必要な過半数のことです。3メンバー構成の場合、2メンバーが生きていれば過半数を満たせます。つまり、1台障害までは継続できますが、2台停止するとクォーラムを失い、状態更新が困難になります。

2-3. Scheduler

Schedulerは、どのWorker NodeにPodを配置するかを決めるコンポーネントです。

主な役割

• 新規Podの配置先決定
• Nodeの空きリソースや制約条件を見たスケジューリング

Schedulerは、CPUやメモリの空き状況、Nodeのラベル、テイント/容認 (Toleration)、アフィニティーなどを見ながら、配置先のWorker Nodeを決定します。

テイント/容認 (Toleration)は、特定のNodeにPodを配置させない、または許可されたPodだけを配置するための仕組みです。
アフィニティーは、Podを特定のNodeに寄せたり、逆に離したりするための配置ルールです。

Schedulerは「このPodはこのNodeに置く」と決め、その結果をAPI Serverに書き戻します。

実際にコンテナを起動するのは、Worker Node上のkubeletです。

2-4.Controller Manager 

Controller Managerは、複数のControllerを動かし、現在の状態をあるべき状態へ近づける制御ループを実行します。

主な役割

• Replica数の維持
• Node状態の監視
• 障害時の再作成判断
• 各種Controllerの実行

たとえば、Deploymentで「Podを3つ動かす」と定義されているのに、実際には2つしか動いていない場合、Controllerが差分を検知し、不足分のPodを作成しようとします。

この「あるべき状態」と「現在の状態」の差を埋め続ける動きが、Kubernetes / OpenShiftの基本的な考え方です。

2-5.Operator 

OpenShiftでは、Cluster Operatorが構成管理・監視・修復に関わります。
OpenShiftの各機能を、期待される状態に保つための仕組みです。

主な役割

• コンポーネントの設定管理
• 状態監視
• 異常時の再調整
• アップデート時の整合性維持

OpenShiftの標準機能が期待どおりに動いているか、設定にずれがないか、更新時に矛盾が起きていないかを継続的に確認します。

３．Podが起動するまでの流れ

コントロールプレーンを理解するために、Deploymentを作成してからPodが起動するまでの流れで説明します。

ユーザーが oc apply などでDeploymentを作成すると、裏側では次のような処理が進みます。

1. User / oc がDeployment作成をAPI Serverへ送信
2. API ServerがDeploymentをetcdへ保存
3. Controller ManagerがDeployment作成を検知
4. Controller ManagerがReplicaSetを作成
5. API ServerがReplicaSetをetcdへ保存
6. Controller ManagerがPodを作成
7. API ServerがPodをetcdへ保存
8. Schedulerが未配置Podを検知
9. Schedulerが配置先Worker Nodeを決定
10. API ServerがPodのNode割当をetcdへ保存
11. Kubeletが自Nodeに割り当てられたPodを検知
12. Kubeletがコンテナランタイムを通じてコンテナを起動

４．可用性を支える基本設計

OpenShiftのコントロールプレーンは、単一障害点を減らすため、一般的に3台構成で設計されます。

それぞれのコントロールプレーンノード上で主要コンポーネントが動作し、APIアクセスはロードバランサ経由で分散されます。

ここでいうロードバランサは、API Serverへのアクセスを複数のコントロールプレーンノードへ振り分けるための仕組みです。
1台のAPI Serverに障害が発生しても、他のAPI Serverへアクセスできるようにするために使われます。

etcdは複数メンバーでデータを複製し、過半数が生きていれば状態更新を継続できます。
SchedulerやController Managerは複数起動していても、実際に処理するインスタンスをリーダー選出で決めます。

リーダー選出とは、複数のインスタンスの中から「今アクティブに処理する担当」を1つ選ぶ仕組みです。
選ばれていないインスタンスは待機し、リーダーに障害が起きた場合に引き継ぎます。

可用性の全体像

５．コンポーネントごとの可用性の考え方

API Serverの可用性

API Serverは、複数のコントロールプレーンノード上で冗長稼働します。
利用者やコンポーネントからのAPIリクエストは、ロードバランサによって各API Serverへ振り分けられます。

そのため、1台のコントロールプレーンノードに障害が起きても、他のAPI Serverが応答を継続できます。

etcdの可用性

etcdは、複数メンバーで構成され、データを複製します。

3メンバー構成の場合、2メンバーが生存していればクォーラムを維持できます。
クォーラムを維持できている間は、クラスタ状態の読み書きを継続できます。

逆に、3メンバー中2メンバーが停止すると、過半数を失います。
この場合、データの不整合を防ぐため、etcdは更新を確定できなくなります。

Schedulerの可用性

Schedulerは複数インスタンスで起動できます。
ただし、複数のSchedulerが同時に同じPodの配置を決めると混乱するため、リーダー選出によってアクティブなインスタンスを決めます。

アクティブなSchedulerに障害が発生した場合は、別のインスタンスがリーダーとなり、処理を引き継ぎます。

Controller Managerの可用性

Controller Managerも複数インスタンスで起動できます。
Schedulerと同じく、リーダー選出によってアクティブなインスタンスを決めます。

Controller Managerが長時間正常に動作しないと、Podの再作成やNode障害時の調整に影響が出ます。

６．障害時の影響をどう考えるか

6-1. コントロールプレーン1台障害

3台中1台のコントロールプレーンノードが停止した場合、通常は想定内の障害として扱えます。

API Serverは残りのノードで応答できます。
etcdも3メンバー中2メンバーが残っていれば、クォーラムを維持できます。
SchedulerやController Managerも、必要に応じて別インスタンスへリーダーが切り替わります。

ただし、残ったノードへの負荷増加は増えるため、1台障害時の性能や復旧手順は事前に確認しておく必要があります。

6-2. コントロールプレーン2台障害

3台中2台のコントロールプレーンノードが停止すると、影響は大きくなります。

特に問題になるのが、etcdのクォーラム喪失です。
3メンバー構成のetcdでは、2メンバーが必要です。1メンバーだけになると過半数を満たせません。

この状態では、クラスタ状態の更新が難しくなります。

既にWorker Node上で動いているPodは、コントロールプレーン障害だけで即停止するとは限りません。

しかし、新しいPodの作成、障害時の再配置、設定変更、Operatorによる再調整などは大きく影響を受けます。

７．ワーカー障害とコントロールプレーン障害は別物

ワーカー障害とコントロールプレーン障害は、影響する場所が異なります。

ワーカー障害

ワーカー障害は、アプリケーションの実行基盤に関わる障害です。

たとえば、Worker Nodeが1台停止すると、そのNode上で動いていたPodに影響が出ます。
Replica数やPodの分散設計が適切であれば、別のWorker NodeにPodを再配置して吸収できる可能性があります。

コントロールプレーン障害

コントロールプレーン障害は、クラスタの管理・制御能力に関わる障害です。

既存のPodがすぐに停止しなくても、新規デプロイ、スケール変更、障害時の再調整などが難しくなります。
つまり、アプリケーションの実行そのものよりも、クラスタを変更・復旧する力に影響します。

８．OpenShift運用で確認したいポイント

コントロールプレーンは製品機能だけで成り立つものではなく、運用設計も重要です。

設計・運用のチェックポイント

• 単一障害点の排除
• パッチ／アップグレード時の可用性確認
• バックアップ／リストア手順の検証
• 監視と障害訓練
• DR / BCPを見据えた構成整備
• 認証、Ingress、DNS、LB、ネットワーク、ストレージの周辺設計

アップデート時の考え方

OpenShiftはローリングにコンポーネント更新を行い、Operator主導で整合性を保ちながら進めます。
ただし、事前に確認すべき点もあります。

• クラスタ健全性の確認
• 依存コンポーネントの互換性確認
• 監視アラートの確認
• メンテナンス計画の明確化

９．まとめ

OpenShiftのコントロールプレーンは、クラスタ全体を管理する中枢です。

主なコンポーネント

• API Server：操作の入口
• etcd：状態情報の保存先
• Scheduler：Podの配置先を決定するコンポーネント
• Controller Manager：現在の状態をあるべき状態へ近づけるコンポーネント
• Operator：OpenShiftの構成管理や監視、再調整を支える仕組み

可用性の観点では、一般的に3台のコントロールプレーン構成を取り、API Serverの冗長化、etcdのクォーラム、Scheduler / Controller Managerのリーダー選出によって継続性を確保します。

ただし、可用性はOpenShiftを導入しただけで自動的に完成するものではありません。

ノード配置、ロードバランサ、周辺コンポーネント、バックアップ、障害訓練、アップデート手順まで含めて設計する必要があります。

コントロールプレーンの役割を理解しておくと、障害時に「どこで何が止まっているのか」を切り分けやすくなります。

OpenShiftを安定して運用するためにも、まずはAPI Server、etcd、Scheduler、Controller Managerの役割と関係性を押さえておくことが大切です。

参考文献

1.Red Hat Documentation「第6章 コントロールプレーンアーキテクチャー」

https://docs.redhat.com/ja/documentation/openshift_container_platform/4.21/html/architecture/

2.Kubernetes Documentation 「Kubernetesのコンポーネント」

https://kubernetes.io/docs/concepts/overview/components/

3.etcd Documentation「 Frequently Asked Questions | etcd」

https://etcd.io/docs/v3.3/faq/