API設計原則
對於雲端計算系統，系統API實際上處於系統設計的統領地位，正如本文前面所說，K8s集
群系統每支援一項新功能，引入一項新技術，一定會新引入對應的API物件，支援對該
功能的管理操作，理解掌握的API，就好比抓住了K8s系統的牛鼻子。K8s系統API的設
計有以下幾條原則：
1.
所有API應該是宣告式的。
正如前文所說，宣告式的操作，相對於命令式操作，對於重複操作的效果是穩定的，這對於容易出現資料丟失或重複的分散式環境來說是很重要的。
另外，宣告式操作更容易被使用者使用，可以使系統向使用者隱藏實現的細節，隱藏實現的細節的同時，也就保留了系統未來持續優化的可能性。
此外，宣告式的API，同時隱含了所有的API物件都是名詞性質的，例如Service、Volume這些API都是名詞，這些名詞描述了使用者所期望得到的一個目標分散式物件
2.
API物件是彼此互補而且可組合的。
這裡面實際是鼓勵API物件儘量實現物件導向設計時的要求，即“高內聚，鬆耦合”，對業務相關的概念有一個合適的分解，提高分解出來的物件的可重用性。
事實上，K8s這種分散式系統管理平臺，也是一種業務系統，只不過它的業務就是排程和管理容器服務。
3.
高層API以操作意圖為基礎設計。
如何能夠設計好API，跟如何能用物件導向的方法設計好應用系統有相通的地方，高層設計一定是從業務出發，而不是過早的從技術實現出發。
因此，針對K8s的高層API設計，一定是以K8s的業務為基礎出發，也就是以系統排程管理容器的操作意圖為基礎設計。
4.
低層API根據高層API的控制需要設計。
設計實現低層API的目的，是為了被高層API使用，考慮減少冗餘、提高重用性的目的，低層API的設計也要以需求為基礎，要儘量抵抗受技術實現影響的誘惑。
5.
儘量避免簡單封裝，不要有在外部API無法顯式知道的內部隱藏的機制。
簡單的封裝，實際沒有提供新的功能，反而增加了對所封裝API的依賴性。
內部隱藏的機制也是非常不利於系統維護的設計方式，例如PetSet和ReplicaSet，本來就是兩種Pod集合，
那麼K8s就用不同API物件來定義它們，而不會說只用同一個設計理念
ReplicaSet，內部通過特殊的演算法再來區分這個ReplicaSet是有狀態的還是無狀態。
6.
API操作複雜度與物件數量成正比。
這一條主要是從系統效能角度考慮，要保證整個系統隨著系統規模的擴大，效能不會迅速變慢到無法使用，那麼最低的限定就是
API的操作複雜度不能超過O(N)，N是物件的數量，否則系統就不具備水平伸縮性了
7.
API物件狀態不能依賴於網路連線狀態。
由於眾所周知，在分散式環境下，網路連線斷開是經常發生的事情，
因此要保證API物件狀態能應對網路的不穩定，API物件的狀態就不能依賴於網路連線狀態。
8.
儘量避免讓操作機制依賴於全域性狀態，因為在分散式系統中要保證全域性狀態的同步是非常困難的。