雲端工程的 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 的運作方式，您得到的輸出內容可能與範例輸出內容不同。這是生成式 AI 的預期行為。請著重瞭解模型提供的步驟和推論，而不是嘗試複製範例中的確切文字或格式。

2. 專案設定

開始實驗室之前，請先準備環境。開啟 Cloud Shell、選取專案，然後執行設定指令碼。立即開始！

開啟 Cloud Shell

在本實驗室中，請使用 Cloud Shell。這是 Google Cloud 提供的瀏覽器型終端機環境，已預先設定所有必要工具，包括 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 API，用途如下：

  • container.googleapis.com:Google Kubernetes Engine API。這是執行任何叢集層級作業的必要條件。
  • generativelanguage.googleapis.com:這項 API 可讓 Gemini CLI 與 Gemini 模型通訊。
  • 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 結束觀察。您會發現清單中有兩個失敗的 Pod：
    • 前端 Pod 顯示「CreateContainerConfigError」。這類錯誤通常表示容器無法載入必要設定。請想想容器啟動時可能需要哪些外部資源，是否有設定錯誤或缺少的環境變數、密鑰或 ConfigMap？您需要調查 Pod 的設定，找出具體原因。
    • userservice Pod 處於「ImagePullBackOff」狀態。看到這則訊息通常表示叢集無法擷取要使用的容器映像檔。請考慮圖片要求的詳細資料：圖片名稱和標記是否完全正確？註冊表是否有潛在的權限問題？查看圖片的擷取來源，找出要求失敗的原因。
  2. 檢查損壞情形：使用標準 Kubernetes 指令，查看哪些項目發生故障。
    • 👉💻 檢查 Pod 的狀態和名稱：
      kubectl get pods
      • 觀察：您會在 ImagePullBackOff、CrashLoopBackOff、Pending 或 CreateContainerConfigError 中看到 Pod。
      • 注意：處於 Running 狀態的 Pod 不一定表示運作正常。舉例來說，Pod 可能缺少足夠的健康狀態探查 (存活/完備性)，因此即使內部應用程式發生故障，仍會標示為執行中。即使 Pod 似乎正在執行，記錄檔仍可能會顯示錯誤。總共有 11 種不同的錯誤需要修正。
    • 👉💻 描述失敗的 Pod，查看事件 (將 [POD_NAME] 換成實際的 Pod 名稱)：
      kubectl describe pod [POD_NAME]
    • 👉💻 檢查失敗的 Pod 記錄，查看應用程式錯誤：
      kubectl logs [POD_NAME]

螢幕截圖：顯示 kubectl get pods 的輸出內容

  1. 偵錯工作：使用 Cloud Shell 編輯器 (kubernetes-manifests/) 或終端機 (cat) 開啟資訊清單。嘗試將記錄檔和事件中顯示的錯誤，與 YAML 檔案中的設定建立關聯。挑戰：嘗試手動修正一個錯誤。請注意，您必須在檔案之間切換，才能找出其餘的失敗鏈。

4. 第 1 階段：詢問網頁 (Gemini 網頁使用者介面)

手動疑難排解速度緩慢，因此我們將嘗試使用 AI 助理。Gemini 網頁應用程式是功能強大的通用即時通訊介面，擅長說明概念和生成程式碼片段。不過，這項工具完全不瞭解您的具體環境，無法查看您的檔案、檢查叢集或執行指令。您必須手動複製及貼上錯誤訊息和檔案內容。

顯示 Gemini 網頁 UI 的螢幕截圖

  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 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. 限制：雖然可以查看檔案，但仍不知道叢集中實際執行的內容。如果 Pod 因靜態 YAML 中不明顯的執行階段錯誤而失敗，沒有記錄或叢集狀態就無法提供協助。

注意：執行指令或修改檔案時，Gemini CLI 會要求您同意授權，確保您能控管環境。看到類似下方的提示時，您可以按下「Enter」鍵，針對每個動作要求回應「1. 允許一次」。您也可以輕觸向下箭頭鍵並按下「Enter」鍵，選取「2. 允許本次工作階段」，這樣 Gemini CLI 在本次對話期間，一律會獨立執行該動作，不會要求您授權。不過，如果您關閉 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 內執行 /mcp，即可查看可用的工具。

在本實驗室中，GKE MCP 伺服器可讓 Gemini CLI 直接與 GKE 叢集互動，檢查資源、讀取記錄，並充分掌握叢集的即時狀態，協助您偵錯問題。這項功能可將 AI 從靜態程式碼分析器，轉變為瞭解基礎架構即時狀態的動態疑難排解助理。

設定 GKE MCP 擴充功能

根據預設，Gemini CLI 是通用工具。請建立設定檔，設定 GKE MCP 伺服器。

  1. 👉💻 首先，如果仍在 Gemini CLI 中，請輸入 /quit 退出。
  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 指令。Gemini 發現 ImagePullBackOff 錯誤後，會說明原因並建議正確的修正方式。
  2. 修正複雜問題：要求查看應用程式層級錯誤的記錄。
    👉💬 在 Gemini CLI 中輸入以下提示：
    Check the logs for the 'contacts' pod. Why is it failing to connect to the database?
    發現連線遭拒錯誤，並追溯至 config.yaml 中的連接埠不符或服務名稱不符。
  3. 反覆運算：繼續要求 Gemini 修正您在第 0 階段發現的其他問題。
    👉💬 在 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：賦予團隊能力 (Agent Skills)

最後，您可以建立自訂 Agent Skills，根據特定需求擴充 AI 的功能。

什麼是代理程式技能？

代理程式技能是指令、指令碼和資源的套件，可擴充 AI 代理程式的功能，用於執行特定工作。您可藉此編纂機構標準，並自動執行複雜的工作流程。技能位於特定目錄中，並包含定義其行為的 SKILL.md 檔案。建立技能後，AI 就能遵循一致且可重複的程序，而非即興發揮。

典型的技能目錄如下所示：

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 CLI 中預先設定的技能，可讓 Gemini 建立代理程式技能。
    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

後續步驟

如要進一步瞭解相關資訊，建議閱讀下列文章：

9. 附錄：資訊清單中斷問題的解決方案

如果遇到問題或想驗證錯誤，請參閱以下 manifests-broken/ 目錄中導入的重大變更清單，以及修正方式：

  1. config.yaml中的網址格式錯誤：
    • 錯誤： TRANSACTIONS_API_ADDR: "ledgerwriter::8080" (雙冒號)。
    • 原因：應用程式無法剖析位址，導致連線錯誤。
    • 修正：改回 "ledgerwriter:8080"。
  2. contacts.yaml中的標籤不符：
    • 錯誤：服務選取器設為 app: contacts-backend，而非 contacts。
    • 原因：服務找不到 Pod (仍有 app: contacts)，因此不會轉送流量。
    • 修正方式：將選取器變更為 app: contacts。
  3. userservice.yaml中的通訊埠不符：
    • 錯誤：服務 targetPort 設為 8081，而非 8080。
    • 原因：傳送至服務的流量會轉送至錯誤的容器通訊埠，導致連線遭拒。
    • 修正方式：將 targetPort 改回 8080。
  4. config.yaml中的服務名稱不符：
    • 錯誤： BALANCES_API_ADDR: "balance-reader:8080" (而非 balancereader)。
    • 原因：由於服務名稱為 balancereader，因此主機名稱不會在 DNS 中解析。
    • 修正：改回 "balancereader:8080"。
  5. contacts.yaml中的映像檔提取政策：
    • 錯誤： imagePullPolicy: Never。
    • 原因：K8s 會假設映像檔位於本機，因此不會從登錄檔提取映像檔，並會因 ErrImagePull 而失敗。
    • 修正：移除該行或設為 IfNotPresent。
  6. userservice.yaml 中的完備性探測失敗：
    • 錯誤：路徑已變更為 /healthz，而非 /ready。
    • 原因：容器不會提供 /healthz，因此探測會失敗，且 Pod 永遠不會標示為就緒。
    • 修正方式：將路徑改回 /ready。
  7. contacts.yaml的資源限制：
    • 錯誤：記憶體限制設為 10Mi，而非 128Mi。
    • 原因：應用程式需要更多記憶體才能啟動，因此遭到 OOMKilled。
    • 修正：還原記憶體限制。
  8. frontend.yaml 中缺少環境變數：
    • 錯誤：已移除 REGISTERED_OAUTH_CLIENT_ID 環境變數。
    • 原因：如果缺少預期的環境變數，應用程式可能會失敗或停用功能。
    • 修正：還原環境變數定義。
  9. frontend.yaml中的 ConfigMap 鍵不符：
    • 錯誤： key: DEMO_USER，而非 DEMO_LOGIN_USERNAME。
    • 原因：K8s 無法在 ConfigMap 中找到金鑰，導致容器無法啟動。
    • 修正方式：將金鑰改回 DEMO_LOGIN_USERNAME。
  10. userservice.yaml：圖片名稱有錯字
    • 錯誤： user-service，而非 userservice。
    • 原因：登錄檔中沒有該圖片，導致 ImagePullBackOff。
    • 修正方式：更正圖片名稱。
  11. contacts.yaml中的服務帳戶問題：
    • 錯誤： bank-of-anthos-sa，而非 bank-of-anthos。
    • 原因：服務帳戶不存在或缺少權限。
    • 修正方式：使用正確的 ServiceAccount 名稱。