對于跨云和本地環境在分布式系統上管理和部署工作負載，Kubernetes很快變得不可或缺。

[[312243]]

雖然現在大多數人都熟悉如何使用Kubernetes，但很少有人知道其背后的“為什么”?為什么Kubernetes API看起來是這樣的?為什么Kubernetes組件僅通過Kubernetes API相互交互?當您可以輕松地直接從pod引用卷時，為什么會有PersistentVolumeClaim對象?

為了回答這些問題并幫助您對Kubernetes進行更深入的了解，本講座將揭示支撐Kubernetes設計的原理。

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

我們從很簡單的一個例子開始，要如何在一臺節點上啟動需要運行的任務。

很簡單的方式就是發送一個命令，啟動容器。

但是這樣做的話，如果容器，節點崩潰，或者節點臨時不可訪問的時候，用戶就必須監控和存儲每一個節點和容器的狀態，捕獲所有的異常，并做異常處理。也就是說把所有的復雜的異常處理的邏輯交給客戶端來做。

這就引入了Kubernetes的第一個設計原則：

Kubernetes APIs 是聲明性的而非命令性的 ( Kubernetes APIs are declarative rather then imperative )

命令式：

• 用戶：提供一系列的指令來驅動系統達到制定狀態。
• 系統：執行指令
• 用戶：監控系統，根據系統狀態，提供進一步的指令

聲明式：

• 用戶：定義期望的狀態
• 系統：向著指定的狀態工作

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

1、用戶創建一個API對象

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

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

1、節點B掛了

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

這里需要注意主節點只是存儲了Pod的定義聲明，而不會向節點B發送命令，如果那樣做，主節點就會變得和我們之前提到的客戶端一樣，復雜而脆弱，且難以擴展。這就引入了K8s的第二個設計原則：

Kubernetes控制平面是透明的，沒有隱藏的內部API ( The Kubernetes control plane is transparent. There are no hidden internal APIs. )

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

之前：

• 主節點：提供一系列的指令來驅動節點達到制定狀態。
• 節點：執行主節點發來的指令
• 主節點：監控每一個節點，根據節點狀態，提供進一步的指令

現在：

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

我們來看一個Pod創建的例子：

如下圖所示，所有的組件都監視Kubernetes API，然后決定自己應該怎么做。

用戶調用API聲明要創建的Pod

主節點創建Pod的定義

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

Node B觀察到Pod A的定義是在自己的管轄范圍，啟動Pod A

用戶通過API刪除 Pod A

節點B發現 Pod A被刪除

節點B刪除Pod A

這樣做的能促成一個更簡單，更健壯的系統設計，并很容易從故障狀態中恢復。系統沒有單點故障，主節點的職責非常簡單。

這樣做的另一個好處是，系統更容易擴展和組合。因為沒有內部隱藏的API，用戶可以很容易的用自定的組件替代已有組件，或者增加自定義的功能。

K8s還有很對對象對業務是很重要的，例如存儲密碼的密匙文件secret，配置configmap，或者下行API提供Pod的基本信息。那么應用程序必須修改為調用KubeAPI來或者這些信息么?

這就引入了Kubernetes的第三個設計原則：

滿足用戶的需求 ( Meet the user where they are )

原則3. 滿足用戶的需求

之前：

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

現在：

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

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

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

可移植的工作負載 ( Workload portability )

原則4. 可移植的工作負載

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

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

總結

本文總結了Kubecon 2018的一場由谷歌高級軟件工程師、kubernete開發人員Saad Ali分享的《Kubernetes設計原則》。其中的四個設計原則分別是：

1. Kubernetes APIs 是聲明性的而非命令性的
2. Kubernetes控制平面是透明的，沒有隱藏的內部API
3. 滿足用戶的需求
4. 可移植的工作負載

通過該分享，我們可以發現，K8s的背后設計原則的原因，其實它軟件設計的一些一般性原則是一致的，雖然面向對象已經不在是什么流行的術語，但是本文中的設計原則和面向對象的設計原則高度一致。

• 對象要對自己負責。在設計對象的時候，對象應該盡可能的封裝內部的狀態，對自己負責，我們設計一輛可行駛的車。一種設計是兩個對象，driver和car，然后diver.run(car)。而更好的設計是 不需要driver，或者把dirver看成Car的一個屬性，這樣就是Car.run()。第二種設計更符合面向對象的設計原則。這正是聲明式API背后的原則，組件對自己負責
• Kube API類似對象的接口，對象對修改封閉，對擴展開放。通過開放的API，用戶可以很容易的實現功能擴展，但是你無法修改已有的組件，你可以開發自定義的組件來替換已有的組件
• 可移植性的設計利用了類似面向對象的多態，同多定義抽象接口PVC，隱藏具體的實現細節。

希望本文的分享能幫助你理解K8s背后的設計原則。