0、前言

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

1、SRE定義

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

2、對(duì)于SRE的理解

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

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

（a）清晰的問(wèn)題升級(jí)路線(xiàn)

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

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

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

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

2.2 SLO和SLA制定和保障

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

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

2.3 變更管理

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

2.4 容量規(guī)劃

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

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

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

2.6 可靠性衡量

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

3、得物容器SRE的實(shí)踐

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

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

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

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

3.2 一次容器故障的分享

3.2.1 延遲問(wèn)題背景：

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

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

3.2.2 問(wèn)題排查思路：

排障過(guò)程描述只是說(shuō)了一個(gè)思路，部分時(shí)間點(diǎn)可能和故障產(chǎn)生的時(shí)間重合

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

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

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

接下來(lái)是整個(gè)根因排查分析：

• 排除鏈路問(wèn)題

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

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

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

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

• 深挖排查到IO平均等待時(shí)間上存在問(wèn)題

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

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

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

3.2.3 最終根因定位：

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

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

（一個(gè)展示源代碼存儲(chǔ)庫(kù)的軟件工具集）

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

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

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

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

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

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

當(dāng)時(shí)線(xiàn)上內(nèi)存

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

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

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

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

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

然后我們?cè)趺凑业绞钦l(shuí)呢？通常情況下可以這么理解，一個(gè) soket 就是一個(gè) fd （句柄），對(duì)應(yīng)soket 大必然fd 也大?。ㄒ?yàn)閘inux 一切皆文件）隨后我們用了 for 循環(huán)查找對(duì)應(yīng)的/proc 下的文件數(shù)量，結(jié)果如下：

附上命令參考：

#看進(jìn)程對(duì)應(yīng)哪個(gè)容器
for i in `docker ps |grep Up|awk '{print $1}'`;do echo \ &&docker top $i &&echo ID=$i; done |grep -A 15 4078683
#看FD誰(shuí)占用的多
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)無(wú)疑！

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

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

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

繼上文說(shuō)到的故障后，我們意識(shí)到了容器監(jiān)控上的不足故成立了專(zhuān)項(xiàng)來(lái)做內(nèi)核參數(shù)上的監(jiān)控。但是內(nèi)核參數(shù)上千個(gè)我們?cè)趺磥?lái)做？

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

所以第一步就是完成內(nèi)核指標(biāo)羅列范圍。我們對(duì)以往的故障和反饋分析來(lái)看，網(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)的采集實(shí)現(xiàn)

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

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

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

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

3.3.4 場(chǎng)景分類(lèi)逐個(gè)優(yōu)化

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

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

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

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

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

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

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

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

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

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

3.4 容器安全的一些保障

上面正好說(shuō)到兜底保障，其實(shí)我們?cè)谡麄€(gè)容器集群里部署有多個(gè)保護(hù)系統(tǒng)，下面我就舉例一個(gè)防誤刪場(chǎng)景的方案。

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

首先我們來(lái)參考下某知名大廠的防控體系

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

權(quán)限管控：

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

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

風(fēng)險(xiǎn)控制Webhook風(fēng)控：

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

流量控制K8S-Defender

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

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

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

3.4.2.1 Namespace 防誤刪：

這里分為硬性和軟性?xún)煞N方式。

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

對(duì)于 Addons 或者 純業(yè)務(wù)類(lèi)型的Namespace，因?yàn)榭赡艹霈F(xiàn)調(diào)試場(chǎng)景，比如：調(diào)試或者測(cè)試某個(gè)復(fù)雜的Addons組件，因?yàn)闋可娴教嗟呐渲煤唾Y源，過(guò)程中已經(jīng)混亂不堪，想徹底干凈地重裝一遍，回到初始狀態(tài)。這種情況下是需要利用K8S級(jí)聯(lián)刪除特性，把該Namespace包括下面所有資源清理一次。如果鎖死該Namespace，業(yè)務(wù)方遇到這種情況，就會(huì)很麻煩，所以這個(gè)場(chǎng)景走 硬性防刪 就不是明智之舉。

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

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

3.4.2.2 NS-CRD|CR 防誤刪：

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

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

3.4.2.3 高危配置校驗(yàn)：

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

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

4、總結(jié)

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

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

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

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