深度探索：EKS MCP Server 與 Amazon Q Developer CLI 集成實踐詳情 - 人工智能亞馬遜雲開發者博客

“又一次半夜被Kubernetes告警驚醒，我發現自己正在查閲第五個不同的文檔，試圖找出為什麼集羣中的一個關鍵服務突然不可用。”作為一名身處雲原生轉型前線的架構師，這樣的經歷對我而言曾是家常便飯。儘管Amazon EKS讓Kubernetes部署變得更簡單，但運維的複雜性和知識門檻仍然是許多團隊面臨的巨大挑戰。然而，亞馬遜雲科技最新推出的AI驅動運維工具徹底改變了這一現狀。在這篇文章中，我將分享如何利用這些革命性技術讓Kubernetes管理變得像日常對話一樣自然，以及這些工具如何幫助一個陷入運維困境的大型企業重獲雲原生之路的信心。

1. 雲原生智能運維的新紀元

客户痛點：某消費電子行業製造商的EKS運維困境

近一年來，持續與一家大型消費電子製造商合作，他們在亞馬遜雲科技的北美及歐洲區域內共計部署了14個EKS集羣來支持其研發、生產和供應鏈系統。儘管雲原生技術為他們帶來了巨大的靈活性和創新能力，但他們的運維團隊正面臨嚴峻挑戰：

專業知識短缺：團隊中只有兩名工程師精通Kubernetes，導致關鍵操作存在人員依賴
incident響應遲緩：生產環境問題平均解決時間超過3小時，影響業務連續性Best Practices
運維人員倦怠：頻繁的告警和複雜的故障排查導致團隊疲憊Best Practices
環境不一致：開發、測試和生產環境配置漂移，導致”在我機器上能運行”的問題
文檔滯後：快速迭代導致操作手冊和知識庫無法及時更新
學習曲線陡峭：新加入的運維工程師需要3-6個月才能獨立處理集羣事務

其公司的運維總監向我坦言：”我們的工程師花費過多時間在重複性任務上，而非創新。每次Kubernetes或亞馬遜雲科技發佈新功能，我們都需要大量學習時間。我們需要一種方法來降低管理EKS集羣的複雜性，並使我們的整個團隊能夠高效操作，而不只是依賴少數專家。”

Kubernetes複雜性痛點與傳統管理方法的侷限

隨着企業雲原生架構的廣泛採用，Kubernetes已經成為容器編排的事實標準。然而，Kubernetes的強大功能伴隨着顯著的技術複雜性，這為DevOps和平台工程團隊帶來了諸多挑戰：

陡峭的學習曲線：掌握Kubernetes需要深入理解其資源模型、網絡模型和安全機制，這對新手來説尤其困難
API複雜性：Kubernetes擁有超過50種資源類型，各有不同的API版本和字段定義
故障排查困難：當應用程序出現問題時，可能涉及多個組件和資源層級，導致根因分析耗時且複雜
操作風險高：配置錯誤可能導致生產環境中斷，尤其在多集羣、多租户環境中
配置管理挑戰：隨着集羣和應用數量增加，手動管理配置變得越來越困難
工具碎片化：需要使用多種命令行工具(kubectl, eksctl, aws cli等)和配置文件

傳統的Kubernetes管理方法主要依靠命令行工具、聲明式YAML配置和自動化腳本。這些方法雖然有效，但存在一系列侷限：

高度依賴專業知識：需要專家級別的Kubernetes和雲服務知識
缺乏上下文感知：工具不瞭解整個環境的狀態，無法提供智能建議
自動化腳本維護成本高：隨着集羣配置的變化，腳本需要不斷更新
跨團隊協作障礙：不同經驗水平的團隊成員難以高效協作

AI驅動的DevOps轉型：從工具到助手的演進

人工智能，特別是大型語言模型(LLM)的出現，正在徹底改變DevOps和雲基礎設施管理的方式。這一轉變可以描述為”從工具到助手”的演進：

AI助手時代的特點：

自然語言交互
上下文感知和適應性
關注”要做什麼”而非”如何做”
智能錯誤解釋與指導
能夠理解模糊的需求並給出建議

亞馬遜雲科技的智能EKS管理解決方案代表了這一演進的前沿，它將Kubernetes專業知識與AI助手能力相結合，創建了一個更智能、更直觀的雲原生管理範式，正是消費電子行業客户所迫切需要的解決方案。

在本文中將深入探討如何利用AI驅動工具來構建智能化EKS運維體系，以及這如何為我們的客户解決了長期困擾的集羣管理難題，並提供了創建EKS集羣、部署容器化應用、實時故障排查、性能監控與優化、EKS集羣升級規劃等5個實戰案例來幫助您理解AI工具與EKS交互的方式，以及作為您實際應用中的參考。Amazon EKS MCP Server代表了這一演進的前沿，它將Kubernetes專業知識與AI助手能力相結合，創建了一個更智能、更直觀的雲原生管理範式。

📢限時插播：Amazon Q Developer 來幫你做應用啦！
🌟10分鐘幫你構建智能番茄鍾應用，1小時搞定新功能拓展、測試優化、文檔注程和部署
⏩快快點擊進入《Agentic Al 幫你做應用 -- 從0到1打造自己的智能番茄鍾》實驗
免費體驗企業級 AI 開發工具的真實效果吧
構建無限，探索啓程!

2. 技術架構深度解析

Model Context Protocol (MCP)技術解析：連接LLM與基礎設施的橋樑

Model Context Protocol (MCP)是一個開放協議，設計用於連接大語言模型(LLM)與外部工具和服務。它解決了LLM在實際應用中的一個核心限制：雖然這些模型擁有豐富的通用知識，但它們無法直接與實時系統交互或訪問最新數據。

MCP的核心原理：

工具調用標準化：定義了LLM如何發現、調用和使用外部工具的統一接口
上下文共享機制：允許LLM和工具之間高效交換信息和狀態
雙向通信流：支持從LLM到工具的調用，以及從工具到LLM的響應
工具定義標準：提供描述工具功能、參數和約束的結構化方式

在EKS MCP Server中，MCP成為連接LLM（如Amazon Q）與Kubernetes基礎設施的橋樑，使AI助手能夠：

理解和執行復雜的Kubernetes管理任務
訪問集羣狀態和資源信息
生成和應用配置
診斷問題並提供解決方案

這種集成徹底改變了工程師與Kubernetes的交互方式，從手動命令和YAML編寫轉變為自然語言對話和意圖表達。

EKS MCP Server是基於MCP協議構建的專用服務，連接Amazon Q Developer CLI與Amazon EKS環境，提供Kubernetes管理功能。其核心能力如下，

使AI代碼助手的用户能夠創建新的EKS集羣，包括完成所有前提條件，如專用VPC、網絡配置和EKS自動模式節點池，通過將請求轉換為適當的CloudFormation操作實現。
提供部署容器化應用程序的能力，可以通過應用現有的Kubernetes YAML文件，或根據用户提供的參數生成新的部署和服務清單。
支持EKS集羣內各種Kubernetes資源(如Pod、Service和Deployment)的完整生命週期管理，支持創建、讀取、更新、補丁和刪除操作。
提供列出Kubernetes資源的功能，可按命名空間、標籤和字段進行篩選，簡化了用户和大語言模型(LLM)收集Kubernetes應用程序和EKS基礎設施狀態信息的過程。
促進運維任務，如從特定Pod和容器中檢索日誌，或獲取與特定資源相關的Kubernetes事件，為直接用户和AI驅動的工作流提供故障排除和監控支持。
使用户能夠排查EKS集羣的問題。

EKS MCP Server的模塊化設計確保了高度的可擴展性和可維護性，使系統能夠適應不斷變化的需求和環境。同時，其標準化的接口使Amazon Q能夠通過自然語言理解用户意圖，並將其轉化為適當的Kubernetes操作，極大地簡化了集羣管理流程。讓我們以以”查看EKS集羣狀態”為例，展示Amazon Q Developer CLI、LLM、MCP協議與EKS服務之間的完整交互流程和數據傳遞過程。

EKS MCP Server作為為AI代碼助手，提供了完整的EKS和Kubernetes資源管理能力。簡單來説，它讓Amazon Q理解並可以直接

操作你的Kubernetes集羣，從創建集羣到部署應用，從監控到故障排除，全部通過自然語言對話完成。Amazon EKS MCP Server的核心願景是實現AI驅動的雲原生管理範式，通過將LLM的智能與Kubernetes的強大功能相結合，大幅提升運維效率和可靠性。

技術門檻降低：
- 將Kubernetes專業知識編碼到工具中，降低入門壁壘
- 通過自然語言簡化複雜概念和流程
效率顯著提升：
- 將小時級任務壓縮至分鐘或秒級
- 自動化重複性工作流程
- 減少上下文切換和工具切換開銷
一致性與可靠性保障：
- 應用內置的最佳實踐和安全措施
- 減少手動操作錯誤
- 提供可重複、可審計的操作記錄
智能故障排除：
- 提供上下文感知的問題診斷
- 自動關聯日誌、指標和事件
- 建議針對性解決方案和預防措施
全生命週期支持：
- 從集羣創建到應用部署再到監控維護
- 覆蓋開發、測試、生產全環節
- 支持基礎設施即代碼(IaC)和配置管理
適應性與可擴展性：
- 支持多樣化的EKS和Kubernetes環境
- 可通過自定義工具擴展功能
- 適應不斷髮展的雲原生生態系統

通過這些價值主張，EKS MCP Server正在重新定義雲原生管理的可能性，從傳統的”工具驅動”向”意圖驅動”模式轉變，使組織能夠更快速、更安全地實現雲基礎設施的價值。

3. 部署架構與環境配置

安裝準備工作

在安裝EKS MCP Server之前，需要確保您的環境滿足以下前提條件：

3.1 系統要求

Python 3.10或更高版本
有效的亞馬遜雲科技賬户和憑證
對目標EKS集羣的訪問權限

3.2 環境配置

配置Amazon CLI並驗證憑證
確認IAM權限滿足最低要求（EKS只讀權限或更高）

IAM 只讀權限策略，

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:DescribeCluster",
        "cloudformation:DescribeStacks",
        "cloudwatch:GetMetricData",
        "logs:StartQuery",
        "logs:GetQueryResults",
        "iam:GetRole",
        "iam:GetRolePolicy",
        "iam:ListRolePolicies",
        "iam:ListAttachedRolePolicies",
        "iam:GetPolicy",
        "iam:GetPolicyVersion",
        "eks-mcpserver:QueryKnowledgeBase"
      ],
      "Resource": "*"
    }
  ]
}

EKS Full Access權限策略（注意：此處展示的是具有完全訪問權限的策略，僅用於學習演示目的。在生產環境中，應當遵循最小權限原則，根據管理員職責範圍和實際需求配置精細化的權限策略。通配符權限（eks:*）會授予對所有EKS資源的完全控制權，這在安全性方面存在潛在風險。建議在實際部署中限制特定操作和資源範圍，以提高系統安全性。）

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Allow",
     "Action": "eks:*",
     "Resource": "*"
   }
 ]
}

3.3 Python環境準備

Install Python 3.10+
install the uv package manager
Install and configure the AWS CLI with credentials

安裝步驟詳解，以下是安裝EKS MCP Server的詳細步驟：

git clone https://github.com/awslabs/mcp.git
cd mcp/src/eks-mcp-server

3.4 配置Amazon Q開發者設置

創建或編輯~/.amazon-q/config.json文件，此配置文件設置Amazon Q與EKS MCP服務器的交互方式。它指定了服務器運行命令、工作目錄、環境變量以及自動批准的操作列表。通過這些設置，Amazon Q可以幫助開發者管理和監控EKS資源，而無需頻繁進行權限確認。您可以根據實際需求調整路徑、亞馬遜雲科技配置文件和區域設置。”autoApprove”部分定義了哪些操作可以自動執行，增強使用體驗的同時減少重複授權操作。：

{
  "mcpServers": {
    "awslabs.eks-mcp-server": { // 服務器標識名稱，用於在Amazon Q中識別此EKS MCP服務器
      "command": "uv", // 啓動命令：使用uv作為Python包管理和運行工具
      "args": [
        "run", // uv子命令：運行Python應用
        "--directory", // 指定工作目錄參數
        "/Users/eks/mcp/src/eks-mcp-server",  // EKS MCP服務器的安裝路徑
        "python",  // 使用Python解釋器
        "-m",  // 以模塊方式運行
        "awslabs.eks_mcp_server.server",  // 要運行的Python模塊路徑
        "--allow-write", // 允許寫操作權限（創建/修改K8s資源）
        "--allow-sensitive-data-access" // 允許訪問敏感數據（如Secrets、日誌等）
      ],
      "env": { // 環境變量配置，用於設置亞馬遜雲科技和日誌相關參數
        "aws_PROFILE": "default",
        // 亞馬遜雲科技配置文件名稱，對應~/.aws/credentials中的profile
        // 可以改為其他profile名稱，如"production"、"development"等
        "aws_REGION": "us-east-1",
        // 默認亞馬遜雲科技區域，EKS集羣必須在此區域
        // 常用區域：us-west-2, eu-west-1, ap-southeast-1等
        "FASTMCP_LOG_LEVEL": "INFO"
        // 日誌級別設置，控制輸出的詳細程度
        // 可選值：DEBUG（最詳細）、INFO（一般）、WARNING、ERROR（最少）
      },
      "autoApprove": [
      // 自動批准的工具列表，這些操作無需用户手動確認
      // 注意：自動批准會降低安全性，請根據需要調整
        "manage_eks_stacks", // EKS CloudFormation堆棧管理：創建、更新、刪除EKS集羣
        "manage_k8s_resource", // Kubernetes資源管理：創建、更新、刪除K8s對象（Pod、Service等）
        "list_k8s_resources", // 列出Kubernetes資源：查看集羣中的各種資源狀態
        "get_pod_logs", // 獲取Pod日誌：查看容器應用的運行日誌，用於故障排查
        "get_k8s_events", // 獲取Kubernetes事件：查看集羣中發生的事件和警告
        "get_cloudwatch_logs", // 獲取CloudWatch日誌：查看EKS控制平面和節點日誌
        "get_cloudwatch_metrics", // 獲取CloudWatch指標：監控集羣性能和資源使用情況
        "get_policies_for_role", // 獲取IAM角色策略：查看EKS相關的權限配置
        "search_eks_troubleshoot_guide", // 搜索EKS故障排除指南：獲取問題解決建議
        "list_api_versions" // 列出Kubernetes API版本：查看集羣支持的API版本
      ]
    }
  }
}

3.5 使用已安裝的MCP Server

若已安裝和配置EKS MCP Server，可通過Amazon Q Developer CLI直接使用：

q chat

在terminal輸出如下

在Amazon Q交互界面中，您可以通過自然語言執行EKS管理任務，例如：

“列出我的EKS集羣”
“在us-east-1創建一個新的EKS集羣”
“顯示default命名空間中的所有Pod”

嘗試基本命令

在交互界面中輸入任意語種的自然語言即可與Amazon Q Cli進行交互，比如以下示例我們均採用中文語言與Amazon Q Cli進行交互：

列出我所有的EKS集羣

檢查工具調用，您應該看到類似以下的輸出：

我將為您列出EKS集羣。
   
   [工具調用: list_clusters]
   region: us-east-1
   
   在us-east-1區域找到以下EKS集羣：

1. my-cluster-1 (1.30)
2. my-cluster-2 (1.31)

如果工具調用成功並返回結果，則表示安裝和配置成功。

4. 實戰案例：對話式EKS管理的威力

在這一章節，我們將通過幾個實戰案例，展示EKS MCP Server與Amazon Q Developer CLI的集成如何徹底改變Kubernetes管理體驗。這些案例基於真實工作場景，展示了通過自然語言對話完成複雜EKS任務的強大能力。

4.1 案例一：零基礎創建EKS集羣

場景描述：一位開發人員需要創建一個新的EKS集羣，但不熟悉CloudFormation模板或EKS配置細節。

對話實例

用户:

我需要在us-east-1區域創建一個名為"peculiar-funk-badger"的新EKS集羣，帶有3個節點，能幫我實現嗎？

Amazon Q:

我可以幫你在us-east-1區域創建一個名為"peculiar-funk-badger"的EKS集羣，包含3個節點。我會使用CloudFormation來完成這項工作。

首先，讓我查看你當前的EKS集羣情況，確認該名稱未被使用。

[工具調用: manage_eks_stacks]
operation: describe
cluster_name: peculiar-funk-badger

我會為你創建EKS集羣。這個操作將創建以下資源：
- 一個VPC及其相關聯的網絡組件（子網、路由表、NAT網關等）
- 必要的IAM角色和策略
- EKS集羣控制平面
- 包含3個節點的EKS節點組

這個操作需要一些時間完成（通常15-20分鐘）。你確定要創建這個集羣嗎？

[工具調用: manage_eks_stacks]
operation: deploy
cluster_name: peculiar-funk-badger
node_count: 3
region: us-east-1

已開始創建名為"peculiar-funk-badger"的EKS集羣。
CloudFormation堆棧"eks-peculiar-funk-badger"正在創建中。
你可以通過亞馬遜雲科技控制枱或命令行工具監控創建進度。
完成時間預計為15-20分鐘。

堆棧狀態: CREATE_IN_PROGRESS

技術解析

在這個交互中，EKS MCP Server通過manage_eks_stacks工具完成了幾個關鍵步驟：

資源驗證：檢查集羣名稱是否已存在
模板生成：自動生成適合的CloudFormation模板
資源預估：向用户説明將創建哪些資源
部署執行：調用 CloudFormation API創建所需資源

整個過程用户不需要了解任何CloudFormation語法或EKS資源配置細節，只需用自然語言表達意圖即可。

4.2 案例二：部署容器化應用

場景描述：團隊需要將一個簡單的微服務部署到現有EKS集羣，包括創建部署和服務。

對話實例

用户:

我想在peculiar-funk-badger集羣的demo-ns命名空間中部署nginx，並通過LoadBalancer暴露服務，能做到嗎？

Amazon Q:

我可以幫你在"peculiar-funk-badger"集羣的"demo-ns"命名空間中部署nginx，並通過LoadBalancer暴露服務。

首先，讓我檢查這個集羣和命名空間是否存在。

[工具調用: list_k8s_resources]
cluster_name: peculiar-funk-badger
kind: Namespace
api_version: v1

我沒有找到"demo-ns"命名空間。我會先創建這個命名空間，然後部署nginx。

[工具調用: manage_k8s_resource]
operation: create
cluster_name: peculiar-funk-badger
kind: Namespace
api_version: v1
name: demo-ns
body: {"apiVersion":"v1","kind":"Namespace","metadata":{"name":"demo-ns"}}

命名空間"demo-ns"已創建成功。

現在，我將生成nginx部署和服務的YAML清單，並應用到集羣。

[工具調用: generate_app_manifest]
app_name: nginx
image_uri: nginx:latest
output_dir: /tmp
port: 80
replicas: 2
cpu: "500m"
memory: "512Mi"
namespace: demo-ns
load_balancer_scheme: internet-facing

已生成應用清單：
- Deployment: nginx
- Service: nginx (LoadBalancer類型)

現在將這些清單應用到集羣：

[工具調用: apply_yaml]
cluster_name: peculiar-funk-badger
yaml_path: /tmp/nginx-manifests.yaml
namespace: demo-ns
force: true

部署已成功完成！

你的nginx應用已在"peculiar-funk-badger"的"demo-ns"命名空間中部署，並通過LoadBalancer暴露。服務將需要幾分鐘來配置並獲取外部IP地址。

你可以通過以下命令查看服務狀態和IP地址：

[工具調用: list_k8s_resources]
cluster_name: peculiar-funk-badger
kind: Service
api_version: v1
namespace: demo-ns
name: nginx

服務詳情：
- 名稱: nginx
- 類型: LoadBalancer
- 外部IP: a13b4c5d6e7f.us-east-1.elb.amazonaws.com (可能需要幾分鐘才會分配)
- 端口: 80

技術解析

這個交互展示了多個工具的協同工作：

環境驗證：使用list_k8s_resources檢查命名空間是否存在
資源創建：使用manage_k8s_resource創建命名空間
清單生成：使用generate_app_manifest生成適當的Kubernetes YAML
資源應用：使用apply_yaml將資源應用到集羣
狀態驗證：再次使用list_k8s_resources檢查部署狀態

整個過程展示了EKS MCP Server如何將複雜的Kubernetes部署流程簡化為一次簡單的對話交互，部署完成後的的應用架構圖如下，

4.3 案例三：實時故障排查

場景描述：一個生產應用出現故障，開發人員需要快速排查原因。

對話實例

用户:

我的payment-service應用在production命名空間下似乎不工作了，能幫我找出問題嗎？

Amazon Q:

我會幫你排查production命名空間中payment-service應用的問題。讓我們逐步檢查各種可能的故障點。

首先，讓我查看deployment的狀態：

[工具調用: list_k8s_resources]
cluster_name: peculiar-funk-badger
kind: Deployment
api_version: apps/v1
namespace: production
name: payment-service

我看到payment-service的deployment存在問題：
- 期望副本數: 3
- 可用副本數: 1
- 就緒副本數: 1
- 最新狀態副本數: 3

這表明有2個pod無法正常啓動。讓我查看相關pod的狀態：

[工具調用: list_k8s_resources]
cluster_name: peculiar-funk-badger
kind: Pod
api_version: v1
namespace: production
label_selector: app=payment-service

我找到了3個pod：
1. payment-service-7d8f9c6b5-abc12 (狀態: Running)
2. payment-service-7d8f9c6b5-def34 (狀態: CrashLoopBackOff)
3. payment-service-7d8f9c6b5-ghi56 (狀態: CrashLoopBackOff)

有兩個pod處於CrashLoopBackOff狀態，這表明它們無法成功啓動。讓我檢查其中一個失敗pod的日誌：

[工具調用: get_pod_logs]
cluster_name: peculiar-funk-badger
pod_name: payment-service-7d8f9c6b5-def34
namespace: production
tail_lines: 50

日誌顯示以下錯誤：
Error: could not connect to database at db-service:5432
failed to initialize database connection
retrying in 5 seconds...
Error: could not connect to database at db-service:5432
failed to initialize database connection
retrying in 5 seconds...




現在讓我檢查相關的Kubernetes事件，可能提供更多線索：

[工具調用: get_k8s_events]
cluster_name: peculiar-funk-badger
kind: Pod
name: payment-service-7d8f9c6b5-def34
namespace: production

我發現了問題所在！根據日誌和事件分析：
1. payment-service無法連接到數據庫服務(db-service)
2. 讓我檢查db-service是否存在並正常運行

[工具調用: list_k8s_resources]
cluster_name: peculiar-funk-badger
kind: Service
api_version: v1
namespace: production
name: db-service

我發現db-service存在，但沒有對應的pod在運行。讓我檢查數據庫deployment：

[工具調用: list_k8s_resources]
cluster_name: peculiar-funk-badger
kind: Deployment
api_version: apps/v1
namespace: production
name: db-service

數據庫deployment存在問題：
- 期望副本數: 1
- 可用副本數: 0
- 就緒副本數: 0

根據我的分析，問題是：
1. 數據庫服務(db-service)的pod沒有正常運行
2. 導致payment-service無法連接數據庫而崩潰
3. 建議首先修復數據庫部署問題

你要我進一步檢查數據庫pod的狀態和日誌嗎？

技術解析

這個案例展示了EKS MCP Server在故障排查中的強大能力：

系統分析：自動檢查部署狀態、Pod狀態等關鍵指標
日誌收集：使用get_pod_logs獲取關鍵錯誤信息
事件關聯：通過get_k8s_events收集相關事件
根因分析：基於收集的信息推斷問題根源
關聯服務檢查：擴展到相關服務(數據庫)的狀態檢查

整個過程模擬了有經驗的Kubernetes工程師的思維方式，提供了系統性的故障排查流程。

4.4 案例四：性能監控與優化

場景描述：運維團隊需要了解應用的資源使用情況，優化資源分配。

對話實例

用户:

我想了解inventory-ver1服務在過去30分鐘的CPU和內存使用情況，以便我們優化資源配置

Amazon Q:

我會幫你獲取過去30分鐘inventory-ver1服務的CPU和內存使用情況。

首先，讓我瞭解一下在查詢容器指標時應該使用哪些指標和維度：

[工具調用: get_eks_metrics_guidance]
resource_type: pod

感謝您的耐心等待。現在我來查詢api-gateway的CPU使用情況：

[工具調用: get_cloudwatch_metrics]
cluster_name: peculiar-funk-badger
metric_name: pod_cpu_utilization
namespace: ContainerInsights
dimensions: {"ClusterName":"peculiar-funk-badger","PodName":"inventory-ver1"}
minutes: 30
period: 60
stat: Average

接下來查詢內存使用情況：

[工具調用: get_cloudwatch_metrics]
cluster_name: peculiar-funk-badger
metric_name: pod_memory_utilization
namespace: ContainerInsights
dimensions: {"ClusterName":"peculiar-funk-badger","PodName":"inventory-ver1"}
minutes: 30
period: 60
stat: Average

基於收集到的指標，我為你整理了inventory-ver1服務的資源使用情況：

**CPU使用情況**:
- 平均使用率: 37.5%
- 峯值使用率: 65.2% (在22:45出現)
- 最低使用率: 12.3% (在22:30出現)

**內存使用情況**:
- 平均使用率: 42.8%
- 峯值使用率: 45.6% (持續穩定)
- 最低使用率: 40.2% (啓動階段)

**資源優化建議**:
1. **CPU資源**: 目前的設置似乎合理，有足夠的頭部空間應對峯值，但不會過度浪費。如果當前設置為1000m (1 vCPU)，可以考慮調整到750m，仍能應對當前負載。

2. **內存資源**: 內存使用相對穩定，峯值僅為45.6%。如果當前設置為1Gi，可以安全降低到768Mi，為集羣釋放資源。

3. **擴展策略**: 基於CPU使用模式，建議設置HPA (Horizontal Pod Autoscaler)：
   - CPU目標使用率: 60%
   - 最小副本數: 2
   - 最大副本數: 5

你希望我幫你實施這些建議中的哪一個？或者你需要更多的數據分析？

技術解析

這個案例展示了EKS MCP Server在性能監控與優化方面的應用：

指標指南獲取：使用get_eks_metrics_guidance瞭解可用指標
CPU指標收集：使用get_cloudwatch_metrics獲取CPU使用數據
內存指標收集：同樣獲取內存使用數據
數據分析：對收集的時序數據進行分析
最佳實踐建議：基於數據分析提供具體的資源優化建議

整個流程展示瞭如何將複雜的指標收集與分析轉化為明確的操作建議。

4.5 案例五：EKS集羣升級方案設計與規劃

場景描述：

客户需要將業務關鍵型EKS集羣從1.31版本升級到1.32版本，要求升級過程中不能影響線上業務。客户需要一個詳細的升級規劃方案，按照控制平面、插件組件(add-on)和數據平面的順序進行升級。

對話實例

用户:

請幫我規劃設計目前eks集羣peculiar-funk-badger從1.31到1.32的升級方案，
在升級的過程中不能影響線上業務，目前只規劃和設計，不需要執行升級。

Amazon Q:

我來幫您規劃設計EKS集羣peculiar-funk-badger從1.31到1.32的無中斷升級方案。
首先讓我獲取當前集羣的詳細信息來制定合適的升級策略。

[工具調用: manage_eks_stacks]
operation: describe
cluster_name: peculiar-funk-badger

讓我通過Amazon CLI直接查看集羣信息：

[工具調用: use_aws]
service: eks
operation: describe-cluster
parameters: {"name": "peculiar-funk-badger"}
region: us-east-1
label: Get EKS cluster details

現在讓我查看節點組信息：

[工具調用: use_aws]
service: eks
operation: list-nodegroups
parameters: {"cluster-name": "peculiar-funk-badger"}
region: us-east-1
label: List EKS nodegroups

讓我獲取每個節點組的詳細信息：

[工具調用: use_aws]
service: eks
operation: describe-nodegroup
parameters: {"nodegroup-name": "mng", "cluster-name": "peculiar-funk-badger"}
region: us-east-1
label: Describe first nodegroup

[工具調用: use_aws]
service: eks
operation: describe-nodegroup
parameters: {"cluster-name": "peculiar-funk-badger", "nodegroup-name": "x86-c6a-large-nodegroup"}
region: us-east-1
label: Describe second nodegroup

現在讓我查看集羣中運行的工作負載：

[工具調用: list_k8s_resources]
cluster_name: peculiar-funk-badger
kind: Deployment
api_version: apps/v1

現在讓我查看集羣中的插件信息：

[工具調用: use_aws]
service: eks
operation: list-addons
parameters: {"cluster-name": "peculiar-funk-badger"}
region: us-east-1
label: List EKS addons

讓我查看一些關鍵插件的版本信息：

[工具調用: use_aws]
service: eks
operation: describe-addon
parameters: {"addon-name": "coredns", "cluster-name": "peculiar-funk-badger"}
region: us-east-1
label: Describe coredns addon

基於收集到的信息，我為您制定以下EKS集羣peculiar-funk-badger從1.31到1.32的無中斷升級方案：

EKS集羣升級方案：peculiar-funk-badger (1.31 → 1.32)
當前集羣狀態分析
集羣基本信息：
集羣名稱：peculiar-funk-badger
當前版本：1.31
創建時間：2025-05-07
狀態：ACTIVE
認證模式：API
節點組配置：
mng：2個節點（最小2，最大2），使用自定義AMI
x86-c6a-large-nodegroup：1個節點（最小1，最大3），使用AL2_x86_64 AMI
關鍵工作負載：
業務應用：inventory-ver1, parking, review, nginx-simple（default命名空間）
Istio服務網格：istiod, istio-ingressgateway, grafana, kiali, jaeger, prometheus
系統組件：coredns, aws-load-balancer-controller, metrics-server等
升級策略與時間規劃
階段1：升級前準備（預計1-2小時）
1.1 兼容性檢查
# 檢查Kubernetes 1.32的API變更和棄用
# 驗證當前工作負載與1.32的兼容性
# 特別關注Istio 1.25.2與K8s 1.32的兼容性

1.2 備份關鍵配置
備份所有應用的YAML配置
導出重要的ConfigMap和Secret
記錄當前插件版本和配置

1.3 擴容準備
將x86-c6a-large-nodegroup擴容至3個節點（為滾動升級提供緩衝）
確保有足夠的計算資源處理工作負載遷移
階段2：控制平面升級（預計30-45分鐘）

2.1 升級EKS控制平面
aws eks update-cluster-version \
    --region us-east-1 \
    --name peculiar-funk-badger \
    --kubernetes-version 1.32

影響評估：
控制平面升級期間API服務器會短暫不可用（通常<5分鐘）
現有Pod不受影響，繼續正常運行
新的Pod調度會暫停

階段3：插件升級（預計45-60分鐘）
3.1 核心插件升級順序
vpc-cni → 1.32兼容版本
coredns → 1.32兼容版本  
kube-proxy → 1.32兼容版本
aws-ebs-csi-driver → 最新兼容版本
metrics-server → 最新兼容版本

3.2 升級命令示例
aws eks update-addon \
    --cluster-name peculiar-funk-badger \
    --addon-name vpc-cni \
    --addon-version <1.32-compatible-version> \
    --resolve-conflicts OVERWRITE

階段4：節點組升級（預計60-90分鐘）
4.1 升級策略
採用滾動升級方式，確保業務連續性
先升級x86-c6a-large-nodegroup，再升級mng
利用maxUnavailable=1的配置逐個替換節點

4.2 節點組升級命令
# 升級x86-c6a-large-nodegroup
aws eks update-nodegroup-version \
    --cluster-name peculiar-funk-badger \
    --nodegroup-name x86-c6a-large-nodegroup \
    --kubernetes-version 1.32

# 升級mng
aws eks update-nodegroup-version \
    --cluster-name peculiar-funk-badger \
    --nodegroup-name mng \
    --kubernetes-version 1.32
業務連續性保障措施
1. Pod分佈策略
確保關鍵應用（inventory-ver1, parking, review）的Pod分佈在不同節點
利用Pod反親和性規則避免單點故障

2. 健康檢查增強
在升級期間增加應用健康檢查頻率
監控Istio網關和服務網格連通性

3. 流量管理
利用Istio的流量管理功能實現優雅的服務遷移
配置適當的超時和重試策略

4. 回滾準備
保留原始節點組配置
準備快速回滾腳本和流程
風險評估與緩解
1.主要風險
Istio兼容性：Istio 1.25.2可能需要更新以完全支持K8s 1.32
自定義AMI：mng使用自定義AMI，需要確保1.32兼容性
應用依賴：某些應用可能依賴特定的Kubernetes API版本

2.緩解措施
分階段升級：先升級測試環境驗證兼容性
藍綠部署：考慮為關鍵應用實施藍綠部署策略
監控告警：設置詳細的監控告警機制

3.總體時間估算
總升級時間：3-4小時
業務影響：最小化，預期<5分鐘的API服務器不可用
建議執行時間：業務低峯期（如凌晨2-6點）

4.升級後優化建議
節點組優化：升級完成後可以考慮統一節點組配置
資源調整：根據1.32的新特性調整資源配置
安全加固：應用1.32版本的安全最佳實踐
這個升級方案確保了業務連續性，通過分階段、滾動升級的方式最小化對線上服務的影響。建議在執行前先在測試環境進行完整的升級演練。

技術解析

這個案例展示了AI助手如何構建全面的EKS集羣升級規劃：

系統性信息收集：通過多種工具全面收集集羣狀態，包括：

集羣核心配置（版本、平台版本等）
節點組配置與容量
運行中的工作負載狀態
現有插件版本與配置

多維度分析與規劃：基於收集到的數據進行深入分析，設計了符合最佳實踐的升級路徑：

按照控制平面→插件→數據平面的嚴格升級順序
為每個階段提供具體的命令和步驟
對每個階段可能的影響進行評估

業務連續性設計：針對客户”不影響業務”的核心要求，設計了多層次的保護措施：

節點擴容緩衝策略
滾動更新與Pod分佈策略
基於Istio的流量管理
全面的備份與回滾準備

風險管理與監控：通過識別潛在風險點並提供緩解措施，結合詳細的監控計劃，確保升級過程可控可觀測：

識別關鍵組件兼容性風險
設計分步驗證流程
提供具體的監控命令

這個案例展示了AI如何像經驗豐富的雲原生架構師一樣，能夠從簡單的用户需求出發，通過系統性的信息收集和專業分析，生成一個全面、實用且符合亞馬遜雲科技最佳實踐的EKS升級方案。整個方案嚴格遵循控制平面→插件組件→數據平面的升級順序，並特別關注業務連續性保障，體現了AI在複雜雲基礎設施管理中的實際應用價值。

4.6 實戰案例總結

通過這些實戰案例，我們可以看到EKS MCP Server與Amazon Q Developer CLI集成帶來的顯著優勢：

知識門檻降低：無需深入瞭解Kubernetes或EKS的複雜細節
操作效率提升：通過自然語言完成複雜任務，無需記憶命令和參數
智能化故障排查：系統性分析問題，提供專業級別的故障診斷
決策支持增強：基於數據分析提供具體的優化建議

這種對話式Kubernetes管理方式特別適合以下場景：

對Kubernetes不熟悉的開發團隊
需要快速解決問題的生產環境
資源優化和性能調優
複雜多集羣環境管理

最重要的是，這種方式不僅提高了效率，也降低了操作錯誤的風險，為團隊提供了一種更安全、更智能的雲原生管理範式。

5. EKS MCP Server的價值與未來展望

在雲原生時代，Kubernetes已成為容器編排的事實標準，而Amazon EKS作為託管Kubernetes服務，為眾多企業提供了強大的容器部署平台。然而，Kubernetes的複雜性一直是阻礙其廣泛採用的因素之一。EKS MCP Server的出現，標誌着一種全新的交互範式誕生，它徹底改變了我們與EKS集羣交互的方式。

EKS MCP Server通過將複雜的Kubernetes操作轉化為自然語言對話，實現了從”命令式”到”意圖式”的管理模式轉變。這種轉變意味着用户不再需要記憶大量命令、參數和YAML語法，而是可以直接表達他們的意圖，由系統智能地解析並執行相應操作。

通過自然語言理解、智能工具集成和上下文感知等技術，EKS MCP Server正在重塑EKS集羣管理的體驗，使之更加直觀、高效且富有洞察力。隨着技術的不斷成熟，我們有理由相信，這種”對話式Kubernetes管理”模式將成為未來雲原生運維的主流範式。

在企業全面擁抱雲原生架構的今天，EKS MCP Server提供了一條降低複雜性、提升效率、加速創新的道路。無論您是剛開始Kubernetes之旅，還是尋求優化現有EKS環境，EKS MCP Server都能為您提供顯著價值，助力您在雲原生時代保持競爭優勢。

*前述特定亞馬遜雲科技生成式人工智能相關的服務目前在亞馬遜雲科技海外區域可用。亞馬遜雲科技中國區域相關雲服務由西雲數據和光環新網運營，具體信息以中國區域官網為準。

本篇作者

本期最新實驗為《Agentic AI 幫你做應用 —— 從0到1打造自己的智能番茄鍾》
✨ 自然語言玩轉命令行，10分鐘幫你構建應用，1小時搞定新功能拓展、測試優化、文檔註釋和部署
💪 免費體驗企業級 AI 開發工具，質量+安全全掌控
⏩️[點擊進入實驗] 即刻開啓 AI 開發之旅
構建無限, 探索啓程！

亞馬遜雲開發者博客

亞馬遜雲開發者博客

博客 / 詳情