0、前言

關(guān)于什么是SRE，以及在業(yè)務(wù)上有哪些具體的輸出，網(wǎng)上資料眾多但都只是對基本概念做描述。那容器SRE究竟要怎么結(jié)合業(yè)務(wù)，得物容器SRE又有哪些最佳實踐，本文就得物容器SRE的一些事情向大家做介紹。

1、SRE定義

穩(wěn)定性工程師，用軟件工程解決復(fù)雜的運維問題，50%的時間用于運維瑣事,50%的時間用于軟件工程保障業(yè)務(wù)的穩(wěn)定性和可擴(kuò)展性，包括開發(fā)監(jiān)控，日志，告警系統(tǒng)，業(yè)務(wù)性能調(diào)優(yōu)等

2、對于SRE的理解

2.1 SRE的監(jiān)控和Oncall應(yīng)急響應(yīng)

2.1.1 一個團(tuán)隊 Oncall 至多需要兩個人 （另外一個是新手 shadow），oncall人員需要具備以下能力：

（a）清晰的問題升級路線

（b）清晰定義的應(yīng)急事件處理步驟

（c) 監(jiān)控巡檢，如下:

查看監(jiān)控，分析服務(wù)可用性下降或者耗時增加等影響服務(wù)質(zhì)量的問題的根部原因。

• 2. 整理以上事件的數(shù)據(jù)
• 3. 分析根本原因，優(yōu)化并且解決（運維手段，代碼，或者腳本 / 代碼自動化運維手段）
• 2.1.2 遇到重大故障時的各種重要角色
• IC(Incident Commander)：故障指揮官，這個角色是整個指揮體系的核心，最重要的職責(zé)是組織和協(xié)調(diào)，而非執(zhí)行，下面所有角色都要接受他的指令并嚴(yán)格執(zhí)行。
• CL(Communication Lead)：溝通引導(dǎo)，負(fù)責(zé)對內(nèi)和對外的信息收集及通報，這個角色一般相對固定，由技術(shù)支持、QA或者是某個SRE來承擔(dān)，要求溝通表達(dá)能力要比較好。
• OL(Operations Lead)：運維指揮，負(fù)責(zé)指揮或指導(dǎo)各種故障預(yù)案的執(zhí)行和業(yè)務(wù)恢復(fù)。
• IR(Incident Responders)：即所有需要參與到故障處理中的各類人員，真正的故障定位和業(yè)務(wù)恢復(fù)都是他們來完成的，如具體執(zhí)行的SRE、運維、業(yè)務(wù)開發(fā)、平臺開發(fā)、DBA，甚至是QA

2.2 SLO和SLA制定和保障

100%穩(wěn)定的系統(tǒng)是不存在的

• 服務(wù)質(zhì)量指標(biāo) SLI（indicator）：量化指標(biāo)，包括延遲、吞吐量、錯誤率、可用性、持久性等
• 指標(biāo)不宜過多，應(yīng)關(guān)注用戶的真實需求
• 常用的指標(biāo)度量應(yīng)該盡量標(biāo)準(zhǔn)化（如時間間隔、頻率等）
• 服務(wù)質(zhì)量目標(biāo) SLO（Objective）：對特定 SLI 的目標(biāo)值
• 服務(wù)質(zhì)量協(xié)議 SLA（Aggrement）：與用戶間的明確協(xié)議，一般伴隨著代價
• 維護(hù)服務(wù)可用性的成本不是線性增長的，到一定程度，增加一個9可能需要10倍100倍的成本，通過SLO讓成本和收益取得很好的平衡，假設(shè)一個業(yè)務(wù)增加SLO等級，可以計算一下需要的成本和帶來的收益，如果得不償失就可以不用增加SLO等級

2.3 變更管理

•   SRE的經(jīng)驗大概 70% 的生產(chǎn)事故由某種部署的變更而觸發(fā)
•   變更管理的最佳實踐：
•   1. 采用漸進(jìn)式發(fā)布機(jī)制
•   2. 迅速而準(zhǔn)確地檢測到問題的發(fā)生
•   3. 當(dāng)出現(xiàn)問題時，安全迅速地回退改動

2.4 容量規(guī)劃

• 容量規(guī)劃必需步驟：
• 必須有一個準(zhǔn)確的自然增長需求預(yù)測模型，需求預(yù)測的時間應(yīng)該超過資源獲取的時間。
• 規(guī)劃中必須有準(zhǔn)確的非自然增長的需求來源的統(tǒng)計。
• 必須有周期性壓力測試，以便準(zhǔn)確地將系統(tǒng)原始資源信息與業(yè)務(wù)容量對應(yīng)起來

2.5 監(jiān)控系統(tǒng)

•   SRE的四個黃金指標(biāo)是構(gòu)建成功的監(jiān)控和告警系統(tǒng)的一些基本原則和最佳實踐
• 延遲：延遲是信息發(fā)送方和接收方之間的時間延遲，以毫秒（ms）為單位。而原因往往是由于數(shù)據(jù)包丟失網(wǎng)絡(luò)擁塞和網(wǎng)絡(luò)抖動造成的，稱為“數(shù)據(jù)包延遲差異”延遲對客戶體驗有直接影響，轉(zhuǎn)化為成功請求的延遲和失敗請求的延遲。
• 流量：流量是系統(tǒng)工作量帶來的壓力。它通過每秒查詢數(shù)（QPS）或每秒事務(wù)數(shù)（TPS）來衡量。企業(yè)通過數(shù)量來衡量這一點：關(guān)鍵績效指標(biāo)（KPI）是在給定時間來到站點的人數(shù)。這與商業(yè)價值有直接關(guān)系。
• 錯誤：錯誤是根據(jù)整個系統(tǒng)中發(fā)生的錯誤來衡量的。被認(rèn)為是服務(wù)錯誤率的重要指標(biāo)！有兩類錯誤：顯式錯誤，如失敗的HTTP請求（500個錯誤代碼，例如）；隱含錯誤是成功的響應(yīng)，但內(nèi)容錯誤或響應(yīng)時間長。
• 飽和度：飽和度定義了服務(wù)的過載程度。它衡量系統(tǒng)利用率，強(qiáng)調(diào)服務(wù)的資源和整體容量。這通常適用于CPU利用率、內(nèi)存使用、磁盤容量和每秒操作數(shù)等資源。儀表板和監(jiān)控警報是幫助你密切關(guān)注這些資源并幫助你在容量飽和之前主動調(diào)整容量的理想工具

2.6 可靠性衡量

• 可靠性是MTTF（平均失敗時間）和MTTR（平均恢復(fù)時間）的函數(shù)。評價一個團(tuán)隊將系統(tǒng)恢復(fù)到正常情況的最有效指標(biāo)，就是MTTR。
• 任何需要人工操作的事情都只會延長恢復(fù)時間。一個可以自動恢復(fù)的系統(tǒng)即使有更多的故障發(fā)生，也要比事事都需要人工干預(yù)的系統(tǒng)可用性更高

3、得物容器SRE的實踐

3.1 Oncall應(yīng)急響應(yīng)的總結(jié)

Oncall是直接體現(xiàn)SRE價值所在，能夠直接影響MTTR時間的主要核心系數(shù)，一個好的Oncall甚至可以幫助公司挽回很多資損甚至是公司的形象，所以O(shè)ncall是每個SRE最重要的工作。

我們有自己的Oncall機(jī)制、適用范圍、人員構(gòu)成、復(fù)盤跟進(jìn)、不同場景會邀請不同隊員參與排障。有基本的故障處理原則，事故處理后的閉環(huán)。下圖為整個Oncall流程的進(jìn)行方式：

當(dāng)然每次都只是處理故障，恢復(fù)后不做總結(jié)歸納是不會有任何沉淀的，容器SRE會記錄每次有意義的故障進(jìn)行文案撰寫并在故障中總結(jié)現(xiàn)有系統(tǒng)存在的工具類、平臺類、代碼類隱患點，分等級高中低進(jìn)行推進(jìn)push幫助業(yè)務(wù)，基架不斷完善系統(tǒng)健壯性；

3.2 一次容器故障的分享

3.2.1 延遲問題背景：

某天下午SRE側(cè)開始陸續(xù)接到業(yè)務(wù)研發(fā)反饋redisRT 增長導(dǎo)致超時，其中某服務(wù)有多個 pod 存在redis RT 突增導(dǎo)致部分請求超時（截圖如下）

經(jīng)過了一系列的驅(qū)逐與資源規(guī)整等止血操作后，該故障在30分鐘后恢復(fù)。在這種場景下排查根因通常是一個很辣手的問題，因為第一現(xiàn)場很難在短時間內(nèi)再進(jìn)行模擬、恢復(fù)，第二在生產(chǎn)環(huán)境下不易做太多的測試工作。這種背景下就要發(fā)揮SRE的價值了。下面是敘述我們整個問題的排查思路與過程，希望能給大家一些借鑒。

3.2.2 問題排查思路：

排障過程描述只是說了一個思路，部分時間點可能和故障產(chǎn)生的時間重合

先排查是否是網(wǎng)絡(luò)問題引起的，當(dāng)問題發(fā)現(xiàn)解決后后我們梳理了對應(yīng)的宿主機(jī)的信息，想發(fā)現(xiàn)一些規(guī)律來確認(rèn)故障的根因；

圖上可見，這三臺并不是一個網(wǎng)段的，唯一相同的也就是同一個區(qū)域，這個范圍較大，不像是一個局部事件。所以我優(yōu)先想到了云商故障；

為了進(jìn)一步確認(rèn)問題，我將對故障的 ecs ID 給到了阿里并進(jìn)行了一個授權(quán)，隨后還拉群做了語音討論

接下來是整個根因排查分析：

• 排除鏈路問題

翻閱故障時的監(jiān)控發(fā)現(xiàn)，網(wǎng)絡(luò)耗時在故障時間點附近比較平穩(wěn)、經(jīng)過和阿里內(nèi)部監(jiān)控的核對，當(dāng)時問題宿主機(jī)網(wǎng)絡(luò)延遲在故障時間點延遲僅從 2ms 增加到 4ms 所以可以排除是由于網(wǎng)絡(luò)問題導(dǎo)致的

• 發(fā)現(xiàn)異常現(xiàn)象

node監(jiān)控有大量的異常包，drop 計數(shù)異常，常規(guī)情況下應(yīng)該為0（上圖），我們對這些drop 包做了分析（下圖）發(fā)現(xiàn)Drop 的統(tǒng)計數(shù)非常高，同時tcpofo，tcprcvq這兩個指標(biāo)指向了TCP內(nèi)存限制，需要擴(kuò)充內(nèi)存空間。

為了更進(jìn)一步知道根因所在，我們又去觀察了對應(yīng)的 io夯、調(diào)度（任務(wù)等待）、 夯住（應(yīng)用進(jìn)程鎖）、用戶態(tài)內(nèi)存等待、網(wǎng)絡(luò) (系統(tǒng) 5狀態(tài)分類左圖) （這里第一步已經(jīng)排除了“網(wǎng)絡(luò)”故障所以這里做了刪除線處理），可以看到排查到io等待時間過長（下圖）

• 深挖排查到IO平均等待時間上存在問題

IO平均等待時間在秒級以上，遠(yuǎn)超了正常范圍，故開始排查percpu iowait 狀況。經(jīng)過一系列的操作最終我們使用sls 導(dǎo)入tidb 的方法數(shù)據(jù)做了一個可視化；

select * from cpus where time > now() - 4h and host = 'i-bp11f8g5h7oofu5pqgr8' and iowait > 50.0

我們對那些 CPU iowait 比較高的篩選出來，看看能不能找到對應(yīng)的業(yè)務(wù)（當(dāng)時就懷疑是不是由于混部原因?qū)е碌模┑钦伊艘蝗]有發(fā)現(xiàn)什么問題。

3.2.3 最終根因定位：

繞了一圈發(fā)現(xiàn)線索又?jǐn)嗔耍€是回到那個TCP 內(nèi)存限制的問題，為什么會判斷tcpofodrop 指標(biāo)會與tcp_mem 有關(guān)呢？可以直接看代碼邏輯

內(nèi)核源碼網(wǎng)站推薦https://lxr.missinglinkelectronics.com/linux+v4.19/net/ipv4/tcp_input.c#L4459

（一個展示源代碼存儲庫的軟件工具集）

上面的邏輯簡單敘述：TCP的核心預(yù)分配緩存額度函數(shù)為tcp_try_rmem_schedule，如果無法分配緩存額度，將首先調(diào)用tcp_prune_queue函數(shù)嘗試合并sk_receive_queue中的數(shù)據(jù)包skb以減少空間占用，如果空間仍然不足，最后調(diào)用tcp_prune_ofo_queue函數(shù)清理亂序數(shù)據(jù)包隊列 （out_of_order_queue）。簡單說：如果內(nèi)存分配失敗，對應(yīng)drop計數(shù)就會遞增

另外當(dāng)時我們也發(fā)現(xiàn)了dmesg日志里tcp oom的日志，如下圖所示

于是就搜了一些實踐準(zhǔn)備將線上連接數(shù)比較高的那幾臺機(jī)器做一個替換處理試試

#命令查看方法
sysctl -a|grep -i tcp_mem|tcp_rmem|tcp_wmem

當(dāng)時想準(zhǔn)備替換的配置（當(dāng)時這個調(diào)整低于線上目前的值）

# 擴(kuò)大TCP 總內(nèi)存大小
# 擴(kuò)大到 32G  最小值不動  中間數(shù)為max 的 70%  
echo  "net.ipv4.tcp_mem = 1104864 5872026 8388608">> /etc/sysctl.conf  
#單個 socket 讀分配最大內(nèi)存 
#原先16MB 擴(kuò)大到 32MB （中間數(shù)為最佳實踐推薦）
echo "net.ipv4.tcp_rmem = 4096 25165824 33554432">> /etc/sysctl.conf
#單個 socket 寫分配最大內(nèi)存 
#原先16MB 擴(kuò)大到 32MB （中間數(shù)為最佳實踐推薦）
echo "net.ipv4.tcp_wmem = 4096 25165824 33554（）432">> /etc/sysctl.conf

當(dāng)時線上內(nèi)存

cat /proc/sys/net/ipv4/tcp_mem
6169920        8226561        12339840，這里是最小值24G 壓力值32G 最大值48G

在check這些參數(shù)的過程中突然就發(fā)現(xiàn)了一個問題，我們線上的參數(shù)換算成內(nèi)存值是48G左右，已經(jīng)算大了，可以想象一下 tcp 鏈接總的內(nèi)存已經(jīng)用了48G！這部分還不光是網(wǎng)絡(luò)開銷只是一個 TCP 鏈接，我們就有 ss 看了下當(dāng)時的鏈接情況：

通常出現(xiàn)這種情況的原因有以下兩種：1、應(yīng)用沒有正確close他的socket進(jìn)程 2、沒有處理異常情況下的socket??

感興趣的同學(xué)可以看下這個文檔（推薦）

??https://stackoverflow.com/questions/38837724/linux-too-many-closed-connections??

然后我們怎么找到是誰呢？通常情況下可以這么理解，一個 soket 就是一個 fd （句柄），對應(yīng)soket 大必然fd 也大！（因為linux 一切皆文件）隨后我們用了 for 循環(huán)查找對應(yīng)的/proc 下的文件數(shù)量，結(jié)果如下：

附上命令參考：

#看進(jìn)程對應(yīng)哪個容器
for i in `docker ps |grep Up|awk '{print $1}'`;do echo \ &&docker top $i &&echo ID=$i; done |grep -A 15 4078683
#看FD誰占用的多
for pid in `ls -1 /proc/|grep -Eo '[0-9]{1,}'`; do pnum=$(ls -1 /proc/${pid}/fd/|wc -l); if [ $pnum -gt 1000 ];then echo "${pid} ${pnum}"; fi; done

為了確認(rèn)又去容器中查看，確認(rèn)無疑！

拉了對應(yīng)引用的負(fù)責(zé)人后將結(jié)果反饋，業(yè)務(wù)得到信息后立即響應(yīng)并將自己的應(yīng)用做了下線處理，隨后觀察指標(biāo)立馬恢復(fù)了 - 破案~

這次故障我們深刻反省，同事建議將我們的系統(tǒng)參數(shù)的監(jiān)控覆蓋完全，所以之后我們立即就成立了一個項目，優(yōu)化推進(jìn)監(jiān)控覆蓋

3.3 容器底層對于內(nèi)核參數(shù)監(jiān)控與優(yōu)化

繼上文說到的故障后，我們意識到了容器監(jiān)控上的不足故成立了專項來做內(nèi)核參數(shù)上的監(jiān)控。但是內(nèi)核參數(shù)上千個我們怎么來做？

3.3.1 圈定監(jiān)控指標(biāo)范圍

所以第一步就是完成內(nèi)核指標(biāo)羅列范圍。我們對以往的故障和反饋分析來看，網(wǎng)絡(luò)故障發(fā)生較為頻繁，所以范圍圈定為宿主機(jī)網(wǎng)絡(luò)指標(biāo)為主；網(wǎng)絡(luò)指標(biāo)在系統(tǒng)中主要由/proc/net/netstat提供，所以我們羅列了他所提供的所有指標(biāo)；（如圖是netstat的所有指標(biāo)）

3.3.2 內(nèi)核指標(biāo)的采集實現(xiàn)

有了范圍我們要制定采集方案有些是node-export需要特殊配置才能采集到的具體方案；比如下面要增加netstat的監(jiān)控是需要啟用node-export對應(yīng)的擴(kuò)展包

第二個就是通過開源的采集組件監(jiān)控不到的數(shù)據(jù)比如tcp.socket.mem這部分只能靠自己開發(fā)完成。如下圖通常采用截取字段方式將os的狀態(tài)指標(biāo)采集到

3.3.3 指標(biāo)的展示可視化

有了采集后就是完成指標(biāo)的展示與統(tǒng)計，我們通過/proc/net/netstat獲取到了46個網(wǎng)絡(luò)指標(biāo)，同時也借鑒了業(yè)內(nèi)的最佳實踐總共55個指標(biāo)的羅列與代表的意義，并將各內(nèi)核常見參數(shù) 含義及公式形成文檔，解決了很多參數(shù)不目的不明確的問題，下圖是我們展示這些指標(biāo)的案例截圖

3.3.4 場景分類逐個優(yōu)化

完成了展示后，我們就需要對這些核心內(nèi)核指標(biāo)參數(shù)進(jìn)行分類（這些指標(biāo)存在問題可能會影響業(yè)務(wù)正常運行）

以上55個指標(biāo)大多為輔助定位的指標(biāo)，作為業(yè)務(wù)類型不同，關(guān)注的指標(biāo)與內(nèi)核參數(shù)的調(diào)整是有區(qū)別的

通用類型default資源池模型；（注重并發(fā)，多鏈接，多請求的場景）監(jiān)控參考如下：監(jiān)控統(tǒng)計可以看到資源使用比較平均，需要均衡的參數(shù)配置

算法類型高密度計算類型資源池；（主動睡眠，被動睡眠，看調(diào)度延時，cpu消耗在用戶態(tài)還是內(nèi)核態(tài)）監(jiān)控參考如下：監(jiān)控統(tǒng)計可以看到 cpu大多使用率較高

大數(shù)據(jù)類型 專有集群資源池；（關(guān)注網(wǎng)絡(luò)IO，磁盤IO，文件系統(tǒng)cache，網(wǎng)絡(luò)開銷大）監(jiān)控參考如下：監(jiān)控統(tǒng)計可以看到網(wǎng)絡(luò)上開銷較大

3.3.5 參數(shù)優(yōu)化管理與兜底保障

然后我們就對這三個類型的主機(jī)分別做了參數(shù)調(diào)整和鋪平，由于文章長度關(guān)系親，就不做詳細(xì)描述了。完成了調(diào)整后我們怎么去維護(hù)和管理這些內(nèi)核參數(shù)呢？這里我們對內(nèi)核參數(shù)管理也做了一個方案，保障這次治理后是長久有效的。具體的流程如下：

有整理出的內(nèi)核指標(biāo)后還會通過日常的監(jiān)控、巡檢對某些需要調(diào)整的內(nèi)核參數(shù)做出修改，由于是wget統(tǒng)一拉取的，所以在update的時候只要通過修改oss里面的批量類型init.sh就可以做到了，不需要修改每一個資源池配置

為了更安全起見，我們還做了內(nèi)核初始化兜底保障功能，當(dāng)然我們在以往的經(jīng)歷中發(fā)現(xiàn)，有些節(jié)點會因為網(wǎng)絡(luò)變更等原因拉不到oss的初始化文件，且Ali沒有這塊初始化的提示，所以kube-node會有一個初始化的兜底，如果節(jié)點啟動初始化失敗會檢測到對應(yīng)的錯誤數(shù)據(jù)并將其修改為正常值

整套上線后，我們配置了7個監(jiān)控告警項，在實際運行中發(fā)現(xiàn)5次以上隱患問題提前在故障發(fā)生前就預(yù)先進(jìn)行了處理，保障了產(chǎn)線的穩(wěn)定性運行。至此，整個故障算是畫上了圓滿的句號

3.4 容器安全的一些保障

上面正好說到兜底保障，其實我們在整個容器集群里部署有多個保護(hù)系統(tǒng)，下面我就舉例一個防誤刪場景的方案。

3.4.1 簡介業(yè)內(nèi)防控體系

首先我們來參考下某知名大廠的防控體系

從架構(gòu)看來，大致分為三大塊：權(quán)限、風(fēng)控、流控

權(quán)限管控：

2018年某大廠整體架構(gòu)開始往社區(qū)K8S方向遷移。遷移是個非常漫長的過程，需要考慮很多的細(xì)節(jié)。最開始自然是K8S權(quán)限體系管控問題，不同BU、不同平臺、基礎(chǔ)組件，都要跟新的ASI對接，第一件事情就是 申請項目專用賬號 。當(dāng)時SRE開了個Git倉庫，專門用于各個 基礎(chǔ)業(yè)務(wù)方 提交 賬號申請信息，格式是按照 K8S標(biāo)準(zhǔn)權(quán)限資源 進(jìn)行提交。

除了 RBAC，SRE還管控 CRD、WebHook 、Kubeconfig 等核心資源

風(fēng)險控制Webhook風(fēng)控：

不同平臺方、業(yè)務(wù)方一般在自己的前端或者后端都有對應(yīng)的邏輯進(jìn)行風(fēng)險控制。但是也搞不好業(yè)務(wù)方在邏輯上存在Bug或者不夠完善的地方，因此在最基礎(chǔ)的底層上，需要有個SRE的WebHook對所有請求進(jìn)行攔截校驗兜底。

流量控制K8S-Defender

阿里搞的 K8S防火墻主要針對于API流量風(fēng)控，早期是Webhook機(jī)制實現(xiàn)，但是K8S-Webhook天然存在一些缺陷，比如無法站起全局視角進(jìn)行精準(zhǔn)流控，因此后面是獨立出來了。做成了C/S模型，但需要強(qiáng)制讓所有接入ASI的基礎(chǔ)組件在關(guān)鍵的位置統(tǒng)一使用 Defender 做K8S流量風(fēng)制，這個目前在得物這個階段很難推得動，所以可以降級到Webhook機(jī)制去實現(xiàn)。

他山之石，可以攻玉。我們可以參考

3.4.2 得物現(xiàn)在防護(hù)具備的功能

3.4.2.1 Namespace 防誤刪：

這里分為硬性和軟性兩種方式。

對于核心的Namespace，例如 kube-system、monitoring。不應(yīng)該以任何理由刪除，這類Namespace可以 普通賬號直接鎖死，即便你RBAC里面擁有刪除NS的權(quán)限，就不允許刪除。

對于 Addons 或者 純業(yè)務(wù)類型的Namespace，因為可能出現(xiàn)調(diào)試場景，比如：調(diào)試或者測試某個復(fù)雜的Addons組件，因為牽涉到太多的配置和資源，過程中已經(jīng)混亂不堪，想徹底干凈地重裝一遍，回到初始狀態(tài)。這種情況下是需要利用K8S級聯(lián)刪除特性，把該Namespace包括下面所有資源清理一次。如果鎖死該Namespace，業(yè)務(wù)方遇到這種情況，就會很麻煩，所以這個場景走 硬性防刪 就不是明智之舉。

相對于硬性防刪，我們引入了軟性防刪策略。也就是對于非核心的Namespace，在一定的時間內(nèi)，我們對刪除的請求做計數(shù)統(tǒng)計，在沒達(dá)到閥值之前，會一直拒絕刪除。并在返回的結(jié)果上給予風(fēng)險提示，如果N秒內(nèi)再提交X次，則真的執(zhí)行刪除動作。這種方式對業(yè)務(wù)方明顯會更加友好一些，一方面起到了一定防誤刪效果，另一方面也不至于在你真正想刪除的時候刪不掉。

另外我們還開發(fā)了一種策略，專門針對批量刪除Namespace的場景。對于我們目前Namespace的使用方式是不合理的，說不定哪天可能會對Namespace做治理，以域的方式來確定Namespace。這個時候就會涉及到大量Namespace的清理工作。這種合法的刪除，如果不斷地被Webhook攔截中斷，這不是個合理的設(shè)計。所以我們支持以管控標(biāo)降級策略，也就是給對應(yīng)的Namespace打一個管控標(biāo)，則Webhook對這類Namespace就主動做降級處理，不再校驗攔截。這樣運維就可以正常地做批量刪除動作。

3.4.2.2 NS-CRD|CR 防誤刪：

K8S WebHook 機(jī)制，是可以對任意帶Namespace的CRD|CR進(jìn)行攔截。其攔截邏輯是可以共享的，只是資源類型不一樣。所以我們可以動態(tài)配置，攔截邏輯對哪些資源生效。

支持 Ingress、WorkLoad、Service、ConfigMap、Secret、Pod ... 類型資源，并支持標(biāo)簽篩選能力

3.4.2.3 高危配置校驗：

對于 Ingress 規(guī)則配置比較復(fù)雜，很多初學(xué)者會犯一些低級錯誤。比如：rule.host 配置為 '*' ，這意味著該規(guī)則匹配所有域名，所有請求都會過這條規(guī)則進(jìn)行轉(zhuǎn)發(fā)，顯然生產(chǎn)環(huán)境這種配置是不合理的。而且一旦配置上可能會覆蓋掉大量的rule，導(dǎo)致生產(chǎn)故障。所以這類低級錯誤配置一定要攔截，不允許配置。

這里就簡單畫下方案圖，大致基本借助于webhook的能力，對一些刪除動作的時候加強(qiáng)校驗與攔截的機(jī)制。

4、總結(jié)

上述幾個案例都是得物容器SRE團(tuán)隊在日常工作中真實發(fā)生的事件，覆蓋的也只是多項工作中的冰山一角，寫這篇文章也是想讓大家認(rèn)知到我們團(tuán)隊，了解我們?nèi)萜鱏RE。由于篇幅有限其余細(xì)節(jié)不再展開了，大家有疑問歡迎找我討論。同時也歡迎對容器/云原生/SRE 等領(lǐng)域感興趣的同學(xué)加入我們。

我們是得物容器SRE團(tuán)隊。

我們團(tuán)隊的宗旨是為全司提供穩(wěn)定、高效、安全的支撐和服務(wù)。

服務(wù)項目：業(yè)務(wù)穩(wěn)定性保障，線上業(yè)務(wù)系統(tǒng)變更，業(yè)務(wù)性能&狀態(tài)監(jiān)控，容量評估；核心業(yè)務(wù)場景梳理，識別關(guān)鍵鏈路和關(guān)鍵接口，制定服務(wù)保障預(yù)案，對關(guān)鍵鏈路實施故障演練，確保服務(wù)的連續(xù)性。得物容器化集群維護(hù)、系統(tǒng)網(wǎng)絡(luò)維護(hù)以及系統(tǒng)基礎(chǔ)組件維護(hù)。保障基礎(chǔ)環(huán)境的穩(wěn)定、高效，并提供豐富的工具和平臺提升系統(tǒng)的自動化、可視化、智能化。