Kubernetes容器雲平臺實踐

Kubernetes是Google開源的一個容器編排引擎，它支持自動化部署、大規模可伸縮、應用容器化管理。伴隨着雲原生技術的迅速崛起，現在Kubernetes 事實上已經成爲應用容器化平臺的標準，愈來愈受到企業的青睞，在生產中也應用的也愈來愈普遍。
咱們的容器平臺建設從2016年開始，大體經歷了探索預研、體系建設和平臺落地這樣三個階段。

下面就從Kubernetes的網絡、存儲、集羣管理和監控與運維幾個方面來分享下咱們容器雲平臺建設走過的歷程，但願給你們一些思考和啓發。
1、 kubernetes網絡
容器網絡發展到如今，已是雙雄會的格局。雙雄會其實指的就是Docker的CNM和Google、CoreOS、Kuberenetes主導的CNI。首先明確一點，CNM和CNI並非網絡實現，他們是網絡規範和網絡體系，從研發的角度他們就是一堆接口，你底層是用Flannel也好、用Calico也好，他們並不關心，CNM和CNI關心的是網絡管理的問題。
網絡需求調研發現，業務部門主要關注如下幾點：一、容器網絡與物理網絡打通二、速度越快越好三、改動越少越好四、儘量少的風險點。
容器的網絡方案大致可分爲協議棧層級、穿越形態、隔離方式這三種形式

協議棧層級：二層比較好理解，在之前傳統的機房或虛擬化場景中比較常見，就是基於橋接的 ARP+MAC 學習，它最大的缺陷是廣播。由於二層的廣播，會限制節點的量級；三層（純路由轉發），協議棧三層通常基於 BGP，自主學習整個機房的路由狀態。它最大的優勢是它的 IP 穿透性，也就是說只要是基於這個 IP 的網絡，那此網絡就能夠去穿越。顯而易見，它的規模是很是有優點，且具備良好的量級擴展性。但在實際部署過程當中，由於企業的網絡大多受控。好比，有的企業網絡的 BGP 是基於安全考慮不給開發者用或者說企業網絡自己不是 BGP，那這種狀況下你就受限了；協議棧二層加三層，它的優勢是可以解決純二層的規模性擴展問題，又能解決純三層的各類限制問題，特別是在雲化 VPC 場景下，能夠利用 VPC 的跨節點三層轉發能力。
穿越形態：
這個與實際部署環境十分相關。穿越形態分爲兩種：Underlay、Overlay。
Underlay：在一個較好的可控的網絡場景下，咱們通常利用 Underlay。能夠這樣通俗的理解，不管下面是裸機仍是虛擬機，只要整個網絡可控，容器的網絡即可直接穿過去 ，這就是 Underlay。
Overlay：Overlay 在雲化場景比較常見。Overlay 下面是受控的 VPC 網絡，當出現不屬於 VPC 管轄範圍中的 IP 或者 MAC，VPC 將不容許此 IP/MAC 穿越。出現這種狀況時，咱們可利用 Overlay 方式來作。
Overlay網絡使物理網絡虛擬化、資源池化，是實現雲網融合的關鍵。把Overlay網絡和SDN技術結合使用，把SDN控制器做爲Overlay網絡控制平面的控制器，這種方式更容易使網絡與計算組件整合，是網絡向雲平臺服務轉變的理想選擇。
隔離方式：
隔離方式一般分爲VLAN和VXLAN 兩種：
VLAN：VLAN 機房中使用偏多，但實際上存在一個問題。就是它總的租戶數量受限。衆所周知，VLAN 具備數量限制。
VXLAN：VXLAN 是現今較爲主流的一種隔離方式。由於它的規模性較好較大，且它基於 IP 穿越方式較好。
咱們從協議層級、穿越形態和隔離方式對kubernetes幾個常見的網絡組件（calico、contiv、flannel、Openshift SDN、自定義路由）在傳統機房網絡以及雲化VPC網絡應用場景下作一個分析，用連線圖來表述它們以前的關係。

首先不管是傳統機房網絡仍是雲化 VPC 網絡，咱們能夠看到 Overlay 方案是通用的，它在雲化場景裏可能用的更多一些，由於它有很好的穿越性。
在上圖中，紅線實線指向傳統機房網絡，這裏重點說明下。Underlay + 三層的方案，是傳統機房網絡很是流行的方案，同時它的性能很是可觀，場景應用比較偏多。
綠色虛線指向雲化VPC網絡， Underlay+三層網絡在雲化 VPC 場景下，也是能夠受限使用。受限使用顧名思義，可使用但不是每一個供應商都讓你用，由於每個雲廠商對他本身網絡保護的定義不同。好比像 Calico 方案，它的 BGP 在 AWS 中就容易作，但在 Azure 中就不容許，由於 Azure 的 VPC 自己是不容許不受它管控範圍的 IP 經過。
黃顏色的實線指向雲化VPC網絡，Overlay+二層或三層在雲化場景中比較常見。Overlay 下面是受控的 VPC 網絡，管控會比較方便。
固然雲化VPC場景下也存在一些問題，以下圖所示。

接下來講一下多租戶之間的網絡隔離問題

K8s從1.3版引入網絡策略機制，經過網絡策略可實現POD之間的入站和出站訪問策略。
網絡策略可應用於經過經常使用標籤標識的pod組，而後使用標籤來模擬傳統的分段網絡，能夠經過特定的「段」標籤來標識前端和後端pod。策略控制這些段之間的流量，甚至控制來自外部源的流量。但並不是全部的網絡後端都支持策略，好比 flannel。如今不少廠商在這方面增強了研究，也有不少新的解決方案，就不一一列舉了。
還有就是集羣邊界Ingress的管理

Ingress 是在kubernetes 1.2版本纔出現的，容器應用默認以Service的形式提供服務，但Service僅做用於集羣內部，經過Ingress將Service暴露出去才能爲集羣外的客戶端提供服務。
下面對常見的Ingress Controller作一個對比，見下表

咱們看到Nginx在性能和功能適用面上，還有社區活躍度上都較好，實用中也較多。
2、 kubernetes的存儲
k8s最初用於管理無狀態的服務，但隨着愈來愈多的應用遷移到k8s平臺，管理存儲資源成爲一個很是重要的功能。
Kubernetes中對於存儲的使用主要集中在如下幾個方面：
服務的基本配置文件讀取、密碼密鑰管理等；服務的存儲狀態、數據存取等；不一樣服務或應用程序間共享數據。大體有如下幾個場景，如圖：

Kubernete存儲在設計的時候遵循着Kubernetes的一向哲學，即聲明式（Declarative）架構。同時爲了儘量多地兼容各類存儲平臺，Kubernetes以in-tree plugin的形式來對接不一樣的存儲系統，知足用戶能夠根據本身業務的須要使用這些插件給容器提供存儲服務。同時兼容用戶使用FlexVolume和CSI定製化插件。相比較於Docker Volume，支持的存儲功能更加豐富和多樣。
Kubernete存儲插件解析：
一、in-tree plugin：存儲代碼與K8S緊密集成，耦合性太強
二、FlexVolume：存儲插件安裝在宿主機上，須要宿主機的root權限
三、CSI規範：將存儲代碼與K8S徹底解耦（1.10版本及以上，使用CSI attacher使用0.2.0版本）

csi規範極大地方便了插件的開發、維護和集成，具備很好的發展前景。
Kubernetes使用兩種資源管理存儲：
PersistentVolume（簡稱PV）：由管理員添加的的一個存儲的描述，是一個全局資源，包含存儲的類型，存儲的大小和訪問模式等。它的生命週期獨立於Pod，例如當使用它的Pod銷燬時對PV沒有影響。
PersistentVolumeClaim（簡稱PVC）：是Namespace裏的資源，描述對PV的一個請求。請求信息包含存儲大小，訪問模式等。
PV能夠看做可用的存儲資源，PVC則是對存儲資源的需求，PVC會根據Pod的要求去自動綁定合適的PV給Pod使用。PV和PVC的相互關係遵循下圖所示的生命週期。

PV模式有靜態和動態，靜態PV模式管理NFS、FC、ISCSI，動態PV模式管理glusterfs、Cinder、Ceph RBD、Vsphere、ScaleIO、AWS、Azure等。靜態的須要管理員建立和管理PV，而動態的則由系統自動生成PV並綁定PVC.
下面再簡單補充下kubernetes中的鏡像管理，生產中都會有不少不一樣版本不一樣應用的鏡像，對鏡像的管理也是比較重要的環節。

鏡像的多租戶權限管理：
一、不一樣租戶的鏡像應相互隔離
二、不一樣的租戶對鏡像擁有不一樣的權限，例如讀寫、只讀、上傳、下載權限
三、鏡像庫提供鏡像的查詢、更新和刪除等功能

對於跨地域多數據中心的鏡像管理，鏡像庫的遠程複製管理須要注意：
一、在多數據中心或跨地域多站點的環境下，爲了提升多地區鏡像的下載效率，至少須要兩級鏡像庫的設置：總鏡像庫和子鏡像庫
二、鏡像庫之間的準實時增量同步

3、 Kubernetes集羣管理
在生產系統中，kubernetes多集羣的管理主要涉及：
一、服務運維
二、集中配置
三、擴容升級
四、資源配額
首先說說多集羣的調度管理
一、Kubernetes中的調度策略能夠大體分爲兩種，一種是全局的調度策略，另外一種是運行時調度策略
二、NODE的隔離與恢復；NODE的擴容；Pod動態擴容和縮放
三、親和性能夠實現就近部署，加強網絡能力實現通訊上的就近路由，減小網絡的損耗。反親和性主要是出於高可靠性考慮，儘可能分散實例。
四、 微服務依賴，定義啓動順序
五、跨部門應用不混部
六、api網關以及GPU節點應用獨佔

多集羣管理中的應用彈性伸縮管理：
一、手工擴縮容：預先知道業務量的變化狀況
二、基於CPU使用率的自動擴縮容：v1.1版引入控制器HPA，POD必須設置CPU資源使用率請求
三、基於自定義業務指標的自動擴縮容：v1.7版對HPA從新設計，增長了組件，被稱爲HPA v2
在實際應用中，HPA還有不少不完善的地方，不少廠商都用本身的監控體系來實現對業務指標的監控並實現自動擴容
Kubernetes多集羣的調優：
主要有三個難點：
第一是如何分配資源，當用戶選擇多集羣部署後，系統根據每一個集羣的資源用量，決定每一個集羣分配的容器數量，而且保證每一個集羣至少有一個容器。集羣自動伸縮時，也會按照此比例建立和回收容器。
第二是故障遷移，集羣控制器主要是爲了解決多集羣的自動伸縮和集羣故障時的容器遷移，控制器定時檢測集羣的多個節點，若是屢次失敗後將觸發集羣容器遷移的操做，保障服務可靠運行。
第三是網絡和存儲的互連，因爲跨機房的網絡須要互連，咱們採用vxlan的網絡方案實現，存儲也是經過專線互連。容器的鏡像倉庫採用Harbor，多集羣之間設置同步策略，而且在每一個集羣都設置各自的域名解析，分別解析到不一樣的鏡像倉庫。

接下來講說K8S集羣的Master節點高可用實現，咱們知道Kubernetes集羣的核心是其master node，但目前默認狀況下master node只有一個，一旦master node出現問題，Kubernetes集羣將陷入「癱瘓」，對集羣的管理、Pod的調度等均將沒法實施。因此後面出現了一主多從的架構，包括master node、etcd等均可設計高可用的架構。

還有了解下Federation 集羣聯邦架構
在雲計算環境中，服務的做用距離範圍從近到遠通常能夠有：同主機（Host，Node）、跨主機同可用區（Available Zone）、跨可用區同地區（Region）、跨地區同服務商（Cloud Service Provider）、跨雲平臺。K8s的設計定位是單一集羣在同一個地域內，由於同一個地區的網絡性能才能知足K8s的調度和計算存儲鏈接要求。而集羣聯邦（Federation）就是爲提供跨Region跨服務商K8s集羣服務而設計的，實現業務高可用。
Federation 在1.3版引入，集羣聯邦federation/v1beta1 API擴展基於DNS服務發現的功能。利用DNS，讓POD能夠跨集羣、透明的解析服務。
1.6版支持級聯刪除聯邦資源,1.8版宣稱支持5000節點集羣，集羣聯邦V2

目前存在的問題：
一、網絡帶寬和成本的增長
二、削弱了多集羣之間的隔離性
三、成熟度不足，在生產中尚未正式的應用
4、kubernetes的監控與運維
對於一個監控系統而言，常見的監控維度包括：資源監控和應用監控。資源監控是指節點、應用的資源使用狀況，在容器場景中就延伸爲節點的資源利用率、集羣的資源利用率、Pod的資源利用率等。應用監控指的是應用內部指標的監控，例如咱們會將應用在線人數進行實時統計，並經過端口進行暴露來實現應用業務級別的監控與告警。那麼在Kubernetes中，監控對象會細化爲哪些實體呢？
系統組件
kubernetes集羣中內置的組件，包括apiserver、controller-manager、etcd等等。
靜態資源實體
主要指節點的資源狀態、內核事件等等
動態資源實體
主要指Kubernetes中抽象工做負載的實體，例如Deployment、DaemonSet、Pod等等。
自定義應用
主要指須要應用內部須要定製化的監控數據以及監控指標。
不一樣容器雲監控方案的對比：

關於Prometheus監控：
主要注意兩點：
 查詢api的封裝
 配置文件的下發
有了prometheus這個強大的監控開源系統以後，咱們所須要投入的工做就是查詢api的封裝和配置文件的下發。查詢api的封裝沒什麼好說的，無非就是前端調用咱們本身的server，咱們的server呢經過http協議去調用prometheus的api接口查詢到原始數據，而後進行組裝，最後返回給前端。 配置文件的話包含三部分吧，警報的定義，alertmanager的配置，以及prometheus的配置，這裏也很差展開講，有興趣的能夠去官網看看。固然也可使用Prometheus+Grafana來搭建監控系統，這樣可視化會更豐富些，展示也比較快。
運維的思考---開發與運維的一體化

運維的思考---高可用問題
• Ocp平臺:
一、負載均衡Router高可用集羣: 2個節點
二、EFK高可用集羣: 3個ES節點+n個F節點
三、鏡像倉庫高可用集羣: 2個鏡像倉庫
• 微服務架構:
一、註冊中心高可用集羣(Eureka): 3個
二、配置中心高可用集羣: 3個
三、網關高可用集羣: 2個
四、關鍵微服務均是高可用集羣
運維的思考---高併發問題
• Ocp平臺:
一、對後端微服務(Pod)配置彈性擴容, K8的彈性伸縮擴容以及Docker容器的秒級啓動能夠支撐用戶量的持續增加;
二、提早預留20%的資源, 當高併發狀況發生時, 能夠緊急擴充資源。
• 微服務架構:

1. 調大關鍵鏈路微服務的熔斷線程數: 提高主要業務的併發響應能力。
2. 對非關鍵鏈路微服務經過熔斷限流進行降級處理甚相當閉非關鍵鏈路的微服務。
3. 熔斷機制：提高容器雲高併發場景下的容錯能力，防止故障級聯以及微服務的雪崩效應，提高系統的可用性。• 中間件:一、除了正在使用的集羣外, 提早增長冷備的集羣。二、當高併發場景即將發生時, 能夠緊急水平擴展。還有就是性能壓測與優化問題，限於時間關係，這裏就不展開講了。最後，容器雲之路總結1.業務層面：因大型企業對業務的穩定性和連續性有比較高的要求，故容器化的演進路徑必然是從邊緣業務到核心業務，從簡單應用到複雜應用，具體到業務，首先能夠考慮在Web前端進行容器化遷移，最後動後端業務。 2.技術層面：目前原生Docker在服務發現、負載均衡、容器生命週期管理、容器間網絡、存儲等方面還存在諸多的不足，許多第三方廠家提供的開源解決方案和商業化版本，各具特點，難分高下。用戶不管選擇何種產品，可靠性、靈活性是須要慎重考慮的2個重要因素。 3.兼顧成本效益：綜合考慮容器化付出的成本代價與將來收益之間的平衡。4.考慮現有硬件的負載能力，容器化並不是包治百病的良藥，某些對併發吞吐量要求更高的業務，直接運行在裸機上，經過系統調優提升性能，容器化未必是最好的選擇。五、持續更新，時刻提醒本身持續學習，擁抱變化，這樣才能看到平臺的不足，不斷迭代出更好的產品。在生產實踐中，只有夯實基礎不斷去完善基於容器雲平臺的產品和建設生態體系，才能掌控將來決勝千里！