KRM を使用したプラットフォームの構築: パート 1 - プラットフォームに必要なこと

※この投稿は米国時間 2021 年 6 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

この投稿は、Kubernetes Resource Model（KRM）を使用したデベロッパー向けプラットフォームの構築に関するシリーズのパート 1 です。

今日のデジタル世界では、企業が機能を迅速に開発して発表し、スケールアップを行い、サービス停止時には迅速に復旧させ、さらにこれらすべてを安全かつコンプライアンスに対応した方法で行うことが、これまで以上に重要になっています。もしご自分がデベロッパー、システム管理者、セキュリティ管理者であるならば、すべてを実現するにはエンジニアリング チームとオペレーション チームの間のコラボレーションと信頼の文化を含め、多くのことが必要であることをご存じでしょう。

しかしカルチャーを構築するには、単にコミュニケーションをとり、価値観を共有すればよいわけではなく、ツールも重要になります。アプリケーション デベロッパーは、コードを記述するためのツールや能力があれば、機能の構築に集中するのに十分な抽象化により、インフラストラクチャに煩わされることのない迅速な構築が可能となります。セキュリティ管理者がポリシーの作成と監査のプロセスを合理化すれば、エンジニアリング チームはセキュリティ レビューを待つことなく構築を続けられます。また、サービス オペレーターが、強力な環境間の自動化を自由に利用できるようになれば、新しいエンジニアリング チームでビジネスの成長をサポートできます。IT スタッフを増やす必要はありません。言い換えれば、高品質なコードを迅速かつ安全に提供するには、優れたデベロッパー向けプラットフォームが必要なのです。

プラットフォームとは、Git リポジトリやテストサーバーから、ファイアウォール ルールや CI / CD パイプライン、分析やモニタリングのための専用ツール、ソフトウェア自体を実行する本番環境のインフラストラクチャにいたるまで、ソフトウェア デリバリーを可能にするテクノロジーのレイヤです。  

組織が必要とするプラットフォームは、組織の業種、規模、セキュリティ要件など、さまざまな要因によって異なります。組織によっては、Google App Engine のようなフルマネージド Platform as a Service（PaaS）で十分な場合もあれば、自社のプラットフォームの構築が必要な場合もあります。Google Cloud では、その中間に位置する多くのお客様にサービスを提供しています。つまり、オールインワンの PaaS で提供される以上のカスタマイズ（およびロックインの低減）を求めながら、自社のプラットフォームをゼロから構築する時間もリソースもないというお客様です。このようなお客様は、技術的な好みや目標を確立したうえで Google Cloud を利用しています。たとえば、サーバーレスは採用したいが、サービス メッシュは採用したくない場合、あるいはその逆の場合もあります。このカテゴリに属する組織は、下の図に示すように、ホストされたインフラストラクチャとサービスを組み合わせて使用するために、Google Cloud のようなプロバイダを利用する可能性があります。

しかし、プラットフォームは単なるプロダクトの組み合わせではありません。プラットフォームはこれらのプロダクトと連携するために使用する API、UI、コマンドライン ツールであり、プロダクトを統合する接着剤として機能し、反復可能な方法で環境を構築できるようにする構成です。これまでに、一度に多くのリソースを操作したり、エンジニアリング チームに代わってリソースを管理したりしたことがあれば、さまざまなことを把握しておかなければならないことをご存じでしょう。では、プラットフォームでは他に何が必要でしょうか。

まず、プラットフォームは、ユーザーに応じて抽象化された、人間が理解しやすいものである必要があります。たとえば上の図では、アプリ デベロッパーはソースコードの記述とコミットに注力しています。下位レベルのインフラストラクチャへのアクセスは、開発環境の始動など、必要なものに限定できます。また、プラットフォームはスケーラブルでなければならず、追加のリソースは、自動化された繰り返し可能な方法で除外できる必要があります。プラットフォームは、ビジネスやテクノロジーのニーズの変化に応じて新しいプロダクトを追加できるように、拡張可能である必要があります。最後に、プラットフォームには、業界や地域固有の規制を遵守した安全性が求められます。

では、インフラストラクチャの集合体から、抽象化され、スケーラブルかつ拡張可能で、安全なプラットフォームを得るにはどうすればよいでしょうか。

上の図の中にある 1 つのプロダクトのアイコンが、Google Kubernetes Engine（GKE）です。これは、オープンソースの Kubernetes プロジェクトをベースにしたコンテナ オーケストレーション ツールです。Kubernetes は、何よりもまず「コンピューティング」ツールですが、できることはそれだけではありません。

Kubernetes の特徴は、その宣言型デザインにあります。これにより、デベロッパーはインテントを宣言し、Kubernetes コントロール プレーンは「それを実現する」ためのアクションを起こすことができます。Kubernetes Resource Model（KRM）は、Kubernetes API と通信するために使用される宣言形式です。多くの場合、KRM は以下に示すファイルのように YAML で表現されます。

すでにご存じの方もいるかもしれませんが、上のような Deployment リソースに対して「kubectl apply」を実行すると、Kubernetes は Pod 内のコンテナをデプロイし、クラスタ内のノードにスケジューリングします。また、Pod を手動で削除しようとしても、Kubernetes のコントロール プレーンが Pod を復活させます。これは、「helloworld」コンテナを 3 つコピーするというインテントが引き続き機能しているからです。Kubernetes には、ユーザーのインテントとリソースの実行状態を、一度だけでなく、継続的に一致させる役割があります。  

では、これはプラットフォームや上の図にあるその他のプロダクトとどう関係するのでしょうか。コンテナのデプロイやスケーリングは、Kubernetes のコントロール プレーンができることのほんの一部にすぎません。Kubernetes には、コアとなる API のセットがありますが、これは拡張可能でもあり、デベロッパーやプロバイダは自身のリソース、さらにはクラスタの外に存在するリソースに対しても Kubernetes コントローラを構築できます。実際、上の図の Google Cloud プロダクトは、Cloud SQL から IAM やファイアウォール ルールまで、そのほぼすべてを Kubernetes スタイルの YAML で管理できます。これにより、組織はこれらの異なるプラットフォームの管理を、1 つの構成言語と 1 つの調整エンジンに集約して簡素化できます。また、KRM は OpenAPI をベースとしているため、デベロッパーは KRM をデベロッパー向けに抽象化し、その上にツールや UI を構築できます。

さらに、KRM は一般的に YAML ファイルで表現されるため、ユーザーは KRM を Git に保存し、一度に複数のクラスタに同期させることができます。これにより、簡単にスケールできるだけでなく、再現性、信頼性、管理の強化が可能になります。KRM ツールにより、セキュリティ ポリシーが手動で削除されてしまっても、クラスタ上に常に存在するようにすることができます。

要するに、Kubernetes はプラットフォーム図の中の単なる「コンピューティング」ブロックではなく、プラットフォームの大部分を管理する強力な宣言型コントロール プレーンにもなり得るのです。最終的に、ユーザーは KRM を使うことで、ソフトウェアを迅速かつ安全に提供可能なデベロッパー向けプラットフォームの実現に大きく近づくことができます。

このシリーズの後続パートでは、Kubernetes リソースモデルを使ってプラットフォームを構築する方法を、デモを伴う具体的な例を使ってご紹介します。GitHub リポジトリにアクセスして、Part 1 - Setup を実行してください。お使いの Google Cloud プロジェクトでサンプル GKE 環境が立ち上がります。

パート 2 では、Kubernetes Resource Model の仕組みを紹介します。

-デベロッパー プログラム エンジニア Megan O'Keefe