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與容器雲平臺。Kubernetes這個PaaS平臺要解決三個方面的IT架構方面的問題。第一，耦合，我們做研發的知道，除了應用程序之外，不管Java，還是Go，還是Python，都需要大量的應用配置，這些配置和我們的系統環境——Windows也好，Linux也好——都是耦合的，所以會經常出現我們在交付產品的時候，明明在研發的環境可用的，到了測試不可用，到了最後的生產發布也不可用，從而出現這樣的神秘的BUG、神秘的配置。之前有人提出一個比較好的方法是寫一個很好的文檔以供參考，但是文檔通常還是會遺漏，而且這還要依賴於我們人員寫文檔的能力，以及理解的能力。第二個，繁雜

所以如何來解決這些問題？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，自然使用我們的容器雲三劍客，Jenkins+Docker+Kubernetes。其實在容器雲出現之前，其實已經有CI/CD了，那時CI/CD用Jenkins做，Jenkins可以提供編譯、構件、測試、任務調度的流水線；那Docker有什麽作用？可以讓我們的環境標準化，可以隔離；Kubernetes可以提供一個大的平臺，可以讓資源共享、彈性伸縮。

CI/CD也就是需要把開發、測試流水線做一個自動化，從開發、編譯、構件、測試、打包到部署，所以在我們的測試報告出來之後，如果是通過了就把鏡像上傳到鏡像倉庫，然後再發布到Kubernetes的發布平臺。

談完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 公眾號的最新推送~