“中國-東盟資訊港”是按照國家“一帶一路”倡議總體佈局要求、建設更為緊密的中國—東盟命運共同體、21世紀海上絲綢之路的一個資訊平臺：http://www.caih.com。東信基於Rancher Kubernetes架構和建設了他們的容器雲PaaS平臺，在雲原生、容器化、微服務、CICD、DevOps等方面的都有了相關實踐和應用。
6月28日，負責中國東信容器雲PaaS 平臺的研發和建設、中國-東盟資訊港的研發總監王志雄出席了Rancher Labs舉辦的Container Day 2018容器技術大會，並做了題為《中國東信基於Kubernetes的容器雲PaaS平臺》的主題演講，本文根據演講內容整理而成。
各位來賓，各位朋友，大家上午好，我是來自中國-東盟資訊港的王志雄，在中國東信負責容器雲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、神秘的配置。之前有人提出一個比較好的方法是寫一個很好的檔案以供參考，但是檔案通常還是會遺漏，而且這還要依賴於我們人員寫檔案的能力，以及理解的能力。第二個，繁雜，現在不論是技術、工具還是語言都非常繁雜，例如語言有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，自然使用我們的容器雲三劍客，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。
Kubernetes應用實戰培訓將於2018年10月12日在深圳開課，3天時間帶你係統學習Kubernetes。本次培訓包括：容器基礎、Docker基礎、Docker進階、Kubernetes架構及部署、Kubernetes常用物件、Kubernetes網路、儲存、服務發現、Kubernetes的排程和服務質量保證、監控和日誌、Helm、專案實踐等，點選下方圖片檢視詳情。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
![]()
微信掃一掃
使用小程式
知識星球
