こんにちは。Red Hat で、ソリューションアーキテクトをしています花田です。
OpenShift Advanced Cluster Management for Kubernetes (ACM) と AWS 環境への OpenShift の超簡単新規構築！！で、岡野さんが既にご紹介してくれている ACM (Advanced Cluster Management) という製品の新バージョンが11月にリリースされ、晴れて ACM 2.1となりました。
今回は、この製品が生まれた背景と、製品の概要についてもう少し深掘りしてみたいと思います。
ACM という製品が生まれた背景
一般的には「そろそろキャズムを超えた？」言われている Kubernetes ですが、一方では、Kubernetes や、Red Hat版のKubernetesである OpenShift を使って複数のクラスターをデプロイして管理するようなヘビーユーザーも現れ始めました。
開発、ステージング、プロダクション毎に Kubernetes クラスターを用意する場合もありますし、本番クラスターを多数運用しているケースもでてきてます。
Kubernetes で言う所のクラスターとは、Master Node と呼ばれる管理ノードと、それらが管理するWorker Nodeというユーザーアプリケーション（コンテナ）が稼働する Node群をひとまとめにした概念です。
さらに、最近では、5Gの普及を見据えて「ユーザーに近い Edgeで何か処理を行う事で、新しいサービスが開始できるのでは？」という期待も生まれてきています。
Edge 環境にアプリケーションを配布するには、フットプリントの小さいコンテナの使用が期待されており、そうなると当然、全国津々浦々の Edge 環境にコンテナを動かすためのインフラであるKubernetes のクラスターを設置したい。という話がでてきます。(リモート環境に、Kubernetes クラスターを配置するのではなく、コンテナを動かす Worker Node だけを遠隔の Edge に配置するというアイディアもありますが、その話はまたどこかの機会に…)
そう言った背景もあり、Kubernetesのクラスターをたくさん管理しなければいけない時代というのが、一部では始まっている or 始まりつつある状況になっています。
Kuberentesクラスターをどのように効率的に管理するか。という問題です。例えば、数個の Kuberentes クラスターであれば、一つ一つの手作業でも運用可能と言えるでしょう。
Kuberentes クラスターの数が多ければ、その運用管理に目眩がしてくる事が予想されます。
終電で帰る事を目標にしていたら、いつのまにか始発で帰る事に目標がすり替わって、幾つもの夜を越える事になるかも知れません。
こうした状況の中で生まれてきたのが、今回ご紹介するRed Hat Advanced Cluster Management for Kubernetres、通称 ACM です。
ACM ができる事は、大まかに4つあります。
1.管理対象のクラスターの可視化
管理対象のクラスターのモニタリング機能や、管理しているリソースの検索機能等を提供しています。
Kubernetes の世界では Observability(可観測性)という単語がよく出てきますが、ここではシンプルに「可視化」と呼んでも良いでしょう。
2.クラスターのライフサイクル管理
ここで言うライフルサイクルは、クラスタの作成・削除・アップグレードを指します。OpenShiftクラスターをパブリック・クラウド・プロバイダーなどの環境に簡単にデプロイする事が可能です。
3.クラスターをまたがったアプリケーションのデプロイ
指定したクラスター、namespace等にアプリケーションを配布する事が可能です。
4.クラスターに対する統一したポリシーの適用
これは各クラスターに管理用のnamespaceを必ず作成したい、セキュリティのポリシーがあってそれを適用したい。等の要件があった時に、ポリシーを作成して対象としたい クラスターやnamespaceにデプロイしてポリシー違反を検知・修正する事ができるようになります。
どんな環境をサポートするか？
ACMは、Hub クラスターと呼ばれるクラスターから管理対象となる Kubernetes クラスターを管理します。管理対象のクラスターを Managed クラスターと呼びます。管理されるクラスターなので、受動態になって Managedクラスターです。
ACM の Hub クラスター(管理対象をまとめる「親」)のインストール先として、サポートされるのは、 Red Hat OpenShift だけになります。
ACM 自身は、 Pod の集合体ですので、他のユーザー・アプリケーションとも同居できますが、それなりにリソースを要求するため、運用も考えて、基本的には、ACM 専用の Hub クラスター を作成する事をおすすめしています。
一方で管理対象の Managed クラスター としては、OpenShift の他に、AKS、EKS、GKE等の Kubernetes もサポートしています。
これは、ACM Hub クラスター から見ると、管理は Kubernetes の APIサーバーを通したものになるものになるため、Certify された Kubernetesであれば、共通のプロトコルで話す事ができるからです。
原理的には、Kuberntes であれば、管理対象に追加できるはずですが、ACM は商用サポートを提供する製品ですので、テストが行われた正確なサポート対象というものが定義されています。
また、クラスターの作成・削除等の Kubernetes より下のインフラーレイヤーが関わる作業は、インフラを部分を提供するベンダー(パブリック・クラウド・プロバイダー/仮想化環境ベンダー/物理環境のベンダー) のAPIやサービス依存の部分があったり、クラスターの更新は Kuberntes を提供するベンダーのサービスによって独自のコンポーネントを含むものとなるため、環境によって必要な作業は異なってきます。
ACMのサポート範囲は、環境に異なる部分があるため、詳細をお知りになりたい方は、以下のリンクをご参照ください。
Red Hat Advanced Cluster Management for Kubernetes 2.1 Support Matrix
管理対象クラスターの可視化
ACMから作成されたクラスター、ACMにインポートされたクラスターはダッシュボードから一元的に確認する事ができます。
このダッシュボードでは、環境内でデプロイされているクラスターの接続状態や、Nodeの数、Pod の数、コンプライアンスの状態 etc…等が表示されています。
また、Kuberntes は、リソースというオブジェクトの集合体です。namespaceや、ConfigMap、Pod、Node、Role…と様々なリソースから構成されています。
ACMでは、環境で起きた問題や現在の設定を確認するために、これらのリソースを検索して見つけ出すDynamic Search機能を提供しています。
例えば、多数のクラスターがある環境でも、特定の cluster のある namespace に所属するPodの一覧を検索条件で指定して表示するような事がDynamic Search機能で可能になっています。
クラスターのライフサイクル管理
2つめの大きな柱の機能として「クラスターのライフサイクル管理」があります。
これは、ACM の Hub クラスターから、OpenShift クラスターを「作成」「削除」「更新」する事のできる機能です。
各クラウド・プロバイダーや仮想化環境等を操作するためのクレデンシャル情報等を事前に作成しておく必要はありますが、それができていれば、コンソール画面から Worker Node 等の本数やスペックを選択して、新規の OpenShift クラスターを簡単にデプロイする事ができます。
また、ACM 2.1 からは、vSphere 環境、Baremetal 環境への OpenShift クラスターのデプロイもサポート対象に加わりました。
これらの機能は、内部的には、OpeShift 4.6 からサポートされた vSphere 環境、Baremetal 環境への IPI(Installer-Provisioned Infrastructuer) を使用しています。IPIとはある一定の条件が整っている環境 (DNSに事前に必要なベースドメインが登録されている等。対象とする環境によって条件が異なる) であれば、OpenShift の Node OSのインストールから、その上の OpenShift ソフトウェアのインストールまでを自動化してくれるインストール方式です。
ただし、AKS、EKS、GKSと言ったクラウド・プロバイダー独自のKubernetes サービスについては、クラスターの作成等の機能はサポートされていません。これらのクラウド・プロバイダー独自の Kubernetesサービスについては、既に作成されているクラスターをインポートして、管理対象に加える事が可能です。インポート する事で「アプリケーショのデプロイ」や「ポリシーのデプロイ」を使用した管理を行う事ができるようになります。
アプリケーションのデプロイ
3つ目の大きな柱の機能として「アプリケーションのデプロイ」があります。
これはアプリケーションを定義しておき、ラベルを使用して、ラベルの条件が一致するクラスターに対してアプリケーションをデプロイする機能です。
「アプリケーションのデプロイ」では、ラベルを使用する事で、特定の namespace にだけアプリケーションをデプロイすることや、devラベルが付いている環境にだけアプリケーションをデプロイする。等のように細かくアプリケーションのデプロイ先を指定する事ができます。
これらのアプリケーションは、YAMLで定義されます。アプリケーションのパッケージングの具体的な情報(deplyment、PVC、Service等のリソース定義)は、GitHub等のレポジトリに置かれているものをアプリケーションの定義から参照する形になります。
尚、ACM 2.0を触った事がある方、向けの話になりますが、ACM 2.0では、一つのアプリケーションを作成するのに、それに紐付く「チャネル」「サブスクリプション」「デプロイメント」などのカスタム・リソースをそれぞれ作成しないといけませんでしたが、ACM 2.1ではそれらのカスタム・リソースを意識しなくても GUIの設定のみでアプリケーションを作成できるように改善されました。
ACMは、アプリケーションのチャネル (YouTube のチャネルと同じイメージです。デプロイ対象のアプリケーションのレポジトリを表します。) を常に監視しており、変更があった場合、自動的に更新されたアプリケーションのデプロイを開始します。
例えば、GitHub上で開発用のdevelopmentブランチと、本番用のproductionブランチを作成していたとします。
ACMを使用すると、devlopment ブランチに更新があった場合、developmentブランチのアプリケーションをdevクラスター にデプロイさせるように構成する事ができます。また、GitHub 上で、そのコードが production ブランチにマージされたタイミングで、prodクラスターにproductionブランチのアプリケーションをデプロイするという事も可能です。
その他にもアプリケーションをデプロイしたくない時間帯を指定したり、反対にアプリケーションをデプロイしたい時間帯を指定する事が可能になっています。
ポリシーによるガバナンスとリスク管理
4つ目の大きな柱は、ポリシーによる環境のコンプライアンス管理です。
管理者がポリシーを YAML で作成して、クラスターに配布して、ポリシーに適合している設定が行われているか確認する事ができます。
ポリシー違反や現在のポリシーの遵守情報は、ACM のダッシュボード画面に表示されます。
このポリシーの配布も、アプリケーションの配布と同じように、ラベルによってポリシーの配布対象を特定のクラスターだったり、特定のnamespace に限定する事が可能です。
またポリシーの内容にもよりますが、修正できる内容であれば、ポリシー違反があった場合に自動でポリシーに適合するように修正を行うように指定する事も可能です。
ポリシーはある程度 GUIで書くことが可能ですが、現実的には YAML でゴリゴリとポリシーを作成して行く事になると思います。
とは言え、そう言った作業を楽にするためのサンプルのポリシーが提供されており、GitHub で公開されています。これらのポリシーの一部のワードを自分の環境用に書き替える事で、簡単にポリシーの作り方を学ぶ事ができます。
ポリシーについては、製品としてバンドルされているものと、コミニティ版が存在していて、どちらもGitHub で公開されています。
実際にポリシーを使用してどのような事ができるかは、これらのサンプルを見るのが一番わかりやすいと思います。
製品にバンドルされているポリシー
コミニティ作成のポリシー
ACM の今後
ACMは、現状では OpenShift と同じで、3ヶ月毎のリリースが予定されています。
今回は、ACMの基本的な機能部分の概略だけを解説しましたが、ACM 2.1 では、Red Hatの自動化ツールであるAnsibleとの連携のTech Previewが開始されたり、統合モニタリング機能としてPrometheusで収集したデータをHubクラスターで見るためのダッシュボード、ポリシー管理の方法としてGatekeeperへの対応などが盛り込まれました。
これらについては追々解説して行きたいと思います。
