GKE と Gemini CLI を使用したプラットフォーム エンジニアリング AI

1. はじめに

このラボでは、インフラストラクチャ管理に Gemini CLI と GKE Model Context Protocol（MCP）サーバーを使用する方法について技術的な概要を説明します。従来の GKE 管理では、オペレーターがインフラストラクチャ要件を gcloud コマンドに手動で変換し、アプリケーション定義を YAML マニフェストに記述します。このラボでは、Google Kubernetes Engine（GKE）で自然言語の意図と技術的な実行を結び付けるインタラクティブ インターフェースを使用するという、別のアプローチを説明します。この変化は、プラットフォーム エンジニアリングにおけるより広範なトレンドの一部です。このトレンドでは、厳格な自動化スクリプトの構築から、インフラストラクチャ オペレーションの微妙な詳細を処理できるインテリジェント エージェントの管理に焦点が移っています。

基本概念

  • プラットフォーム エンジニアリング: ソフトウェア デベロッパーが基盤となるすべてのクラウド サービスの専門家でなくても、独自のインフラストラクチャを管理できるようにする内部ツールとワークフローを構築して維持する手法です。目標は、一貫性とセキュリティを維持しながら、技術的な摩擦を軽減することです。標準化されたゴールデン パスを作成することで、プラットフォーム チームは、アプリケーション開発者が安全かつ迅速にデプロイできるようにしながら、ガバナンスと費用を管理できます。
  • Gemini CLI: ターミナルから Gemini モデルと直接やり取りできるコマンドライン インターフェースです。標準のウェブベースの chatbot とは異なり、CLI は開発環境内に存在するように設計されているため、既存のシェルベースのワークフローに AI を簡単に統合できます。これにより、他のコマンドの出力をモデルに直接パイプして、ターミナル環境を離れることなく指示を実行できます。
  • Model Context Protocol（MCP）: MCP は、AI モデルが特定のツールやデータソースに接続できるようにするオープン スタンダードです。MCP がないと、AI モデルはトレーニングされた内容しか認識できず、特定のリソースを認識できません。GKE MCP サーバーを使用すると、Gemini CLI は Google Cloud プロジェクトの API をアクティブにクエリし、クラスタの状態を検査し、ユーザーに代わってコマンドを実行できます。モデルの推論エンジンと実際の GKE API の間の橋渡し役として機能します。

ラボの目標

このセッションを修了すると、次のことができるようになります。

  1. 環境を構成する: Cloud Shell にアクセスし、GKE MCP 拡張機能を認証して、Gemini CLI が Google Cloud リソースを操作できるようにします。
  2. インフラストラクチャの設計: インタラクティブなプロンプトを使用して、費用、管理オーバーヘッド、ワークロード要件に基づいて最適なクラスタ構成を決定します。
  3. リソース管理: 自然言語を使用して Kubernetes マニフェスト（Deployment、Service など）を生成、監査、デプロイします。
  4. 運用分析: AI のログとイベントを集約する機能を使用して、デプロイの失敗の根本原因を特定し、具体的な技術的修正を提案します。

2. プロジェクトの設定

Gemini CLI がリソースとやり取りするには、Google Cloud 環境が正しく構成されている必要があります。この設定により、プロジェクトに正しい権限が付与され、必要なすべてのバックエンド サービスが AI エージェントからのリクエストを受信できるようになります。

Cloud Shell を開く

このラボでは、Google Cloud が提供するブラウザベースのターミナル環境である Cloud Shell を使用します。Cloud Shell には、Google Cloud CLI（gcloud）、kubectl、Gemini CLI など、必要なツールがすべて事前に構成されているため、Cloud Shell を使用します。これにより、ローカルマシンにこれらのツールをインストールする手間を省くことができます。

  1. Google Cloud Console に移動します。
  2. コンソールの右上にあるヘッダーを確認し、[Cloud Shell をアクティブにする] ボタン（ターミナル プロンプト >_ のようなアイコン）をクリックします。
  3. ブラウザ ウィンドウの下部にターミナル セッションが開きます。プロンプトが表示されたら、[続行] をクリックします。

プロジェクトの選択

Cloud Shell ターミナルで、正しいプロジェクト内で作業していることを確認します。

  1. コンソールで、既存のプロジェクトを選択するか、このラボ専用の新しいプロジェクトを作成します。
  2. プロジェクト ID をメモします。現在のシェルでプロジェクトを設定するには、gcloud config set project [YOUR_PROJECT_ID] を実行します。

API を有効にする

新しいプロジェクトでは、Kubernetes 機能と AI 機能はデフォルトで有効になっていません。これらの API を有効にすると、コンテナ管理、生成モデル、一元化されたロギングを処理する基盤となる Google Cloud サービスが初期化されます。

👉💻 Cloud Shell で次のコマンドを実行して、これらを有効にします。この処理には 1 分ほどかかることがあります。

gcloud services enable \
    container.googleapis.com \
    generativelanguage.googleapis.com \
    cloudresourcemanager.googleapis.com \
    logging.googleapis.com
  • container.googleapis.com: Google Kubernetes Engine API。クラスタの作成、更新、削除など、クラスタレベルのオペレーションには必須です。
  • generativelanguage.googleapis.com: Gemini CLI がテキスト生成と推論のために Gemini 大規模言語モデルと通信できるようにする API。
  • cloudresourcemanager.googleapis.com: エージェントがプロジェクト レベルのメタデータを検査し、プロジェクト ID を検証して、IAM 権限を管理するために必要です。
  • logging.googleapis.com: トラブルシューティングに不可欠です。これにより、問題が発生したときに MCP サーバーがコンテナからログを取得して分析できます。

3. Gemini CLI の構成

Cloud Shell には Gemini CLI がデフォルトで含まれているため、このワークフローに最適な環境です。まず、GKE 環境の管理に必要な権限と特定のツールを備えた「エージェント」として機能するように構成します。この構成手順は、AI のロジックと実際のクラウド インフラストラクチャ間の安全な接続を確立するため、非常に重要です。

Gemini CLI を起動する

Cloud Shell ターミナルで、新しい作業ディレクトリを作成して Gemini CLI を実行します。これにより、モデルとの継続的な会話が可能なセッションが開始されます。1 回限りのコマンドとは異なり、インタラクティブ モードでは、以前の指示とプロジェクトの状態を記憶するコンテキスト ウィンドウが維持されます。

👉💻 次のコマンドを実行します。

mkdir -p ~/gke-lab
cd ~/gke-lab
gemini

内部に入ったら、ツールの基本的な認識をテストして、環境を認識できることを確認します。

  • 👉💬 プロンプト: Which Google Cloud project is currently active in this shell?

gcloud コマンドの実行を確認するよう求められることがあります。その場合は、承認してください。

/quit と入力すると、いつでもインターフェースを終了できます。

注: Gemini 2.5 Pro で容量の問題が発生した場合は、

gemini -m gemini-2.5-flash

または

/model

コマンド

GKE MCP 拡張機能を接続する

デフォルトでは、Gemini CLI は汎用ツールであり、クラスタとのやり取り方法に関する特定の知識はありません。GKE MCP 拡張機能をインストールする必要があります。この拡張機能は、モデルがタスクを実行する必要があるときに呼び出すことができる特定のツールと関数（「クラスタのリストを取得する」や「Pod のログを取得する」など）を定義するプラグインとして機能します。

👉💻 次のコマンドを実行して GKE 拡張機能をインストールし、Gemini CLI を再度開きます。

gemini extensions install https://github.com/GoogleCloudPlatform/gke-mcp.git
gemini

Gemini CLI に再度アクセスして次のコマンドを入力すると、正しく有効になっていることを確認できます。

/extensions

4. インフラストラクチャのプロビジョニング

従来のインフラストラクチャ プロビジョニングでは、複雑なドキュメントを読み解いたり、数百行の構成コードを記述したりすることがよくあります。エージェントを使用すると、要件の説明に集中し、AI に正しい API 呼び出しへの技術的な変換を任せることができます。このセクションでは、計画フェーズと GKE 環境の実際の作成の両方でエージェントを使用する方法について説明します。

技術計画と比較

クラスタを作成する前に、ニーズに合ったアーキテクチャを選択する必要があります。GKE には、基盤となるノードを完全に制御できる Standard と、Google がノードを管理し、Pod がリクエストしたリソースに基づいて課金される Autopilot の 2 つの主要なモードがあります。簡単なクエリを試して、2 つの違いを理解し、特定のユースケースでどちらを使用するかをブレインストーミングしてみましょう。

  • 👉💬 プロンプト: I need to run a standard 3-tier web application. Compare GKE Standard and GKE Autopilot. Focus on the operational effort for a small team and the cost structure for small workloads.

他のインフラストラクチャのアイデアについて質問してみてください。AI 推論ワークロードをデプロイする場合、非常に大規模なものが必要な場合、または複雑なネットワーキング制約がある場合はどうすればよいでしょうか？他のプロンプトを試してみる。

クラスタの作成を実行する

比較を確認して選択したら、エージェントにクラスタの構築を指示できます。エージェントはリクエストを分析し、GKE MCP サーバーから create_cluster ツールを呼び出して、これらの要件に基づいて本番環境をデプロイします。

  • 👉💬 プロンプト: Create a GKE Standard zonal cluster named 'gke-lab' in us-central1-a with 1 node with 4 CPUs. The cluster should have Workload Identity enabled.

注: GKE クラスタのプロビジョニングには、コントロール プレーン、仮想プライベート ネットワーク、初期ノード構成の設定が含まれます。通常、これには 8 ～ 10 分かかります。Gemini CLI セッションを閉じないでください。

クラスタのステータスを尋ねると、GKE MCP サーバーが最新の情報を返します。

  • 👉💬 プロンプト: Is the new GKE cluster created and ready to use, yet?

5. デプロイと検証

プラットフォーム エンジニアリングに AI エージェントを使用する主なメリットは、構成の「プリフライト」チェックと監査を実行できることです。マニフェストをデプロイして失敗するのを待つのではなく、エージェントを使用して、クラスタに到達する前に YAML が技術的に健全で、組織のセキュリティ ポリシーに準拠していることを確認できます。

マニフェストを生成する

エージェントに Deployment マニフェストの作成を依頼します。エージェントは Kubernetes API のバージョン管理とスキーマを理解しているため、正しい形式で、デプロイを成功させるために必要なすべてのフィールドを含む YAML を生成します。

  • 👉💬 プロンプト: Generate a Kubernetes YAML manifest for an Nginx web server. I need 3 replicas. Set a memory limit of 256Mi and a CPU limit of 500m. Also, include a Service of type LoadBalancer to make it accessible via the internet. Save the manifest as web-server.yaml

技術検証とセキュリティ監査

YAML を手動で作成すると、必要以上の権限で実行される構成や、基本的な信頼性機能が欠落している構成になることがよくあります。エージェントを使用して、作成したマニフェストを監査し、セキュリティと復元性に関する最新の標準を満たしていることを確認できます。

  • 👉💬 プロンプト: Review the Nginx manifest you just created. Does it include resource requests (not just limits)? Does it specify a non-root user for the container? Add a Pod Disruption Budget to ensure high availability during cluster maintenance. Make any necessary modifications to the file, and tell me what changes were made.

デプロイの実行

前のセクションのクラスタ プロビジョニングが完了したら、Gemini CLI に新しいクラスタに構成を適用するように指示します。エージェントは、ツールを使用して Kubernetes API サーバーと通信し、リクエストされたリソースを作成します。

  • 👉💬 プロンプト: Deploy the audited Nginx manifest to the 'gke-lab' cluster. Use the kubectl command to do this.

リアルタイム ステータス チェック

複数の kubectl get pods コマンドや kubectl describe コマンドを実行する代わりに、エージェントにデプロイの進行状況の自然言語による概要をリクエストできます。

  • 👉💬 プロンプト: Are the Nginx pods running? Provide the external IP address assigned to the LoadBalancer once it is available.

行き詰まったら

Nginx サービスが正常にデプロイされていないと思われる場合は、Gemini CLI を使用して問題のトラブルシューティングを試してください。ぜひご活用ください。

  • 👉💬 プロンプト: The Nginx deployment doesn't start up as expected. Can you help troubleshoot?

6. メンテナンスとトラブルシューティング

AI を活用したプラットフォームの最も価値のある側面の 1 つは、「2 日目」の運用機能です。システムで障害が発生した場合、数千行のログから重要なエラーを 1 つ見つけることが課題となることがよくあります。Gemini CLI と MCP を使用すると、エージェントがログ、イベント、ステータス メッセージを集計して、概要レベルの診断と解決への具体的なパスを提供できます。

手動による障害挿入

エージェントの診断機能をテストするために、意図的に障害状態を作成します。別のターミナルタブで、次のコマンドを実行して、存在しないコンテナ イメージで Deployment を更新します。これは、コンテナタグのタイプミスという一般的な人的ミスをシミュレートしています。

👉💻 Gemini CLI の外部で次のコマンドを実行します。

kubectl set image deployment/nginx nginx=nginx:invalid-version-xyz123

注: デプロイが「nginx」という名前ではない場合があります。 を実行して確認できます。

kubectl get deployments

Kubernetes はこのイメージを pull しようとしますが、タグが見つからないため失敗し、Pod は ImagePullBackOff 状態になります。

Gemini CLI を使用した分析

Gemini CLI セッションに戻ります。Cloud Logging コンソールを手動で検索する代わりに、エージェントにエラーの検索と説明を依頼します。

  • 👉💬 プロンプト: The Nginx deployment on my 'gke-lab' cluster has stopped working. Use your tools to inspect the cluster state, check the recent events, and explain exactly why the pods are failing to start.

ここで何が起こるか: Gemini CLI は、デプロイが正常でないことを確認します。次に、使用可能なツールを使用して、失敗した Pod を検査します。エージェントは pull エラーを特定し、タグが無効であることを説明して、既知の正常なイメージに戻すことを提案します。

メンテナンスとリスク評価

プラットフォームのメンテナンスでは、アップグレードと非推奨に先手を打つ必要があります。エージェントに SRE としてクラスタの健全性と寿命を評価するよう依頼できます。

  • 👉💬 プロンプト: Is my cluster 'gke-lab' running the latest version of GKE? Check for available upgrades and let me know if any of my current resources use deprecated APIs that would break during an upgrade.

これにより、Gemini がクラスタ ステータスや推奨事項ツールなどの GKE MCP サーバーツールを呼び出す可能性があります。

7. まとめ

このラボでは、クラウド インフラストラクチャを操作する新しい方法を説明しました。Gemini CLI と MCP を介して AI エージェントをターミナル ワークフローに直接統合することで、コマンドを手動で記述する作業から、意図を指示する作業に移行しました。このアプローチにより、プラットフォーム チームは、Kubernetes 管理の繰り返しが多くエラーが発生しやすい詳細を処理するインテリジェントなインターフェースを提供することで、専門知識を拡大できます。一方、エンジニアは高レベルのアーキテクチャと問題解決に集中できます。

ラボの概要

  • 接続性: Model Context Protocol を使用して Gemini CLI を GKE API に接続し、AI モデルがプロジェクトの状態を直接認識できるようにしました。
  • インフラストラクチャ: 自然言語を使用して GKE クラスタを設計してプロビジョニングし、複雑な CLI フラグを覚える必要がなくなりました。
  • 開発: 手動で YAML を編集することなく Kubernetes リソースを生成、セキュリティ監査、デプロイし、最初からベスト プラクティスが適用されるようにしました。
  • 運用: AI を使用して、破損したデプロイの根本原因分析を実行しました。AI がログとイベントを要約できるようにすることで、平均復旧時間を大幅に短縮しました。

クリーンアップ

このラボで作成したリソースについて、Google Cloud への継続的な課金を回避するには、エージェントにクラスタの削除を指示します。

注: 別のラボで GKE クラスタを再利用する場合は、この手順をスキップしてください。

  • 👉💬 プロンプト: Delete the 'gke-lab' cluster and any associated resources.

次のステップ

おすすめの関連資料: