【ITニュース解説】How to Deploy Karpenter on Google Cloud

Karpenterは、Kubernetesクラスターがアプリケーションの負荷に応じて、必要な仮想マシン（ノード）の数を自動で調整する仕組みを、より効率的に行うためのツールである。これまでの自動スケーリングツールに比べて、Karpenterはアプリケーションが要求するリソース（CPUやメモリなど）に最適化されたノードを、クラウドプロバイダから直接、素早く起動できる点が大きな特徴だ。今回、そのKarpenterがGoogle Cloud Platform（GCP）に対応したプレビュー版のプロバイダをリリースした。これは、GCP上でKubernetes（Google Kubernetes Engine、GKE）を運用している、あるいはこれから運用しようと考えているシステムエンジニアにとって、ノードの管理をより柔軟かつコスト効率良く行えるようになる重要なニュースである。

Kubernetesでは、アプリケーションはPodという最小単位で実行され、これらのPodはノード上で動作する。もしアプリケーションの負荷が増大し、既存のノードのリソースだけではPodを十分に実行できなくなった場合、通常は新しいノードを追加する必要がある。Karpenterは、この新しいノードの追加を、Podがどのノードにもスケジュールできない状況を検知した際に、自動で、かつ最適なかたちで行う。たとえば、あるPodが大量のメモリを必要としている場合、Karpenterはメモリを豊富に持つGCPのインスタンスタイプを選んで起動し、そのPodを配置する。これにより、アプリケーションは必要な時に必要なリソースを確保でき、また不要なノードは自動で停止されるため、クラウド利用費の最適化にもつながる。

このGCPプロバイダのリリースはまだプレビュー版であり、本番環境での利用は推奨されない。しかし、テストや実験目的であれば完全に機能し、Karpenterの高度な自動スケーリングをGCP上で体験することが可能だ。この機能を利用するには、いくつかの準備と設定が必要になる。

まず前提条件として、Karpenterを動かすためのGKEクラスターが稼働していること、そしてそのGKEクラスターを操作するためのkubectlコマンドが設定済みであること、さらにKubernetesのアプリケーションをパッケージ管理するhelmツールがインストールされていることが必要となる。また、Karpenterが利用するカスタムリソース定義（CRD）がGKEクラスターに既にインストールされていることも確認する。これらの基本的な環境が整っていれば、GCPとKarpenterの連携設定に進める。

KarpenterがGCP上でノードを自動で作成・管理するためには、GCPの特定のサービスへのアクセス権限が必要だ。最初に、GCPのサービスを有効化する。具体的には、仮想マシンの作成や操作を行う「Compute Engine API（compute.googleapis.com）」と、GKEクラスターの情報を取得するために必要な「Kubernetes Engine API（container.googleapis.com）」を、gcloud services enableコマンドを使って有効にする。

次に、KarpenterがGCPリソースを操作するための認証情報を用意する。これは、GCPの「サービスアカウント」を作成し、必要な権限を付与することで行う。KarpenterコントローラーとGCPプロバイダは、GCPインスタンスの作成、サブネットの管理、ディスクの操作など、多岐にわたる作業を行う必要があるため、「Compute 管理者」「Kubernetes Engine 管理者」「Monitoring 管理者」「サービスアカウント ユーザー」といった複数のロール（権限のセット）をこのサービスアカウントに付与する。これにより、KarpenterはGCPの仮想マシンやGKEのメタデータ、監視データにアクセスできるようになる。サービスアカウントを作成したら、その認証情報を含むJSONキーファイルを生成し、これを安全な場所に保管する。このキーファイルはKarpenterがGCP APIにアクセスする際の「鍵」となる。

このGCPサービスアカウントの認証情報（JSONキーファイル）は、Kubernetesクラスターの内部に「Secret」という形で安全に保存する。Secretは、パスワードやAPIキーのような機密情報をKubernetesクラスター内で安全に管理するためのリソースである。先ほどダウンロードしたJSONキーファイルの内容をkarpenter-gcp-credentials.yamlというファイルに記述し、kubectl applyコマンドを使ってクラスターに適用する。これにより、KarpenterはGCPにアクセスする際に、このSecretから認証情報を安全に取得して利用できる。

GCPの認証情報の準備が整ったら、KarpenterのGCPプロバイダ本体をインストールする。ここではhelmコマンドを利用する。まず、Karpenterが動作するGCPプロジェクトのID、GKEクラスターの名前、そしてクラスターがデプロイされているGCPリージョンの名前を環境変数として設定する。これらの情報は、KarpenterがどのGCP環境で作業すべきかを認識するために不可欠だ。その後、helm upgrade --installコマンドを実行してKarpenterチャートをデプロイする。このコマンドでは、設定した環境変数をHelmのオプションを通じてKarpenterコントローラーに渡し、GCPの情報を設定する。

インストールが完了したら、実際にKarpenterが新しいノードを作成するかどうかをテストする。このテストには、GCENodeClassとNodePoolという二つのKarpenterカスタムリソースが使われる。GCENodeClassは、KarpenterがGCPインスタンスを作成する際の具体的な設定（使用するサービスアカウント、ノードにインストールするOSイメージ、GCPインスタンスに付与するタグなど）を定義する。例えば、最新の「Container Optimized OS」をイメージとして指定したり、事前に作成したGCPサービスアカウントのメールアドレスを関連付けたりする。

NodePoolは、Karpenterがノードをプロビジョニングする際の全体的なポリシーと、どのGCENodeClassを使うかを指定する。NodePoolでは、どのようなノードがプロビジョニングされるべきかという要件を細かく定義できる。たとえば、オンデマンドインスタンスとスポットインスタンスのどちらを使うか、特定のCPUアーキテクチャやインスタンスファミリー（例：n2、e2など）を選ぶか、ノードをデプロイするGCPゾーンの候補などを設定する。これにより、Karpenterはアプリケーションの要求に応じて、最も適切でコスト効率の良いGCPインスタンスタイプと配置場所を自動的に選択する。

これらのGCENodeClassとNodePoolの設定をGKEクラスターに適用した後、Karpenterがノードをプロビジョニングするきっかけとなる「ワークロード（Pod）」をデプロイする。記事の例では、inflateという名前のDeploymentを作成し、このDeploymentが特定のCPUとメモリのリソースを要求するように設定する。このワークロードをデプロイすると、Karpenterは既存のノードだけではこのPodをスケジュールできないことを検知し、NodePoolとGCENodeClassの定義に従って、新しいGCPインスタンス（ノード）を自動的に起動する。

ワークロードのデプロイ後、kubectl get nodeコマンドを実行してGKEクラスター内のノード一覧を確認すると、Karpenterによって新しく作成されたノードが表示されるはずだ。さらに、kubectl get nodeclaimコマンドを実行すると、Karpenterが管理するノード作成要求の詳細や、実際にプロビジョニングされたGCPインスタンスの情報（インスタンスタイプ、ゾーンなど）を確認できる。Karpenterが作成したノードには、通常、karpenter.sh/provisioner-nameという特別なラベルが付与され、NodeClassやNodePoolで定義した追加のラベルやテイント（特定のPodの配置を制御する設定）も適用されている場合がある。

このように、KarpenterのGCPプロバイダを利用することで、GCP環境でのKubernetesワークロードのノード自動スケーリングを、より高度かつ効率的に実現することが可能となる。現在はプレビューリリース段階であり、本番環境での利用はまだ推奨されないが、GCP上でKubernetesを扱うシステムエンジニアにとって、この技術は今後のクラウド運用の効率化に大きく貢献する可能性を秘めている。この機能を実際に試してみることで、Kubernetesとクラウドインフラの連携に関する理解を深める良い機会となるだろう。