中國東信基於Kubernetes的容器雲PaaS平臺

「中國-東盟信息港」是按照國家「一帶一路」倡議整體佈局要求、建設更爲緊密的中國—東盟命運共同體、21世紀海上絲綢之路的一個信息平臺：http://www.caih.com。東信基於Rancher Kubernetes架構和建設了他們的容器雲PaaS平臺，在雲原生、容器化、微服務、CICD、DevOps等方面的都有了相關實踐和應用。

6月28日，負責中國東信容器雲PaaS 平臺的研發和建設、中國-東盟信息港的研發總監王志雄出席了Rancher Labs舉辦的Container Day 2018容器技術大會，並作了題爲**《中國東信基於Kubernetes的容器雲PaaS平臺》**的主題演講，本文根據演講內容整理而成。

王志雄，中國-東盟信息港研發總監，負責中國東信公司容器雲的研發和管理工做。碩士，曾就任於IBM、華爲等公司，在IBM時任研發部門經理、技術專家。10年以上的雲計算IaaS、PaaS、容器雲、SDN/NFV、微服務、DevOps等研發經驗。

各位來賓，各位朋友，你們上午好，我是來自中國-東盟信息港的王志雄，在中國東信負責容器雲PaaS 平臺的研發和建設。今天我從技術角度、就以下四個方面，給你們分享中國東信基於Kubernetes建設容器雲PaaS平臺的經驗。

第一個是PaaS平臺，PaaS平臺在雲計算剛出現的時候就已經和IaaS、SaaS已經共存了，可是剛開始只是不溫不火，爲何到這幾年PaaS平臺才這麼火了呢？如何來建設一個PaaS臺？PaaS平臺須要哪些技術內容來承載？我會在這裏作一個分享。

第二個是微服務，微服務咱們說有兩條路線，第一條是SpringCloud，第二條是Kubernetes，咱們來看一看怎麼使用Kubernetes來構建一個微服務的平臺。

第三個是CICD ，第四個是DevOps。咱們會看到有些場合說的CICD，有的場合說的DevOps，這兩者有什麼關係，有什麼區別，如何來構建CICD 和DevOps，我會在這裏作一個揭曉。

Kubernetes與容器雲PaaS平臺

咱們首先來看一下Kubernetes與容器雲平臺。Kubernetes這個PaaS平臺要解決三個方面的IT架構方面的問題。第一，耦合，咱們作研發的知道，除了應用程序以外，無論Java，仍是Go，仍是Python，都須要大量的應用配置，這些配置和咱們的系統環境——Windows也好，Linux也好——都是耦合的，因此會常常出現咱們在交付產品的時候，明明在研發的環境可用的，到了測試不可用，到了最後的生產發佈也不可用，從而出現這樣的神祕的BUG、神祕的配置。以前有人提出一個比較好的方法是寫一個很好的文檔以供參考，可是文檔一般仍是會遺漏，並且這還要依賴於咱們人員寫文檔的能力，以及理解的能力。第二個，繁雜，如今不管是技術、工具仍是語言都很是繁雜，例如語言有java、有Go、有python、有php。第三個，不靈活，咱們如今互聯網時代是須要從按周發佈，提高爲按天發佈，甚至一天幾回、十幾回甚至上百次發佈，這在之前的物理機或者虛擬機時代是不可能的。

因此如何來解決這些問題？Cloud Native是這個答案。Cloud Native能作到什麼呢？第一是容器化，把應用以及它的配置打包，保證開發、測試和運維的環境一致，從而避免神祕的配置、神祕的錯誤、神祕的文檔、還有多是神祕的人。第二是面向微服務，把之前的一體的區域式服務給分解爲微服務，從而更靈活，並能夠獨立更新。第三方面是動態編排管理，若是容器不少，則須要大量的配置文件，須要部署不少容器則必然要用到編排管理，也就是咱們在此選擇的Kubernetes。

下圖是中國東信基於Kubernetes、Docker研發的四大場景。第一是企業應用平臺，企業應用平臺能夠將應用在平臺上作到一鍵部署，利用pod auto-scaling進行彈性自動伸縮，若是出現故障則能夠經過health check實現故障自愈，另外還有強大的灰度發佈功能。以前的互聯網公司可能須要一個很是大的團隊來作灰度發佈，現在使用Kubernetes，Kubernetes已經自帶灰度發佈功能了。第二個是咱們的微服務，用Kubernetes來構建咱們的微服務平臺，構建以後咱們就能夠組件化、鬆耦合、去中心，並且是靈活獨立的。第三個咱們作了這樣一套CICD的系統，CICD的系統從咱們的開發、從代碼提交、從編譯到構建到自動化測試、到容器化發佈。第四個是DevOps ，DevOps是能夠作到開發運維的協同。

這是咱們中國東信的PaaS 平臺，咱們從最底層看起，最底層是容器雲的Infra，咱們說Infra不是IaaS產品嗎？其實不論是IaaS仍是PaaS 都須要Infrastructure，固然它們是有區別的。咱們無論作Iass作PaaS ，其中的難點歸到最後其實都是存儲和網絡，我在後面會分享存儲網絡咱們是怎麼作的。再上來是容器資源管理，以及容器集羣編排與調度，須要把這個Pod調度到衆多集羣節點中的哪個？根據什麼策略來調度？根據CPU調度仍是根據內存調度？根據親和策略仍是反親和策略？再上來是咱們容器雲應用Service，咱們說PaaS 平臺是以應用爲中心，因此確定須要這樣一個強大的應用Service，PaaS平臺應用的Service有服務發現、配置中心、負載均衡、彈性伸縮、服務編排這樣一些強大的功能，那麼就用咱們的PaaS平臺，上面咱們會提供中間件、數據庫、負載均衡、文件存儲等等。若是須要哪個，好比須要一個MySQL ，把一個MySQL容器拿過去用就能夠了。再去用咱們的中間件，PaaS平臺上面就承載咱們龐大的、靈活的企業應用。

若是研發過Kubernetes應該對這個圖很熟悉，這是個典型的Kubernetes集羣，咱們分兩個層面來看。第一個層面一個是咱們本身內部的管理，部署Service，Service都是經過Master進行來管理，經過API Server來和各個組件進行交互，用Controller Mananger來控制咱們各個組件得到的調度，Scheduler是具體的應用策略，etcd 是一個數據庫。那麼會調度到咱們的Node上，Node上存在咱們的Pod ，一個Pod裏能夠有能夠有多個Container，這是咱們的內部的管理提供Service。第二個層面是咱們從外部的訪問，外部的訪問通常就是經過Internet通過防火牆來訪問咱們對外提供一個ingress ，ingress是Kubernetes提供的一個很是強大的功能，有了ingress 以後，咱們能夠對外提供一個統一的域名系統，外部只要訪問咱們的統一域名，就能夠訪問咱們內部的不一樣的應用，經過此域名就能夠進行智能的分發。

上面咱們說的叫物理架構，而下面我會講講邏輯架構，這兩個的關注面不同。邏輯架構從咱們研發內部看，最底層是容器基礎設施層，包括咱們的Runtime、Volume Plugin、Network Plugin；再上來是核心層，核心層對外提供API，對內提供Plugin環境；第三層是應用層，能夠進行部署，能夠進行ingress智能路由；再上來是管理層，能夠進行智能化以及Network policy；接口層是對外提供咱們的命令行管理工具；Ecosystem是咱們的生態。

剛纔說PaaS的基礎架構的終極難題是網絡和存儲。咱們先來看一下中國東信是怎麼解決網絡問題的。網絡的方案很是多，咱們看到有單組區域的，開始是單組區域有bridge、host、container、NAT，也有原生的iptables；再上來有主機集羣，有OVS，有IPSec；如今最主流的就是最上面一行，一個是Flannel，一個是calico，還有將這兩個折在一塊兒的Canal。這裏我能夠提一下咱們的SDN（軟件定義網絡）。SDN起源於Openflow，什麼是Openflow？Openflow是有強大的報文解析能力，能夠對報文進行任意的更改，這個強大的能力剛問世時取得了矚目的關注，而且在當年被評爲將來10大創新技術的排名第二位，第一位是雲計算，第二位是SDN。但最初Openflow在問世後的廣大的應用中碰到了一些問題，由於它和之前傳統的不兼容，因此實際上最後被應用最多的是VXLAN。VXLAN是一個overlay的技術。SDN在應用最多的是什麼？是VXLAN overlay。第三個是BGP，BGP在網絡中應該有二三十年的歷史，通過不斷地打磨、沉澱、優化，實際上BGP已經開始統一咱們的SDN領域了，如今BGP已經能夠取代咱們的軟件定義網絡，虛擬化的網絡。

SDN網絡通用的兩個方向，第一個是Flannel，Flannel其實本質上是一個Overlay的方案，因此在主機的容器內是自動分佈的IP，只是在主機以外，作了一個Overlay疊加的封裝，但這個Overlay和咱們傳統的IaaS的overlay相比實際上是不同的，傳統的IaaS的VXLAN除了Overlay的功能，還有多租戶的功能，可是這裏由於它只在出口作了個封裝，因此沒有多租戶的功能。因此Flannel有什麼缺點？它沒有安全隔離的功能。第二個它封包解包必然帶來開銷，因此這個是咱們要解決的問題。Flannel官方也表示若是用戶想對數據中心作更好的網絡安全隔離，推薦用Calico。

Calico的核心是基於BGP，若是是小網絡能夠用BGP的client進行IP路由的自動分發以及路由互聯。Calico的好處是什麼？簡單！如果使用Overlay網絡出現故障，用戶難以排查故障是來自overlay仍是underlay；但用BGP，用戶直接定位路由就行了。此外，Calico還帶了一個很好的特性就是和network policy結合在一塊兒，能夠提供網絡的微分段，若一個主機上有多個容器、有多個應用，能夠提供很好的安全隔離。Calico的不足是什麼？它須要取決於數據中心對於BGP的支持力度，可能如今還不是全部數據中心都是BGP。但我仍是推薦BGP的，從最初的的Facebook到如今國內的大公司，不少都已經開使用BGP來取代全部的內部的路由協議，包括二層協議。這是一個很好的方案，能夠簡化運維工做，數據中心只有一種路由協議多好。

談完網絡，另外一個難題就是存儲。Kubernetes和Docker相比除了普通的volume以外，還提供了persistent volume和storage class，經過PV和PVC來抽象存儲細節。這有什麼好處？能夠作到管理控制與轉化分離。管理員關注PV的存儲細節，用戶只要關注PVC使用存儲就行了。通用的存儲ceph、NFS、Gluster都沒問題。

容器雲微服務

下面咱們來看一下怎樣用Kubernetes來構建一個微服務。下圖是咱們很熟悉的微服務架構的特性，把一個單體的應用來分解拆分爲多個靈活的微服務。微服務的特性是服務的組件化。怎樣拆分一個微服務？不是按代碼的行數，不是按函數，而是按功能、按產品模式來拆分。有了微服務就能夠去中心化的管理。

構建微服務，必然要有以下這些功能：有這麼多的服務，怎樣發現這個服務？因此要服務發現。多個服務如何作到負載均衡？多個應用service怎麼樣進行智能的路由分發？怎樣管理成千上萬個服務的配置？怎樣彈性伸縮？怎樣容錯？怎樣自動升級？訪問控制怎麼作？

下圖就是咱們使用Kubernetes來構建的微服務。怎樣來構建？把上述問題的答案匯聚在一塊兒就是最終答案了。第一個服務發現，使用咱們的service，包括咱們Kubernetes內置的DNS就能夠來作這樣一個服務發現。第二個負載均衡，有node上的kube-proxy加上咱們的service分發是負載均衡。第三個智能路由，經過ingress能夠智能地將不一樣的應用經過統一的入口分發到後端的服務。配置中心經過咱們的Kubernetes的config-map，能夠在一個統一的服務器上進行遠端多個微服務的配置的統一管理、統一更新。明文用config-map，若是重要的機密的配置能夠secret。

再接下來是咱們的服務編排，deployment是實際使用過程當中用戶很是歡迎的一個特性。由於deployment把這個yaml文件寫好以後，你們去自動部署了，須要幾個副本，它會自動的去擴容以及縮容deployment。若是須要開發一個應用商店，能夠去helm開發。

再下來是咱們的彈性伸縮，經過RS寫好副本數，再經過auto-scaling指定須要自動伸縮的條件，好比說能夠基於CPU伸縮，能夠基於咱們的內存訪問伸縮。再下來是咱們的容錯，使用咱們的liveness來監控咱們的容器以及應用的健康情況，若是容器掛掉了，能夠把它重啓，若是這個節點掛掉了，那就把容器調度到另外一個節點。熔斷怎麼作？能夠用咱們的readiness，readiness不但能夠監控咱們的容器的存活，還能夠監控咱們的service是不是健康的。

限流，限流能夠經過咱們的quota限額，能夠經過咱們的namespace限額，也能夠對咱們的pod限額，也能夠對容器限額。

升級，rolling updates是自動升級，有問題能夠一鍵回滾。那RBAC是能夠提供基於角色的安全訪問。Network policy在BGP Calico基礎上提供微分段，能夠很好的安全隔離，包括日誌監控EFK和Prometheus。

容器雲CI/CD

如何來作容器雲的CI/CD，天然使用咱們的容器雲三劍客，Jenkins+Docker+Kubernetes。其實在容器雲出現以前，其實已經有CI/CD了，那時CI/CD用Jenkins作，Jenkins能夠提供編譯、構件、測試、任務調度的流水線；那Docker有什麼做用？可讓咱們的環境標準化，能夠隔離；Kubernetes能夠提供一個大的平臺，可讓資源共享、彈性伸縮。

CI/CD也就是須要把開發、測試流水線作一個自動化，從開發、編譯、構件、測試、打包到部署，因此在咱們的測試報告出來以後，若是是經過了就把鏡像上傳到鏡像倉庫，而後再發布到Kubernetes的發佈平臺。

DevOps

談完CI/CD咱們來看一下很火的DevOps。經過這張圖咱們其實就能夠看出CI/CD和DevOps有什麼區別，有什麼聯繫，什麼場合該用CI/CD，什麼場合該用DevOps。CI/CD在左邊，CI/CD最關注的是開發和測試，關注的具體的序數是什麼？是Jenkins來作個流水線，是Git來作一個源代碼的倉庫、源代碼的拉取，Maven來作構建，SonarQube來作靜態的代碼分析，Robotframework來作自動化的測試。SonarQube這樣一個代碼分析工具對咱們的編譯經過以外的一個保證把它良好的代碼是有很是好的好處。由於我記得仍是在十年前，當時在一個國內特大公司入職培訓的時候，通常的導師對每位員工都會培訓一個案例：代碼規範。好的代碼並非經過編譯就好了，並且須要好的編程規範，避免經過了編譯但卻其實會出現神祕的故障，並且很難定位。

看完CI/CD，咱們來看看DevOps關注什麼。DevOps的關注的是咱們發佈的環境要自動伸縮，要A/B Test，要灰度發佈，要自動的升級，或者要滾動升級，滾動升級就是指不是一次性升級完全部的pod，仍是能夠選擇性的升級一部分，好比升級20%，或者升級50%。有什麼好處？可使咱們的應用服務不中斷。它們二者的共同點，固然都須要基於Docker和Kubernetes來作這樣的一個容器化封裝和自動化。右邊的這個DevOps實際上是DevOps剛出現的時候，咱們叫標準的DevOps。它和CI/CD有區別，可是其實有很大的聯繫，CI/CD和這樣的標準DevOps組合起來就叫作咱們的大DevOps，因此這二者是能夠結合起來，CI/CD解決咱們開發、測試、自動化、標準化的問題，標準DevOps解決咱們的開發運維，主要是運維方面的問題，只有這二者結合起來就能夠一鍵式解決咱們的開發、測試、運維問題，而且能夠造成一個閉環。

下圖就是滾動升級這一功能，能夠經過逐個容器替代，升級其中的25%的容器，而後再確認一下，若是工做正常，咱們再能夠升級其中的下一批容器。

下面是灰度發佈。這在咱們突飛猛進的頻繁發佈的互聯網場景特別有用。由於咱們有大量的互聯網應用。因此有一個特別好的新功能，像看看它的這個功能，看看用戶的反饋，用戶的使用狀況怎麼樣，咱們的灰度發佈。用Kubernetes的pod很是方便。開始能夠給一個灰度版本1，內部用戶使用的沒問題，再給一個版本2，給咱們的用戶羣，用戶羣A，再逐漸的擴大到全部的用戶，這是互聯網很是好的應用。

總 結

這裏來回顧一下中國東信基於Kubernetes開發的這樣四大場景。第一個是PaaS企業應用平臺。第二個是Kubernetes的微服務，SpringCloud也是微服務，但SpringCloud微服務是主要關注在應用層面，並且它只是針對Java有效，對別的語言是沒有的。Kubernetes是語言無關的，並且是比SpringCloud使用面更廣的，但最佳的實踐是能夠把咱們的SpringCloud的每一個微服務經過容器化的方式進行封裝，再經過Kubernetes進行平臺的集羣資源調度和自動伸縮。第三個就是咱們CICD，第四個是咱們的DevOps。

後續將會爲你們帶來更多大會的演講實錄，請保持關注Rancher公衆號的最新推送~