Categories
程式開發

分析Kubernetes技術體系的層級,慎用比較前沿的技術


Kubernetes作為容器化時代的一個成功標準,構建了一套宏大的技術體系,包含了Cloud中的方方面面。在這個技術體系中,既有成熟的技術,也有比較前沿、實驗性的技術。

本文回顧Kubernetes技術的發展歷程、展望比較前沿的技術,目標是帶領讀者區分成熟的技術、前沿的技術,對於比較前沿的技術,根據自己的實際情況來選用——需要的就是最好的。

CNCF的全景圖如下所示。

分析Kubernetes技術體系的層級,慎用比較前沿的技術 1

Kubernetes雙輪驅動與馬斯洛需求層級

對於雲時代的R&D工程師、測試工程師、運維工程師、平台研發者等技術人員來說,首先需要明白的概念是:Kubernetes體系技術的發展來自於“雙輪驅動”,也就是平台驅動力、應用驅動力。

平台驅動力:從Kubernetes平台級研發的角度出發,屬於技術型驅動力,以雲原生、標準化為目標,可以對應於CloudNative給出的宏偉技術體系給出的各個部分。

應用驅動力:從使用者的角度出發,屬於需求型的驅動力,應用開發者對雲的需求較多,一個典型目標就是“盡量少關心分佈式系統的細節”。

分析Kubernetes技術體系的層級,慎用比較前沿的技術 2

如果用馬斯洛需求層級來表現雲時代的發展,可以整體的技術體系的發展分成四個層次:

第一個層級:分佈式系統的基本功能第二個層級:平台方的移植能力、應用方的配套設施第三個層級:平台方的擴展點、應用方的可見-控制能力第四個層級:平台方的高度統一標準化、應用方的高度綜合而方便

這四個層級的發展階段是不一樣的,第一、二個層級可以說已經達到了“業界標配”的水平,而第三個層級大部分屬於“有收益、非標準的階段”,第四個層次對於不同的使用者,往往還是“收益不確定的階段”。

在做技術選型、評估技術合理性的時候,要為全流程負責:計劃、編碼、構建、測試、發布、部署、運維、監控。

分析Kubernetes技術體系的層級,慎用比較前沿的技術 3

第一層次:分佈式系統的基本功能

對於任何一個平台,無論是基於Kubernetes的,還是更早之前的,它都要解決分佈式系統一個核心的問題:上線-運維等分佈式工作,需要盡量簡化。

在應用驅動力上面,比較樸實而基本的邏輯是:

我們的RD:本質工作寫代碼的,不要花過多精力在分佈式上面;我們的QA:最好用傳統的方法幹活,分佈式環境相關的工作盡量簡化;我們的OP:分佈式系統量級的增加、人力不能線性增加,應該達到“一個羊也是牽、一群羊也是趕”的狀態

在平台驅動力上面,至少要將打包-發布-部署的全流程貫通,並且具有運行時的調度能力。

第1個重要成果

最基礎的機制是Docker所提供的,也是一個比Kubernetes還要早達成的共識,這就是包括編譯-拉取-運行三個主要階段的Docker Image。

分析Kubernetes技術體系的層級,慎用比較前沿的技術 4

Docker Image的邏輯在於從代碼變成Code變成倉庫裡面的Image,再運行倉庫裡面Image。

Image是分佈式系統運行時與開發成果主要接口,當用Image上線的業界共識達成之後,分佈式系統就向前走了一大步。

分析Kubernetes技術體系的層級,慎用比較前沿的技術 5

直到9012年,也會有“槓精“認為不用Image上線,可以效率更高。這本質上是將上線的成本,轉嫁給了運維成本,可以說是方便了一時,卻增加了更長時間的複雜度。

第2個重要成果

第2個重要的成果就是Kubernetes比較基礎的機制:以Node代表的機器,以Pod代表的容器、以ReplicationController、ReplicaSet代表的無狀態分佈式機制。

Kubernetes的Pod本意是豆莢,裡面每個豆子其實可以視作一個Docker Container,Pod代表了應用的容器、唯一的ID、提供了基本訪問、管理機制。 Pod裡面一般有一個運行的Container,一個Pause的Container,由每個Node的Kubelet來創建。 Pod的對於應用的邏輯在於:僅有Docker(cgroup)提供的隔離機制是不夠的,還需要調度需要配置設施。

分析Kubernetes技術體系的層級,慎用比較前沿的技術 6

Kubernetes的ReplicationController、ReplicaSet則是分佈式的真諦,在它的spec.replicas已經表示了分佈式的核心內容,保證有幾個副本Pod運行,至於template.spec.containers.resources等參數,則是表示了這裡需要資源。多副本運行的拉起,也正是Kubernetes提供的最基本的調度能力。

分佈式系統馬斯洛需求的第一個層次,簡單來說就是:應用方只需要建立RC、RS等無狀態的Workload,指定image,平台用其在一些Node創建pod,調度Pod運行、確保Pod的數目。

第二層次:平台方的移植能力、應用方的配套設施

當Cloud的馬斯洛需求層級向第二層延伸的時候,平台方、應用方各自產生了一些訴求,

分析Kubernetes技術體系的層級,慎用比較前沿的技術 7

從應用方的角度,新的需求在於應用並非是一個單體的東西,而是有著“服務化“的訴求,需要有多服務、服務調用問題;還有一些服務是並非簡單的RS、RC等無狀態服務,它們有著特殊的生命週期。

從平台方的角度,增加自身的生存能力很重要,因此Kubernetes的CRI、CNI、CSI等移植層的接口應運而生。

應用方的配套設施

作為應用方,一個典型的需求就是:服務化建設。這個工作涉及到Kubernetes一些機制的重新利用,比如Service、Load Balance、DNS……

這些機製本身是Kubernetes的提供的,卻又不是基礎-核心功能,但又是應用需要標準依賴的。至於應用如何用這些機制,其實也存在著變數。

Kubernetes的Service演進過程也是比較複雜的,它本身與kube-proxy的代理轉發模式有關,也提供後端的ClusterIP、NodePort、loadbalance和Ingress四種模式,還有一種Headless Service變種情況。它解決的問題比較明確:如何表示一個分佈式服務。

一個Kubernetes的Service主要用於對外提供服務,如下面圖所示。

分析Kubernetes技術體系的層級,慎用比較前沿的技術 8

應用開發者遇到的另外一個問題就是“特殊生命週期的程序“,它們不同於RC、RS或者Deployment等無狀態、等待外部調用的服務。

Kubernetes提供一個概念是Workload Controllers:

Jobs、CrobJob:用於單次、多次運行的機制DaemonSet:保持單Node只有一個特性StatefulSets:用於有狀態服務保持序列

這些組件其實是對應用層一些生命週期特殊的程序提供機制,本身也屬於高度的抽象實現。

平台方的移植能力

作為Kubernetes平台的生存能力也在這個層級得到了進展,這裡面也就是它的移植層。

CRI(Container Runtime Interface):容器運行時接口CNI(Container Network Interface):容器網絡接口CSI(Container Storage Interface):容器存儲接口

下面圖表示了Kubernetes與移植層的關係。

分析Kubernetes技術體系的層級,慎用比較前沿的技術 9

CRI本身是一個Docker單一實現的封裝,而CNI所表示了抽象網絡、CSI表示抽象存儲,其實也就是提供了Kubernetes運行於不同地方的能力。從更大的層面來說,網絡、存儲是各種Cloud平台的重度依賴,它們的虛擬化也可以從軟件做到硬件,下層實現的”可移植化“,顯然也是比較重要的。

在雲時代的第二個需求層級,平台方、應用方的技術走向關聯性不強,但二者殊途同歸:提升了Kubernetes的使用場景。

第三層級:平台方的擴展點、應用方的可見-控制能力

隨著Cloud技術的發展,馬斯洛需求向第三層次演進,這也是應用方、平台方的一個新的契合點——平台的可擴展性。

從應用方的角度,第三層級屬於較高級人員的需求,而第一層級屬於較低級人員的需求。雖然Cloud的大目標是“盡量簡單”,但高級的人員依然希望“看到並控制“平台的運行,這兩點也並不矛盾。從平台方角度,並不能將Kubernetes所有的能力都當成的“上下層不可預約的鴻溝“,而是需要讓上層也能做一些事情,Kubernetes的擴展點也去越來越重要了。

下面的圖表示了Kubernetes的擴展點。

分析Kubernetes技術體系的層級,慎用比較前沿的技術 10

Kubernetes的擴展點有些屬於移植層,有些並不常用,以下三個需要關注:

自定義資源CRD(3):提供了不屬於系統提供,但可以封裝成標準形式的能力;調度器scheduler(4)、控制器Controllers(5):通過監聽api-server來可以進行管理擴展。

通過以上擴展點,其實類似RC、RS之類的機制,完全可以在Kubernetes的核心代碼以外來實現。當Kubernetes發展到這個階段,它已經可稱之為技術平台,RC、RS及調度器、控制器等也並非底層機制,而是預置實現。

監控典型是一個典型的屬於馬斯洛需求第三層次的工作,在傳統的方式中,監控實現方式常常需要“侵入“,這其實與雲原生的理念違和。

一個現實的情況很明顯,雖然Prometheus體係是按照比較雲原生,比較吻合Kubernetes裡面模式來架構的,但實際的應用中,往往標準化沒有如此重要。

分析Kubernetes技術體系的層級,慎用比較前沿的技術 11

實際情況則是,Prometheus等監控體係並不需要按照非常標準化的方式來部署,它的核心價值在於實用性,而不是標準化。

這裡面的原因也很簡單,對於應用方來說,並不關心Observability-Analysis體係與Kubernetes關係是否標準,因為它們都屬於系統層。

Kubernetes技術生態要有擴展能力,這正是雲的需求第三層級,這點顯然有收益;但擴展方式是否“標準“,卻是未必。公有云、私有云的不同部署模式,也決定了”標準化“的重要程度。

第四層次:平台方的高度統一標準化、應用方的高度綜合而方便

從更長遠的角度,應當看到Cloud發展的星辰大海,也有一些美好的願景……

平台方希望高度統一標準化的平台,應用方希望高度綜合方便的平台,一些很新穎、也很不標準化的技術點包括:Service Mesh、CI/CD、等綜合性的技術,比如Database、Queue、Steaming等模塊@Kubernetes上。

Service Mesh(服務網格)對於應用的微服務建設、開發-測試-運維的效率提升,有著重要的意義。 Istio及其衍生的Sidecar方案,也非常有代表性,但它們並非一定就是Service Mesh的唯一方案、最終方案。

分析Kubernetes技術體系的層級,慎用比較前沿的技術 12

CI/CD(持續集成、持續交付)是生產流程中的強需求,卻不是由單一技術能解決的,這方面方案也不僅僅是技術,也與環境、流程大有關係。

下面圖代表了CI/CD在研發流程中所影響的環節。

分析Kubernetes技術體系的層級,慎用比較前沿的技術 13

特別需要說明的一點就是在CNCF的全景圖當中,官方認證的Service Mesh、CI/CD全局方案並未出現——LINKERD只是個網絡代理。

Kubernetes在發展過程中,也衍生一個新的方向:Database等分佈式組件,也可以跑在Kubernetes上面,而它們原本的運行方式,類似於小平台。在Kubernetes運行顯然是可以實現的,而Kubernetes也為此提供了Operator框架。 MySql、Kafka、Spark都可以運行Kubernetes在上面,並且用Operator管理這些有狀態服務。

分析Kubernetes技術體系的層級,慎用比較前沿的技術 14

把這些成熟的分佈式軟件搬到Kubernetes上面,業界並未形成完全統一的方案。大方向的正確與實際的收益是兩回事。

從技術發展的角度來說,統一環境不能提高標準化程度,理論上還能提高資源利用率,但這種技術方案可能只在某些場景有收益,而非所有場景都有收益。

結語:適合的就是好的

Kubernetes仍在快速的發展過程中,本文通過需求層級來描述了技術的成熟度。

從技術選型的角度來說,對於一、二層的成熟技術,跟從既成事實的標準即可;對於第三、四層的技術,有些其實比較前沿,需要一分為二來看待。

可以從幾個角度思考問題:

標準化重要,還是極限優化重要?目標系統是大型,中型,還是小型?實際的生產中,開發、部署、運維的工作比例是多大?對於某個技術,“有你,跟沒你,有什麼區別?“

總之,在Cloud時代中看Kubernetes相關技術方案,依然可以秉承一個原則:適合的就是好的。