第26回『OpenShift の新機能 – Hosted Control Plane (HCP) とは』

記事をシェアする:

2023年5月に開催された Red Hat Summit 2023 に合わせる形で OpenShift の AWS上での マネージド・サービスであるROSA (Red Hat OpenShift on AWS) の  Hosted Control Plane 機能の Technology Preview のアナウンスが行われました。日本のリージョンには、まだデプロイできませんが、US等の一部のリージョンで先行して使用できるようになっており、日本からも使用は可能です。

元々、この機能は、ソフトウェアとして提供されているセルフ・マネージド版の OpenShift での Technology Preview は、既に始まっていたのですが、今回それにマネージド 版 (SREが Control Plane 等を管理するサービス) の OpenShift も加わった形になります。

1. Hosted Control Plane の歴史

Hosted Control Plane は、以前は HyperShift と呼ばれていた Project が、OpenShift の機能の一つとして正式に実装されるにあたり、名前が変更されたものです。

Hosted Control Plane の 歴史を遡ると、その発端は IBM Cloud 上のマネージド OpenShift (RHOIC: Red Hat OpenShift on IBM Cloud) に導入された HypeShift tool kit が起源になります。これは IBMと Red Hat の共同プロジェクトで、2020年4月の OpenShift 4.3 の時代にまで遡る事になります。

やがてこの Project が HyperShift として発展し、誰もが使える機能として OpenShift に実装されはじめ、Technology Preview という形で現在の Hosted Control Plane になりました。Hosted Control Plane と長いので HCP と省略される事が多いですが、機能の本質を表す呼び名になっています。

このように、Hosted Control Plane は、元々 IBM の managed の OpenShift サービスである、Red Hat OpenShift on IBM Cloud で、複数のお客様の Control Plane Node を効率良く、安全に管理するために発案された仕組みが元になっています。

Hosted Control Plane では、一つの中央管理クラスターの上に、複数の Control Plane をセキュアな方法でホストし、さらにユーザーが cluster admin (クラスター管理者）の権限を持ちながらも、そのクラスターを破壊しないような安全柵を設けた構造が特徴です。この機能を誰もが手にする事ができるようになりました。

2. 複数の Kubernetes クラスターを管理する

一般的な Kubernetes 運用環境では、本番環境以外にも、ステージング環境、開発環境、テスト環境等の複数の環境が必要になります。これらの環境を一つのクラスターの namespace 等を使って独立させて個別の独立した環境として保持するというアイディアもあります。実際、そのような手法を採用し、一つのクラスターの上で「マルチテナント」を目指す、Open Source のソリューションもこれまで幾つか作られてきています。

一方で、バージョンアップの回数がこれまでのエンタープライズ・ソフトウェアと比較しても多いのも現状の Kubernetes の特徴です。 クラスター自身のバージョンとその上で稼働するアプリケーションの関係性を考えると、それぞれの環境毎に独立したクラスターを保持し、各環境でバージョンアップを試しながら本番のバージョンを行うという運用を行いたくなります。

また、Kubernetes クラスターをミクロな視点でみると、APIや CSI / CNI 経由で、各コンポーネントが接続され、独立性を保った疎結合のアーキテクチャーになっています。が、これらはバージョン等の依存関係を持つ事があり、まとめて管理したい所です。クラシックなスタイルのネットワーク、コンピュート、ストレージが HWレベルの境界線で分かれているアーキテクチャーよりも、Kubernetes のコンポーネントの相互関係性は高くなっており、管理単位をクラスター単位にしたいモチベーションが運用視点ではでてきます。

このような背景から、複数の Kubernetes クラスターを持つケースが多くみられるようになり、それらのクラスターを効率良く管理するというのは、Kubernetes 運用環境での大きな課題の一つでした。

3. Hosted Control Plane の構造

Hosted Control Plane を解説する前に、まず標準的な OpenShift のクラスター構造を見てみましょう。以下の図のようになります。

ネットワーク構成などは、変更する事もできますが、この絵では OpenShift の一般的なインストールで行われるように、全てのコンポーネントが同一のネットワークに配置されています。Control Plane Node は、etcd というデータベースがあり、このデータベースは、障害が起きた時に多数決で正しい database を決めるために、３つの Node で冗長化されます。

管理者 (cluster-admin) ロールを持ったユーザーが、クラスターの Node の一覧を確認すると以下のように見えます。

上の三行が Control Plane Node、下の三行が Compute node になります。(見やすいように出力順を並べ替えてます）
次に、Hosted Control Plane の機能を使って作られた OpenShift クラスターの構造を見てみましょう。これは、以下の図のようになります。

管理者 (cluster-admin) ロールを持ったユーザーが、Node の一覧を表示させると以下のように見えます。

上記の一覧には表示されませんが、もちろん、これらの compute node を管理している control plane がどこかに存在しています。control plane node は、上図のネットワークの外部に存在しています。

この緑色のクラスターの cluster-admin からは見えない、control plane 部分までを含めて図示すると以下のようになります。

緑色の Compute Node の Control Plane は、Pod として紫色のクラスターの Compute Node 上に存在しています。この時、紫色のクラスターは Hosting クラスターと呼ばれます。

緑色のクラスターの cluster-admin は、自分の Control Plane の Pod 群を、サービスとして利用しているだけで、Pod として操作する事も見る事もできません。これらの Pod をリスト、操作するには、Hosting クラスター側の適切な権限が必要になります。

4. Hosted Control Plane を使って複数のクラスターをデプロイする。

今度は、Hosted Control Plane を持った複数のクラスターを管理するケースを考えて見ます。

1つ目のクラスターをデプロイしてみます。
尚、Hosted Control Plane の Control Plane の冗長度は、選択する事ができ、ここでは 1つのStatefulSet として描いています。

２つめのクラスターをデプロイしてみます。

３つ目のクラスターをデプロイしてみます。

このように、全てのクラスターの Control Plane (Pod) は、紫色のクラスター上のワークロードとして、同じクラスター上で一元管理される事になります。

Hosted Control Plane の各 Pod は、独立した project (OpenShift の namespace を拡張した概念) 内で管理されており、相互の存在を知る事はできず、セキュアに保たれています。また、Control Plane にアクセスするための Load Balancer も独立したものがデプロイされて使われるため、各 Hosted Control Plane は、独立した API Server ドメインを持ちます。

5. Hosted Control Plane がもたらすメリット

Hosted Control Plane 型の OpenShift がもたらすメリットを上げるとなると、おおよそ以下の３つになると思います。

1. Control Plane の集約化による、全体としての必要リソースの削減。
2. OpenShift クラスターのデプロイ時間の短縮。
3. Control Plane と Compute Node のネットワーク分離による OpenShift クラスター の堅牢化

一つ目は、Control Plane を集約した事でOSレイヤーを共通化する事による、必要なリソース量の削減です。
実際のユーザー環境では、様々なサイズのクラスターが存在し、Control Plane に必要とされるリソース量が異なってきます。そういった異なるリソース要件を、複数の Compute Node の上に Hosted Control Plane の Pod として上手く配置する事で、効率的な Node の使用が可能になります。

二つ目は、OpenShift クラスターのデプロイ時間の短縮です。
もちろんこれは Hosted Control Plane 型の OpenShift クラスターをホストするためのベースとなるクラスターの Compute Node が存在している事が前提になります。
Hosted Control Plane 型のクラスターでは、通常のクラスターとは違い Control Plane の Node の OS からインストールする必要がないため、デプロイ時間が短縮されます。これまで、最小構成の OpenShift クラスターで、40-50分ほどかかっていたクラスターのデプロイが、Hosted Control Plane 型クラスターでは 10-15分程度できるようになっています。
気軽に OpenShift クラスターをデプロイできるようになる事で、様々な状況で作業性の改善につながる事が予想されます。

三つ目は、Control Plane のコンポーネントが、Compute Node と側と分離される事による、クラスターの堅牢性の向上です。
Hosted Control Plane 型のクラスターでは、cluster-admin 権限をもった管理者でも、見えるのは、Compute Node だけです。Network 的にも Control Plane の存在は分離されます。そのため、cluster-admin の権限を使ったとしても、何らかの誤った操作で、Control Plane を破壊してしまうような事自体が、非常に起きにくくなっています。

多くの場合、OpenShift 上でアプリを開発してデプロイする人間と、Control Plane の保守をする人間は別になっていると思いますが、アプリの開発者でも、他の開発チームの管理や、Compute Node そのものに関わる設定を変更するために cluster-admin 権限が必要になる場合があります。そう言った場合、通常の OpenShift では、どのようにして Control Plane へのアクセスを制限しつつ、必要権限を与えるのかロール分割の設計が難しくなる事がありました。

Hosted Control Plane 型の OpenShift クラスターでは、cluster-admin をそのままアプリの開発者に渡したとしても、アプリ開発者が誤って Control Plane を破壊してしまうような事自体が難しくなっています。

6. まとめ

このように、Hosted Control Plane の機能は、OpenShift をエンタープライズレベルの Kubernetes として運用しているユーザーのニーズに応えるための新たなソリューションを提供します。

社内向けに複数の OpenShift クラスターを管理しなければいけないプロジェクトや、社外に OpenShift クラスターをマネージド・サービスとして展開している企業様においても、マルチクラスター環境をセキュアに、安定して運用できるようになるだけでなく、コスト面でもメリットが出る機能になっていますので、是非、おためし下さい。

尚、現時点で、Technology Preview となるため、Red Hat 社からは正式なサポートが無い事と、ドキュメントの更新が頻繁に起きており、リリースされているバージョンに追いついてない場合がある事をご了承ください。