最近閑下來，打算把Knative的核心組件Serving給學習下，會繼續采用k8s原始碼學習的方式，管中窺豹以小擊大，學習serving的主要目標: 可觀測性基礎設施、自動伸縮、流量管理等核心組件的設計與實作，今天先簡單臆測下，感興趣的同學， 一起來學習吧
1. 基于云原生的單體應用構建
大多數公司的服務可能都已經經過單體、SOA演進到了當下流行的微服務架構，微服務給我們帶來了獨立演進、擴容、協作、資料自治等便利的背景下，也帶來了諸如穩定性保障、維護、服務治理等實際的問題，我們今天來一起來回歸單體，比如我們要新開一個業務，新上一個小的模塊這個場景，在云原生的場景下，是如何玩的
1.1 云原生下的單體應用
云原生有很多大佬有很多的解釋，我就簡單理解成是基于云構建而來，可以使用云上所有已知的現有的服務，同時享受云所帶來的彈性、按需付費、高可用等方面的原生能力
一個基礎的單體應用通常會依賴如下幾部分：持久化資料存盤、高性能快取、全文索引、訊息佇列等常見組件， 各家云廠商大多數會包含這些基礎的服務，我們只需要引入對應的類別庫完成我們的應用邏輯即可, 然后程式就完成代碼的coding后,下一步就是交付了
1.2 基于k8s的云原生交付
基于k8s的云原生已經成為一個事實上的標準，將代碼和應用的資料打包成docker鏡像，基于Pod的交付模式，讓我們并不需要關注我們是使用IDC里面的物體機，還是公有云的云服務，我們只需要打包成docker鏡像，然后設定好檔期環境的配置資料，我們的單體應用就可以運行了, 但是通常我們會有一些非業務需求, 比如監控、日志等, 下一節我們來解決這些問題
1.3 slidecar模式
在應用開發的初期，我們可能并沒有考慮監控、日志這種可觀測性的需求，通常是在上線的時候才會考慮這些，而基于k8s的云原生的環境下，通常會使用一個slidecar來實作這種基礎功能的增強，通過嵌入一個slidecar容器完成這種基礎組件的復用，可以基于slidecar模式實作日志、監控、分布式跟蹤、Https支持等基礎功能，而讓上層應用只關注業務邏輯的實作
1.4 服務即基礎設施
在公司中通常一個業務往往都會進行一些公司內部系統的接入，比如用戶、支付、運營等服務，如果公司的服務也可以與基礎設施同等對待，并且這些服務也可以通過k8s的形式進行交付，則我們就可以只關注單體應用自身的擴展(小前臺)
通過上面的設想我們構建出了一個基礎的單體應用，應用程式只需要關注應用邏輯的撰寫，全部的業務邏輯都耦合在一個應用內，其余的基礎設施、非業務需求全都由其他組件實作，接下來就該部署了，通常我們就需要分配個XHXG配置的Pod，然后為了高可用可能還需要N個replicaset，然后再來個HPA體驗下自動伸縮，跑了一段時間可能會發現，可能一天就兩個巴掌的訪問量，可是依舊占用著N*XHXG的資源，以這個角度我們來進入我們今天的主題Knative
2.Knative
Knative還在不斷變化中，一些設計檔案也并沒有對外開放，讀起來就相對k8s難一些，但整體代碼量相比較也少了一些，在后續的文章里面我們還是先管中窺豹，逐個組件進行代碼閱讀，但因為沒有相關的Proposal, 主要是參考冬島大神的相關文章來進行代碼的閱讀，只是個人理解，如有不對，歡迎指教，接下來我們看看knative是如何完成上面提到的功能與實作按需分配關鍵組件, 我們從流量入口開始依次介紹各個組件
2.1 基于Istio實作南北向流量的管控
在k8s中南北向流量通常由Ingress來進行管控，而在kantive流量管控的實作，主要是依賴于istio, Istio是一個ServiceMesh框架，Knative中與其集成主要是使用了istio的南北向流量管控的功能，其實就是利用istio對應的ingress的功能, 主要功能分為下面兩個部分
2.1.1 版本部署管理
Knative里面支持藍綠、金絲雀等發布策略，其核心就是通過自己的revision版本管理和istio中的ingress的路由配置功能，即我們可以根據自己的需要設定對應的流量策略，從而進行版本的發布配置管理
2.1.2 自動伸縮(至零)
Knative自動伸縮有兩個特點：按需自動分配、縮容至零，按需分配時指的knative可以根據應用的并發能力，來自動計算實作自動擴容，而且整個基本上是秒級，不同于HPA, 其次是就是縮容至零，即可以將對應的業務容器Pod，全部干掉，但是新進入請求之后會立即進行分配，并不影響正常訪問(可能初期延遲會相對高一些)
2.2 Queue slidecar
在上面到過可觀測性需求，在應用服務中通常可以分為三個部分：日志、監控、分布式跟蹤，為了實作這些功能Knative實作了Queue組件，其職責目前理解主要是分為兩個部分：完成觀測性資料收集、代理業務容器的訪問, Queue組件通過代理的方式實作上面提到指標的統計, 并將對應的資料匯報給后端的日志/監控/分布式跟蹤服務, 同時還需要向autoscaler同步當前的并發監控, 以便實作自動伸縮功能, Queue主要是代理應用容器, 而Kantive支持縮容至零的特性, 在縮容至零的時候, Knative就會使用一個Activator Pod來替代Queue和應用容器，從而實作縮容至零
2.3 Activator
Activator容器是縮容至零的關鍵，當業務容器沒有訪問的時候，Knative就會將對應的ingress流量指向Activator組件，當縮容至零的時候，如果此時又業務請求，Activator會立即通知autoscaler立刻拉起業務容器，并將流量轉發真正的業務容器，這樣既可以完成流量的無損轉發，又可以實作按需付費，再也不用為沒有訪問量的業務，一直啟動著Pod了, Activator并不負責實際的伸縮決策，伸縮組件主要是通過Autoscaler來實作
2.4 Autoscaler
Autoscaler是Knative中實作自動擴容的關鍵，其通過Activator和Queue兩個組件傳遞過來的監控資料并根據配置來計算，實時動態的調整業務容器的副本數量，從而實作自動伸縮
2.5 Controller
Controller是Knative對應資源的控制器，其本身的功能跟k8s中其他的組件的實作類似，根據資源的當前狀態和期望狀態來進行一致性調整，從而實作最終一致性
2.6 webhook
Knative是基于k8s的CRD實作的，其webhook主要包含對應資源資料的驗證和修改等admission相關
3. 總結
結合上面的組件功能猜想，大概猜想了核心的資料流的實作，如圖所示，我們可以分為五層來考慮：觀測層(Queue和Activator)、決策層(Autoscaler)、控制層(Controller)、準入層(Webhook)、路由層(Istio INgress), 通過觀測層實時獲取用戶請求資料，發給決策層進行決策，并將決策結果寫入到Apiserver, 控制層感知，負責進行對應資源的更新，最終由路由層感知，進行流量分配，這樣就實作了整體流量的感知、決策、路由等核心功能，暫時就理解這些，后續希望隨著代碼的深入，有更深的體會，祝我好運，good luck!
原文 https://www.yuque.com/baxiaoshi/tyado3/up5efq
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/21415.html
標籤：其他
上一篇：java連接ssh并執行命令 關于命令有的無法執行問題
下一篇：pyQGIS的應用