Kubernetes設計的原則是什么

本篇內容介紹了“Kubernetes設計的原則是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

引言：

• 用戶：提供一系列的指令來驅動系統達到制定狀態。

• 系統：執行指令

• 用戶：監控系統，根據系統狀態，提供進一步的指令

• 用戶：定義期望的狀態

• 系統：向著指定的狀態工作

下圖是一個聲明式API的例子：

1、用戶創建一個API對象

2、所用的組件并行工作來達到該狀態。

聲明式的API支持自動恢復。例如：

2、系統自主地把Pod移動到健康的節點A上

• 主節點：提供一系列的指令來驅動節點達到制定狀態。

• 節點：執行主節點發來的指令

• 主節點：監控每一個節點，根據節點狀態，提供進一步的指令

• 主節點：定義想要達到的狀態

• 節點：獨立工作以達到主節點定義的狀態

Scheduler通過API觀察到Pod A的定義，通過調度運算，決定要在Node B上創建Pod A，并通過API更新主節點上的Pod A的定義。

• 應用程序必須被修改為知道K8s的存在，調用KubeAPI

• 應用程序可以從環境變量加載配置文件或者密匙文件，所以不需要修改

我們可以舉一個例子，是關于遠程存儲的。

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

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

如上圖所示，通過PVC的抽象，用戶Pod并不直接引用GCE PD或者EBS，這樣就使得該Pod可以在不同的基礎架構中互相遷移，做到可移植。就像操作系統一樣，該設計使得系統應用和底層的硬件或者架構實現分離解耦。

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

2. Kubernetes控制平面是透明的，沒有隱藏的內部API

3. 滿足用戶的需求

4. 可移植的工作負載

• 對象要對自己負責。在設計對象的時候，對象應該盡可能的封裝內部的狀態，對自己負責，我們設計一輛可行駛的車。一種設計是兩個對象，driver和car，然后diver.run(car)。而更好的設計是 不需要driver，或者把dirver看成Car的一個屬性，這樣就是Car.run()。第二種設計更符合面向對象的設計原則。這正是聲明式API背后的原則，組件對自己負責

• Kube API類似對象的接口，對象對修改封閉，對擴展開放。通過開放的API，用戶可以很容易的實現功能擴展，但是你無法修改已有的組件，你可以開發自定義的組件來替換已有的組件

• 可移植性的設計利用了類似面向對象的多態，同多定義抽象接口PVC，隱藏具體的實現細節。

“Kubernetes設計的原則是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！