基于kubernetes自研容器管理平臺的技術實踐是怎樣的

小編今天帶大家了解基于kubernetes自研容器管理平臺的技術實踐是怎樣的，文中知識點介紹的非常詳細。覺得有幫助的朋友可以跟著小編一起瀏覽文章的內容，希望能夠幫助更多想解決這個問題的朋友找到問題的答案，下面跟著小編一起深入學習“基于kubernetes自研容器管理平臺的技術實踐是怎樣的”的知識吧。

一、容器云的背景

伴隨著微服務的架構的普及，結合開源的Dubbo和Spring Cloud等微服務框架，宜信內部很多業務線逐漸了從原來的單體架構逐漸轉移到微服務架構。應用從有狀態到無狀態，具體來說將業務狀態數據如：會話、用戶數據等存儲到中間件中服務中。

微服務的拆分雖然將每個服務的復雜度降低，但服務實例的數目卻呈現出爆炸式增長，這給運維增加難度，一方面是服務部署、升級，另一方面是服務的監控故障恢復等。

在2016年，容器技術尤其是Docker迅速流行起來，公司內部開始嘗試將容器放到容器內運行，雖然通過容器解決了服務發布問題，但很多容器的運維仍然讓運維捉襟見肘。宜信是一家金融科技公司，在引入開源組件的時候，穩定可靠是作為考量的最重要標準，在2017年初kubernetes慢慢成熟，成為容器的管理標準，并且被國內外很多公司采用，在這種背景下，宜信借鑒開源社區和商業PAAS平臺產品，基于kubernetes自研一套容器管理平臺。

二、整體架構

整個架構圍繞kubernetes構建，分為四個層級，最底層主要是基礎資源，包括網絡、計算、存儲，所有的容器都是部署在物理服務器上，容器掛載商業NAS存儲，網絡通過vxlan互連；中間層核心的是資源調度層，主要完成多集群的管理、發布部署、智能調度、自動伸縮等，這層主要是資源管理和服務編排；左側面是提供系統安全，主要是為了系統安全和容器鏡像安全，右側面是一套代碼自動編譯、自動構建、自動部署系統；中間件層主要提供常用的中間件服務，Nginx配置和監控告警等；最上層的是用戶接入層，主要提供用戶的操作入口。整體架構如下圖所示：

三、Nginx自助管理

公司大部分的服務都是通過Nginx反向代理對外提供服務，為了服務的隔離和負載均衡，總計十幾套的Nginx集群，這些nginx的版本、配置方式各有不同，導致單純靠人工去運維的成本非常高而且容易出錯，并且容器的IP地址不固定，無法直接配置到nginx后端。自研了一套nginx管理系統，主要是為了解決nginx的模板化配置，如下圖所示：

Nginx-mgr提供HTTP請求，負責接收nginx配置請求，并更新到etcd，每個nginx-agent通過watch Etcd批量刷新nginx的配置。在實際的生產環境里，部署的是阿里開源的Tengine而并非nginx，由于配置基本相同不做區分。每個服務都配置了健康檢查，這樣能夠保障在后端故障中自動切換。如果有虛擬機場景需要手動切換，下圖展示了手動切換nginx的頁面：

由于很多業務都是虛擬機和容器混跑的情況下，如果后端是容器，我們通過kubernetes的API獲取容器的IP地址動態刷新。

四、多集群管理

雖然kubernetes本身存在采用高可用的部署架構，避免單點故障，但這遠遠還不夠，一方面是因為單個kubernetes集群部署在一個機房，如果發生機房級別的故障，將會導致服務中斷，另一方面由于單個kubernetes集群本身故障，如集群的網絡配置錯誤導致整個網絡故障等，都將會影響業務的正常使用，在宜信將kubernetes部署在多個機房內，機房之間通過專線互連。那么多集群的管理將成為主要難點：第一是如何分配資源，當用戶選擇多集群部署后，系統根據每個集群的資源用量，決定每個集群分配的容器數量，并且保證每個集群至少有一個容器。集群自動伸縮時，也會按照此比例創建和回收容器。第二是故障遷移，如圖中的集群控制器主要為了解決多集群的自動伸縮和集群故障時的容器遷移，控制器定時檢測集群的多個節點，如果多次失敗后將觸發集群容器遷移的操作，保障服務可靠運行。

第三是網絡和存儲的互連，由于跨機房的網絡需要互連，我們采用vxlan的網絡方案實現，存儲也是通過專線互連。容器的鏡像倉庫采用Harbor，多集群之間設置同步策略，并且在每個集群都設置各自的域名解析，分別解析到不同的鏡像倉庫。

五、DNS解析

由于業務人員對容器技術還存在疑慮，所以大部分應用都是虛擬機和容器的混合部署，容器通過域名訪問虛擬機和虛擬機通過域名訪問容器都是普遍存在的，為了統一管理域名，我們沒有采用kubernetes自帶的kube-dns（coreDns）而采用bind提供域名解析。通過kubernetes支持的Default DNS策略將容器的域名指向公司的DNS服務器，并配置域名管理的API動態添加。

六、網絡方案

kubernetes的CNI的網絡方案有很多種，主要分為二層、三層和overlay方案。一方面機房并不允許跑BGP協議，并且需要跨機房的主機互連，所以我們采用了flannel的vxlan方案，為了實現跨機房的互通，兩個集群的flannel連接到同一個etcd集群，這樣保障網絡配置的一致性。老版本的Flannel存在很多問題，包括：路由條數過多，ARP表緩存失效等問題。建議修改成網段路由的形式，并且設置ARP規則永久有效，避免因為etcd等故障導致集群網絡癱瘓。

Flannel的使用還需要注意一些配置優化，默認情況下每天都會申請Etcd的租約，如果申請失敗會刪除etcd網段信息。為了避免網段變化，可以將etcd數據節點的ttl置為0（永不過期）；Docker默認是會masq所有離開主機的數據包，導致flannel中無法獲取源容器的IP地址，通過設置Ipmasq添加例外，排除目標地址為flannel網段數據包；由于flannel使用vxlan的方式，開啟網卡的vxlan offloading對性能提升很高。Flannel本身沒有網絡隔離，為了實現kubernetes的network policy我們采用canal，它是calico實現kubernetes的網絡策略的插件。

七、CICD

為了支持Devops流程，在最初的版本我們嘗試使用Jenkins的方式執行代碼編譯，但Jenkins對多租戶的支持比較差。在第二版通過kubernetes的Job機制，每個用戶的編譯都會啟動一個編譯的Job，首先會下載用戶代碼，并根據編譯語言選擇對應的編譯鏡像，編譯完成后生成執行程序，如果jar或者war文件。通過Dockerfile打成Docker鏡像并推送到鏡像倉庫，通過鏡像倉庫的webhook觸發滾動升級流程。

八、服務編排

系統設計了應用的邏輯概念，kubernetes雖然有服務的概念，但缺少服務的關聯關系，一個完整的應用通常包括前端、后端API、中間件等多個服務，這些服務存在相互調用和制約的關系，通過定義應用的概念，不僅可以做到服務啟動先后順序的控制，還可以統一規劃啟停一組服務。

九、日志

容器的日志歸集使用公司自研的watchdog日志系統，每臺宿主機上通過DaemonSet方式部署日志采集Agent，Agent通過Docker API獲取需要采集的容器和日志路徑，采集日志并發送到日志中心，日志中心基于elasticsearch開發，提供多維度日志檢索和導出。

十、監控

容器本身資源監控的性能監控通過Cadvisor + Prometheus的方式，容器內業務的監控集成開源的APM監控系統uav（https://github.com/uavorg/uavstack），完成應用的性能監控。uav的鏈路跟蹤基于JavaAgent技術，如果用戶部署應用勾選了使用uav監控，系統在構建鏡像時將uav的agent植入到鏡像內，并修改啟動參數。

除了上述幾個模塊外，系統還集Harbor完成容器鏡像的多租戶管理和鏡像掃描功能；日志審計是記錄用戶在管理界面的操作，webshell提供用戶的web控制臺接入，為了支持安全審計，后臺會截獲用戶所有在webshell的操作命令并記錄入庫；存儲管理主要是集成公司商業的NAS存儲，為容器直接提供數據共享和持久化；應用商店主要是通過kubernetes的operator提供開發和測試使用的場景中間件服務。

十一、落地實踐

11.1 docker不是虛擬機

在容器推廣的初期業務開發人員對容器還不是很熟悉，會下意識認為容器就是虛擬機，其實他們不僅是使用方式的區別，更是實現方式和原理的差異，虛擬機是通過模擬硬件指令虛擬出操作系統的硬件環境，而容器是在共享內核的前提下提供資源的隔離和限制。下圖展示了4.8內核中linux支持的7種namespace。

換句話說，其他的都沒有差異，譬如，時鐘，所有容器和操作系統都共享同一個時鐘，如果修改了操作系統的時間，所有容器都時間都會變化。除此之外，容器內proc文件系統也是沒有隔離，看到的都是宿主的信息，這給很多應用程序帶來困擾，JVM初始的堆大小為內存總量的1/4，如果容器被限制在2G的內存上限，而宿主機通常都是200+G內存，JVM很容易觸發OOM, 解決方案通常是啟動時根據內存和CPU的限制設置JVM，或者借助lxcfs等。

Cgroup的資源限制目前對網絡和磁盤IO的限制比較弱，v1的cgroup只支持direct IO的限制，但實際的生產環境都是些緩存的。目前我們也在測試cgroup v2關于IO的限制。當最新的CNI已經支持網絡限速，結合tc可以很好的達到這個效果。

11.2 Kubernetes優化

Kubernetes自帶了很多調度算法，在啟動容器之前會通過調度的算法，這些算法都是需要過濾所有的節點并打分排序，大大增加了容器的部署時間，通過刪除一些無用的調度算法，從而提高部署的速度。容器采用反親和的策略，降低物理機故障對服務造成的影響。

雖然kubernetes開啟了RBAC，但kubernetes token還是不建議掛載到業務容器內，通過關閉ServiceAccountToken提升系統的安全。

Docker鏡像存儲使用direct-lvm的方式，這樣性能更優，在部署的時候劃分單獨的vg，避免因為Docker問題影響操作系統。通過devicemapper存儲限制每個容器系統盤為10G，避免業務容器耗盡宿主機磁盤空間，容器運行時需要限制每個容器的最大進程數量，避免fork×××。

Etcd里面記錄了kubernetes核心數據，所以etcd個高可用和定時備份是必須的，在kubernetes集群超過一百個節點以后，查詢速度就會降低，通過SSD能夠有效提升速度。本系統在kubernetes之外通過數據庫保存服務和

關注證書的有效期，在部署kubernetes集群時候，很多都是自簽的證書，在不指定的情況下，openssl默認一年的有效期，更新證書需要非常謹慎，因為整個kubernetes的API都是基于證書構建的，所有關聯的服務都需要修改。

感謝大家的閱讀，以上就是“基于kubernetes自研容器管理平臺的技術實踐是怎樣的”的全部內容了，學會的朋友趕緊操作起來吧。相信億速云小編一定會給大家帶來更優質的文章。謝謝大家對億速云網站的支持！