導入MCP串接維運工具　用自然語言管理K8s叢集

在現代化企業的IT與DevOps日常維運情境中，Kubernetes（K8s）無疑已成為容器化應用部署與管理的標準平台。然而，傳統的K8s維運模式高度依賴工程師手動輸入kubectl指令，包括檢查Pod運作狀態、追蹤日誌（Logs）、網路與儲存設定故障排除、YAML檔案的建立與部署、變更與刪除等容器的CRUD生命週期等等操作步驟。

這不僅需要維運人員具備極高的指令熟練度，在面對複雜叢集架構或緊急進行故障排除作業時，頻繁地切換視窗與人為診斷程序，也相對容易拉長平均修復時間（MTTR），甚至可能因為維護人員的疲勞程度，而增加人為操作上的風險，例如打錯字或指令導致誤刪某個容器，造成已經有問題的服務雪上加霜。

隨著生成式AI模型的爆發性成長，「AI驅動維運」（AIOps）已經從初始概念走向逐步實踐。在傳統作法上，大多是將LLM大型語言模型作為聊天機器人的方式使用，管理人員需要自行複製內容後貼上，再讓LLM大型語言模型進行判讀和解說。

然而，透過最新開放的「模型上下文協定」（Model Context Protocol，MCP），能夠進一步達成打通AI大腦與實際基礎架構之間的雙向通道，讓AI助手具備直接呼叫工具，並且執行K8s叢集診斷與維運操控的能力，賦予管理Kubernetes叢集環境真正的思考與執行力，如圖1所示。

MCP-Kubernetes運作架構

傳統上，LLM大型語言模型雖然具備強大的文字理解與產生程式碼的能力，然而因為缺乏與外部系統互動的手跟腳，所以只能停留在一問一答之間的簡易互動階段。

因此，若要讓AI能夠直接幫管理人員管理Kubernetes叢集，就必須建立一套標準化的互動機制，微軟官方所發布的Azure/mcp-kubernetes，正是為了打通這最後一哩路而生的核心元件。

簡單來說，MCP Server扮演著AI助手與Kubernetes叢集之間的轉譯器與安全閘道角色，當管理人員在VS Code操作介面中透過自然語言下達管理指令時，整體的呼叫與執行流程為下列幾項步驟，如圖2所示：

‧意圖解析與工具呼叫：當管理人員送出自然語言請求，例如請幫我檢查frontend namespace下的Pod運作狀態，經過AI助手分析使用者傳送的意圖後，將其轉換為標準的MCP工具呼叫格式，然後傳送至mcp-kubernetes-server，也就是流程運作示意圖中MCP Request的工作階段。

‧安全驗證與指令轉譯：當mcp-kubernetes-server接收到請求後，會先進行「權限等級」（Access Level）的驗證程序，順利通過驗證程序後，系統便會依據設定的運作模式，將請求透過Kubernetes SDK封裝為Direct API Request，然後由Shell Process工作階段建構出正確對應的kubectl管理指令。

‧叢集管理與結果回傳：系統將Kubectl管理指令交給底層的Kubernetes Client或Shell執行，並對Kubernetes叢集發出請求，此時Kubernetes叢集回應的Raw Data，例如JSON或文字輸出，會先傳回MCP Server進行結構化處理，再轉譯成LLM大型語言模型能夠理解的Context，同時封裝成為MCP Response之後回傳給AI助手，呈現最終的執行結果或是故障排除的診斷報告。

新式設計有效降低Token消耗

事實上，早期MCP工具的設計架構，通常會針對不同管理動作拆開為6到7個獨立的工具，例如get_pods、describe_node等等管理指令，然而此舉會導致AI模型在每次對話時，都需要載入大量的工具Schema，導致產生許多額外的上下文，造成Token大量消耗的情況。

現在，採用新式運作架構的Azure/mcp-kubernetes，預設採用了統一工具介面（Unified Tools）的策略：

‧call_kubectl：統一指令工具，只透過單一工具即可封裝所有的kubectl指令與參數，例如「kubectl get pods -n frontend -o wide」，管理指令無須再進行指令與參數的拆分工作任務。

‧call_az：Azure CLI統一工具，適用於企業和組織管理Azure雲端環境，直接將Azure CLI指令封裝，例如「az aks list –resource-group myRG」，方便AI助手診斷Azure雲端資源，以及Kubernetes叢集的跨層級診斷作業。

‧進階延伸工具組：除了基礎的call_kubectl之外，mcp-kubernetes運作架構也支援針對Helm（call_helm）、網路觀測（call_cilium/call_hubble）以及網路資源（aks_network_resources）的統一呼叫介面，大幅擴充AI助手針對企業和組織正式營運環境的守備範圍。

存取權限管控機制

對於企業和組織來說，引進AIOps自動化管理維護機制時，最擔心的莫過於AI發生失控或因為幻覺，導致錯誤操作或者更嚴重誤刪正式環境的相關資源，反而讓正式營運環境發生中斷的情況。因此，為了避免發生不可預期的錯誤情況產生，mcp-kubernetes提供基於「角色導向存取控制」（Role-Based Access Control，RBAC）的嚴格權限隔離機制。

更重要的是，MCP Server在執行Kubernetes叢集任何操作管理作業時，無須從頭來過重新設定RBAC權限原則，而是能夠完全繼承現有的Kubernetes RBAC與Azure RBAC權限原則，讓管理人員能夠輕易套用現有的RBAC權限原則進行管控作業。

在部署與設定MCP Server時，例如在mcp.json設定檔當中，可以透過「–access-level」參數來管控AI助手的操作權限：

‧readonly（預設值）：唯讀模式，在唯讀模式運作時，MCP Server只會向AI助手公開查詢相關類型的工具介面，因此AI助手只能執行get、describe、logs等等讀取動作，即便管理人員下達刪除指令，AI助手也無法透過MCP程序執行變更作業，非常適合用於日常診斷與了解故障情況的運作情境。

‧readwrite：讀取和寫入模式，在讀寫模式運作的情況下，AI助手將被允許執行Kubernetes叢集資源變更指令，例如create、apply、scale、delete等等管理指令。在本文實戰中，為了讓AI助手能夠自動部署Nginx網頁容器工作負載，便會採用此權限等級。

‧admin：完全管理模式，在此模式中將會釋放所有Kubernetes叢集的進階管理權限，包括Kubernetes節點隔離（cordon）、資源驅逐（drain）與污點設定（taint）等等高風險作業，專門提供給已經完成最佳化調校，且非常熟練的管理人員使用，以提供AIOps自動化維運管理機制。

實戰導入MCP Server

在實作演練中，將帶領大家從零開始，在Windows Server 2025作業系統中，採用輕量級且適合邊緣與企業地端環境的Azure Kubernetes Service Edge Essentials（AKS-EE），建構Kubernetes叢集環境，並且採用Ollama以擔任地端執行的開源AI助手的角色，安裝VSCode來擔任屆時MCP Client的角色，最後再搭配專屬的Azure/mcp-kubernetes擔任MCP Server的角色，達成一套完全自主可控、高資安等級的智慧維運體系。整體架構主要由以下四大核心元件相互協作：

‧基礎架構與容器平台：在Windows Server 2025系統中，安裝及建構以AKS EE – K3s為核心的輕量級Kubernetes叢集運作環境。

‧MCP Server工具服務端：將擔任MCP Server角色的Azure/mcp-kubernetes，部署於Kubernetes叢集內，以便封裝Kubernetes API指令，並轉換為AI助手可以理解與呼叫的標準工具介面。

‧本地端AI助手：在Windows Server 2025系統中，使用Ollama載入Gemma4:e4b開源模型，以便在Kubernetes叢集環境中，接收管理人員需求後，進行邏輯推理並決策能夠執行的kubectl指令，確保企業組織的機敏資料不外流。

‧MCP Client互動管理前端：透過安裝VSCode運作環境，並載入Continue extension和組態設定後，一旦正確連結MCP Server後溝通便正式打通，即可成為管理人員與MCP Server的互動介面，後續便能透過MCP Protocol送出管理人員的請求，達成透過自然語言與Kubernetes叢集互動的整合體驗。

部署K3s叢集環境

為了讓管理人員能夠在企業地端環境中安全且快速地驗證AIOps維運機制，這裡將採用微軟官方的輕量化Kubernetes叢集解決方案AKS-EE。事實上，AKS-EE同時支援K3s與K8s兩種版本，在本文實戰環境中，將採用效能優異且資源占用極低的K3s核心，建立單機版本的Kubernetes叢集以利運作測試環境。

在下載並執行AKS Edge Essentials K3s安裝檔案後，執行「Import-Module AksEdge -Verbose」指令，確保正確匯入AksEdge PowerShell模組，然後執行「Install-AksEdgeHostFeatures -Confirm:$false」指令，確認目前Windows Server 2025伺服器主機的環境需求是否滿足，包括Hyper-V、OpenSSH與電源設定，倘若系統提示需要重新啟動，依照指示重新啟動伺服器以便套用生效。重新啟動後，再次執行確保滿足AKS EE運作環境需求，如圖3所示。

完成主機環境準備後，接著產生AKS-EE部署設定檔，以便稍後啟動K3s叢集建構程序，執行New-AksEdgeConfig指令，產生名稱為aksedge-config.json的部署設定檔，開啟JSON部署設定檔後，原則上只要修改第6行的參數，將原本的「ServiceIPRangeSize: 0」參數值中數字0修改成「10」即可存檔離開。

執行New-AksEdgeDeployment指令，並搭配剛才修改完成的aksedge-config.json部署設定檔，系統便立即執行K3s叢集的部署作業，整個建置時間大約需要5～10分鐘時間，期間系統會自動建立Kubernetes叢集基礎虛擬網路，以及AKS EE Linux VM並完成K3s叢集的初始化程序。

當K3s叢集部署完成後，如果發生kubectl指令找不到的情況時，記得將AksEdge內建kubectl路徑加入系統環境變數中即可。接著，執行「kubectl get nodes -o wide」和「kubectl get pods -A -o wide」指令，確認Kubernetes叢集的Node狀態為Ready，並且系統Pods均為Running狀態，便代表K3s叢集基礎架構已經部署完成，如圖4所示。

為了驗證K3s叢集的Pod排程與網路路由服務是否運作正常，先部署一個微軟官方提供範例Linux應用程式（linux-sample.yaml），執行「kubectl apply -f」指令搭配YAML檔案路徑即可進行部署任務。當Kubernetes叢集順利部署Pods容器後，執行「kubectl get pods -o wide」指令進行驗證，系統將會為Service的EXTERNAL-IP指派IP位址，例如192.168.0.4，執行「kubectl get services」指令進行驗證，如圖5所示。

現在，即可開啟瀏覽器並輸入「192.168.0.4」的IP位址測試服務連線，如圖6所示，倘若運作環境無法順利指派獨立外部IP位址，也可以透過Get-AksEdgeNodeAddr指令，取得Linux Node的IP位址，並搭配Service對應的NodePort，例如本文實作環境為30600，即可在瀏覽器鍵入Linux Node的IP位址，搭配Service對應的NodePort，例如「http://192.168.0.2:30600」進行連線測試。

除了範例Linux應用程式外，也能快速部署Metrics Server資監控元件（metrics-server.yaml），以便後續AI助手能夠透過MCP機制，查詢Kubernetes叢集的CPU與Memory即時資源消耗情況，同樣執行「kubectl apply -f」指令並搭配YAML檔案路徑。

當Kubernetes叢集順利部署Pods容器後，執行「kubectl top nodes」和「kubectl top pods -A」指令，即可查詢Nodes和Pods目前CPU與Memory的使用量百分比，如圖7所示。

部署本地端AI助手

為了確保企業組織在推動AIOps自動化維運時，內部Kubernetes叢集的機敏資訊，以及Pods紀錄與網路架構不致外洩，部署於地端環境且具備高隱私性的AI助手執行引擎便成為關鍵。在本文實作環境中，採用目前LLM社群非常受歡迎並且部署簡便的Ollama作為大型語言模型執行引擎。

在Windows Server 2025伺服器環境中，管理人員可以透過Windows Package Manager（winget）套件管理工具，快速完成Ollama平台的安裝作業。開啟PowerShell指令視窗，並執行「winget install Ollama.Ollama」指令進行安裝的工作任務。

安裝完成後，為了讓目前的PowerShell工作階段能夠即時套用系統路徑，執行環境變數更新指令，並執行「ollama –version」指令檢查安裝的Ollama版本。同時，為了確保Ollama服務是否已在背景順利啟動並監聽預設Port 11434，可執行「Invoke-RestMethod -Uri “http://localhost:11434″」指令進行API連線測試。當系統回傳「Ollama is running」文字時，表示地端LLM服務基礎架構已經都準備完成，如圖8所示。

執行「ollama pull gemma4:e4b」指令，將Google的開源Gemma模型下載至本地端伺服器中。下載作業完成後，執行「ollama list」指令驗證模型清單，確認gemma4:e4b模型已成功載入系統中，然後開啟瀏覽器鍵入「http://localhost:11434/api/tags」，如圖9所示，透過Ollama API介面再次確認本地模型標籤與詳細資訊。至此，專為Kubernetes叢集於地端維運環境的AI大腦已經部署完成。

部署及測試MCP Server

接著，部署扮演Bridge核心角色Azure/mcp-kubernetes的MCP Server，讓AI助手具備將自然語言轉譯為kubectl指令，並且執行Kubernetes叢集管理作業的能力。

在Windows Server 2025伺服器環境中，建立路徑為「C:\mcp-server」資料夾，並下載最新版本的Azure Kubernetes MCP Server可執行檔（aks-mcp-windows-amd64.exe），然後重新命名為mcp-kubernetes.exe的友善名稱，即可在本地端手動啟動並測試MCP Server的運作狀態。

由於MCP Server需要存取Kubernetes叢集，因此必須設定KUBECONFIG環境變數，指引MCP Server讀取叢集金鑰設定檔，例如存取「C:\Users\weithenn.kube\config」路徑。同時，為了讓稍後的AI助手能夠順利進行Kubernetes叢集資源的CRUD操作，在啟動時帶入「–access-level=readwrite」與「–enabled-components=kubectl」參數，為MCP Server賦予讀寫權限並開啟kubectl工具元件，如圖10所示。

當MCP Server順利啟動，並且輸出MCP服務的連線與工具載入資訊時，表示MCP Server已經順利綁定地端Kubernetes叢集權限，同時準備好接受AI助手的溝通與指令轉譯請求。

組態設定MCP Client

在Windows Server 2025伺服器環境中，同樣可以透過winget套件管理工具快速完成VS Code的安裝作業。開啟PowerShell指令視窗，執行「winget install Microsoft.VisualStudioCode」指令進行安裝的工作任務。待安裝作業完成後，開啟VS Code並前往Extensions擴充功能頁面，搜尋並安裝「Continue」擴充功能，如圖11所示，安裝完成後，系統會在VS Code左側導覽列新增Continue圖示。

接著，必須設定Continue套件的config.yaml設定檔，以便將本地端Ollama運行的gemma4:e4b模型註冊為預設AI助手，同時將剛才部署好的mcp-kubernetes.exe綁定為MCP Server。

點擊Continue介面右上角的齒輪圖示，開啟設定檔視窗並填入設定內容，在config.yaml設定檔內容中，透過systemMessage參數明確規範AI助手必須扮演專業的Kubernetes專家，並且強制要求全程使用繁體中文進行回應。

在mcpServers區段中，則指引Continue必須載入「C:\mcp-server\mcp-kubernetes.exe」路徑，並帶入讀取和寫入權限（–access-level=readwrite）與kubectl元件，同時指定KUBECONFIG檔案路徑。

當Continue組態設定檔存檔完成並重新載入後，點選Tools項目，確保看到的MCP Server（kubernetes）項目為綠燈，並且可以看到Tools中有call_kubectl統一指令工具可供使用。值得一提的是，call_kubectl分別提供Automatic、Ask First與Excluded三種選項，用來管控AI助手呼叫該工具時的自動化授權程度，如圖12所示：

‧Ask First（預設值）：詢問後執行或拒絕，當AI助手判斷需要呼叫MCP工具時，必須先在VS Code對話視窗中跳出確認提示，經過管理人員手動點擊「同意」（Accept）之後，系統才會真正執行該工具管理指令，倘若點擊「拒絕」（Reject）則停止執行。此設定能提供「人工介入審核」（Human In The Loop，HITL）安全機制，避免AI助手在未告知的情況下執行變更作業。

‧Automatic：自動直接執行，當AI助手判斷需要呼叫MCP工具時，無須經過管理人員手動點擊確認，系統會直接自動呼叫並執行相關工具指令，此模式適合用於單純的查詢作業，例如唯讀的get或describe，或者已經相當成熟且高度信任的自動化維運情境。

‧Excluded：將該MCP工具完全停用與排除，採用此選項後，即使MCP Server本身有提供該工具功能，Continue也不會將其Schema載入給AI助手，AI助手在對話時也無法使用該工具進行任何操作。

AI助手實戰演練

完成地端AI助手與MCP Server部署程序後，即可正式進入實戰演練環節。現在，管理人員將透過自然語言，讓AI助手自動在Kubernetes叢集中，完成一系列的資源建立任務，包括部署獨立的Namespace、部署Nginx應用程式、設定副本數（Replicas）以及配置外部網路存取服務。

開啟VS Code介面並切換至Continue對話視窗，在對話方塊中輸入下列Prompt提示詞，交由AI助手進行意圖分析與指令執行：

1. 請幫我在Kubernetes叢集中，建立一個名稱為frontend的Namespace，並在裡面部署一個名稱為web-nginx的Nginx應用程式，使用nginx:alpine鏡像，Replicas設定為3，並建立一個Port 80的EXTERNAL-IP以便部署完成後能存取網頁服務。
2. 建立完成後檢查Pod和EXTERNAL-IP是否正常運作。
3. 請全程使用繁體中文回答。

當Prompt提示詞傳送後，本文實作環境的地端AI助手（Gemma4），在收到請求後便會立即分析管理人員的請求，並自動建構對應的kubectl指令，由於MCP工具原則已經採用預設值的Ask First，所以當AI助手呼叫call_kubectl統一工具執行指令進行部署作業時，VS Code對話視窗便會跳出工具執行確認提示，管理人員可以點擊「同意」（Accept）同意執行，或點擊「拒絕」（Reject）停止執行，一旦同意執行後，AI助手便會透過MCP Server依序執行建立frontend Namespace、部署web-nginx Deployment、建立LoadBalancer類型Service的管理指令。

事實上，在部署過程中可以清楚看到AI助手的思考模式和執行方式，當然執行過程中需要得到「同意」（Accept）權限才能繼續執行下一個動作，所以可能需要按下多次同意才行。

當部署作業完成後，可以在VSCode的Terminal視窗中執行「kubectl get all -n frontend」指令，驗證frontend Namespace底下的資源狀態，確認3個Nginx Pods是否處於Running狀態，並且Service也順利指派了對應的EXTERNAL-IP，例如本文實作環境為192.168.0.5，開啟Edge瀏覽器，並鍵入EXTERNAL-IP位址http://192.168.0.5，即可成功連線並看到Nginx預設網頁，如圖13所示，至此順利完成由AI助手驅動部署Kubernetes資源自動化工作任務。

＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞