基於kubernetes託管虛機有一些現成的方案，不過今天筆者要聊的是在虛機交付後，該如何實現後續的管理，包括如何實現環境和代碼的部署與更新，感興趣的能夠一塊兒看看，本篇是設計篇web
1. 虛機應用的託管
因爲虛機應用交付流程鏈路的複雜性，咱們沒法設計一套機制，能cover住100%的異常場景，因此咱們專一正常流的交付，後期能夠針對異常的案例來進行復盤，不斷提升交付成功率，本節主要介紹咱們設計的自動化交付流程、以及用到的k8s相關的機制安全
1.1 面向終態的交付
虛機應用典型的交付流程大概是這樣的：申請機器->部署環境->部署代碼->綁定監控->健康檢查->灰度上線，若是要對標容器則建立機器、部署環境、部署代碼至關於完成了一個"虛機鏡像"的交付，也是咱們主要要自動化的流程微信
1.1.1 核心狀態機
在雲原生中一般都是基於面向終態的交付方式， 基於目標狀態和當前狀態由系統自動進行決策，咱們根據現狀定義了以下的狀態機：
這裏重點說下就緒狀態，就緒狀態表示應用的當前的部署環境、代碼完成，而且健康檢查都經過了即一個節點能夠進行灰度引流了網絡
同時若是一個應用的環境變動則會按照對應的安全頻率來進行節點環境的變動，只須要變動節點的環境列表，系統會自動發現當前節點須要進行更新，進行狀態機的轉換；而後自動化系統會發現這個變動則就會進行檢查而且自動化的進行環境的安裝運維
1.1.2 故障轉移
若是發現某個節點宕機後，則會由系統首先將系統設置爲下線狀態(IAAS平臺還不支持這個事情)， 而後會根據策略來進行決策是否自動進行修復，若是須要修復則系統會新建立一個節點而後執行上述流程，不然則會修改對應的副本數量異步
1.1.3 准入機制
爲了保障穩定性咱們在自動化的流程中加入准入機制，即在對應的階段容許引入人工節點來進行決策，將控制權交給應用運維，而且提供相關的數據和策略輔助提升運維決策效率ide
1.1.4 任務列表
那若是如何肯定一個節點處於某個狀態下該作哪些任務呢？這裏其實取決於兩部分當前狀態和目標狀態，首先咱們這裏經過系統內部(k8s)裏面當前的狀態來進行計算以肯定節點當前該處於哪一個狀態，每當進入到一個狀態就會同時追加一個任務列表，controller則根據外部狀態和任務列表進行自動化操做，並更新內部狀態，從而不斷的完成不一樣狀態的切換，最終達到目標狀態學習
1.1.5 異常流程
異常流程的處理多是全部自動化系統裏面最頭痛的了，在咱們的系統裏面主要經過兩種方式來解決：人工和自動化(好像特麼的是廢話)，首先來講自動化，當節點某些自動化任務沒法進行時系統會通知運維，當前系統遇到沒法處理的異常了，這時候運維會根據當前問題來修復某些不知足的條件，好比開通網絡策略、部署Agent等等，當完成後只須要變動節點狀態，後續就會自動化修復ui
當遇到沒法經過上述自動化短期來解決的時候，運行運維進行手工修復，並強制更新對應的狀態，則系統會根據當前的狀態進行後續的操做，好比檢測到就緒以後就進行負載掛載等spa
1.2 kubernetes相關機制
那如何利用k8s的相關機制來實現上述交付流程呢，這裏主要通道了webhook、finalizer、annotations幾個機制
1.2.1 webhook
首先咱們經過webhook再server更新的時候經過admission.Mutation機制來根據當前內部狀態進行狀態的決策，以肯定接下來的自動化任務，在這環節咱們實現了從部署環境->部署代碼->就緒狀態的轉換
1.2.2 finalizer
在主機進行刪除的時候，須要等待負載刪除、暫停監控、刪除虛機等流程所有結束後才能進行節點對象的刪除，從而實現了節點信息的異步清理機制
2. 核心設計
2.1 核心對象設計
考慮到應用的環境操做和部署操做兩個操做頻率的差別性，咱們這裏參考k8s聲明瞭兩個上層控制器，即經過VMReplicaSet來實現程序運行環境的交付，而將部署操做交由VMDeployment來控制，同時兩個控制在操做某個實例的時候都會先進行狀態檢測，而後在進行資源的鎖定才能進行相關的操做，從而保障執行流程的穩定性
2.2 狀態轉換機制
下面咱們會按照幾個不一樣的場景來分別介紹下虛機狀態的轉換以及對應控制器的控制，咱們有兩個核心的設計理念：1.人只負責環境配置的描述，由系統完成相關狀態和自動化操做2.狀態的肯定依賴於當前現狀，同時人的決策高於一切
2.2.1 初始化
當檢測副本數量發生變化VMReplicaSet首先會發送申請，確認當前是否要進行機器的建立，同時會建立對應的Server的Package配置，經過計算Package狀態設置當前狀態爲Initializing，並同時建立部署環境的任務，而後等待環境部署的結果，同時會掛載Server的負載信息
等待環境部署完成後，控制器會自動檢測狀態並設置爲Deploying，同時經過部署系統進行代碼的部署，並將對象從新入隊，直到狀態部署完成
代碼部署完成後，會進行狀態檢測，若是系統節點健康檢查經過而且監控狀態未發現異常，則會將節點設置爲Ready狀態，同時負載控制器和監控控制器都會對應的配置，至此完成虛機的初始化完成，後續若是環境不變，則代碼部署只須要重複當前操做
2.2.2 有狀態的下線
虛機一般是有狀態的應用，若是要下線一般都是選擇指定的節點，並標記爲下線狀態，同時結合finalizer和控制器完成對應負載和監控的同步操做，當全部的finalizer都釋放後，最後進行對應節點的刪除
2.2.3 故障轉移機制
若是對應的節點宕機，則只須要加一個處理轉換邏輯便可，若是是短期能夠恢復就只須要將對應的節點標記爲UnKnown，同時監控和負載控制器進行對應的操做，而後等待重啓後接收到對應的事件後將節點設置爲Initializing, 而後系統會自動進行對應的檢測邏輯，自動轉換爲Ready，監控和負載控制器監控自動執行相關邏輯，便可完成上線
若是節點不可修復只須要將狀態設置爲下線狀態，而後對應的副本控制器檢測到節點不足，就會自動調用IAAS系統進行自動建立，而後執行初始化流程便可
3. 未完待續
基於流程驅動的跟基於k8s的控制器在實現流程上其實並無本質的差異，在雲原生裏面有不少種玩法，虛機應用的管理本質上就是複雜環境的管理。
如何管理複雜的環境，其實就是讓環境可描述，系統自治，儘量減小人的參與，人只參與影響穩定性的決策，而不參與任何關於流程驅動；嗯，這句話說得貌似有道理
最近在搞雲原生應用管理和私有云方向，感興趣的朋友能夠一塊兒聊聊，交流交流
雲原生學習筆記地址: https://www.yuque.com/baxiaoshi/tyado3微信號：baxiaoshi2020 公共號: 圖解源碼
本文分享自微信公衆號 - 圖解源碼（sreguide）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。