一、項目背景

    1.傳統(tǒng)運維的痛點與挑戰(zhàn)

    2.Kubernetes 與 Operator 的優(yōu)勢

    3.平臺建設(shè)的核心目標(biāo)

二、建設(shè)歷程

    1.平臺架構(gòu)概覽

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

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

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

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

    6.CPU Burst 管理：關(guān)鍵時刻的“應(yīng)急電源”

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

三、項目收益總結(jié)

四、經(jīng)驗總結(jié)與反思

五、未來展望

一、項目背景

傳統(tǒng)運維的痛點與挑戰(zhàn)

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

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

Kubernetes與Operator的優(yōu)勢

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

• 標(biāo)準(zhǔn)化：運維操作可以以 CR 為中心進行統(tǒng)一管理。
• 自動化：減少了人工干預(yù)，降低了人為失誤的風(fēng)險。
• 可視化：可以通過 UI 平臺降低運維復(fù)雜度。

平臺建設(shè)的核心目標(biāo)

基于上述背景，我們決定建設(shè)一個統(tǒng)一的中間件運維平臺，目標(biāo)包括：

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

二、建設(shè)歷程

平臺架構(gòu)概覽

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

圖片

運維平臺層的核心作用

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

圖片

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

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

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

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

故事背景

“Kubeconfig 切換地獄，誰用誰知道?！?/p>

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

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

痛點分析

解決方案

根據(jù)運維同學(xué)的痛點，我們計劃構(gòu)建一個多云 Kubernetes 集群管理平臺，實現(xiàn)跨云環(huán)境資源的統(tǒng)一托管、可視化管理與快速訪問，避免 kubeconfig 切換帶來的混亂和風(fēng)險。效果圖如下：

圖片

目標(biāo)和行動拆解：

圖片

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

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

故事背景

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

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

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

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

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

• 第一步：修改 YAML，spec.replicas +1。
• 第二步：輪詢所有 Pod 狀態(tài)，檢查是否都變?yōu)?Running。
• 第三步：調(diào)用 Cruise-Control API，觸發(fā)數(shù)據(jù)遷移。
• 第四步：輪詢數(shù)據(jù)遷移狀態(tài)，直到所有分區(qū)完成重新分配。

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

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

傳統(tǒng) Kafka 擴容黑屏腳本

在中間件運維場景中，Kafka 集群擴容是一項典型的復(fù)雜運維任務(wù)。這不僅僅是一個簡單的「增加節(jié)點」操作，還涉及到集群狀態(tài)監(jiān)控、資源調(diào)度、數(shù)據(jù)遷移 等多個環(huán)節(jié)。

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

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

#!/bin/bash


# 設(shè)置 kubeconfig
export KUBECONFIG=/path/to/kubeconfig


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


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


# 3. 輪詢 Kafka Pod 狀態(tài)
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 已經(jīng)就緒"
        break
    fi
    sleep 5
done


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


# 5. 輪詢數(shù)據(jù)遷移狀態(tài)
echo "Step 5: 等待數(shù)據(jù)遷移完成"
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 "數(shù)據(jù)遷移完成"
        break
    fi
    sleep 10
done


echo "Kafka 集群擴容完成！"

可以看到，傳統(tǒng)腳本有以下幾個痛點：

白屏化平臺的 Kafka 擴容

目標(biāo)：將 Kafka 擴容的整個過程標(biāo)準(zhǔn)化、可視化、自動化，降低操作風(fēng)險，提升執(zhí)行效率。

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

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

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

圖片

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

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

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

故事背景

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

運維小哥小吳接到告警電話，ES集群節(jié)點資源已接近飽和，業(yè)務(wù)性能明顯下降。擴容節(jié)點，是當(dāng)務(wù)之急。

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

在過去，Node 資源調(diào)度和打標(biāo)是一項高風(fēng)險、高強度的任務(wù)。需要依賴腳本在黑屏終端中逐臺節(jié)點檢查 CPU、內(nèi)存、磁盤類型、可用區(qū) 等指標(biāo)，然后篩選出符合條件的節(jié)點進行打標(biāo)和調(diào)度。

如果某個細節(jié)疏忽——比如忘記檢查污點、磁盤掛載數(shù)量超標(biāo)，輕則導(dǎo)致擴容失敗，重則影響整個業(yè)務(wù)鏈路。

傳統(tǒng)黑屏腳本分析

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

public class ESNodeSelectorTest {
    public static void main(String[] args) {
        //cpu核心數(shù)
        int needCpu = 9;
        //內(nèi)存容量G
        int needMemory = 33;
        //磁盤類型
        DiskType needDiskType = DiskType.efficiency;
        //可用區(qū)
        Zone zone = Zone.cn_shanghai_m;
        //標(biāo)簽
        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);
        }
    }
}

可以看到，傳統(tǒng)方式有以下幾個痛點：

白屏化平臺的 Node 管理

目標(biāo)：

將 Node 資源管理的整個流程標(biāo)準(zhǔn)化、自動化和可視化。

設(shè)計思路：

1.指標(biāo)可視化

• 在白屏界面上展示 Node 的 CPU 分配/使用率、內(nèi)存分配/使用率、磁盤類型、標(biāo)簽、污點等關(guān)鍵指標(biāo)。

2.多維度篩選

• 支持通過標(biāo)簽、污點、CPU/內(nèi)存余量、磁盤類型、可用區(qū)等維度快速篩選節(jié)點。

3.批量打標(biāo)與調(diào)度

• 支持批量打標(biāo)和污點管理，減少人工操作的復(fù)雜性。

4.資源狀態(tài)實時更新

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

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

圖片

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

故事背景

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

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

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

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

圖片

痛點分析

解決方案

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

圖片

目標(biāo)和行動拆解：

圖片

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

CPU Burst 管理：關(guān)鍵時刻的“應(yīng)急電源”

故事背景

“高峰期 CPU 100%，服務(wù)卡成 PPT？”

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

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

痛點分析

解決方案

目標(biāo)：在高壓場景下，通過 CPU Burst 管理功能，允許關(guān)鍵 Pod 在短時間內(nèi)突破 CPU Limit 限制，保障服務(wù)穩(wěn)定性和業(yè)務(wù)連續(xù)性。如下所示：

圖片

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

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

故事背景

“一行 YAML，毀滅一個集群?！?/p>

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

但 YAML 配置管理往往充滿風(fēng)險：

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

“運維人員常說：‘YAML 是 Kubernetes 的靈魂，但也是運維事故的導(dǎo)火索?！?/p>

痛點分析

解決方案

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

圖片

三、項目收益總結(jié)

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

運維標(biāo)準(zhǔn)化與規(guī)范化

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

運維效率顯著提升

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

成本優(yōu)化與資源利用最大化

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

安全性與可審計性提升

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

業(yè)務(wù)穩(wěn)定性與可擴展性

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

四、經(jīng)驗總結(jié)與反思

在三期的建設(shè)和落地過程中，我們積累了寶貴的經(jīng)驗，也發(fā)現(xiàn)了一些可以優(yōu)化和提升的空間。以下是關(guān)鍵經(jīng)驗和反思：

以標(biāo)準(zhǔn)化為核心

• 運維流程標(biāo)準(zhǔn)化：通CR管理、Node/PV/PVC/SVC 資源管理，實現(xiàn)了運維操作的標(biāo)準(zhǔn)化和可重復(fù)性。
• 減少個性化操作：避免了運維過程中因個人操作習(xí)慣差異帶來的不一致性。

技術(shù)與流程的深度結(jié)合

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

強化審計與合規(guī)

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

面向未來的架構(gòu)設(shè)計

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

遇到的挑戰(zhàn)

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

五、未來展望

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

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