概要
本記事ではROSA(Red Hat OpenShift on AWS)のClassicを普段運用している立場から、HCPを検証してみた際のTipsについてご紹介します。
OpenShiftとは？ROSAとは？については説明しませんので、Red Hat公式ドキュメントおよびAWS公式ドキュメントをご確認ください。
前提
HCPとは？
HCPとはHosted Control Planesの略で、ROSAで提供されるアーキテクチャ構成の一つです。
HCPではクラスタのマスターノード(コントロールプレーン)がRed Hatの管理となっており、利用者のAWSアカウント内にはワーカーノードしか存在しない構成になります。
EKSなどクラウドプロバイダーの提供するManaged Kubernetesを利用していると、マスターノードが利用者のアカウント内にないのは当たり前のように思われるかもしれませんが、ROSA Classicと呼ばれる構成ではマスターノード・ワーカーノード(・インフラノード)すべてが利用者のアカウント内にEC2として存在していました。
ClassicとHCPを比較すると、最小構成やUpgrade戦略などでHCPの方が優位となる点が何点かありますが、本記事では紹介しません。主な比較は以下のRed Hat公式ドキュメントをご確認ください。
検証用環境のアーキテクチャ
本記事では以下のような環境で検証を行っています。
HCPはプライベートクラスターを利用する
HCPにはコントロールプレーンへの接続のためにPublic Endpointを利用するパターンと、PrivateLinkを利用してPrivate Endpoint経由でコントロールプレーンに接続するパターン(プライベートクラスター)があります。
本記事では企業環境でROSA HCPを利用する想定でプライベートクラスターでの検証を行っています。
ROSA Workload専用のVPCを用意し、ROSAクラスタに関連しないリソースは別VPCに配置する
本検証ではROSA専用のVPCを用意し、ROSAクラスタ作成時に自動的に作成されるリソースのみをこのVPCに、それ以外のリソース(rosa cliを実行・OpenShift ConsoleへアクセスするEC2等)は別のVPCに配置しています。
これはROSA自体が多くのCIDRを要求すること(Machine CIDR, Service CIDR, Pod CIDR)*に加え、自動で多くのリソースが作成されることもあり、セキュリティ・運用効率性を鑑みてVPC単位で分離する設計としているためです。
＊CIDRについては、上記に加えクラスター内の仮想ネットワークを管理するOVN-Kubernetes用に更に追加で確保する必要があります。(VPCのCIDRとしての確保は不要ですが、他のVPCやAWSと接続されるオンプレミスのCIDRと重複しないことが求められます)
ROSAを構築する際のVPCに関する考慮点については以下を参照。
また、OVN-Kubernetesで必要となるCIDRが他VPCで利用しているCIDRと重複している場合は、以下のようにOVN-Kubernetesが利用するCIDRを変更することで問題の回避が可能です。
クラスタ構築
クラスタ構築は基本的に公式ドキュメントに従って進めればOKです。
ただし、一部の設定はクラスタ構築時にしか設定出来ず、後から変更できないので注意が必要です。
プライベートクラスターの設定についてもクラスタ構築時にしか設定できず、後からの変更は不可です。
＊手順の中には"Terraformを使用したデフォルトのROSAクラスター作成"という章がありますが、残念ながらterraformで作成可能なのはIAMロールやVPCのみで肝心のクラスターは作成できません。アップデートを期待しましょう。
OpenShiftコンソールにアクセス出来ない
事象
ROSA HCPのクラスタを構築後、稼働確認のために管理用EC2からOpenShiftコンソールにアクセスしようとしたところ、タイムアウトになりました。
原因と対応
OpenshiftコンソールのPodはControl Planeにある
Classicは同一のVPCにControl Plane(Master Node)・Woker Nodeが存在し、すべてVPC内の通信で完結するため、Control Plane上にホストされるクラスタ管理に関するPodへのアクセス・Worker Node上にホストされるユーザーアプリのPodへのアクセスについて、両者を区別して考える必要はありませんでした。
ですが、HCPの場合、Control PlaneはVPCの外側に存在するため、クラスタ管理に関するPodへのアクセスはVPC Endpoint経由でのアクセスとなります。
そして、OpenShiftコンソール(Webコンソール)のPodはControl Plane側に存在するのでした。
Web コンソールは、openshift-console プロジェクトのコントロールプレーンノードで Pod として実行されます。これは console-operator Pod によって管理されます。
今回はWebコンソールのアクセスで気がつきましたが、Webコンソールに限らず何のコンポーネントがControl Planeに配置されるのかを気にかけておくようにしましょう。
以下のドキュメントは何のコンポーネントがControl Plane側に配置されるかが記載されています。ただし、HCPを完全にサポートしているわけではに点に注意してください。
This control plane architecture is not supported on Red Hat OpenShift Service on AWS (ROSA) with hosted control planes (HCP).
Classicでは、非推奨ながらクラスタ内のetcdを参照することで何のリソースが存在するのか確認することが出来ました(Control PlaneのNode内にバックアップスクリプトが配置されていた)が、残念ながらHCPではこれは出来なくなりました。
VPCエンドポイントのセキュリティグループ
例えControl Plane側にWebコンソールのPodが存在していたとしても、VPCエンドポイント経由で接続出来るはずなのですが、今回は別VPCに存在するEC2からWebコンソールにアクセスを試みていたのが問題でした。
VPCエンドポイントはROSA HCPクラスタを作成する際に自動で作成されますが、このVPCエンドポイントにはROSAクラスタが存在するVPCにソースを限定したセキュリティグループがアタッチされています。
そのため、このポリシーにより別VPCのEC2からの通信が阻まれていたのでした。
対応としては以下の公式ドキュメントの通りで、セキュリティグループで経路を空けてあげることで通信が可能となります。
ただし、ROSAクラスタ作成時に自動で作られるセキュリティグループを編集しないようにすること・サポートされるバージョンには注意してください。
デフォルトの AWS PrivateLink エンドポイントセキュリティーグループの変更または削除はサポートされておらず、予期しない動作が発生する可能性があります。
AWS PrivateLink エンドポイントへの追加の AWS セキュリティーグループの追加は、ROSA with HCP バージョン 4.17.2 以降でのみサポートされます。
Route53 Private HostZone
セキュリティグループをアタッチすることでネットワークの経路はOKになりましたが、別VPCからWebコンソールにアクセスするには名前解決についても対処が必要です。
ROSAのWebコンソールはROSAクラスタ標準のドメインで公開されており、このドメインを管理するRoute53 Private HostZoneもやはりROSAクラスタが存在するVPCのみと関連付けられています。
そのため、管理用EC2の存在するVPCにもHostZoneの関連付けを行うことで名前解決出来るようになります。
また、Route53だけでなくVPCエンドポイントとも関連しますが、管理用EC2が存在するVPCにVPCエンドポイントを作成することでも対応が可能です。
大規模な環境などでVPCエンドポイントを集約するアカウントが存在する場合は、そのアカウントにVPCエンドポイントを作成するほうがコスト効率・運用効率の観点では良いように思います。
Auditログを取得できない
事象
OpenShiftではアプリケーションログ・インフラログ・監査ログ(Auditログ)の3種類のログが出力され、OpenShift Logging OperatorによりこれらのログをCloudWatch Logsや対応するログストアに転送することが出来るのですが、HCPではAuditログの出力が出来ませんでした。
原因と対応
AuditログはControl Planeに保管される
OpenShift Loggingはログ転送用のPod(OpenShift Logging v5.9まではFluentd, v6.0以降はVector)が各ノードに1台ずつ配置され、各ノードに保管されたログを転送する仕組みです。
ClassicではControl Planeに対してもPodの配置が可能なため、Control Planeにしか保管されないAuditログについても転送が可能でした。
しかし、HCPではControl PlaneはRed Hat側のAWSアカウントで集中管理されるため、そもそもユーザーがPodをスケジュールすることも・ノードにアクセスしてログを覗くことも出来ないのでした。
＊これはEKSなどCloud Providerが提供するManaged Kubernetesを利用している方にとっては当たり前(と思われるの)ですが、Control PlaneがEC2として見えているROSA Classicとは大きなギャップがあります。
Control PlaneのEC2が見える前提で監視などが実装されている場合は、HCPに移行する前に監視構成の再考が必要です。
(監視だけでなく、daemonsetsで展開する3rd Party製品のAgentなどについても考慮が必要)
HCPでのAuditログ出力にはClassicと異なる設定が必要
HCPでのAuditログの取得については別の仕組みが用意されており、Red Hatの公式ドキュメントとして公開されています。
(何故かROSAのドキュメント本体ではなく、ナレッジベースの一記事の形で公開されていますが...)
案内している内容としては簡単で、ログ転送用のIAMロールを作成し、ロール情報をocmコマンドで引き渡せばAuditログのCloudWatch Logsへの転送が可能です。
ドキュメントにはROSAクラスタの存在するアカウントにしか転送できないことが注意点として記載されていますが、こちらについてはCloudWatch Logsに転送してしまいさえすればS3バケットや他のサービスへのさらなる連携が可能ですから大した制約にはならないでしょう。
まとめ
本記事ではROSA HCPの検証結果のTipsとして、Openshiftコンソール(Webコンソール)への接続に関する問題と、Auditログの取得に関する問題を取り上げました。
ROSAを利用されている方はあまり多くないかもしれませんが、その分公開されている情報も少ないかと思いますので、この情報がどなたかのお役に立てれば幸いです。