KRM を使用したプラットフォームの構築: パート 5 - Kubernetes によるホストされたリソースの管理
Google Cloud Japan Team
※この投稿は米国時間 2021 年 7 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。
この投稿は、Kubernetes Resource Model に関するシリーズの最後となるパート 5 です。これまでの内容については、パート 1、2、3、4 をご参照ください。
シリーズのパート 2 で、Kubernetes Resource Model の仕組みと、望ましいリソースの状態と現在の状態を Kubernetes のコントロール プレーンがどのように一致させるかについて学習しました。
「現在のリソースの状態」が Kubernetes の世界の内側に存在していたこれまでは、たとえば Pod などはクラスタ内のノード上で動作していました。ただし、そのリソースがクラウド プロバイダに依存する主要な Kubernetes コア リソースである場合は例外です。たとえば、ロードバランサ タイプの GKE Service は Google Cloud のネットワーク ロードバランサに依存します。そして GKE には Google Cloud 固有のコントローラがあり、これがユーザーの代わりにリソースをスピンアップします。
ただし Kubernetes プラットフォームを運用中の場合は、リソースが完全に Kubernetes の外に存在すると考えられます。また CI / CD トリガーや IAM ポリシー、ファイアウォール ルール、データベースがある場合もあります。このシリーズの最初の投稿で、下の図のようなプラットフォームを紹介し、「Kubernetes はプラットフォームの大部分を管理する強力な宣言型コントロール プレーンになり得る」と述べました。Google Cloud にホストされたリソースを Kubernetes Resource Model を使用して設定およびプロビジョニングする方法を解説して、このシリーズをまとめることにしましょう。
ホストされたリソースに KRM を使用する理由
クラウドにホストされたリソースに対して「どの」KRM を「どのように」使用するかについて説明する前に、まず「なぜ」KRM を使用するかを説明しましょう。クラウドにホストされたリソースを管理できるものとしては、Terraform などの Infrastructure as Code ツールのエコシステムがすでに活用されています。では、クラスタの境界の外側でのリソースの管理に KRM を使用するのはなぜでしょうか。
理由は大きく分けて 3 つあります。1 つ目は整合性です。前回の投稿で、複数の Kubernetes クラスタの整合性を保証する方法について考察しました。では、Kubernetes リソースとクラウド リソースの間の整合性についてはどうでしょうか。Kubernetes リソースに適用したい組織規模のポリシーがある場合、ホストされたリソースにまつわるポリシーもおそらくあるでしょう。そのため、KRM でクラウド リソースを管理する理由のひとつは、インフラストラクチャのツールチェーンを標準化することです。それによって Kubernetes とクラウド リソースの設定を、1 つの言語（YAML）、1 つの Git config リポジトリ、1 つのポリシー適用メカニズムに統一します。
2 つ目の理由は、継続的に調整が行われることです。Kubernetes の大きなメリットのひとつに、制御ループ アーキテクチャがあります。そのため、ホストされたファイアウォール ルールを KRM を使用してデプロイすると、Kubernetes が常時動作するため、リソースが常に（手動で削除された場合も）クラウド プロバイダにデプロイされるようになります。
ホストされたリソースに KRM を使用する 3 つ目の理由は、ホストされたリソース仕様に kustomize などのツールを統合できるため、テンプレート言語なしでもリソース仕様をカスタマイズできます。
これらのメリットの結果として生まれたのが、クラウドにホストされたリソースを管理するために設計された KRM ツールの新しいエコシステム（Crossplane プロジェクトなど）や、AWS、Azure、Google Cloud の自社製ツールです。
Google Cloud の Config Connector を使用して GCP にホストされたリソースを KRM で管理する方法について、詳しく見てみましょう。
Config Connector の概要
Config Connector は、Kubernetes Resource Model による Google Cloud リソースの管理に特化したツールです。Config Connector は、GCP に固有の一連のリソース コントローラを GKE クラスタにインストールし、それと同時に Cloud DNS から Pub/Sub へ Google Cloud プロダクト用の一連の Kubernetes カスタム リソースをインストールすることで動作します。
仕組みを説明しましょう。Cymbal Bank のセキュリティ管理者が、Policy Controller の制約の管理とテストのため、プラットフォーム チームともっと緊密に連携したいと考えたとします。しかしプラットフォーム チームには、チームが使用するオペレーティング システムである Linux マシンへのアクセス権がありません。
この問題は、プラットフォーム チームが Google Compute Engine（GCE）の Linux インスタンスをセキュリティ管理者用に手動で設定することで対処できます。しかし Config Connector を使用すれば、GCE のインスタンス用に宣言型の KRM リソースを作成し、Config リポジトリにそのリソースを commit することで、プラットフォーム チームが手動で設定しなくても、Config Connector がチームの代わりにインスタンスをスピンアップできます。
宣言型のリソースとはどのようなものでしょうか。Config Connector リソースは、単なる標準の Kubernetes 形式の YAML ファイルです。このケースでは、コンピューティング インスタンスというカスタム リソースになります。リソース仕様の中で、プラットフォーム チームは特定のフィールド（使用する GCE マシンタイプなど）を定義することが可能です。
プラットフォーム チームがこのリソースを Config Sync リポジトリに commit すると、Config Sync がリソースを Cymbal の管理者の GKE クラスタにデプロイし、同じクラスタ上で動作する Config Connector がファイル内に示される GCE リソースをスピンアップします。
クラウド リソースに対するこの KRM ワークフローにより、強力な自動化への道が開けます。たとえば、Cymbal Bank という組織内でリソース リクエストを自動化するカスタムの UI などです。
Config Connector と Policy Controller の統合
Config Connector を使用して、Google Cloud にホストされたリソースを KRM として管理することにより、クラウド リソースと Kubernetes リソース全体にガードレールを適用する Policy Controller を導入することが可能になります。
たとえば、Cymbal Bank のデータ分析チームが BigQuery の導入を開始しようとしているとします。セキュリティ チームからは BigQuery の本番環境での使用を承認されていますが、プラットフォーム チームでは実際の顧客データが一切インポートされないようにしたいと考えています。Config Connector と Policy Controller を併用することで、Cymbal Bank 内に BigQuery を使用するためのガードレールを設置できます。
Config Connector は、ジョブ、データセット、テーブルなどの BigQuery リソースをサポートしています。プラットフォーム チームは分析チームと協力し、仮のデータを含むテスト用のデータセットを KRM と定義して、そのリソースを GCEインスタンス リソースで行ったとおりに Config Sync リポジトリに push できます。
ここから、プラットフォーム チームが Policy Controller 用にカスタムの制約テンプレートを作成できます。その際、以下のようにして、Cymbal のデータセットを、事前に用意した仮のデータセットのみに制限します。
これらのガードレールを IAM と組み合わせることで、特定のリソースを設定できる人物だけでなく、そのリソースの中で容認されるフィールド値を定義できるため、新しいクラウド プロダクトを安全に導入できるようになります。
Config Connector を使用した既存の GCP リソースの管理
Config Connector の便利な特長としてはその他に、既存の Google Cloud リソースの KRM 形式へのインポートがサポートされていることがあります。そのため、実際に運用中のリソースを Config Connector の管理ドメインへ持ち込むことが可能です。
そのためには config-connector コマンドライン ツールを使用して、次のように特定のリソース URI を静的ファイルにエクスポートします。
出力:
ここから、この KRM リソースを Config リポジトリに push することで、自分の代わりに Config Sync と Config Controller にリソースのライフサイクルを管理させることができます。下のスクリーンショットは、cymbal-dev という Cloud SQL データベースに「managed-by-cnrm」というラベルがある様子を示しています。このラベルは、データベースが Config Connector から管理されていることを意味します（CNRM = cloud-native resource management）。
このリソース エクスポート用ツールは、コストをかけて既存のリソースに対する一連の YAML ファイルを新しく記述することなく、ホストされたリソースに対して KRM を試そうと考えているチームにとって特に便利です。また、Config Connector を導入して既存のリソースを大量に処理しようと考えている場合は、一括エクスポート オプションも利用可能です。
まとめると、ホストされたリソースの KRM による管理は、まだ比較的新しい枠組みである一方、リソースの整合性やポリシーの適用に多大なメリットをもたらしうるものでもあります。ぜひご自身で、Config Connector をお試しください。お試しになる場合はパート 5 のデモをご確認ください。
「KRM を使用したプラットフォームの構築」シリーズはこの投稿で最後になります。本シリーズの投稿とデモが、正しい抽象化と基本層のツールを念頭に置いた、Kubernetes を中心とするプラットフォーム構築手法のインスピレーションとなれば幸いです。
お読みいただきありがとうございました。KRM 関連の新しいプロダクトおよび新機能についての今後の情報にご注目ください。
-デベロッパー プログラム エンジニア Megan O'Keefe
