新聞中心
對于跨云和本地環(huán)境在分布式系統(tǒng)上管理和部署工作負(fù)載,Kubernetes很快變得不可或缺。

創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供白山網(wǎng)站建設(shè)、白山做網(wǎng)站、白山網(wǎng)站設(shè)計、白山網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、白山企業(yè)網(wǎng)站模板建站服務(wù),10余年白山做網(wǎng)站經(jīng)驗(yàn),不只是建網(wǎng)站,更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。
雖然現(xiàn)在大多數(shù)人都熟悉如何使用Kubernetes,但很少有人知道其背后的“為什么”?為什么Kubernetes API看起來是這樣的?為什么Kubernetes組件僅通過Kubernetes API相互交互?當(dāng)您可以輕松地直接從pod引用卷時,為什么會有PersistentVolumeClaim對象?
為了回答這些問題并幫助您對Kubernetes進(jìn)行更深入的了解,本講座將揭示支撐Kubernetes設(shè)計的原理。
原則1. Kubernetes APIs是聲明性的而非命令性的
我們從很簡單的一個例子開始,要如何在一臺節(jié)點(diǎn)上啟動需要運(yùn)行的任務(wù)。
很簡單的方式就是發(fā)送一個命令,啟動容器。
但是這樣做的話,如果容器,節(jié)點(diǎn)崩潰,或者節(jié)點(diǎn)臨時不可訪問的時候,用戶就必須監(jiān)控和存儲每一個節(jié)點(diǎn)和容器的狀態(tài),捕獲所有的異常,并做異常處理。也就是說把所有的復(fù)雜的異常處理的邏輯交給客戶端來做。
這就引入了Kubernetes的第一個設(shè)計原則:
Kubernetes APIs 是聲明性的而非命令性的 ( Kubernetes APIs are declarative rather then imperative )
命令式:
- 用戶:提供一系列的指令來驅(qū)動系統(tǒng)達(dá)到制定狀態(tài)。
- 系統(tǒng):執(zhí)行指令
- 用戶:監(jiān)控系統(tǒng),根據(jù)系統(tǒng)狀態(tài),提供進(jìn)一步的指令
聲明式:
- 用戶:定義期望的狀態(tài)
- 系統(tǒng):向著指定的狀態(tài)工作
下圖是一個聲明式API的例子:
1、用戶創(chuàng)建一個API對象
2、所用的組件并行工作來達(dá)到該狀態(tài)。
聲明式的API支持自動恢復(fù)。例如:
1、節(jié)點(diǎn)B掛了
2、系統(tǒng)自主地把Pod移動到健康的節(jié)點(diǎn)A上
這里需要注意主節(jié)點(diǎn)只是存儲了Pod的定義聲明,而不會向節(jié)點(diǎn)B發(fā)送命令,如果那樣做,主節(jié)點(diǎn)就會變得和我們之前提到的客戶端一樣,復(fù)雜而脆弱,且難以擴(kuò)展。這就引入了K8s的第二個設(shè)計原則:
Kubernetes控制平面是透明的,沒有隱藏的內(nèi)部API ( The Kubernetes control plane is transparent. There are no hidden internal APIs. )
原則2. Kubernetes控制平面是透明的,沒有隱藏的內(nèi)部API
之前:
- 主節(jié)點(diǎn):提供一系列的指令來驅(qū)動節(jié)點(diǎn)達(dá)到制定狀態(tài)。
- 節(jié)點(diǎn):執(zhí)行主節(jié)點(diǎn)發(fā)來的指令
- 主節(jié)點(diǎn):監(jiān)控每一個節(jié)點(diǎn),根據(jù)節(jié)點(diǎn)狀態(tài),提供進(jìn)一步的指令
現(xiàn)在:
- 主節(jié)點(diǎn):定義想要達(dá)到的狀態(tài)
- 節(jié)點(diǎn):獨(dú)立工作以達(dá)到主節(jié)點(diǎn)定義的狀態(tài)
我們來看一個Pod創(chuàng)建的例子:
如下圖所示,所有的組件都監(jiān)視Kubernetes API,然后決定自己應(yīng)該怎么做。
用戶調(diào)用API聲明要創(chuàng)建的Pod
主節(jié)點(diǎn)創(chuàng)建Pod的定義
Scheduler通過API觀察到Pod A的定義,通過調(diào)度運(yùn)算,決定要在Node B上創(chuàng)建Pod A,并通過API更新主節(jié)點(diǎn)上的Pod A的定義。
Node B觀察到Pod A的定義是在自己的管轄范圍,啟動Pod A
用戶通過API刪除 Pod A
節(jié)點(diǎn)B發(fā)現(xiàn) Pod A被刪除
節(jié)點(diǎn)B刪除Pod A
這樣做的能促成一個更簡單,更健壯的系統(tǒng)設(shè)計,并很容易從故障狀態(tài)中恢復(fù)。系統(tǒng)沒有單點(diǎn)故障,主節(jié)點(diǎn)的職責(zé)非常簡單。
這樣做的另一個好處是,系統(tǒng)更容易擴(kuò)展和組合。因?yàn)闆]有內(nèi)部隱藏的API,用戶可以很容易的用自定的組件替代已有組件,或者增加自定義的功能。
K8s還有很對對象對業(yè)務(wù)是很重要的,例如存儲密碼的密匙文件secret,配置configmap,或者下行API提供Pod的基本信息。那么應(yīng)用程序必須修改為調(diào)用KubeAPI來或者這些信息么?
這就引入了Kubernetes的第三個設(shè)計原則:
滿足用戶的需求 ( Meet the user where they are )
原則3. 滿足用戶的需求
之前:
- 應(yīng)用程序必須被修改為知道K8s的存在,調(diào)用KubeAPI
現(xiàn)在:
- 應(yīng)用程序可以從環(huán)境變量加載配置文件或者密匙文件,所以不需要修改
我們可以舉一個例子,是關(guān)于遠(yuǎn)程存儲的。
如上圖所示,Pod可以直接引用一個遠(yuǎn)程的存儲卷(GCE PD,AWS EBS,NFS等),kubernetes會自動使得該卷被用于Pod。但是這樣做的話,有一個問題,如果你要遷移到一個新的基礎(chǔ)架構(gòu)上,那么它就不工作了。于是這就引入了kubernetes設(shè)計的第四個原則:
可移植的工作負(fù)載 ( Workload portability )
原則4. 可移植的工作負(fù)載
持久卷(PersistentVolumn,PV)和持久卷聲明(PersistenVolumnClaim, PVC)就是這樣一個例子。
如上圖所示,通過PVC的抽象,用戶Pod并不直接引用GCE PD或者EBS,這樣就使得該P(yáng)od可以在不同的基礎(chǔ)架構(gòu)中互相遷移,做到可移植。就像操作系統(tǒng)一樣,該設(shè)計使得系統(tǒng)應(yīng)用和底層的硬件或者架構(gòu)實(shí)現(xiàn)分離解耦。
總結(jié)
本文總結(jié)了Kubecon 2018的一場由谷歌高級軟件工程師、kubernete開發(fā)人員Saad Ali分享的《Kubernetes設(shè)計原則》。其中的四個設(shè)計原則分別是:
- Kubernetes APIs 是聲明性的而非命令性的
- Kubernetes控制平面是透明的,沒有隱藏的內(nèi)部API
- 滿足用戶的需求
- 可移植的工作負(fù)載
通過該分享,我們可以發(fā)現(xiàn),K8s的背后設(shè)計原則的原因,其實(shí)它軟件設(shè)計的一些一般性原則是一致的,雖然面向?qū)ο笠呀?jīng)不在是什么流行的術(shù)語,但是本文中的設(shè)計原則和面向?qū)ο蟮脑O(shè)計原則高度一致。
- 對象要對自己負(fù)責(zé)。在設(shè)計對象的時候,對象應(yīng)該盡可能的封裝內(nèi)部的狀態(tài),對自己負(fù)責(zé),我們設(shè)計一輛可行駛的車。一種設(shè)計是兩個對象,driver和car,然后diver.run(car)。而更好的設(shè)計是 不需要driver,或者把dirver看成Car的一個屬性,這樣就是Car.run()。第二種設(shè)計更符合面向?qū)ο蟮脑O(shè)計原則。這正是聲明式API背后的原則,組件對自己負(fù)責(zé)
- Kube API類似對象的接口,對象對修改封閉,對擴(kuò)展開放。通過開放的API,用戶可以很容易的實(shí)現(xiàn)功能擴(kuò)展,但是你無法修改已有的組件,你可以開發(fā)自定義的組件來替換已有的組件
- 可移植性的設(shè)計利用了類似面向?qū)ο蟮亩鄳B(tài),同多定義抽象接口PVC,隱藏具體的實(shí)現(xiàn)細(xì)節(jié)。
希望本文的分享能幫助你理解K8s背后的設(shè)計原則。
本文標(biāo)題:Kubernetes設(shè)計的4個原則
文章源于:http://fisionsoft.com.cn/article/dpggpsi.html


咨詢
建站咨詢
