本篇內(nèi)容介紹了“Kubernetes設計的原則是什么”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！
創(chuàng)新互聯(lián)專注于余慶網(wǎng)站建設服務及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供余慶營銷型網(wǎng)站建設，余慶網(wǎng)站制作、余慶網(wǎng)頁設計、余慶網(wǎng)站官網(wǎng)定制、重慶小程序開發(fā)服務，打造余慶網(wǎng)絡公司原創(chuàng)品牌,更為您提供余慶網(wǎng)站排名全網(wǎng)營銷落地服務。
引言：
原則1. Kubernetes APIs
是聲明性的而非命令性的
用戶：提供一系列的指令來驅(qū)動系統(tǒng)達到制定狀態(tài)。
系統(tǒng)：執(zhí)行指令
用戶：監(jiān)控系統(tǒng)，根據(jù)系統(tǒng)狀態(tài)，提供進一步的指令
用戶：定義期望的狀態(tài)
系統(tǒng)：向著指定的狀態(tài)工作
下圖是一個聲明式API的例子：
1、用戶創(chuàng)建一個API對象
2、所用的組件并行工作來達到該狀態(tài)。
聲明式的API支持自動恢復。例如：
2、系統(tǒng)自主地把Pod移動到健康的節(jié)點A上
原則2. Kubernetes控制平面
是透明的，沒有隱藏的內(nèi)部API
主節(jié)點：提供一系列的指令來驅(qū)動節(jié)點達到制定狀態(tài)。
節(jié)點：執(zhí)行主節(jié)點發(fā)來的指令
主節(jié)點：監(jiān)控每一個節(jié)點，根據(jù)節(jié)點狀態(tài)，提供進一步的指令
主節(jié)點：定義想要達到的狀態(tài)
節(jié)點：獨立工作以達到主節(jié)點定義的狀態(tài)
Scheduler通過API觀察到Pod A的定義，通過調(diào)度運算，決定要在Node B上創(chuàng)建Pod A，并通過API更新主節(jié)點上的Pod A的定義。
原則3. 滿足用戶的需求
應用程序必須被修改為知道K8s的存在，調(diào)用KubeAPI
應用程序可以從環(huán)境變量加載配置文件或者密匙文件，所以不需要修改
我們可以舉一個例子，是關(guān)于遠程存儲的。
如上圖所示，Pod可以直接引用一個遠程的存儲卷（GCE PD，AWS EBS，NFS等），kubernetes會自動使得該卷被用于Pod。但是這樣做的話，有一個問題，如果你要遷移到一個新的基礎(chǔ)架構(gòu)上，那么它就不工作了。于是這就引入了kubernetes設計的第四個原則：
原則4. 可移植的工作負載
持久卷（PersistentVolumn，PV）和持久卷聲明（PersistenVolumnClaim， PVC）就是這樣一個例子。
如上圖所示，通過PVC的抽象，用戶Pod并不直接引用GCE PD或者EBS，這樣就使得該Pod可以在不同的基礎(chǔ)架構(gòu)中互相遷移，做到可移植。就像操作系統(tǒng)一樣，該設計使得系統(tǒng)應用和底層的硬件或者架構(gòu)實現(xiàn)分離解耦。
總結(jié)
Kubernetes APIs 是聲明性的而非命令性的
Kubernetes控制平面是透明的，沒有隱藏的內(nèi)部API
滿足用戶的需求
可移植的工作負載
對象要對自己負責。在設計對象的時候，對象應該盡可能的封裝內(nèi)部的狀態(tài)，對自己負責，我們設計一輛可行駛的車。一種設計是兩個對象，driver和car，然后diver.run(car)。而更好的設計是 不需要driver，或者把dirver看成Car的一個屬性，這樣就是Car.run()。第二種設計更符合面向?qū)ο蟮脑O計原則。這正是聲明式API背后的原則，組件對自己負責
Kube API類似對象的接口，對象對修改封閉，對擴展開放。通過開放的API，用戶可以很容易的實現(xiàn)功能擴展，但是你無法修改已有的組件，你可以開發(fā)自定義的組件來替換已有的組件
可移植性的設計利用了類似面向?qū)ο蟮亩鄳B(tài)，同多定義抽象接口PVC，隱藏具體的實現(xiàn)細節(jié)。
“Kubernetes設計的原則是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！
重慶分公司
重慶分公司
