KRM を使用したプラットフォームの構築: パート 3 - Kubernetes アプリ開発の簡素化

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

この投稿は、Kubernetes Resource Model に関するシリーズのパート 3 です。詳細については、パート 1 と 2 をご参照ください。

前回の投稿では、Kubernetes とその宣言型のリソースモデルが強固なプラットフォームの基盤となる仕組みについてご紹介しました。ただ、Kubernetes Resource Model は強力ではあるものの、数十ものコアとなる Kubernetes API リソースが、Deployments や StatefulSets から ConfigMaps や Services まであるため、学ぶのが大変だと思われるかもしれません。さらに、それぞれに固有の機能、フィールド、構文もあります。

組織の中には、プラットフォームの統合を行うチームなど、Kubernetes デベロッパーの外部連携について知る必要があるチームがあるかもしれません。しかしそれ以外の、アプリケーション デベロッパーなどのチームは、生産性を高めるために Kubernetes のすべてを学ぶ必要はありません。適切な抽象化を行うことで、デベロッパーは Kubernetes プラットフォームをより簡単に操作できるようになり、結果として手間が減り、機能開発のスピードが向上します。

プラットフォームの抽象化とは何でしょうか？これは、必要な機能以外の詳細を隠す方法です。特定の詳細を取り除くことで、抽象化は新たな可能性を広げ、組織にとって意味のあるコンセプトやオブジェクトを作成できます。たとえば、1 つのサービスのすべての Kubernetes のリソースを 1 つの「アプリケーション」のコンセプトにまとめたり、複数の Kubernetes クラスタを 1 つの「環境」にまとめたりできます。

Kubernetes プラットフォームを抽象化する方法は、カスタムの UI やコマンドライン ツール、IDE との統合まで多数あります。組織の抽象化のニーズは、Kubernetes をどれくらいデベロッパーに公開するかによって異なります。これは、多くの場合、使いやすさと柔軟性がトレードオフの関係になります。さらに、これらの抽象化の設定（および維持）に充てることができるエンジニアリング リソースによっても異なります。すべての組織に自社のプラットフォーム チームがあるわけではありません。

では、何から始めるべきでしょうか？すでに Kubernetes 環境にコードを公開している場合、抽象化についてブレインストーミングする方法の一つとして、既存のソフトウェア開発ライフサイクルを調査するという方法があります。組織内のアプリ デベロッパーに、どのようにプラットフォームを利用しているのか、どのようにコードをテストし、ステージングしているのか、どのように Kubernetes 構成を扱っているのか、デベロッパーが抱える課題は何かなど、さまざまなことを質問してください。

質問することで、具体的な問題を念頭に置き、クラウドネイティブ環境の多岐にわたる事項について検討できるようになります。この投稿では、わかりやすい Kubernetes ツールを使用したエンドツーエンドの開発ワークフローをご紹介します。

kustomize を使用したデベロッパーのブートストラップ

あなたは Cymbal Bank の新しいフロントエンド開発者であるとします。あなたの仕事は、お客様が銀行口座を作り、取引を実行できる公開ウェブ アプリケーションを構築し、維持することです。日々の仕事のほとんどは、Python や HTML フロントエンドの機能の変更や追加を行い、これらの機能をテストし、ソースコード リポジトリ内に pull リクエストを作成することです。あなたは前職では別のプラットフォームを使用していたため、Kubernetes にはあまり馴染みがありませんが、開発用の GKE クラスタを利用できると言われました。どうすればよいでしょうか。

アプリケーションのデベロッパーは、基盤となるインフラストラクチャではなく、ソースコードに集中できることが理想的です。アプリ デベロッパーが、Kubernetes のリソース ファイルの書き込みや編集をすることなく、開発中のコードをテストできる抽象化を導入してみましょう。これには kustomize というオープンソースのツールが役立ちます。

kustomize は、Kubernetes リソースのグループを「カスタマイズ」することで、リソース マニフェストを重複させることなく、異なる種類の構成を維持することを容易にします。kustomize の 2 つの基本コンセプトは、ベースとオーバーレイです。ベースとは、Deployment や Service など、1 つ以上の Kubernetes リソースを含むディレクトリのことです。ベースのリソースは、完全かつ有効な KRM であり、そのままクラスタにデプロイできます。オーバーレイとは、1 つ以上のベースにパッチを当ててカスタマイズを行うためのディレクトリのことです。オーバーレイには、ベース内のリソースの変更や、オーバーレイ ディレクトリで定義された追加のリソースを含めることができます。複数のオーバーレイを同じベースで使用できます。これにより、同じ Kubernetes リソースを基盤とする開発、ステージング、本番環境を別々に用意できます。

実際に見てみましょう。この cymbalbank-app-config リポジトリには、Cymbal Bank アプリ向けの kustomize リソースが含まれています。このリポジトリには、ベースとなる KRM リソースのセットが 1 つ含まれています。このセットには、各 Cymbal Bank のサービスに対応する Deployment、Service、ConfigMaps の完全な YAML ファイルが含まれています。また、リポジトリには、「dev」と「prod」という 2 つのオーバーレイ ディレクトリもあります。開発用オーバーレイは、デバッグレベルのログを有効にするなど、ベースのリソースの特定のフィールドをカスタマイズします。本番環境用オーバーレイでは、デフォルトの「info」レベルのロギングを保持しつつ、フロントエンドのレプリカの数を増やし、本番環境のトラフィックにより適切に対応できるように、さまざまなカスタマイズが追加されます。

すべての kustomize ディレクトリには、kustomization.yaml という特別なファイルが 1 つ含まれます。このファイルは、何をどのようにデプロイすべきかが示されています。たとえば、以下に示す開発用オーバーレイの kustomization.yaml ファイルは、どのベースを使用するかを定義し、ベースに対して適用するすべての「パッチ」ファイルを指定します。パッチファイルは不完全な Kubernetes リソースで、対応するベースのリソースの特定の構成部分を変更します。

一連のビルド済みの Kubernetes リソースを開発に特化したオーバーレイとともに使用することで、プラットフォーム チームは新しい Kubernetes ユーザーが YAML ファイルの作成や編集の必要なしにブートストラップできるようサポートできます。また、kustomize はコマンドライン ツールの kubectl とのネイティブ統合を備えているため、デベロッパーは「kubectl apply -k」を使用してそれらのリソースをテストクラスタに直接適用できます。

さらに、この kustomize 環境で、アプリ デベロッパーが IDE から開発 GKE クラスタに直接デプロイできるようにすることも可能です。その方法を見てみましょう。

Cloud Code を使用したアプリケーション機能のテスト

Cloud Code は、デベロッパーが IDE（VSCode または IntelliJ）から離れる必要なく、Google Cloud インフラストラクチャ上で構築を行えるようにするためのツールです。これにより、デベロッパーは GKE クラスタに直接デプロイできるようになります。また、Kubernetes リソースの YAML lint チェックのような便利な機能も利用できます。

フロントエンドのアプリ デベロッパーが、ログインページに新しい HTML を追加したとします。「開発用」kustomize オーバーレイを使用して GKE クラスタにデプロイするにはどうすればよいでしょうか？

Cloud Code では、skaffold というツールによってこれを簡単に実現できます。skaffold は、ソースコードを自動的にビルドして Kubernetes にデプロイできるオープンソースのツールで、一度に複数のコンテナに対応します。kustomize と同様に、skaffold.yaml という YAML 構成ファイルを定義することで、skaffold を使用できます。このファイルには、すべてのソースコードの配置場所とそのビルド方法が指定されています。以下に示す Cymbal Bank の skaffold ファイルは、dev、staging、prod の 3 つのプロファイルで構成されており、それぞれ異なる kustomize オーバーレイを使用するように設定されています。

Cloud Code は skaffold と緊密に統合されているため、IDE 内で [Run on Kubernetes] をクリックし、「dev」プロファイルを指定すると、Cloud Code は skaffold.yaml 構成を読み取り、ローカルのソースコードをコンテナ内にビルドし、これらのコンテナをイメージ レジストリに push した後、kustomize dev オーバーレイ内の YAML リソースを使用してこれらのイメージを Kubernetes クラスタにデプロイします。このようにして、フロントエンドのデベロッパーは、kubectl またはコマンドライン ツールを必要とすることなく、ワンクリックでローカルのコード変更をテストできます。

Cloud Build を使用したステージングから本番環境までの操作

では、フロントエンドのデベロッパーが機能の実装とテストを完了し、git に pull リクエストをする準備ができたとしましょう。ここで、継続的インテグレーションの出番です。これは、本番環境に実装する前に機能の動作を確認するためのあらゆるテストやチェックのことを指します。Google では、ローカルでの開発の場合と同様に、コード レビューアが手動でコンテナを構築したり、YAML ファイルを扱ったりする必要なしに、本番同様の環境でこの機能を検証できるようにしたいと考えています。

skaffold には、CI / CD パイプラインの中で実行でき、pull リクエストからコンテナ イメージを自動的にビルドし、ステージング クラスタにデプロイできるという大きな特長があります。詳細を見てみましょう。

Cymbal Bank のソース リポジトリをリッスンする Cloud Build トリガーを定義します。新しい pull リクエストが作成されると、Cloud Build は「skaffold run」コマンドを含むパイプラインを実行します。このコマンドは、pull リクエストのコードをビルドし、本番環境の kustomize オーバーレイを使用して、ステージング GKE クラスタにコンテナをデプロイします。これにより、pull リクエストの作成者とレビューアの両方が、本番環境で使用されるのと同じ構成のライブの Kubernetes 環境で、コードが実際に動作するのを確認できます。

次に、2 つ目の Cloud Build トリガーを定義します。このトリガーは、pull リクエストが承認されたときに実行され、ソースコード リポジトリのメインブランチに統合されます。このパイプラインでは、リリース イメージをビルドして Container Registry に push してから、本番環境の Deployment リソースを更新して、新しいリリース イメージタグで使用できるようにします。ここでは 2 つのリポジトリを使用していることに注目してください。「App Source Repo」にはソースコード、Dockerfile、skaffold.yaml ファイルが含まれており、「App Config Repo」には Kubernetes リソース ファイルと kustomize オーバーレイが含まれています。そのため、App Source Repo で新しい commit が発生すると、継続的インテグレーションのパイプラインは新しいイメージタグで App Config Repo を自動的に更新します。

リリースビルドが完了すると、Cloud Build で実行されている継続的デプロイのパイプラインがトリガーされ、新しいリリース イメージで構成された本番環境用のリリース オーバーレイが本番環境用の GKE クラスタにデプロイされます。

ここでは、skaffold と Cloud Build により、Cymbal Bank のソースコードのステージング プロセスとデプロイ プロセスを完全に自動化しました。そのため、コードを本番環境に移行させるために手動で行う唯一の操作は、変更承認でした。アプリ デベロッパーが環境内のあらゆるクラスタの詳細を気にする必要はありませんでした。代わりに、ソースコードや機能を書くことに集中して、システム全体を操作することができました。このように、アプリ デベロッパーは、KRM に直接触れることなく KRM を扱うことができます。これは、kustomize や Cloud Code などの抽象化を追加することで実現しました。

この投稿でご紹介したのは、Kubernetes 上でビルドできる抽象化の種類のうちのほんのわずかにすぎませんが、これから始めるにあたってのヒントになれば幸いです。ご自身でお試しになる場合は、パート 3 のデモをご確認ください。

次回の投稿では、Kubernetes プラットフォームの管理と、Kubernetes Resource Model を使用して組織全体のポリシーの定義と適用を行う方法についてご説明します。