杭州是一座極有包容性的城市，古韻清雅的街道景點隨處可見，現代建筑群設計感十足，傳統底蘊與現代科技被這座古城兼容并蓄，***融合。HDG華為開發者匯，就將杭州作為第四站，5位講師***揭秘華為的CloudOpera、PaaS、融合視頻3個生態圈，技術干貨無私分享，聽眾疑問現場解答，思想的小火花一直在碰撞，參會的開發者大呼過癮。

華為PaaS開發部高級工程師鐘成對黃玉奇的發言也做了補充。他表示，華為***次嘗試去構筑PaaS生態圈，希望能有更多的開發者關注這個平臺。在鐘成的演講中，他主要與眾開發者探討了圍繞Kubernetes的核心設計實現的多個技術細節，如怎么落地、在網絡和存儲環節如何操作、華為針對做哪些內容做了改動。社區應用的親和性和反親和性這些內容都是***對外披露。

[[169857]]

現場實錄如下：

我廢話也不多說，直接開始講了，我也沒有什么特別可介紹的，我叫鐘成，也是華為的，2012實驗室的。

剛才黃玉奇已經把Kubernetes主要的背景都介紹了，它有什么夠能或者怎么做，我這里稍微再展開一些，講一些關于它底層設計的事。從大的方向來講，k8s這個東西是應運而生的，它出現在現在這個時代是因為很多很多企業發現自己有很多計算機，有很多集群在機房里面，但是并沒有非常好的手段管理它。傳統的軟件開發是一種單體式的開發，這些軟件力度非常粗，比較大，而且要的東西比較長。換成現在這個時代會變成一種互聯網式的開發，就是我會把我的過多軟件都微服務化，把這個邏輯打的比較碎，打的比較散，發布的周期可以變短。以前可能是做一個軟件，做一個系統，你要做一兩年。現在一個功能可能一天或者一周就會生成一次，這方面就會有一些優點和缺點，這里都會講，就不詳細說了。

這個是國外的一個組織對PaaS的定義，主要是完成這么幾個功能，一個是資源獲取自動化，語言跟框架的自動化，以及運維管理的自動化。從解決集群管理這個角度來說，業界是有好幾個方案，對于集群管理來說主要就是調度器的設計，當你把這個下完之后，你怎么決定這個應用到底跑在這個集群的什么地方。這里面列了有五種比較典型的方案，***種方案就是所謂的單體調度器的方案，就是我在這個系統中有一個調度器，由它來決定我這個應用部署到什么地方。這種方案像目前為止Kubernetes就在采用這種方案。

第二種方案是我去采用兩層式的調度框架，下面這一層我只管資源，管到資源之后往上去報。比如說當上面請求資源的時候，我會給它挑出來往上報，上面的幾個東西去挑，上面的幾個調度器去選。如果上面的調度器覺得這臺機器合適，那就拿去用。這就是myDOS的一個思路，myDOS就是Kubernetes。

第三個則是一個共享狀態的調度方案，這個方案是我把所有集群的狀態全部都同步到各個調度器里面去，由各個調度器進行決策，決策完了之后我往下試圖進行部署。由于上面我看到的這些東西都是一樣的，你***合下來的就需要有一個沖突解決，避免多個角度器之間互相打架，這也是一種方案。

還有一種方案是所謂的分布式調度，這種分布式調度我沒有一個中央的調度器，只是我在中間任何一點都可以調度一些東西，我任何一臺機器上都可以決定我是不是要接受這個應用，是不是要跑這個服務。這個調度其看起來可能比較散，是它其實是很有用的。現在在亞馬遜的(03：57)里面就采用這種調度方案，對于非常短的一個任務，它的本身生命周期只有三四秒，如果你再通過一個比較復雜的調度器，花個十秒鐘去調度的話，就比較得不償失了。

第五種是一種混合式的方案，我把***種跟第四種混合在一起。

這個是我后面列的表，各個系統調度方案的對應表。包括它的一些調度的力度，多調度器，以及重調度的機器。

這個是k8s的一些優勢，已經講過。然后講一下k8s的一些設計理念，它是一個全功能的，該了網絡、服務發現、負載均衡和資源管理這些東西。你可以認為它是一個集成商的操作系統，有了這個操作系統以后，用心就不用操心這些底層的應用到底怎么被調度，怎么被運行，你只要向它提交任務就可以了。這個我覺得是k8s比較大的思路，包括網絡，包括下面的這些資源調度，全部都是它進行管理的。而且它沒有任何綁定，可以支持多種IaaS提供商。

這個我也不怎么講了，這里有一個簡單的動畫，當你創建一個IS的時候會選擇一個節點，然后把它布起來。如果這個節點上的容器或者(06：21)死掉的話，會它進行遷移，遷移到另外一臺機器上面去。

這個是k8s的網絡模型，這里稍微復雜一點，但是也是可以看得出來。當我在Pods部署了一組應用之后，我怎么從外部去訪問它。我會定義一個Frontend Service這么一個東西，這個Service會對應下面的這些容器。這里有三個容器，這三個容器可以進行訪問。第二個Service則是一個Redis Service，這個Service是給內部使用的，不是對外使用的。內部可能又有三個容器Pods的實例進行互相之間的訪問。

目前k8s的網絡訪問方式有四種，一個是ClusterIP，就是我在集群內部定義一個跟我現在網站完全不一樣的IP，這個IP只有在內部可以訪問，它是通過IP(07：31)，你可以認為它造出一個IP，這個IP內部會進行合適的路由。第二個是Nodport，就是說我在集群的每個物理機上，每個部署的節點上面我去開一個端口，這個端口是由我的k8s的(07：44)進行管理，當你外部有流量訪問這個節點上的端口的時候，會把這個節點上的流量進行轉發，轉發到運營的Pods上面去，這是第二種網絡方式。第三種是我結合Dodeport的這種功能，我在上面再放一層loadBalancer，類似于像ELB，我通過這個ELB訪問所有節點上的某個具體的端口，再去訪問具體的Service。

接下來我會談一下k8s的一些核心機制，這個會稍微偏向于代碼一些。這張大家在上面也看到過，就是list-watch目的。前面大黃那邊有一張圖，就是k8s是一個典型的中心式的架構，所有的數據都是存在中心的API Service上面，API Service后面存了ETCD。這個架構在分布式集群里面是比較少見的，一般的分布式集群的做法是什么呢，我會寫很多個進程在很多機器上面，我這些進程之間互相通過消息隊列。連接完了之后，A進程做一件事情，做完之后把這個結果扔到隊列里面去，然后用B進程進行這個操作，***再到C進程。你可以認為是一環扣一環，是消息隊列的模式。但是Kubernetes的做法有點不一樣，它的核心思想是我把所有的數據都放到ETCD里面去，由一個強的分布式數據庫來進行存儲，保證這個數據的強一致性，這是***個。

第二個我這些組建之間互相怎么通信呢?我通過中心的API Service進行通信。這個通信方式和一般的生產者、消費者也不大一樣，前面我講的是生產者、消費者模型，就是A生產，B消費。A處理了這個消息之后，我把它存到數據庫里面去，就是下面的ETCD，ETCD會通知所有關注這個消息的人，把這個消息發給他，讓這些人去處理。我們可以從這里面看到，當我從U客戶端創建一個pods之后，可能是創建一個Replicaset之后，它就會收到Replicaset創建的消息，然后它就會再去創建一個pods，你創建這個pods之后，這些pod其實是沒有被調度的。這時候由于一些變化，就會知道這些pods沒有調度，對它進行處理，處理完之后去改變pod的狀態，后面再這樣分拉下去。這種方式list-watch跟那個不是很一樣，理論上這個數據面比較廣，如果是消息隊列的話，A生產什么B就必須得消費什么。但是list-watch的方式是，我所有的客戶端都可以關心自己想關心的東西，我可以通過watch這種方式去找到自己關心的那一部分，我可以關心node或者關心pods，我有選擇權，所有的客戶端都有選擇權。

這里會稍微涉及到一些代碼，大家看代碼有問題嗎，簡單講一點。這個代碼也很簡單，我在客戶端就是起了一個函數，這個函數就是給它提供一組，你可以認為這就是一個http發起請求的一個函數。當你收到這個apiService這邊發生變化的事件之后，就會調度你這里的三個函數，就是我發生這個事件是增加事件，還是更新事件，還是刪除事件。也就是說當我發起list-watch之后，apiService會不停的把事件發過來，這是在同一條http連接上面，它會不停的把事件發過來。發過來之后，我Client不需要捕捉每一條事件，我只要把我的處理函數掛在這個鉤子上面，這個就是它的一個框架，掛在這個鉤子上面，當有新的事件過來之后，我這里會做相應的處理。同時我會在底層保存一份數據的全樣數據的副本。這個是客戶端的代碼。

服務端的機制也是比較類似，我會在底層也存儲一個store，當有http數據過來的時候，它會在本地保存一個滑動窗口，類似于CCD那個滑動窗口，每次事件發生了，就會給每個Client做一個相應通知。

前面一個過程就是整個k8s list-watch的一個機制，這個我認為是它跟傳統分布式集群軟件***的區別，就是它底層的通信機制不一樣。后面則是一些具體調度器的機制，k8s的調度器我這里大致的講了一下當你有一個pods要被調度的時候它會怎么做。它***步就會辨認這個集群中所有的節點，先去找哪些節點是不是合適。合適的意思就是說它的資源足不足夠，能不能夠有足夠的網絡，足夠的帶寬，先把我實在沒有辦法布的機器都過濾掉。第二步則是進行打分，如果我有一千臺機器，里面有一百臺我這個應用都可以布，我***給這一百個中間選一個。我怎么選呢?就是我給這一百個節點進行打分。打分的依據包括了一些親和性或者反親和性的算法，也包括一些資源算法。也就是說k8s現在調度器的機制是先進行過濾，然后進行排序打分的模式。

這個就是過濾跟排序的一些算法，這些算法其實都是千差變化的，就是說你要想做的話，也可以實現一個k8s的調度器。就是你可以自己中間插入一些函數，我想檢查哪些端口，或者有些什么條件之類的。其實很多業務邏輯都是寫在這個地方的，就是你可以自己去選擇這個集群怎么進行部署。

這個就是講高可靠，這個就是那個社區的方案，接上面的那個問題，就是k8s怎么實現自己的高可靠。它的想法比較簡單，就是我把apiService分成多份，每一份都可以進行獨立的訪問。前面會掛一個為load balancer，就是我所有的工作節點都經過這個load balancer來訪問apiService。底層的ETCD，自身采用(14：56)的協議進行數據同步。就是你的APIService從本質上來說是無狀態的，而調度器和控制器目前還沒有辦法做到真正的多調度，或者是多控制。這個也是受制于前面的list-watch的機制，因為它本質上是所有的調度器或者是資源管理器得到的這個消費者數據是一樣的，所以目前來說暫時還沒有能夠進行拆分。最近我在社區里面跟ETCD的開發者進行討論，我們能不能改善這個機制，讓我們這個集群把所有真正的調度和控制全部可以多副本。現在只能通過分布式鎖，我是有單調度器和單控制器，就是每種類型的控制器只能有一個。

后面過一下社區的方向，這方面聯邦我就不講了，前面大黃講過了，這是聯邦的一個創建過程，這個也不講了。應用親和和反親和，大家知道這個意思就可以了，這是一個需求，這個有好幾個層級。包括是集群聯邦層級，包括集群內部的層級，其實都會有。

這里講了一個我對不同pods進行親和和反親和，這里是一些具體的案例，這個也不展開了，回頭可以具體去看。

這個是我們后面會投入的一些東西，華為這邊會做，也是我們在社區里面會做的，主要是集群的規模和性能，還有調度和重調度，以及集群聯邦，主要是三大塊。

后面我也做一個小小的廣告，左邊的是我們的微信號，后面是一個微信群，華為的微信群，大家可以在里面聊聊天，這個群是長期開設的。