79      阿裏雲  技術社區[雲棲]

網易雲基於Kubernetes+Docker的容器服務研發實踐

網易從2012年春開始雲計算研發，陸續上線私有雲IaaS、PaaS服務，並實現網易95%以上的互聯網業務遷移上雲。在近日的網易雲技術布道係列活動中，張曉龍分享了網易雲基礎服務團隊在研發容器服務過程中的實戰經驗。

首先看到網易雲的研發曆程和整體架構，如下：

下圖是網易雲的簡單架構：

技術架構從底到上可分為三層：

1. 基礎設施層主要采用虛擬化技術將服務器、交換機/路由器以及硬盤等物理設備虛擬成為可以按需分配的計算/存儲/網絡資源。基礎設施層主要包括：雲主機、雲網絡、雲硬盤等服務。基礎設施層不僅為網易雲容器服務運行提供計算/存儲/網絡資源，同時也為數據庫、緩存、負載均衡等網易雲平台服務提供資源；

2. 核心業務層主要包括兩塊：一是容器及容器編排：鏡像倉庫、日誌服務、容器服務、編排服務，主要覆蓋了以容器以及容器編排為中心的網易雲容器服務核心功能；二是PaaS插件服務，主要包括數據庫、負載均衡、對象存儲、緩存等；

3. 最上麵的外圍服務層，也是構成一個平台不可或缺的一部分。主要包括：認證、API服務、計費服務、安全服務、監控服務。

作為核心服務之一，網易雲容器服務提供彈性計算、DevOps工具鏈及微服務基礎設施等。服務的功能包括三個方麵：

1. 提供有狀態/無狀態容器及其鏡像加速/構建/倉庫等在內的容器服務；

2. 提供包括對象存儲、CDN、關係數據庫、MongoDB、負載均衡、緩存服務、安全服務等在內的完善平台服務，是實現互聯網應用的通用的基礎組件；

3. 提供包括服務發現、編排服務、APM服務、持續集成、監控服務、日誌服務、持續發布等在內的完整DevOps工具鏈。

要構建一個容器服務，需要三類核心的技術：基礎設施、容器、容器編排。下麵詳細解讀。

基礎設施提供容器運行所需計算/存儲/網絡資源，高效管理這些資源並確保資源的按需分配、高效交付，同時要保證交付資源的QoS比如計算能力、網絡性能、I/O能力等。

基礎設施服務的技術基礎是虛擬化技術，包括計算、網絡、存儲的虛擬化技術，計算的虛擬化無論在硬件或軟件層麵都相對成熟，而在網絡、存儲的虛擬化上網易雲的選擇是軟件定義的技術。

• 在計算虛擬化方麵，采用了高效穩定可靠的KVM虛擬化技術；

• 在網絡虛擬化方麵，基於OpenVSwitch采用最新流行的SDN技術，獲得更大的網絡靈活性；

• 在塊存儲方麵，采用的是可擴展性較強的Ceph技術；

• 使用開源雲平台框架OpenStack實現對上述資源的高效管理；

容器是網易雲容器服務資源交付的最小單位，通過采用了最新Docker技術，實現應用交付的標準化；目前的容器服務基於Docker1.12版本打造。

要基於容器實現一個可水平擴展的產品服務端架構，需要使用容器編排技術實現對容器集群的發布、回滾、遷移、擴容、縮容等。我們的容器編排基於開源項目Kubernetes，Kubernetes服務將資源抽象為三個層次：容器（軟件及運行環境），Pod（相關聯的容器組合）容納一個或多個容器，Node（提供計算/網絡/存儲的資源節點）容納一個或多個Pod。

關鍵技術1——基礎設施服務

網絡

• 使用VxLan大二層技術實現網絡數據麵，基於OpenVswitch開源虛擬交換機實現OpenFlow協議；

• 基於OpenStack Neutron實現網絡控製麵。

存儲

• 兩類塊存儲後端：1）基於Ceph的普通塊存儲；2）基於軟RAID技術的自研高性能塊存儲（用於高性能IO場景如數據庫等）；

• 基於OpenStack Cinder實現塊存儲資源管理。

計算

• 采用KVM虛擬化技術；

• 基於OpenStack Nova實現虛擬機生命周期的管理。

關鍵設計2——容器計算

首先，容器的計算資源應該如何提供？應該跑在物理機上還是虛擬機上？從公有雲層麵來說，在容器的隔離性不是特別好的情況下，還是要跑在雲主機上麵，這是對用戶最基本的安全承諾。

• 好處1：由於是操作係統層麵的輕量級虛擬化，容器安全性一直是用戶非常關心的問題，也製約著容器技術的發展。容器安全性問題以“容器逃逸”問題最有名，也就是黑客是可以通過容器的一些漏洞滲透到運行容器所在的宿主機上，對宿主機上的其他容器以及宿主機本身都造成巨大的威脅。在容器安全性問題沒有得到有效解決前，將容器運行在虛擬機上，利用虛擬機的強隔離性，可以加固容器的安全性。

• 好處2：由於容器是輕量級虛擬化，所有容器共享宿主機的內核，宿主機上一個容器的運行異常和故障，很有可能導致宿主機內核的crash，從而影響宿主機上其他容器的正常運行；因此，將容器運行在雲主機中，盡可能少的容器共享同一個內核，可以實現故障的隔離，提高係統穩定性；

• 好處3：由於容器運行在雲主機中，我們可以大膽把一些係統的能力如設置iptables的能力開發給用戶，而不用擔心開放這些能力會對宿主機係統造成很大的影響。這可以使得用戶得到更多的功能，對容器具有更強的掌控；

這樣做的缺點在於：容器運行於雲主機，要忍受硬件虛擬化技術帶來一定的資源和性能開銷。

關鍵設計3——容器網絡

容器網絡

• 私有網：虛擬平坦二層網絡、租戶間完全隔離，通過容器私有網卡接入

• 公網：允許綁定公網IP到容器，通過容器公網網卡接入

實現

容器網絡由基礎設施服務來提供，並確保網絡的性能、可擴展性；容器不關心和處理網絡性能、可擴展性問題，隻管用雲提供的網絡服務創建和使用相應的網絡。網易雲為每個租戶提供一張完全隔離的私有網絡以及一張所有租戶共享的公網。

• 私有網接入：基於雲主機上的網橋和容器veth pair實現

• 公網接入：將雲主機上的公網端口置入容器的namespace中

關鍵設計4——持久化容器數據

容器的存儲也是比較難解決的問題，多數容器都是無狀態的，也就是說容器內部不應該保存用戶有用的數據，一個容器掛掉後，用鏡像能很快啟動另一個容器，保證係統的正常運行。從架構上來說這個設計很好，彈性可擴展。但如果架構設計能力不是太好的情況下，很容易出現有狀態容器的需求。

存儲需求

但不管是Docker還是Kubernetes都不解決容器的存儲問題，隻可以用docker -v指定一個數據目錄，所以在構建容器雲時有2個需求：

• 容器根目錄rootfs會保存其運行時數據，需要用雲盤保存容器rootfs數據

• 容器需要掛載雲盤作為data盤

難點

Docker默認會將所有容器rootfs都存儲在overlay目錄下，不同容器rootfs數據無法有效區分並隔離

方案

• 實現Docker啟動時可指定獨立rootfs的功能

• 在啟動容器前將雲盤掛載到啟動容器的rootfs上

關鍵設計5——網絡安全

網絡安全也是雲平台設計非常重要的一點。

網絡過濾

• L2過濾：確保報文源MAC地址是係統所分配端口MAC地址，防止ARP欺騙

• L3過濾：確保數據包源IP是係統所分配IP，防止IP地址欺騙

• L4過濾：過濾指定的TCP/UDP端口，便於實施網絡封禁

DDoS攻擊防護

基於Intel DPDK技術實現高性能實時抗攻擊

關鍵技術6——網絡帶寬QoS

設計原則

• 保證用戶所申請網絡帶寬

• 有效利用空閑網絡資源，免費提升用戶帶寬體驗

實現方案

• 基於Linux Traffic Control並修改OVS，實現保證速率、最大速率

• 將小包按照MPU（Minimum Packet Unit）大小來處理

網絡QoS另一個重要問題是網絡小包過載的問題。

• 問題：VXLAN小包處理性能不夠好，網絡小包過多導致宿主機CPU過載（軟中斷過多），影響網絡性能和穩定性

• 方案：限製容器網絡的PPS （Packet Per Second）

關鍵優化7——容器啟動速度

問題

容器運行於雲主機，容器啟動依賴於雲主機先啟動，而基於硬件虛擬化技術的雲主機啟動速度較慢。

啟動速度優化

1. 定製係統鏡像,裁剪不必要服務啟動加載項；

2. 雲主機IP靜態化，加速網絡初始化過程。IP靜態化的原因：雲主機網絡初始化使用DHCP服務獲取網絡IP和路由等信息，會占用較多啟動時間。在網絡服務啟動前使用Cloud-init和ConfigDrive完成網卡名稱匹配和IP配置信息注入；

3. 優化OpenStack創建雲主機流程,主要是在OpenStack的計算節點上做了一些優化。

優化效果

創建容器在40秒內完成

關鍵優化8——網絡性能

內網使用巨幀（Jumbo Frames）模式，提升數據傳輸的吞吐量。

VxLan性能優化

使用不同內核版本和OVS版本的組合，VxLan性能差異很大，在萬兆網絡環境下使用3.18版本內核 + 2.6版本OVS，雲主機單連接網關轉發性能可近4Gbps，雲主機多連接網關轉發性能可達近9Gbps，雲主機間互訪近4Gbps

關鍵技術9——解決Ceph運維時性能衰減

性能問題

社區Ceph在osd進程重啟時會出現長時間、極其嚴重的性能衰減(80%+)，原因是osd重啟時要恢複重啟期間髒數據對象，會消耗大量網絡/磁盤開銷

解決手段

在pglog記錄重啟期間數據對象的增量數據，在重啟時增量恢複數據對象

解決效果

• 減少重啟過程對集群正常I/O性能影響（ I/O性能降低10%~20%以內）

• 縮短重啟恢複所需時間（重啟單個osd從10分鍾減少到40秒左右）

關鍵優化10——容器編排多租戶支持

原生的Kubernetes沒有租戶和多租戶的概念，意味著要給每個用戶部署一套Kubernetes的集群管理係統，網易雲用一套Kubernetes集群去管理所有租戶的容器，這是跟社區版本中完全不一樣的地方。

完善多租戶支持

• 將容器的資源按照多租戶進行分類，如下圖所示，將node、存儲、網絡等集群共享的資源實現租戶隔離

• 實現租戶資源的安全訪問控製，為每個租戶實現獨立的認證和授權

關鍵優化11——容器編排性能

性能問題

• 原生K8S編排的可擴展性有瓶頸，無法支持更大規模節點的編排

• K8S各組件在高水位下資源占用太大

優化手段

• 實現調度器並行調度，提升集群調度能力

• 實現副本控製器多優先級處理，提升容器創建速度

• 精簡內部負載均衡轉發表

• 優化api-server和kubelet、kube-proxy，減少內存資源占用

調度器並行優化

• 問題：原生scheduler調度是全集群串行，不可並行擴展

• 優化：所有資源按用戶分組，全並行調度，集群規模再大也能瞬間調度

副本控製器多優先級處理

• 問題：原生controller對副本的增量的增/刪/改和全量定時任務單隊列處理

• 優化：增加多優先級隊列(Add>Update>Delete>Sync All)，讓實時控製流優先處理，提升容器創建速度

內部負載均衡轉發表精簡

• 問題：原生使用iptable全局轉發，性能隨集群規模增大線性遞減

• 優化：租戶之間網絡隔離後，可以將轉發規則精簡到各個租戶內部

kubelet、kube-proxy、api-server內存優化

• 問題：這些服務隨著集群規模增長，內存也都直線上漲

• 優化：agent隻加載自己租戶擁有的namespace下數據， apiserver增加索引降低cpu以減少並發協程數

優化效果

• 支持3w+容器的編排

• 高水位下容器創建時間40s之內完成

• K8S上節點占用內存優化為原來的1/4，Api-Server內存減少了1/4

關鍵技術12——容器性能監控

1. 數據采集：基於CAdvisor采集計算存儲網絡等監控如cpu/mem/io/tcp連接/網絡流量

2. 數據推送：Agent負責從CAdvisor拉取監控數據並推送到後端進行數據聚合

3. 數據聚合：將相關監控項按照容器、pod、副本等層次聚合並展示

雲計算的研發是一項係統的基礎開發工作，有非常大的難度，而雲計算產品最重要的是穩定性、性能和安全，我們後續的工作也將圍繞這三方麵展開。

原文發布時間為：2017-04-07

本文來自雲棲社區合作夥伴DBAplus

最後更新：2017-05-16 12:01:29

  上一篇：  一條更新操作引起的MySQL主從複製異常

  下一篇：  從源碼探究MySQL5.7高吞吐事務量的背後操手