Cloud Engineering の AI ツールキット: Gemini を使用した GKE でのプラットフォーム エンジニアリング

1. はじめに

Kubernetes デプロイのトラブルシューティングは、プラットフォーム エンジニアの日常業務でよく行われる作業ですが、多くの場合、非常に面倒です。通常、ログの掘り下げ、kubectl describe コマンドの実行、YAML ファイルの相互参照など、多くの手動調査が必要になります。

汎用 AI チャットボットは、コンセプトの説明や基本的なコードの作成に役立ちますが、独立して動作します。特定のコードベースやクラスタのライブ状態について何も知らないため、手動でのコピー＆ペーストやコンテキストの切り替えが多くなります。

このラボでは、コンテキストのレベルを上げて AI ツールを使用することで、このギャップを埋める方法を体験します。Gemini CLI と Model Context Protocol（MCP）を使用して、GKE で破損したアプリケーションのトラブルシューティングを行います。このラボを修了すると、ファイルとインフラストラクチャを認識する AI を使用して複雑な問題を迅速に解決する方法と、これらのワークフローをチームで再利用可能な「スキル」にコード化する方法を理解できます。

基本コンセプト

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

ラボの目標

このラボの内容:

1. コンテキストの進行状況を確認する: コンテキストを増やすことで AI の問題解決がどのように改善されるかを確認します。
2. 手動のトラブルシューティングと AI を活用したトラブルシューティング: 手動デバッグの難しさと AI を活用したワークフローの難しさを比較します。
3. 完全なコンテキストのデバッグ: GKE MCP サーバーで Gemini CLI を使用して、インフラストラクチャを完全に認識した状態でアプリケーションをデバッグします。
4. 機能を拡張する: カスタム スキルを作成してワークフローを自動化する方法を学びます。

LLM の出力に関する注釈

このラボの性質と LLM の仕組みにより、出力結果は例に示されている出力結果とは異なる可能性があります。これは生成 AI の想定される動作です。例のテキストや書式を正確に再現するのではなく、モデルが提供する手順と推論を理解することに重点を置いてください。

2. プロジェクトのセットアップ

ラボを開始する前に、環境を準備します。Cloud Shell を開き、プロジェクトを選択して、設定スクリプトを実行します。では始めましょう。

Cloud Shell を開く

このラボでは、Google Cloud が提供するブラウザベースのターミナル環境である 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] を実行して、現在のシェルでプロジェクトを設定します。

ラボの設定

次に、設定スクリプトを実行して環境を準備し、ラボのバグを導入します。

1. リポジトリのクローンを作成する:
   👉💻 次のコマンドを実行して、ラボ ディレクトリのみのクローンを作成します。

   git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos ~/devrel-demos
   cd ~/devrel-demos
   git sparse-checkout set codelabs/ai-toolkit-lab-1
   

2. ラボ ディレクトリに移動します。
   👉💻 次のコマンドを実行します。

   cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/
   

3. 環境変数を設定する:
   👉💻 次のコマンドを実行して、プロジェクトとリージョンを設定します。

   export PROJECT_ID=$(gcloud config get-value project)
   export REGION=us-central1
   

4. 設定スクリプトを実行する:
   このスクリプトは、次の API を有効にし、GKE Autopilot クラスタを作成し、必要なツールがインストールされていることを確認します。
   👉💻 ルート ディレクトリからスクリプトを実行します。

   ./setup.sh
   

   注: クラスタの作成には 5 ～ 10 分ほどかかることがあります。
5. 破損した状態を初期化する:
   同僚が破損した環境を残して去ったというシナリオをシミュレートするには、break.sh スクリプトを実行します。破損したマニフェストをアクティブなコードベース ディレクトリにコピーします。
   👉💻 スクリプトを実行します。

   ./break.sh
   

6. ラボ演習の準備:
   AI が答えを見て不正行為をしないように、ラボの残りの部分では cymbal-bank ディレクトリに変更します。
   👉💻 実行:

   cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/cymbal-bank
   

API を有効にした

設定スクリプトは、いくつかの Google Cloud APIs を有効にします。以下に、その手順を示します。

• container.googleapis.com: Google Kubernetes Engine API。クラスタレベルのオペレーションに必要です。
• generativelanguage.googleapis.com: Gemini CLI が Gemini モデルと通信できるようにする API。
• cloudresourcemanager.googleapis.com: プロジェクト レベルのメタデータの検査と権限の管理に必要です。
• logging.googleapis.com: コンテナからログを取得して分析できるため、トラブルシューティングに不可欠です。

3. フェーズ 0: 手動によるトラブルシューティング（AI なし）

cymbal-bank ディレクトリに移動したので、エラーを手動で探してみましょう。これは「難しい方法」です。AI に重労働を任せる前に、ベースラインを体験してください。手動のトラブルシューティングでは、kubectl などの標準ツールを使用して、クラスタの状態を検査し、ログを取得し、YAML ファイルを読み取って不整合を見つけます。多くの場合、時間がかかり、退屈で、関連性を把握するには専門知識が必要です。これは、後で使用する AI ツールの完璧な基準点となります。

1. デプロイを試す: これらのマニフェストに対する Kubernetes の見解を確認しましょう。
   👉💻 次のコマンドを実行して、マニフェストを適用します。

   kubectl apply -f kubernetes-manifests/
   

   Pod のスピンアップには数秒かかることがあります。「watch kubectl get pods」を使用すると、Pod が起動するまで待機できます。起動したら、Ctrl+C を使用して watch を終了します。リストに 2 つの失敗した Pod が表示されます。
   • frontend Pod に 「CreateContainerConfigError」が表示されます。このタイプのエラーは通常、コンテナが必要な構成の読み込みに問題があることを示しています。コンテナの起動に必要な外部リソースについて考えてみましょう。構成が誤っているか、欠落している環境変数、シークレット、ConfigMap がありますか？Pod の構成を調べて、特定の問題の原因を見つける必要があります。
   • userservice Pod が 「ImagePullBackOff」状態になっている。このメッセージが表示された場合、通常は、クラスタが使用するように指示されたコンテナ イメージを取得できないことを意味します。イメージ リクエストの詳細を検討します。イメージ名とタグは正確ですか？レジストリに権限に関する問題が発生する可能性はありますか？画像がどこから取得されているかを確認して、リクエストが失敗している理由を特定します。
2. 損害を調査する: 標準の Kubernetes コマンドを使用して、何が失敗しているかを確認します。
   • 👉💻 Pod のステータスと名前を確認します。

     kubectl get pods
     

     • 観察: ImagePullBackOff、CrashLoopBackOff、Pending、CreateContainerConfigError に Pod が表示されます。
     • 注: Running 状態の Pod が正常に機能しているとは限りません。たとえば、十分なヘルスプローブ（ライブネス/レディネス）がない場合、アプリケーションが失敗していても実行中とマークされることがあります。ログには、Pod が実行されているように見えても、エラーが表示されることがあります。修正する必要があるエラーは合計 11 個あります。
   • 👉💻 失敗した Pod を記述してイベントを表示します（[POD_NAME] は実際の Pod 名に置き換えます）。

     kubectl describe pod [POD_NAME]
     

   • 👉💻 失敗した Pod のログを調べて、アプリケーション エラーを確認します。

     kubectl logs [POD_NAME]
     

3. 調査: Cloud Shell エディタまたはターミナルの cat を使用して、kubernetes-manifests/ のマニフェストを開きます。ログとイベントに表示されるエラーと YAML ファイルの構成を関連付けます。課題: 1 つのエラーを手動で修正してみます。残りのエラーの連鎖を特定するために、ファイルを切り替える必要があることに注意してください。

4. フェーズ 1: ウェブに質問する（Gemini ウェブ UI）

手動のトラブルシューティングは時間がかかるため、AI アシスタントを使用してみましょう。Gemini ウェブ アプリケーションは、強力な汎用チャット インターフェースです。コンセプトの説明やコード スニペットの生成に優れています。ただし、特定の環境のコンテキストはゼロです。ファイルを表示したり、クラスタを検査したり、コマンドを実行したりすることはできません。エラー メッセージとファイルの内容を手動でコピーして貼り付ける必要があります。

1. Gemini にアクセスする: 新しいタブで gemini.google.com を開きます。ご自身の Google アカウントでログインする必要があります。
2. 特定のエラーに関するヘルプを求める: userservice Pod に ImagePullBackOff エラーが表示されたとします。
   👉💬 Gemini ウェブ UI に次のプロンプトを入力します。
   My Kubernetes deployment for 'userservice' is failing with ImagePullBackOff. Here is the image name: us-central1-docker.pkg.dev/bank-of-anthos-ci/bank-of-anthos/user-service:v0.6.9. What is wrong?
3. AI の回答: Gemini は一般的な原因のリストを提示します。
   • イメージが存在しません。
   • プルする権限がありません。
   • 誤字脱字があります。
   レジストリまたは IAM 権限を確認することをおすすめします。ただし、プロジェクトを確認しない限り、実際のイメージ名が userservice（ハイフンなし）であることを認識することはできません。

ここで問題となるのは、Gemini がローカル環境を認識できないことです。必要なコンテキストを取得するには、手動で提供する必要があります（プロンプトを表示してテキストをコピー＆ペーストするなど）。この作業には時間がかかり、エラーが発生しやすくなります。

5. フェーズ 2: ターミナルのパワー（Gemini CLI）

Gemini CLI を使用してターミナルに移動します。Gemini CLI を使用すると、Gemini モデルの機能をターミナルで直接利用できます。CLI は作業環境に存在します。ローカル ファイルを読み取り、パイプ入力を受け入れ、ユーザーの代わりにシェル コマンドを実行します（ユーザーの承認が必要です）。これにより、コンテキストを切り替えることなく AI をワークフローに統合できるため、非常に便利です。詳細情報と高度な使用方法については、Gemini CLI の公式ドキュメントをご覧ください。

注: 現在、Antigravity CLI は正式にリリースされており、Gemini CLI の後継です。このラボでも、Gemini CLI を使用します。Antigravity CLI の詳細については、Antigravity CLI の公式ドキュメントをご覧ください。

コンテキストと可視性

手順に入る前に、Gemini CLI のプロジェクトの可視性は、起動する場所によって異なることに注意してください。モデルは、現在の作業ディレクトリを基準とするファイルとフォルダを確認できます。プロジェクトのルートから実行すると、そのプロジェクト内のすべてのファイルにアクセスできます。サブディレクトリから実行すると、ビューはそのサブディレクトリとその子に制限されます。モデルにファイルの分析や変更を依頼する前に、必ず正しいディレクトリにいることを確認してください。

Gemini CLI を起動する

Cloud Shell には、デフォルトで Gemini CLI が含まれています。起動するだけで、ローカル ファイルでの使用を開始できます。

1. Cymbal Bank ディレクトリに移動します。
   👉💻 次のコマンドを実行して、正しいディレクトリにいることを確認します。

   cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/cymbal-bank
   

2. Gemini CLI を起動する:
   👉💻 次のコマンドを実行して Gemini CLI を起動します。

   gemini
   

Gemini CLI を使用する

このアプリケーションについてわかっているのは、コードの場所と、コードが失敗していることだけです。詳細を確認して、Gemini がアプリケーションの修正にどのように役立つかを見てみましょう。まず、認識できるはずのアプリケーション ファイルに関する質問をして、コンテキストを探索する機能をテストしてみます。

1. コードベースを調べる: このアプリケーションが何であるか、何をするかを Gemini に説明してもらいます。
   👉💬 Gemini CLI に次のプロンプトを入力します。
   What is this application and what does it do?
   Gemini CLI は現在のディレクトリ内のファイルを読み取り、プロジェクトの概要を説明します。
2. コードベースで問題を見つける: Gemini CLI はファイルを参照できるため、不一致を見つけるように依頼します。
   👉💬 Gemini CLI に次のプロンプトを入力します。
   The contacts service pod is running, but I can't reach the service. Review kubernetes-manifests/contacts.yaml and check for common issues
   Gemini CLI はファイルを読み取り、app: contacts-backend と app: contacts の不一致を検出します。これは、前のフェーズと比較して大きな進歩です。
3. 修正を依頼する:
   👉💬 Gemini CLI に次のプロンプトを入力します。
   Fix the label mismatch in contacts.yaml so the service matches the deployment.
   Gemini CLI は、修正された YAML を表示します。コマンドを承認すると、変更が適用されます。
4. 制限事項: ファイルは認識できますが、クラスタで実際に実行されている内容は把握できません。静的 YAML で明らかでないランタイム エラーが原因で Pod が失敗した場合、ログやクラスタの状態がないと、問題を特定できません。

注: Gemini CLI は、コマンドの実行時やファイルの変更時に同意を求めます。これにより、環境を常に制御できます。以下のようなプロンプトが表示されたら、Enter キーを押して各アクション リクエストに対して「1. 1 回許可」と応答します。下矢印キーを押して Enter キーを押すと、「2. このセッションで許可」を選択することもできます。この場合、Gemini CLI はこの会話の間、許可を求めずに常にそのアクションを単独で実行します。ただし、Gemini CLI を閉じて再度開くと、その権限は失われ、アクションを実行する前に再度権限を求められます。

注: 行き詰まった場合や、最初からやり直したい場合は、cymbal-bank ディレクトリから ../break.sh を実行して、Kubernetes マニフェストを初期の破損状態に戻すことができます。

注: 使用量上限に達した場合は、[停止] を選択してから /model を実行して、上限に達したモデルを確認し、gemini-2.5-flash-lite などの別のモデルに切り替えます。次に、モデルに「続行」と入力して、新しいモデルを使用してラボを続行します。

6. フェーズ 3: 完全なコンテキスト デバッグ（Gemini CLI + GKE MCP）

フェーズ 2 では、ファイルを参照できる AI の強力さが示されましたが、ノイズも多くありました。すべてのファイル読み取りとツール アクションを手動で承認する必要があり、複雑なデバッグ セッションで大きな摩擦が生じます。フェーズ 3 では、この問題を解決するために GKE MCP サーバーが導入され、AI に直接的な「インフラストラクチャ認識」が提供されます。これにより、Gemini は手動による中断を減らしてログ、イベント、メタデータのトラブルシューティングを行い、より自動化された一貫性のあるトラブルシューティング フローを実現できます。

MCP とは

MCP を理解するには、まず AI の世界のツールのコンセプトを理解する必要があります。ツールは基本的に、LLM がアクションを実行したり、天気予報の確認、特定のスクリプトの実行、データベースのクエリなど、通常はアクセスできないデータを取得したりするために使用できる外部関数またはアプリケーションです。個々のツールは強力ですが、さまざまな AI エージェントや環境間で安全かつ一貫して共有することは常に課題でした。MCP は、これらのツールをホストし、互換性のある AI クライアントに公開できる標準化されたプラットフォームとして機能することで、この問題を解決します。

Model Context Protocol（MCP）は、AI モデルが外部のデータソースやツールに安全にアクセスできるようにするオープンソース プロトコルです。MCP は、特定のツールやデータベースごとに統合をハードコードするのではなく、モデルが環境とやり取りするための標準化された方法を提供します。

Gemini CLI で使用可能なツールを表示するには、Gemini CLI 内で /mcp を実行します。

このラボでは、GKE MCP サーバーにより、Gemini CLI が GKE クラスタと直接やり取りできるようになります。これにより、リソースの検査、ログの読み取り、クラスタのライブ状態を完全に把握した状態での問題のデバッグが可能になります。これにより、AI は静的なコード アナライザーから、インフラストラクチャのライブ状態を理解するアクティブなトラブルシューティング アシスタントへと変貌します。

GKE MCP 拡張機能を構成する

デフォルトでは、Gemini CLI は汎用ツールです。構成ファイルを作成して、GKE MCP サーバーを構成します。

1. 👉💻 まず、/quit と入力して、まだ Gemini CLI を使用している場合は終了します。
2. 👉💻 次のコマンドを実行して、拡張機能ディレクトリを作成します。

   mkdir -p ~/.gemini/extensions/gke
   

3. 👉💻 次のコマンドを実行して、構成ファイルを作成します。このコマンドは、PROJECT_ID をファイルに自動的に挿入します。

   cat << EOF > ~/.gemini/extensions/gke/gemini-extension.json
   {
     "name": "gke",
     "version": "1.0.0",
     "mcpServers": {
       "container": {
         "httpUrl": "https://container.googleapis.com/mcp",
         "authProviderType": "google_credentials",
         "oauth": {
           "scopes": ["https://www.googleapis.com/auth/container"]
         },
         "timeout": 30000,
         "headers": {
           "x-goog-user-project": "$PROJECT_ID"
         }
       }
     }
   }
   EOF
   

4. 👉💻 Gemini CLI を起動します。

   gemini
   

5. Gemini CLI 内で /mcp と入力して、MCP サーバーが有効になっていることを確認します。

クラスタの状態を使用して Gemini にデバッグを依頼する

1. デプロイの失敗をデバッグする: Gemini にクラスタを検査し、検出された内容に基づいてマニフェストを修正するよう依頼します。
   👉💬 Gemini CLI に次のプロンプトを入力します。
   The frontend deployment is failing. Can you use your tools to check the logs and events of the pods, and then fix it?
   Gemini は MCP ツールを使用して、舞台裏で kubectl コマンドを呼び出します。ImagePullBackOff エラーを検出し、原因を説明して、正しい修正方法を提案します。
2. 複雑な問題を解決する: アプリケーション レベルのエラーのログを確認するよう指示します。
   👉💬 Gemini CLI に次のプロンプトを入力します。
   Check the logs for the 'contacts' pod. Why is it failing to connect to the database?
   接続拒否エラーが検出され、config.yaml のポートの不一致またはサービス名の不一致にトレースバックされます。
3. 反復: フェーズ 0 で見つかった他の問題の修正を Gemini に依頼し続けます。
   👉💬 Gemini CLI に次のプロンプトを入力します。
   Check if the service 'contacts' is correctly routing traffic to its pods
   👉💬 Gemini CLI に次のプロンプトを入力します。
   Are there any pods failing due to resource limits?

注: 行き詰まった場合や、最初からやり直したい場合は、cymbal-bank ディレクトリから ../break.sh を実行して、Kubernetes マニフェストを初期の破損状態に戻すことができます。

7. フェーズ 4: チームの強化（エージェントのスキル）

最後に、カスタム エージェント スキルを作成して、特定のニーズに合わせて AI の機能を拡張します。

エージェントのスキルとは

エージェント スキルは、特殊なタスク用に AI エージェントを拡張する指示、スクリプト、リソースのパッケージです。組織の標準をコード化し、複雑なワークフローを自動化できます。スキルは特定のディレクトリに存在し、その動作を定義する SKILL.md ファイルを含んでいます。スキルを作成することで、AI が即興ではなく一貫性のある再現可能なプロセスに従うようにします。

一般的な Skill ディレクトリは次のようになります。

my-skill/
├── SKILL.md          # Main instruction file (Required)
├── scripts/           # Helper scripts (Optional)
└── resources/         # Templates or data files (Optional)

Kubernetes のトラブルシューティング スキルを構築する

これらのファイルを手動で作成する代わりに、Gemini CLI を使用して自然言語でスキルをスキャフォールディングする強力な方法があります。

先ほどの手順を自動化する k8s-troubleshooter というスキルを作成するとします。

1. プロンプトを使用してスキルを作成する: 今日学んだ内容に基づいて、Gemini CLI にスキルの作成を依頼できます。
   👉💬 Gemini CLI に次のプロンプトを入力します。
   Create a new skill called 'k8s-troubleshooter' that helps diagnose issues with Kubernetes manifests and cluster state. It should be able to analyze pod logs, events, and resource descriptions to identify common deployment problems and configuration errors.
   ツールを呼び出すときやアクションを実行するときと同様に、Gemini CLI は、プロンプトによって「スキル作成者」スキルが有効になったことを通知します。これは、Gemini がエージェント スキルを作成できるようにする、Gemini CLI の事前構成済みスキルです。
   Gemini は、スキル ディレクトリを作成する権限をユーザーに求める必要があります。[1. 今回のみ許可」と表示されます。
   Gemini は次のことを自動的に行います。
   • ~/.gemini/skills/k8s-troubleshooter/ にディレクトリを作成します。
   • プロンプトに基づいて、手順を含む SKILL.md ファイルを生成します。
   • 標準リソース ディレクトリを作成します。
2. Gemini CLI を再起動する:
   👉💻 Gemini CLI（/quit）を閉じてから、再起動します。

   gemini
   

3. スキルが読み込まれていることを確認する:
   👉💻 Gemini CLI 内で /skills と入力して、スキルが有効になっていることを確認します。リストに k8s-troubleshooter が表示されます。
4. 実際の動作: スキルを呼び出します。
   👉💬 Gemini CLI に次のプロンプトを入力します。
   Use the k8s-troubleshooter skill to find out why the contacts service is failing.
   AI は即興ではなく SKILL.md の構造化された計画に従うため、より一貫性のある結果が得られます。

演習: 独自のスキルを概念化する

日々のワークフローを考えてみましょう。スキルで自動化できる繰り返しタスクは何ですか？

• アイデア: デプロイ前にセキュリティのベスト プラクティスに沿ってマニフェストを監査するスキル。
• アイデア: ワークロード タイプに基づいて複雑な GKE クラスタ構成を生成するスキル。

8. まとめ

このラボでは、さまざまなレベルの AI コンテキストを進めることで、クラウド インフラストラクチャを操作する新しい方法を説明します。コンテキストなしの状態からインフラストラクチャの完全なコンテキスト（Gemini CLI + GKE MCP）に移行することで、ファイルとクラスタの状態を認識したときに AI アシスタントの有効性がどれほど向上するかを確認できます。

ラボの概要

• コンテキストの重要性: コンテキストのない AI ツールでは、特定のコードベースの問題を解決できないことがわかります。
• ターミナル コンテキスト: Gemini CLI を使用してローカル ファイルを分析し、ワークスペースから構成エラーを直接特定します。
• フル コンテキスト デバッグ: Gemini CLI と MCP を使用して、コードベース ファイルとライブ クラスタの状態を関連付け、AI が複雑な問題を診断して修正できるようにします。
• 拡張性: スキルと、それらを使用して組織の知識をコード化する方法について学習します。

クリーンアップ

継続的な課金を防ぐには、破棄スクリプトを実行します。Qwiklabs でラボを実行している場合、この手順は必要ありません。

👉💻 ワークショップのディレクトリから次のコマンドを実行します。

cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/
./teardown.sh

次のステップ

参考資料をいくつかご紹介します。

• Gemini CLI のドキュメント: Gemini CLI の公式ドキュメント。
• GKE のドキュメント: すべての GKE ドキュメントのランディング ページ。
• Google Cloud のプラットフォーム エンジニアリング: Google Cloud でプラットフォーム エンジニアリングに取り組む方法に関するガイダンス。
• GKE での AI と ML: GKE で AI/ML ワークロードを実行する方法に関するドキュメント。
• Google Cloud アーキテクチャ センター: Google Cloud でワークロードを構築するためのガイダンスとベスト プラクティス。

9. 付録: マニフェストの破損の解決策

行き詰まった場合やエラーを確認したい場合は、manifests-broken/ ディレクトリで発生した破損の一覧と、その修正方法をご覧ください。

1. config.yaml の形式が正しくない URL:
   • エラー: TRANSACTIONS_API_ADDR: "ledgerwriter::8080"（二重コロン）。
   • 理由: アプリケーションがアドレスを解析できないため、接続エラーが発生します。
   • 修正: "ledgerwriter:8080" に戻します。
2. contacts.yaml のラベルの不一致:
   • エラー: サービス セレクタが contacts ではなく app: contacts-backend に設定されています。
   • 理由: Service が Pod（まだ app: contacts がある）を見つけられないため、トラフィックがルーティングされません。
   • 修正: セレクタを app: contacts に変更します。
3. userservice.yaml でのポートの不一致:
   • エラー: サービス targetPort が 8080 ではなく 8081 に設定されています。
   • 理由: サービスに送信されたトラフィックが間違ったコンテナポートに転送され、接続が拒否されます。
   • 修正: targetPort を 8080 に戻します。
4. config.yaml のサービス名が一致しない:
   • エラー: BALANCES_API_ADDR: "balance-reader:8080"（balancereader ではなく）。
   • 理由: サービスの名前が balancereader であるため、DNS でホスト名を解決できません。
   • 修正: "balancereader:8080" に戻します。
5. contacts.yaml のイメージ pull ポリシー:
   • エラー: imagePullPolicy: Never。
   • 理由: K8s は、イメージがローカルにあると想定して、レジストリからイメージを pull しません。ErrImagePull で失敗します。
   • 修正: 行を削除するか、IfNotPresent に設定します。
6. userservice.yaml での readiness プローブの失敗:
   • エラー: パスが /ready ではなく /healthz に変更されました。
   • 理由: コンテナが /healthz を提供しないため、プローブが失敗し、Pod が準備完了とマークされません。
   • 修正: パスを /ready に戻します。
7. contacts.yaml のリソースの上限:
   • エラー: メモリ制限が 128Mi ではなく 10Mi に設定されています。
   • 理由: アプリの起動に必要なメモリが不足しているため、OOMKilled が発生します。
   • 修正: メモリ上限を復元します。
8. frontend.yaml で環境変数が不足している:
   • エラー: REGISTERED_OAUTH_CLIENT_ID 環境変数を削除しました。
   • 理由: 想定される環境変数が欠落している場合、アプリが失敗したり、機能が無効になったりする可能性があります。
   • 修正: 環境変数定義を復元します。
9. frontend.yaml の ConfigMap キーが一致しない:
   • エラー: DEMO_LOGIN_USERNAME ではなく key: DEMO_USER。
   • 理由: K8s が ConfigMap でキーを見つけられず、コンテナの起動に失敗します。
   • 解決策: キーを DEMO_LOGIN_USERNAME に戻します。
10. userservice.yaml のイメージ名に誤字脱字がある:
    • エラー: userservice ではなく user-service。
    • 理由: イメージがレジストリに存在しないため、ImagePullBackOff が発生します。
    • 修正: イメージ名を修正します。
11. contacts.yaml のサービス アカウントに関する問題:
    • エラー: bank-of-anthos ではなく bank-of-anthos-sa。
    • 理由: ServiceAccount が存在しないか、権限がありません。
    • 修正: 正しい ServiceAccount 名を使用します。