Kubernetes設(shè)計(jì)的原則是什么-創(chuàng)新互聯(lián)

本篇內(nèi)容介紹了“Kubernetes設(shè)計(jì)的原則是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

目前創(chuàng)新互聯(lián)已為上千多家的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬主機(jī)、成都網(wǎng)站托管、企業(yè)網(wǎng)站設(shè)計(jì)、濟(jì)寧網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。

引言：

今天我要帶給大家的是2018年底，在西雅圖舉辦的Kubecon的一場(chǎng)分享，來(lái)自谷歌K8s團(tuán)隊(duì)的工程師Saad Ali分享的《Kubernetes設(shè)計(jì)原則》。這場(chǎng)會(huì)議雖然已經(jīng)過(guò)去一年多了，但是我覺(jué)得本會(huì)議的內(nèi)容非常值得學(xué)習(xí)，我們大都知道K8s是如何工作的，但是本文帶我們了解k8s背后的設(shè)計(jì)原則，以及為什么要這樣設(shè)計(jì)。對(duì)于跨云和本地環(huán)境在分布式系統(tǒng)上管理和部署工作負(fù)載，Kubernetes很快變得不可或缺。雖然現(xiàn)在大多數(shù)人都熟悉如何使用Kubernetes，但很少有人知道其背后的“為什么”？為什么Kubernetes API看起來(lái)是這樣的？為什么Kubernetes組件僅通過(guò)Kubernetes API相互交互？當(dāng)您可以輕松地直接從pod引用卷時(shí)，為什么會(huì)有PersistentVolumeClaim對(duì)象？為了回答這些問(wèn)題并幫助您對(duì)Kubernetes進(jìn)行更深入的了解，本講座將揭示支撐Kubernetes設(shè)計(jì)的原理。

原則1. Kubernetes APIs 

是聲明性的而非命令性的

我們從最簡(jiǎn)單的一個(gè)例子開(kāi)始，要如何在一臺(tái)節(jié)點(diǎn)上啟動(dòng)需要運(yùn)行的任務(wù)。最簡(jiǎn)單的方式就是發(fā)送一個(gè)命令，啟動(dòng)容器。但是這樣做的話，如果容器，節(jié)點(diǎn)崩潰，或者節(jié)點(diǎn)臨時(shí)不可訪問(wèn)的時(shí)候，用戶就必須監(jiān)控和存儲(chǔ)每一個(gè)節(jié)點(diǎn)和容器的狀態(tài)，捕獲所有的異常，并做異常處理。也就是說(shuō)把所有的復(fù)雜的異常處理的邏輯交給客戶端來(lái)做。
這就引入了Kubernetes的第一個(gè)設(shè)計(jì)原則：Kubernetes APIs 是聲明性的而非命令性的 （ Kubernetes APIs are declarative rather then imperative ）命令式：

• 用戶：提供一系列的指令來(lái)驅(qū)動(dòng)系統(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)工作

下圖是一個(gè)聲明式API的例子：

1、用戶創(chuàng)建一個(gè)API對(duì)象

2、所用的組件并行工作來(lái)達(dá)到該狀態(tài)。

聲明式的API支持自動(dòng)恢復(fù)。例如：

1、節(jié)點(diǎn)B掛了

2、系統(tǒng)自主地把Pod移動(dòng)到健康的節(jié)點(diǎn)A上

這里需要注意主節(jié)點(diǎn)只是存儲(chǔ)了Pod的定義聲明，而不會(huì)向節(jié)點(diǎn)B發(fā)送命令，如果那樣做，主節(jié)點(diǎn)就會(huì)變得和我們之前提到的客戶端一樣，復(fù)雜而脆弱，且難以擴(kuò)展。這就引入了K8s的第二個(gè)設(shè)計(jì)原則：Kubernetes控制平面是透明的，沒(méi)有隱藏的內(nèi)部API （ The Kubernetes control plane is transparent. There are no hidden internal APIs. ）

原則2.  Kubernetes控制平面

是透明的，沒(méi)有隱藏的內(nèi)部API

之前：

• 主節(jié)點(diǎn)：提供一系列的指令來(lái)驅(qū)動(dòng)節(jié)點(diǎn)達(dá)到制定狀態(tài)。

• 節(jié)點(diǎn)：執(zhí)行主節(jié)點(diǎn)發(fā)來(lái)的指令

• 主節(jié)點(diǎn)：監(jiān)控每一個(gè)節(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)

我們來(lái)看一個(gè)Pod創(chuàng)建的例子：如下圖所示，所有的組件都監(jiān)視Kubernetes API，然后決定自己應(yīng)該怎么做。用戶調(diào)用API聲明要?jiǎng)?chuàng)建的Pod主節(jié)點(diǎn)創(chuàng)建Pod的定義

Scheduler通過(guò)API觀察到Pod A的定義，通過(guò)調(diào)度運(yùn)算，決定要在Node B上創(chuàng)建Pod A，并通過(guò)API更新主節(jié)點(diǎn)上的Pod A的定義。

Node B觀察到Pod A的定義是在自己的管轄范圍，啟動(dòng)Pod A用戶通過(guò)API刪除 Pod A節(jié)點(diǎn)B發(fā)現(xiàn) Pod A被刪除節(jié)點(diǎn)B刪除Pod A這樣做的能促成一個(gè)更簡(jiǎn)單，更健壯的系統(tǒng)設(shè)計(jì)，并很容易從故障狀態(tài)中恢復(fù)。系統(tǒng)沒(méi)有單點(diǎn)故障，主節(jié)點(diǎn)的職責(zé)非常簡(jiǎn)單。這樣做的另一個(gè)好處是，系統(tǒng)更容易擴(kuò)展和組合。因?yàn)闆](méi)有內(nèi)部隱藏的API，用戶可以很容易的用自定的組件替代已有組件，或者增加自定義的功能。K8s還有很對(duì)對(duì)象對(duì)業(yè)務(wù)是很重要的，例如存儲(chǔ)密碼的密匙文件secret，配置configmap，或者下行API提供Pod的基本信息。那么應(yīng)用程序必須修改為調(diào)用KubeAPI來(lái)或者這些信息么？這就引入了Kubernetes的第三個(gè)設(shè)計(jì)原則：滿足用戶的需求 （ Meet the user where they are ）

原則3.  滿足用戶的需求 

之前：

• 應(yīng)用程序必須被修改為知道K8s的存在，調(diào)用KubeAPI

現(xiàn)在：

• 應(yīng)用程序可以從環(huán)境變量加載配置文件或者密匙文件，所以不需要修改

我們可以舉一個(gè)例子，是關(guān)于遠(yuǎn)程存儲(chǔ)的。

如上圖所示，Pod可以直接引用一個(gè)遠(yuǎn)程的存儲(chǔ)卷（GCE PD，AWS EBS，NFS等），kubernetes會(huì)自動(dòng)使得該卷被用于Pod。但是這樣做的話，有一個(gè)問(wèn)題，如果你要遷移到一個(gè)新的基礎(chǔ)架構(gòu)上，那么它就不工作了。于是這就引入了kubernetes設(shè)計(jì)的第四個(gè)原則：

可移植的工作負(fù)載 （ Workload portability ）

原則4. 可移植的工作負(fù)載

持久卷（PersistentVolumn，PV）和持久卷聲明（PersistenVolumnClaim， PVC）就是這樣一個(gè)例子。

如上圖所示，通過(guò)PVC的抽象，用戶Pod并不直接引用GCE PD或者EBS，這樣就使得該P(yáng)od可以在不同的基礎(chǔ)架構(gòu)中互相遷移，做到可移植。就像操作系統(tǒng)一樣，該設(shè)計(jì)使得系統(tǒng)應(yīng)用和底層的硬件或者架構(gòu)實(shí)現(xiàn)分離解耦。

總結(jié)

本文總結(jié)了Kubecon 2018的一場(chǎng)由谷歌高級(jí)軟件工程師、kubernete開(kāi)發(fā)人員Saad Ali分享的《Kubernetes設(shè)計(jì)原則》。其中的四個(gè)設(shè)計(jì)原則分別是：

1. Kubernetes APIs 是聲明性的而非命令性的

2. Kubernetes控制平面是透明的，沒(méi)有隱藏的內(nèi)部API

3. 滿足用戶的需求

4. 可移植的工作負(fù)載

通過(guò)該分享，我們可以發(fā)現(xiàn)，K8s的背后設(shè)計(jì)原則的原因，其實(shí)它軟件設(shè)計(jì)的一些一般性原則是一致的，雖然面向?qū)ο笠呀?jīng)不在是什么流行的術(shù)語(yǔ)，但是本文中的設(shè)計(jì)原則和面向?qū)ο蟮脑O(shè)計(jì)原則高度一致。

• 對(duì)象要對(duì)自己負(fù)責(zé)。在設(shè)計(jì)對(duì)象的時(shí)候，對(duì)象應(yīng)該盡可能的封裝內(nèi)部的狀態(tài)，對(duì)自己負(fù)責(zé)，我們?cè)O(shè)計(jì)一輛可行駛的車。一種設(shè)計(jì)是兩個(gè)對(duì)象，driver和car，然后diver.run(car)。而更好的設(shè)計(jì)是 不需要driver，或者把dirver看成Car的一個(gè)屬性，這樣就是Car.run()。第二種設(shè)計(jì)更符合面向?qū)ο蟮脑O(shè)計(jì)原則。這正是聲明式API背后的原則，組件對(duì)自己負(fù)責(zé)

• Kube API類似對(duì)象的接口，對(duì)象對(duì)修改封閉，對(duì)擴(kuò)展開(kāi)放。通過(guò)開(kāi)放的API，用戶可以很容易的實(shí)現(xiàn)功能擴(kuò)展，但是你無(wú)法修改已有的組件，你可以開(kāi)發(fā)自定義的組件來(lái)替換已有的組件

• 可移植性的設(shè)計(jì)利用了類似面向?qū)ο蟮亩鄳B(tài)，同多定義抽象接口PVC，隱藏具體的實(shí)現(xiàn)細(xì)節(jié)。

希望本文的分享能幫助你理解K8s背后的設(shè)計(jì)原則。

“Kubernetes設(shè)計(jì)的原則是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

當(dāng)前名稱：Kubernetes設(shè)計(jì)的原則是什么-創(chuàng)新互聯(lián)
標(biāo)題來(lái)源：http://muchs.cn/article14/ddside.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、外貿(mào)建站、App開(kāi)發(fā)、服務(wù)器托管、商城網(wǎng)站、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)