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 など、必要なすべてのツールが事前構成されているため、ローカルマシンにインストールする手間が省けるからです。

  1. Google Cloud コンソール に移動します。
  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 を開いて Gemini 2.5 Flash に切り替えることができます。

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 が技術的に健全であり、クラスタに到達する前に組織のセキュリティ ポリシーに準拠していることを確認できます。

マニフェストを生成する

エージェントにデプロイ マニフェストの作成を依頼します。エージェントは 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 日目」のオペレーションの機能です。システムが失敗した場合、重要なエラーを見つけるために何千行ものログを検索することが課題となることがよくあります。Gemini CLI と MCP を使用すると、エージェントがログ、イベント、ステータス メッセージを集約して、高度な診断と解決への具体的なパスを提供できます。

手動による障害注入

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

👉💻 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.

次のステップ

さらに学習する場合は、次のドキュメントをご覧ください。