作者

tomdu，騰訊雲高階工程師，主要負責宙斯盾安全防護系統管控中心架構設計和後臺開發工作。

導語

宙斯盾 DDoS 防護系統作為公司級網路安全產品，為各類業務提供專業可靠的 DDoS/CC 攻擊防護。在黑客攻防對抗日益激烈的環境下， DDoS 對抗不僅需要“降本”還需要“增效”。隨著雲原生的普及，宙斯盾團隊持續投入雲原生架構改造和優化，以提升系統的處理能力及效率。本文主要介紹宙斯盾防護排程平臺上雲過程實踐與思考。

為什麼上雲？

雲原生作為近年來相當熱門的概念，無論在公司內各部門，還是公司外各大同行友商，都受到追捧。雲原生涉及技術包括容器、微服務、 DevOps 、持續交付等，這些新的技術和理念能帶來哪些收益？在我們看來，

資源共享，動態擴縮容——“降本”

以宙斯盾防護排程平臺為例，因為以前申請的物理機資源還在服役期，所以當前大部分後臺服務還是執行在物理機。申請時會適當預留 buffer （資源消耗跟外部攻擊威脅有關，波峰波谷相差可達十倍）。這部分 buffer 雖然作為 backup ，但同時大部分時間處於空閒狀態，物理機也不便於跨系統、專案共享。在資源上雲階段， CVM 已經對物理機做了虛擬化，一定程度上實現資源共享。隨著容器化管理平臺的出現，資源控制粒度更細。例如在 TKE 平臺上，一個容器分配的資源可以精確到0.1核 CPU 、1 MB 記憶體，根據負載隨時擴縮容。同時所有資源作為一個大池子來共享，減少資源浪費。

容器化管理，快速部署——“增效”

要提升迭代速度，除了開發環節，測試、釋出、運維都需要做優化。原來物理機部署時，需要運維同學手工或者通過專門的運維釋出平臺來完成釋出，期間還可能因為機器環境的差異出現釋出失敗或者異常，需要人工處理。現在通過容器化部署，可以保證服務的執行環境一致性，避免“雪花伺服器”。同時藉助容器管理平臺，可以實現一鍵釋出、快速擴縮容，通用的容器容災策略為服務的穩定性提供了基本保證。

怎麼上雲？

當前架構

如上圖所示， DDoS 防護流程包括攻擊檢測（發現攻擊）和攻擊防護（攻擊流量清洗及正常流量回源）。

在這個過程中，還需要一個主控“大腦”來協調檢測系統和防護系統，以實現全流程的自動化處理——這個“大腦”就是防護排程平臺。在檢測到 DDoS/CC 攻擊時，防護排程平臺會自動化決策需要呼叫的防護裝置機房、數量、以及需要下發的防護策略，遇上強對抗時還需要實時調整防護裝置上的防護策略，其重要程度可見一斑。

當前防護排程平臺整體架構如下圖所示。

• 防護裝置：分為 ADS （ Anti-DDoS System ）、 HTTP CC 、 HTTPS CC 三大類，結合多年來團隊在 DDoS/CC 攻防對抗上的積累，分別集成了各種協議/場景下的自研防護演算法。防護裝置部署在全球各地機房入口，在觸發攻擊告警後牽引並清洗攻擊流量，然後回源。其上部署有管控 agent ，負責與後臺通訊、並管理防護裝置。
• 接入層：多點接入，內網、公網接入。管控 agent 啟動後隨機選擇一個可用接入進行 TCP 連線。
• 後臺服務：多主/主備部署，向接入註冊心跳，所有後臺請求通過接入分發、負載均衡，所有 agent 請求通過接入轉發。

如果按照當前架構直接部署到 TKE 上，系統是可以執行起來，但是由於機器部署和容器部署的特性不同，直接部署總會有些衝突、彆扭的地方。考慮方案時，我們覺得當前架構不適應 TKE 部署的主要地方有：

• 服務發現：後臺服務根據預配置的接入 IP 列表註冊心跳，容器化部署後 IP 切換頻繁，通過配置的方式載入接入已經不適用。
• 無狀態：容器化部署可以做到根據負載快速擴容，但需要服務做到完全無狀態才能達到完全水平擴充套件。當前多主部署的服務都是無狀態的，可以直接遷移，但主備部署的服務則需要改造。
• 配置管理：當前按機器維度管理，與執行環境相關/無關的配置混在一起。

同時，藉著這次上雲的機會，我們也希望對系統架構做一次大的優化，接入公司成熟的公共服務如北極星名字服務、七彩石配置中心、智研，提升研效。

上雲架構

基於當前架構，除了把服務做映象打包、遷移到 TKE 上部署，同時對不適應的地方做改造、優化。改造後的大致架構及流程如下：

• 服務發現：後臺服務全部接入北極星名字服務，向北極星註冊例項、定期傳送心跳，接入從北極星獲取各類服務健康例項來分發請求。
• 無狀態：當前系統存在狀態的場景主要有兩類。
  • 檔案下載：主要是防護裝置的策略檔案下載，無狀態化改造涉及待下載檔案在多個檔案服務例項間同步。解決方案是選擇使用 CFS 來同步檔案。
  • 策略分包下發：策略太大時應用層做了分包，同一請求雜湊到同一後臺策略服務例項。解決方案是請求中帶上當前分包狀態資訊，任一策略服務例項可以處理且結果一致。
• 配置管理：與執行環境無關的配置，接入七彩石配置中心，保證同一型別部署的例項配置一致。
• 日誌監控：遷移到智研日誌匯、監控寶。

兩大“攔路虎”

如何平滑遷移

當前物理機環境穩定執行，計劃逐步灰度、切量到TKE環境，因此會有一段時間是物理機+ TKE 混跑的狀態。管控接入、後臺服務遷移 TKE ，對於防護裝置 agent 是透明的。因為防護裝置 agent 只會選擇一個可用接入建立連線，即 agent 只會連到物理機環境或 TKE 環境，因此後臺服務與 agent 互動時，混跑狀態下涉及物理機環境和 TKE 環境互訪的情況。這種情況 TKE 提供了靈活的配置支援。

在 TKE 上部署服務時，提供了兩種網路模組：

• Global Route ： VPC 內私有 IP ，無法從叢集外訪問，不可以註冊到 CMDB 。開啟隨機埠對映後可從叢集外訪問，並可繫結 CLB 和北極星。
• ENI IP ：公司內可路由 IP ，可從叢集外訪問，可以註冊 CMDB 、 CLB 和北極星。

在混跑灰度期間，接入部署選擇 ENI IP 的方式，物理機後臺服務訪問 TKE 接入跟訪問普通內網服務無異。遷移完成後，後臺服務改用 Global Route 的方式，僅允許叢集內互訪。後臺服務間通過原生的 service 訪問，對外只通過 CLB 暴露服務。

不斷變化的 IP

由於 DDoS 攻防對抗的業務特性，我們長期跟 IP 打交道，對 IP 有一種特殊的情節。在內部交流中，我們發現大家在遷移 TKE 過程中都會遇到一些共性問題。其中，跟 IP 相關的問題就會經常被提及。

在物理機部署環境，機器 IP 是固定的且變化頻率較低（幾年一次的機器裁撤）。但是在 TKE 環境，重啟一次服務，分配到的容器 IP 、節點就可能變了，導致系統中依賴 IP 實現的功能無法很好適應 TKE 環境。

訪問鑑權

比較簡單的鑑權是基於源 IP 加白，如介面訪問、 DB 訪問。對於介面訪問，我們定義了一套基於 JWT 的介面鑑權規範，所有對外介面不再使用源 IP 加白的方式。對於 DB 訪問，當前是使用不限源的獨立 DB 賬號，並對許可權做更細的劃分（精確到表）。後續 DB 許可權支援實時申請，當容器起來以後通過介面申請當前容器所在節點的訪問許可權。

服務發現

原來的架構中，管控接入層實現了簡單的服務註冊、服務發現功能，後臺服務通過 IP 配置來註冊、上報心跳。如果接入層不遷移到 TKE 、繼續保持相對固定，那麼這套方案還是可行的。但是，接入層遷移到 TKE 後，自身的部署節點也在不斷變化，因此需要一個獨立與接入、相對固定的服務註冊與發現模組。叢集內部署的服務可以使用 K8s / TKE 原生的 service ，對於物理機和 TKE 混跑的情況則可以考慮北極星名字服務。

服務暴露

這裡包含兩層含義，一個是該暴露給外部的服務如何保持穩定，另一個是不該暴露給外部的服務如何隱藏起來。

（1）暴露服務給外部

在物理機環境，機器裁撤導致服務IP變化就是經常出現的問題，通過域名、 VIP 都可以解決。在 TKE 上，通過 CLB 來實現。

（2）隱藏內部服務

通過 VPC 內私有 IP ，就能保證服務無法從叢集外訪問，實現隔離。

我們系統的最終目標是：所有對外服務通過接入層暴露出去，做好鑑權；內部的後臺服務都隱藏起來，保證安全性。

上雲效果

防護排程平臺上雲之後，

(1)在降低成本方面，預計資源使用率可以達到50%以上。之前為了保證 DDoS 攻擊峰值時能正常執行而預留的一大部分資源，閒時放到整個大資源池裡共享，忙時動態擴容。

(2)在部署效率方面，部署、擴容耗時從天降到分鐘。原來需要運維同學專人專職完成釋出，上 TKE 後只需開發同學簡單配置即可完成。同時，隨著業務場景的快速變化，通過 TKE 滿足了我們對高防、閘道器、第三方雲等場景的快速部署和擴容。

隨著公司內雲上服務越來越豐富，通過上雲和接入公共服務，優化宙斯盾防護排程平臺的架構，從而提升系統擴充套件性和迭代效率。
另外，宙斯盾的核心能力是 DDoS 、 CC 防護，除了管控上雲，我們也正在探索防護能力虛擬化的可能性，為雲上各種業務、場景提供靈活、彈性的防護能力。

關於我們

更多關於雲原生的案例和知識，可關注同名【騰訊雲原生】公眾號~

福利：

   ①公眾號後臺回覆【手冊】，可獲得《騰訊雲原生路線圖手冊》&《騰訊雲原生最佳實踐》~

   ②公眾號後臺回覆【系列】，可獲得《15個系列100+篇超實用雲原生原創乾貨合集》，包含Kubernetes 降本增效、K8s 效能優化實踐、最佳實踐等系列。

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！