はじめに
はじめまして、Red HatでOpenShift Container Platformのテクニカルサポートの野間です。OpenShift Advent Calendar 2024 の12/19の記事ですが、遅れてしまいました。申し訳ありません。
本日はOpenShift Container Platformでサポートされるノード構成について、現在の情報を整理してお伝えします。というのも、リリースから5年の進化をとげ、選択できる構成が格段に増えました。これにより、初学者にとって「結局、何台のサーバー（インスタンス）が必要なのか」が製品ドキュメントから理解しづらくなったと思います。
control plane/compute node と master/worker node の表記について
これも今更なのですが本題の前に少し補足させてください。OpenShiftもしくはkubernetesではnodeの種類として、control planeとmaster nodeもしくはcomputeとworker nodeが同じように使われています。これは大人の事情で、表記を置き換えたためです。意味は全く同様で、現在はcontrol plane/compute nodeを使用するのが正しいです。ただし、古い表記はドキュメントやソースに根深く存在し、今も混在した表記が散見されます。混乱しないように脳内で置き換えてください。
旧
- master node
- worker node
現在
- control plane node
- compute node
それではノード構成について解説します。
基本の構成
control plane node [3-5]台 + compute node n台(n≧2)
まずは基本のキの構成です。control plane 3台以上と、compute node2台以上です。
control plane nodeはクラスタ全体のステータスを管理をするnodeであり、それを構成するコンポーネントはいくつかあるのですが、特に台数に関連しているのは、分散key valueストアであるetcdです。etcdはRAFTと呼ばれる、メンバーがリーダーを多数決で選出するアルゴリズムを採用しており、耐障害性をもつ最小構成が3ノードです。そのため、基本のcontrol plane node は3台なのですね。
しかしながら、OpenShift4.17から、bare metalプラットフォームでetcdを5台までスケールさせる機能がリリースされました。4.17以上であれば、control plane は4台もしくは5台でも構成可能です。ただし、ドキュメントによると、3台構成と4台構成のFailure toleranceはいずれも1です。つまり3台中1台まで故障可能と、4台中1台まで故障可能という意味になり、ノード台数と故障率も考慮すると可用性は3台構成のほうが高い計算になります。正直、4台構成は積極的に使用するメリットは見つかりません。5台構成にするための段階的なステップぐらいでしょうか。
compute nodeは、ユーザーワークロードコンテナを稼動させるノードです。ですのでユーザーのワークロードにあわせて好きな台数を揃えてください。2台以上となっているのは、やはり耐障害性のためです。実際はユーザーワークロードコンテナだけでなく、Ingress Operator や Cluster Monitoring Operator といったOpenShiftのOperatorが管理するPodも稼動するのですが、これらは耐障害性のため2台以上のcompute nodeが前提で開発されています。
control plane node [3-5]台 + compute node n台(n≧2) + infrastructure node(n≧3)
前述の構成にオプションでinfrastructure nodeを加えることができます。infrastructure nodeは、デフォルトではクラスタのcompute node上で動くinfrastructureのコンポーネント(前述のIngress Operator や Cluster Monitoring Operatorなど)を専用として配置するノードです。利点としてはinfrastructure nodeはcontrol plane nodeと同様でsubscriptionを必要としません。そのため、役割をユーザーワークロードに集中させたcompute nodeにのみsubscriptionがかかります。台数についてはドキュメントを確認すると、推奨が3台以上となってますね。
three-node cluster
上記の基本構成は最低が5台からなので、少しとっつきにくい感じがしますね。そんなニーズに対応したのか、three-node clusterという構成があります。どのようにしているかタネをあかすと、control plane node 3台にワークロードも稼動しているだけです。つまり実態は(control plane nodeかつcompute node) × 3ということですね。ただし、サブスクリプションはcompute nodeとして使っている分だけー！とはいかず全体にかかります。ここら辺は去年のAdvent Calendarで宇都宮さんが3ノードクラスタのすゝめで記事にしてくださっています。
single node OpenShift(SNO)
SNO 1台
3台でも多いでしょう！という方のために、single node OpenShift(SNO)と呼称される1台構成もあります。可用性を考慮しなければetcdも1ノードで構成できるので、すべてを1台に集約した構成です。もちろんノードが故障すればすべて止まります。検証用に便利で当ブログでもよくみかける、みんな大好きな構成ですね。本番環境で使うこともでき、代表的なユースケースはエッジコンピューティングです。昔は本番環境未サポートの検証用としてRed Hat CodeReady Containersという別の1台構成もあったのですが、SNOによってこちらを使用する理由はなくなりました。
SNO 1台 + compute node n台(n≦2)
なんと、単一ノード構成に compute node を追加することができます。台数少ないことがメリットじゃないんかーい！とツッコまれそうですね。追加の compute node は2台までで、追加方法も少し特殊となります。追加しても1台のSNOがトラフィックを受けるため、Single point of failureは変わりません。ポコポコ増やしたら他のクラスタ構成と同等になるというわけでなく、あくまでSNO構成環境の延長という、限定されたユースケースでの利用が想定されます。
Hosted Control Plane (HCP)
Hosting cluster + compute node n台
ノード構成とは異なるトピックになるかもしれませんが、Hosted Control Planeという機能があります。要はcontrol plane の機能だけ別システムに集約し、管理してもらおうという機能です。この別システムはやはりOpenShiftクラスターで、Hosting clusterもしくは管理クラスターと呼ばれます。クラスターを何個もポコポコ構成するような大規模な環境で、組織的に運用管理者も権限分離したいようなユースケースでメリットがでると思います。OpenShift Advent Calendar 2024でもHCPをデプロイする記事が書かれましたので参考にしてください。
まとめ
本記事では、OpenShift Container Platformにおけるノード構成の選択肢について解説しました。ここ数年で選択可能な構成が多様化し、目的や環境に応じて柔軟な選択が可能となっています。以下に主要なポイントを簡単に振り返ります。
1.基本構成 Control plane nodeは3台以上、Compute nodeは2台以上が推奨される標準構成です。耐障害性やスケーラビリティにすぐれています。また、Infrastructure nodeを加えることで、ユーザーワークロードとクラスタ管理機能を分離できます。
2.小規模構成 Three-Node ClusterやSingle Node OpenShift (SNO)といった構成は、小規模環境や検証用途での利用に適しています。ただし、可用性の制約があるため、本番利用時はユースケースに応じた検討が必要です。
3.Hosted Control Plane (HCP) Control planeを別クラスタにホストすることで、特定の運用要件を満たす柔軟な構成も可能です。特に大規模環境での運用管理者の権限分離に効果を発揮します。
各ノード構成にはそれぞれ利点と課題があり、利用するユースケースや環境に応じた選択が重要です。本記事が、OpenShiftクラスタの設計における参考となれば幸いです。
