一、項目背景

    1.傳統運維的痛點與挑戰

    2.Kubernetes 與 Operator 的優勢

    3.平臺建設的核心目標

二、建設歷程

    1.平臺架構概覽

    2.多云管理：跨云資源托管，告別 kubeconfig 切換地獄

    3.中間件運維：Kafka 擴容，從黑屏腳本到白屏可視化

    4.Node 管理：從黑屏腳本到白屏化平臺

    5.PV 云盤管理：打破孤盤與繁瑣操作的枷鎖

    6.CPU Burst 管理：關鍵時刻的“應急電源”

    7.YAML 管理服務：讓配置變更安全、可控、可回滾

三、項目收益總結

四、經驗總結與反思

五、未來展望

一、項目背景

傳統運維的痛點與挑戰

在傳統的中間件運維過程中，存在以下幾個突出問題：

• 管理分散：不同中間件（ Kafka和Elasticsearch）都有獨立的管理臺，運維邏輯分散，難以形成統一規范。
• 成本高昂：運維操作與各自的管理臺強綁定，SRE 需要學習不同工具，操作復雜，維護成本高。
• 黑屏操作依賴：很多關鍵運維操作需要依賴 kubectl apply 等黑屏命令，操作門檻高，風險大。 

Kubernetes與Operator的優勢

Kubernetes（K8s）和 Operator 提供了一套通用的運維管理機制，將中間件運維操作抽象成 Kubernetes CR（Custom Resource）對象，由 Operator 負責具體的運維執行。這種模式具備以下優勢：

• 標準化：運維操作可以以 CR 為中心進行統一管理。
• 自動化：減少了人工干預，降低了人為失誤的風險。
• 可視化：可以通過 UI 平臺降低運維復雜度。

平臺建設的核心目標

基于上述背景，我們決定建設一個統一的中間件運維平臺，目標包括：

• 標準化：統一規范中間件的運維操作，沉淀最佳實踐。
• 自動化：減少對黑屏操作的依賴，提升運維效率。
• 可視化：通過 UI 界面，讓運維操作更加直觀、簡單。

二、建設歷程

平臺架構概覽

在展開詳細的建設內容前，我們先看看整體的架構設計。本架構圖展示了白屏化運維平臺的核心組成和各層之間的交互關系，幫助我們更直觀地理解平臺的整體運作邏輯和功能分布。

圖片

運維平臺層的核心作用

運維平臺層是整個白屏化運維平臺的中樞大腦，承上啟下，連接用戶層與 Kubernetes 集群層，同時對接外部系統，確保運維操作的標準化、自動化和可審計。它的架構圖如下：

圖片

運維平臺的具體作用包括：

運維平臺層不僅是各類運維操作的執行中樞，更是數據流通的核心樞紐，負責將用戶的運維請求轉化為 Kubernetes 資源變更操作，同時記錄和審計所有操作，確保系統的安全性和可追溯性。

接下來，我們將深入剖析這些核心服務，看看它們是如何在實際場景中解決痛點、提升效率的。

多云管理：跨云資源托管，告別kubeconfig切換地獄

故事背景

“Kubeconfig 切換地獄，誰用誰知道。”

小卡作為一名資深 SRE，每天都要在多個 Kubernetes 集群之間穿梭，管理不同環境下的資源。這些集群來自不同的云廠商，運行在不同的 Kubernetes 版本上，甚至還有不同的認證和網絡策略。

• 傳統方式：每個 Kubernetes 集群都需要一個對應的 kubeconfig 文件，存儲在本地的 ~/.kube 目錄中。
• 上下文切換：每次操作前，需要執行kubectl --kubecnotallow=/path/to/kubeconfig，或者使用 kubectl config use-context 切換上下文。
• 風險高：當集群數量增多時，小卡根本記不清當前所操作的集群是 kubeconfig1 還是 kubeconfig2。有時候，為了省事，直接用 cp kubeconfig1 config，再去執行 kubectl 命令，完全忘記當前上下文對應哪個集群。
• 災難場景：一不小心，將生產集群當成測試集群，直接執行了 kubectl delete pods --all，后果不堪設想。  

痛點分析

解決方案

根據運維同學的痛點，我們計劃構建一個多云 Kubernetes 集群管理平臺，實現跨云環境資源的統一托管、可視化管理與快速訪問，避免 kubeconfig 切換帶來的混亂和風險。效果圖如下：

圖片

目標和行動拆解：

圖片

截至目前，平臺已跨云托管了30+套Kubernetes集群。

中間件運維：Kafka 擴容，從黑屏腳本到白屏可視化

故事背景

“Kafka 擴容——一個讓人捏把汗的運維操作”

凌晨三點，運維小卡的手機突然爆炸式震動起來，屏幕上跳出無數條報警消息：“Kafka 集群負載過高，CPU 使用率接近 100%！”

小卡揉了揉惺忪的睡眼，坐在電腦前打開黑屏終端，迅速敲下一連串熟練的命令：

kubectl --kubecnotallow=k8s-xxx-prd get kafka

他屏住呼吸，盯著屏幕上的滾動字符，一行一行地檢查 Kafka 集群狀態，判斷哪些節點資源吃緊，哪些副本需要擴容。然而，每次操作都讓他倍感焦慮——“這可是生產環境啊，萬一一行命令敲錯，就要上新聞頭條了！”

• 第一步：修改 YAML，spec.replicas +1。
• 第二步：輪詢所有 Pod 狀態，檢查是否都變為 Running。
• 第三步：調用 Cruise-Control API，觸發數據遷移。
• 第四步：輪詢數據遷移狀態，直到所有分區完成重新分配。

四步流程，看似簡單，但每一步都需要小卡屏息凝神，稍有差錯，就可能導致數據丟失，甚至集群崩潰。

“這種凌晨搶救場面，為什么不能更簡單一點？” 小卡心里忍不住嘀咕。

傳統 Kafka 擴容黑屏腳本

在中間件運維場景中，Kafka 集群擴容是一項典型的復雜運維任務。這不僅僅是一個簡單的「增加節點」操作，還涉及到集群狀態監控、資源調度、數據遷移 等多個環節。

傳統方式下，SRE 需要通過黑屏腳本完成擴容任務，整個過程不僅繁瑣，還充滿了不確定性。

以下是一個 Kafka 集群擴容的典型黑屏腳本示例：

#!/bin/bash


# 設置 kubeconfig
export KUBECONFIG=/path/to/kubeconfig


# 1. 檢查 Kafka 集群狀態
echo "Step 1: 查詢 Kafka 集群狀態"
kubectl get kafka -n kafka-namespace


# 2. 擴容 Kafka 集群副本數
echo "Step 2: 擴容 Kafka 集群"
kubectl patch kafka my-cluster -n kafka-namespace --type='merge' -p '{"spec":{"kafka":{"replicas":5}}}'


# 3. 輪詢 Kafka Pod 狀態
echo "Step 3: 檢查所有 Kafka Pod 是否 Running"
while true; do
    READY_PODS=$(kubectl get pods -n kafka-namespace -l app.kubernetes.io/name=kafka -o jsnotallow='{.items[*].status.phase}' | grep -o "Running" | wc -l)
    TOTAL_PODS=5
    echo "Running Pods: $READY_PODS / $TOTAL_PODS"
    if [ "$READY_PODS" -eq "$TOTAL_PODS" ]; then
        echo "所有 Kafka Pod 已經就緒"
        break
    fi
    sleep 5
done


# 4. 觸發數據遷移
echo "Step 4: 開始數據遷移"
curl -X POST "http://cruise-control.kafka-namespace.svc.cluster.local:9090/kafkacruisecontrol/rebalance" -d "dryrun=false"


# 5. 輪詢數據遷移狀態
echo "Step 5: 等待數據遷移完成"
while true; do
    STATUS=$(curl -s "http://cruise-control.kafka-namespace.svc.cluster.local:9090/kafkacruisecontrol/user_tasks" | grep "COMPLETED")
    if [ -n "$STATUS" ]; then
        echo "數據遷移完成"
        break
    fi
    sleep 10
done


echo "Kafka 集群擴容完成！"

可以看到，傳統腳本有以下幾個痛點：

白屏化平臺的 Kafka 擴容

目標：將 Kafka 擴容的整個過程標準化、可視化、自動化，降低操作風險，提升執行效率。

從此，凌晨三點的 Kafka 擴容，變成了這樣的場景：

1. 打開平臺：登錄運維平臺，進入 Kafka 集群運維界面。
2. 點擊擴容：輸入副本數，點擊 “一鍵擴容”。
3. 實時監控：平臺自動執行擴容，Pod 狀態、資源分配、數據遷移一目了然。
4. 完成審計：所有操作都記錄在日志中，可隨時回溯。

“10 分鐘，Kafka 擴容完成，小卡又可以安心地回床上睡覺了。”，如下圖：

圖片

目前，Kafka和ES在運維中都面臨相似的痛點。為解決這些問題，大部分通用的中間件運維操作已被統一收斂至平臺。

截至目前，平臺已累計托管300+個中間件集群（Kafka: 120+，ES: 180+），完成100+個中間件的運維操作（Kafka: 60+，ES: 40+），累計執行430+次白屏化運維操作（Kafka: 210+次，ES: 220+次），覆蓋擴縮容、升降配、數據遷移、重啟、重建等常見運維場景，極大提升了運維效率與操作穩定性。

Node管理：從黑屏腳本到白屏化平臺

故事背景

“凌晨三點，ES集群擴容需求緊急上線。”

運維小哥小吳接到告警電話，ES集群節點資源已接近飽和，業務性能明顯下降。擴容節點，是當務之急。

然而，擴容并不是簡單地加幾臺機器那么輕松。Node打標是擴容的關鍵前置步驟，如果節點沒有正確打標，Pod將無法被調度到對應的資源池，擴容將直接失敗。

在過去，Node 資源調度和打標是一項高風險、高強度的任務。需要依賴腳本在黑屏終端中逐臺節點檢查 CPU、內存、磁盤類型、可用區 等指標，然后篩選出符合條件的節點進行打標和調度。

如果某個細節疏忽——比如忘記檢查污點、磁盤掛載數量超標，輕則導致擴容失敗，重則影響整個業務鏈路。

傳統黑屏腳本分析

在傳統的 Node 篩選腳本中，我們依賴 kubectl 命令逐個檢查節點的各類資源指標，并進行節點篩選。以下是小吳編寫的一個典型的黑屏腳本示例：

public class ESNodeSelectorTest {
    public static void main(String[] args) {
        //cpu核心數
        int needCpu = 9;
        //內存容量G
        int needMemory = 33;
        //磁盤類型
        DiskType needDiskType = DiskType.efficiency;
        //可用區
        Zone zone = Zone.cn_shanghai_m;
        //標簽
        String label = null;
        //集群名稱
        String clusterName = null;
        //開始自動篩選
        selectNode(label,zone,needCpu,needMemory,needDiskType,clusterName);
    }


    public static void selectNode(String label,Zone zone,int needCpu,int needMemory,DiskType diskType,String clusterName){
        String getNodes = "kubectl get node -l ";
        String segment;
        if(label!=null){
            getNodes += label;
        }else {
            if (zone != null) {
                segment = "topology.kubernetes.io/znotallow=" + zone.name().replaceAll("_", "-");
                getNodes += segment;
            }
        }


        String nodes = executeCommand("/bin/bash", "-c", getNodes);
        String[] nodeList = nodes.split("\n");
        String describeNode;
        int lineCount = 0;
        for (int i = 1; i < nodeList.length; i++) {
            String node = nodeList[i].split(" ",2)[0];
            if(lineCount>4){
                lineCount = 0;
                System.out.println();
            }
            lineCount++;


            System.out.print(node);
            if(isMaster(node)){
                continue;
            }
            describeNode = "kubectl describe node " + node +" | grep 'Taints\\|cpu    \\|memory   ";
            //...太多了...省略...
            }
        }
    }


    public static String executeCommand(String... command){
        try {
            Process process = Runtime.getRuntime().exec(command);
            //...
        }catch (Exception e){
            throw new RuntimeException("kubectl apply exception:",e);
        }
    }
}

可以看到，傳統方式有以下幾個痛點：

白屏化平臺的 Node 管理

目標：

將 Node 資源管理的整個流程標準化、自動化和可視化。

設計思路：

1.指標可視化

• 在白屏界面上展示 Node 的 CPU 分配/使用率、內存分配/使用率、磁盤類型、標簽、污點等關鍵指標。

2.多維度篩選

• 支持通過標簽、污點、CPU/內存余量、磁盤類型、可用區等維度快速篩選節點。

3.批量打標與調度

• 支持批量打標和污點管理，減少人工操作的復雜性。

4.資源狀態實時更新

• 實時展示節點資源的可用性，避免資源分配沖突。

在大促擴容場景中，平臺已累計完成了 280+ 臺 Node 的打標與調度。原本 1 小時+ 的 Node 篩選和打標操作，現在只需要 3 分鐘 。

圖片

PV云盤管理：打破孤盤與繁瑣操作的枷鎖

故事背景

“集群刪了，PV 留下了，云盤成了‘孤兒’。”

一次運維例會中，小宋提到這樣一個現象：當中間件集群被釋放后，原先掛載的 PV 和云廠商的云盤并不會自動刪除。更讓人頭疼的是，云廠商云盤的標簽只有兩個關鍵字段，這里以某云為例：

• k8s.yun.com : true
• createdby: alibabacloud-csi-plugin

當集群被銷毀，這些標簽幾乎無法追溯到云盤的真正使用方。出于風險考慮，這些云盤被閑置著，無人敢于釋放，久而久之，閑置云盤成堆，云成本居高不下。如下圖：

圖片

痛點分析

解決方案

目標：實現 PV 云盤資源的可視化、自動化管理，打通從 Kubernetes 到云廠商的全鏈路操作流程。如下圖所示：

圖片

目標和行動拆解：

圖片

截止目前，平臺已累計釋放了 675+ 塊閑置云盤，每月節省云成本約 15+萬元。操作時間從 15 分鐘+ 縮短到 1 分鐘。且所有操作均可審計與回溯，保障了運維安全性。

CPU Burst 管理：關鍵時刻的“應急電源”

故事背景

“高峰期 CPU 100%，服務卡成 PPT？”

一次業務高峰來臨，ES 集群的 CPU 使用率迅速飆升到 100%，多個關鍵服務開始響應遲緩，甚至部分 Pod 被強制驅逐。運維同學小宋看著監控大屏上的紅色告警，不禁捏了一把汗。

在傳統運維方式下，CPU 資源一旦達到極限，唯一的解決方案就是擴容，但擴容并非瞬時可完成的操作，往往需要排查資源、調度 Pod、重啟服務，甚至等待新節點的資源分配。而這些步驟，在高并發、高壓力場景下，每一秒的延遲都是用戶體驗的巨大損失。

痛點分析

解決方案

目標：在高壓場景下，通過 CPU Burst 管理功能，允許關鍵 Pod 在短時間內突破 CPU Limit 限制，保障服務穩定性和業務連續性。如下所示：

圖片

截止目前， CPU Burst 已在 10+ 套 Kubernetes 集群 和 30+ 套 ES 集群 中啟用。在高并發場景下，有效解決了 CPU受限和CPU使用率瓶頸問題，提升了服務穩定性。

YAML 管理服務：讓配置變更安全、可控、可回滾

故事背景

“一行 YAML，毀滅一個集群。”

在 Kubernetes 的運維場景中，YAML 配置文件是所有資源操作的核心。無論是 Pod 調度、Service 暴露，還是 ConfigMap 更新，所有的操作都離不開 YAML 文件。

但 YAML 配置管理往往充滿風險：

• 一行配置錯誤：可能導致整個服務不可用。
• 版本混亂：配置文件缺乏版本管理，一旦出錯，回滾難度極大。
• 缺乏審計：每次變更是誰做的，變更了哪些內容，幾乎沒有清晰的記錄。
• 人工操作：黑屏模式下，直接通過 kubectl apply 修改 YAML，出錯率極高。

“運維人員常說：‘YAML 是 Kubernetes 的靈魂，但也是運維事故的導火索。’”

痛點分析

解決方案

目標：通過YAML 管理服務，將 Kubernetes YAML 配置的版本管理、變更審計、回滾機制 和 可視化管理 集中整合到平臺中，降低人為操作風險，提升變更效率和安全性。如下所示：

圖片

三、項目收益總結

經過三期建設，白屏化運維平臺已從概念驗證逐步發展成為覆蓋全場景運維的高效工具，取得了顯著的成果和收益，主要體現在以下幾個方面：

運維標準化與規范化

• 統一運維流程：通過平臺白屏化界面，規范了 Kafka、ES、Node、PV、PVC、SVC、Pod 等核心運維場景，減少了操作流程的隨意性。
• 最佳實踐沉淀：在每個運維場景中，平臺積累并固化了標準化的運維流程與策略，降低了運維操作的失誤率。
• 減少人為依賴：降低了對資深運維人員的依賴，新手 SRE 也可以在平臺指引下完成復雜運維操作。

運維效率顯著提升

• 操作效率：    Node 打標與污點管理從 1小時+ 縮短至 3分鐘。    PV 云盤釋放從 15分鐘+ 縮短至 1分鐘。
• 高效應急響應：在 CPU Burst 管理的支持下，有效緩解高并發場景下的 CPU受限和CPU使用率瓶頸問題，保障業務連續性。
• 批量化管理：支持 Node、PV、PVC、SVC、Pod等資源的批量管理，減少重復性操作，提高資源調度效率。

成本優化與資源利用最大化

• 資源回收：累計釋放 675+ 塊閑置云盤，月均節省云成本 15+萬元。
• 資源高效分配：通過 Node 篩選與 PV優化管理，有效提升了資源利用率，避免資源浪費。
• 跨云資源托管：統一管理來自不同云廠商的 Kubernetes 集群，避免因平臺差異導致的資源閑置。

安全性與可審計性提升

• 操作可追溯：所有運維操作均納入審計日志，累計記錄超過 1020+ 條審計日志。
• 合規性保障：平臺操作對接 DCheck 系統，實現運維審計和合規性檢查。

業務穩定性與可擴展性

• 支撐業務高峰：在七夕大促等業務高壓場景下，平臺有效支撐了中間件的快速擴容和穩定運行。
• 平臺可擴展性：架構設計支持快速新增運維場景，滿足未來更多資源類型和場景的需求。

四、經驗總結與反思

在三期的建設和落地過程中，我們積累了寶貴的經驗，也發現了一些可以優化和提升的空間。以下是關鍵經驗和反思：

以標準化為核心

• 運維流程標準化：通CR管理、Node/PV/PVC/SVC 資源管理，實現了運維操作的標準化和可重復性。
• 減少個性化操作：避免了運維過程中因個人操作習慣差異帶來的不一致性。

技術與流程的深度結合

• 白屏化降低門檻：將復雜的 Kubernetes 運維操作封裝到 UI 界面，減少了對黑屏命令的依賴。
• 批量運維能力：批量操作大幅減少重復性工作，有效提升整體運維效率。

強化審計與合規

• 全鏈路審計：所有操作均有詳細的審計記錄，確保運維行為可追溯、可還原。
• 合規檢查：對接 DCheck 系統，實時進行合規檢查，避免風險隱患。

面向未來的架構設計

• 彈性擴展：平臺架構具備較強的可擴展性，支持快速集成新的運維場景。
• 跨云平臺適配：平臺已實現對多云 Kubernetes 集群的統一管理，降低了跨云資源運維的復雜度。

遇到的挑戰

• 與KubeOne平臺無法融合：KubeOne平臺主要面向無狀態服務的運維，而白屏化平臺主要面向有狀態服務的運維，二者無法融合。
• 多場景運維復雜度：不同中間件和 Kubernetes 資源類型的運維邏輯存在差異，初期難以統一抽象。
• 持續優化測試流程：部分場景的測試覆蓋率還有待提升，未來需持續加強單元測試和集成測試。

五、未來展望

白屏化運維平臺的未來，將持續以“標準化、可視化、智能化”為核心，不斷拓展運維場景，降低運維門檻，提升運維效率與安全性。

• 擴展更多 Kubernetes 運維場景：實現更多 Kubernetes 資源（如Deployment、StatefulSet、 Ingress、ConfigMap、Secret）和自定義資源（DMQ、Pulsar、ZK）的白屏化運維支持。
• 引入智能化運維：基于案例匹配、數據挖掘或總結最佳實踐，實現故障自愈、資源動態調度和智能告警。
• 持續優化用戶體驗：通過用戶反饋持續改進平臺功能，優化運維操作流程，降低運維心智負擔。
• 加強多云資源管理能力：支持更多云廠商 Kubernetes 集群的接入，提升平臺的多云資源管理能力。