作者
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 性能優化實踐、最佳實踐等系列，
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/327815.html
標籤：其他