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.
盡量避免讓操作機制依賴於全局狀態，因為在分布式系統中要保證全局狀態的同步是非常困難的。