網易雲基於 K8S 的容器服務實現

| 為 | 容 | 器 | 技 | 術 | 而 | 生 |

講師：陳定斌 / 網易雲資深雲計算解決方案架構師

編輯：小君君

校對：夏天

網易雲很早就開始使用容器，因為 Kubernetes 在容器編排上的規模應用，使得很多服務都將 Kubernetes 作為基礎核心的一部分。在長時間的使用過程中，積累了很多 Troubleshooting 的經驗，特別是在升級和網路架構演進方面。本次介紹主要針對網易雲在 Kubernetes 應用過程中遇到一些典型挑戰和思路。

網易雲容器服務的歷史

2015 年網易雲容器已經開始啟動基於 Kubernetes 0.6 版本的調研，當時 Kubernetes 1.0 還沒有正式發布。2015 年 10 月，基於 Kubernetes 1.0 版本，我們發布了容器服務 1.0 版本。2016 年我們啟動了基於微服務版本的容器平台開發（基於 Kubernetes 1.3 版本）。在 2016 年 10 月，我們正式發布了容器服務 2.0 版本。2017 年 10 月一直到現在，我們主要用的是 1.8 和 1.9 版本。在發布 2.0 版本後，1.8 和 1.9 版本的使用就正式回歸到原生。現在我們已經在私有雲上線了基於 Kubernetes 1.9 的正式版本。

網易雲主要使用 Kubernetes1.0、1.3、1.6 和 1.9版本。因為 1.0 版本比較老舊我們不再使用，現在主要用的是 1.3 版本。1.6 版本主要是為了基於 Kubernetes 1.3 適配基於 VPC 網路的裸機容器而開發上線的。在使用 1.8 和 1.9 版本後，就捨棄了 1.6 版本。現在已在私有雲上線了基於 Kubernetes 1.8 和 1.9 的容器服務。目前網易雲的容器服務主要還是基於 Kubernetes 1.3 去提供，這就包括經典網路和 VPC 兩種類型網路的容器服務。

這是網易雲容器服務的整體架構。這張圖可以看到左邊是容器服務的管理平台，右邊是容器實例部分。左邊的容器服務管理平台，又分成兩部分，包括偏上一部分的基於微服務的公共服務模塊，包括服務治理和需要支持的公共服務（包括認證，用戶中心等）。另一個模塊，是基於 Kubernetes 基礎容器服務的管理模塊，這個模塊主要是用來管理容器配置，容器管理等。

右邊模塊，可以看到網易雲使用兩種類型的容器。一種是基於 KVM ，部署在 KVM 雲主機內的容器實例。另一種是直接部署在裸機 Kubernetes 的容器實例。同時我們基於 LVS+HAProxy ，再結合 Kubernetes 的 Ingress 來提供面向容器實例的對外負載均衡服務。容器實例配置管理，可以通過 API 網關調用和 Web 控制台兩條路徑下發到配置容器。

剛才講的那些，主要是基於 Kubernetes 1.3。為了使容器網路同時支持經典網路和 VPC 網路，所以我們對於 Kubernetes 的定製改造做的比較深。在同時支持兩種網路模式的情況下，我們對容器服務進行了面向公有雲的全面改造，既要支持多租戶隔離，又要對容器服務實施安全加固還要自己做一些動態資源管理。

同時我們也深度整合了網易雲的基礎資源，租戶的 VPC 內部兼容雲主機和容器實例。容器包括基於虛擬 KVM 主機的容器實例和基於高性能物理機的裸機容器。同時，容器服務兼容經典網路和 VPC 網路，支持本地盤和基於 Ceph 的普通雲盤，結合了網易雲自研的 NLB 提供負載均衡服務。在使用 Kubernetes 容器服務的同時，做了比較多的性能優化和功能增強。

首先在 VPC 網路內部，網易雲能支持的集群規模可達 3.5 萬。在整個 Kubernetes 做配置和管理時會對整個調用鏈路進行優化。同時也實現了一些高級有狀態的服務，並且支持數據自動遷移和容器垂直擴容。

容器網路

現在介紹支持 VPC 網路的容器實例部署。首先介紹一下 VPC 網路，它屬於公有雲平台的一個基礎部分。用戶在使用 VPC 網路時，可完全構建一個隔離的網路空間。租戶在這個空間內，可以自定義它的子網地址、地址段、還有路由表。同時通過配置安全組的規則，實現網路訪問控制，所以它具有一個完整隔離網路的優勢，並能支持靈活配置和安全控制。

這張 PPT 中左邊圖主要是裸機容器實例，裸機設備使用兩個介面，一個介面是直接打通到 Kubernetes Master 網路，Kubernetes Masber 通過這個管理口，去下發配置來創建裸機容器實例。裸機容器實例通過 veth pair 和 OVS datapath 網路打通容器流量就可以通過 OVS 進入到虛擬網路中。容器流量可進入到 VPC 網路內。

右圖是基於 KVM 雲主機內部的容器實例，在部署容器時，首先會去創建一個雲主機。這個雲主機，會分配一個私網地址，將這個地址通過 VPC 網關和 Kubernetes Masber 打通，以此作為管理地址。Kubernetes Masber 通過這個地址下發到 KVM 雲主機內部配置容器實例。通過雲主機的虛擬網卡出去到達宿主機上的虛擬交換機，再通過虛擬交換機進入到虛擬網路。所以 KVM 雲主機容器和裸機容器在 VPC 中可完全通過私有網路互連。它和雲主機之間是一個完全扁平的網路(兩者之間是等價的)。

這張圖，是如何配置 Kubernetes 和基礎網路，雲網路服務做了一個適配，支持容器網路和正常雲主機 VPC 網路。首先 Controller 模塊是我們自己做的，這個模塊會監聽 Kubernetes Pod 的創建和刪除。當 Pod 創建或刪除操作的事件觸發時就會調用基礎服務的雲服務模塊以此來創建或刪除 Port，並將這個 Port 信息傳遞給 Kubernetes Master。而 Node 節點上的 kuberlet 模塊會監聽 Master 上的 Pod&Network 配置。

當事件觸發後，通過本地的 NetEase CNI Plugin 模塊調用基礎服務的雲網路模塊，將這個 Port attach/detach 到容器實例。同時調用雲網路模塊，將分配的的私有網路 IP 地址通過 DHCP 配置到虛擬網卡上，然後下發初始路由到 Node 上。

最後基於這種扁平化雲網路，租戶可以根據應用的需要選擇具體的部署實例，這樣可以更加靈活，應用部署會更加多樣化。對於部分租戶，當在雲內部署時，它的應用可以支持部分容器化，這樣就可以實現整體向容器化的過渡。所以對於很多應用來說，更願意選擇支持雲主機和容器這兩種在雲內的網路模式。

負載均衡

網易雲提供的容器負載均衡，主要是對內負載均衡和對外負載均衡。這一頁主要是對內的負載均衡。我們直接使用 Kubernetes 基於服務發現的負載均衡模式。租戶在配置創建 Service 時，會生成一個虛擬私有 VIP，租戶去訪問這個 VIP 時，會命中一條 iptables 規則。

內部負載均衡是通過這種規則來配置實現。為了更好的在應用部署初始化過程中感知服務網路，可以結合 DNS 來提供內部域名服務，而容器應用不需要獲取具體的 VIP。根據約定好的域名規則去訪問其他服務。在對於容器集群這種無狀態的節點，我們是建議使用 Service 內部負載均衡。

網易雲對於容器提供的對外負載均衡，是基於自研的 NLB 結合 Kubernetes Ingress 。正常的負載均衡，是通過 NLB Manager 模塊（負載均衡控制模塊）將負載均衡配置下發到 NLB Cluster 上。對於容器實例，我們基於自己實現的 NLB Controller 模塊，去監聽 Kubernetes Ingress 配置。租戶去配置 Ingress 時，可以選擇公網類型或機房網的類型網路。

假如租戶選擇公網，此時 Kubernetes 向雲網路服務請求分配一個公網地址。這個公網地址可以作為負載均衡實例的 VIP。租戶將 Ingress 和 Service 做一個對應，Service 對應後端 Endpoint 的私網地址，作為負載均衡的 RealServer，通過 NLB Controller，在負載均衡實例上配置一個完整負載均衡，實現對外的負載均衡服務。

通過我的描述，也能了解到我們的負載均衡服務，無法同時去兼容容器和雲主機。負載均衡如果不全是容器就全是雲主機。因此基於 Ingress 的擴展能夠支持 Kubernetes 版本。

這一頁是對外公網類型的負載均衡的架構。從圖上看，左上角是負載均衡集群。負載均衡，我們主要是通過 LVS +HAProxy 提供負載均衡。右側是第三方服務，主要是為了監控負載均衡集群的服務狀態，做一些日誌和告警。下面這部分是管理模塊，正常用戶可以直接通過控制台去下發，或者通過 API Gateway 下發配置到基於雲主機的負載均衡實例上，也可以通過調用 Kubernetes 來配置基於容器的負載均衡實例。

所以這三種配置方式，可以看出來我們是如何兼容負載均衡，如何提供容器、雲主機負載均衡的模型。同時基於 DPDK 實現的高性能負載均衡，在數據上，用戶的流量是從客戶端通過 Internet 到 NLB 網關。在網關上，會將公網地址映射到一個私網地址，通過私有網路將流量路由到負載均衡實例上，利用負載均衡演算法，再選擇雲主機或容器私有地址作為該請求的最終目的地址。

K8S 升級——1.0~1.3

網易雲在進行容器服務開發時，依賴模塊會比較多。基於現在生產狀況以及我們實際的容器服務版本和基於 Kubernetes 1.0 到 1.9 版本現狀。因為版本跨度太大，所以在容器服務整體升級上幾乎無法實現。

今天是主要講 Kubernetes 升級的一些經驗，從 1.0 到 1.3。我們提供基於微服務版本的容器服務，從整個產品服務來看，改動是很大的。特別是對於 Kubernetes 原有的使用方式改造，產品使用形態是按照自己的產品設計去強行修改。

所以在面對差異版本時，包括技術架構、表結構、數據等，都很難做到兼容，由此造成的升級難度很大。從整體上來看，整體服務遷移主要涉及前端和 Web 服務，NCE 後端包括 Kubernetes 模塊、NLB 的負載模式均衡、日誌和性能數據等。

因為涉及的模塊非常多，所以整體集群非常大。在這種情況下，我們在自己的測試環境上，做了一些針對 Kubernetes 自身升級遇到的問題。

Kubernetes 主要包括程序和元數據兩個部分（基於 1.0 和 1.3）。首先來講一下程序的升級。程序涉及到 Master 和 Node。在進行程序升級時，通過替換二進位文件實現升級，還要注意對於進程服務替換後，對應的初始化腳本升級。

另外，涉及到元數據的遷移和改造。因為在 1.0 版本時，Kubernetes 還沒有像 Service 和 Ingress 的概念資源，所以一部分是對已有數據進行升級，包括 Namespace、Pod、Node、Deployment 等。

Kubernetes 存儲的元數據是通過 etcd 的 Key-Value 的存儲方式，而且 value 本身也支持表結構。所以它的升級，對於數據的處理是非常複雜的，而且要補齊包括 Service，Endpoint，Ingress 等資源的數據結構。在容器服務最早的 1.0 版本中，一個 Namespace 只對應一個用戶。基於 2.0 版本時，一個用戶可以有多個 Namespace。

對於這種模塊，我們需要去對 Namespace 的名字和存儲格式都進行修改。以上都是對於 Kubernetes 本身升級部分。對於除 Kubernetes 外的其他部分，最大的問題是在 Docker 升級及升級後 Docker 容器實例與 Kubernetes 兼容性。目前來看，整個社區都沒有解決方案去升級 Kubernetes+Docker。

故障修復

現在說一下，網易雲針對容器故障場景的應對措施。第一，容器級故障以及節點級故障。在容器級別故障下，我們會採取自動重啟容器實例。如果我們對容器探測出現異常，我們會去觸動自動修復。容器實例相對於虛擬機啟動，耗時更短，業務感知度會比雲主機低很多。

第二，節點級故障。比如伺服器宕機故障，我們應對措施是設置 Node 心跳定時探測。如果 Node 一旦有心跳告警信息，我們會觸發節點上的容器進行自動重建，主要是針對有狀態容器的自動遷移。

這是網易雲最開始的容器服務處理節點級故障。首先在 Node 節點上有配置機器的心跳檢測。一旦心跳持續丟失識別出節點故障，會上報給 Kubernetes，Neatease Controller 模塊會訂閱 Master。關於節點故障時間觸發基礎服務的網路模塊和存儲模塊會 detach 掉容器的網路配置和容器使用的系統盤和數據盤，同時會調度在新節點創建新的容器實例，將老的網路和存儲配置重新 attach 到新的容器實例中。

從這些可以看到，最早改造的有狀態容器實例遷移的方式與現在的原生 Kubernetes 使用的容器方式是有差異的。這就是在 Kubernetes 1.8 和1.9 時我們要去支持 Kubernetes 本身的一些配置理念原因。

我們不會讓容器的系統盤直接外掛，而是使用本地的容器系統盤，容器不再是遷移的概念，而是變成完全新建的概念。新建即可用，不變的是網路配置和數據盤保留。它會直接使用服務鏡像去創建一個新的容器節點，再重新掛載到老的容器實例數據盤中以此來實現回歸到原生的方式。

結語

網易雲在容器服務的管理結合微服務架構的探索涉及持續了很長時間，沉澱的經驗也都是非常寶貴的，在未來網易雲也將持續擁抱 Kubernetes，探索和完善更加豐富成熟的容器服務平台。

陳定斌 /網易雲資深雲計算解決方案架構師

從事網易雲基礎服務解決方案工作，主要面向基礎架構、虛擬化項目設計和部署。目前關注企業應用如何通過容器、Kubernetes、Cloud 等技術和解決方案解決實際問題，幫助企業從傳統 IT 架構向雲演進、並更好的利用雲帶來的益處來促進核心業務發展。

2018 中國雲原生用戶大會

2018 年 9 月 16 日，由才雲科技（ Caicloud ）、「K8sMeetup 中國社區」和「Kubeflow 社區」聯合主辦的聚焦中國行業應用與技術落地的盛會——2018 中國雲原生用戶大會（ 2018 CEUC ）即將盛大啟幕。

屆時 CNCF 執行董事 Dan Kohn，VMware 中國研發中心總經理任道遠、華為雲容器域產品總監方璞、網易雲基礎服務總經理陳諤、Caicloud CEO 張鑫博士、Caicloud CTO 鄧德源以及 Caicloud COO & CNCF 全球大使韓佳瑤博士等眾多雲原生領域行業大牛即將登台演講，與國內外雲原生技術專家及愛好者共同展望雲原生未來，並圍繞開源技術前沿話題，從市場、技術、產業及整個開源生態層面進行全方位探討。

售票通道現已開啟，可以掃描下圖二維碼直接購買。

END

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！