深入剖析Kubernetes

 

　　很多人在學習Kubernetes，但也有很多人抱怨Kubernetes「太複雜了」。 

 

　　這裡的根本問題在於，Kubernetes的定位是「平台的平台」（The Platform for Platform），所以其核心功能、原本服務的對象是基礎平台工程師，而非業務研發人員與運維人員；它的宣告式API設計、CRD Operator系統，也是為了方便基礎平台工程師接入和構建新基礎設施能力而設計的。這就導致作為這些能力的最終使用者——業務人員，實際上跟Kubernetes核心定位之間存在明顯的錯位；而且現有的運維體系和系統，跟Kubernetes之間也存在巨大的鴻溝。所以，首先需要說明的是，本書針對的最主要目標讀者是基礎平台工程師。 

 

　　實際上，與傳統中間件從業務研發視角出發不同，雲原生基礎設施的革命是自底向上的。它始於GoogleBorg/Omega這種比「雲端計算」還要底層的容器基礎設施構建理念，然後逐層向上對底層的計算、儲存、網路進行了統一的抽象，這些抽象就是今天我們所熟知的Pod、NetworkPolicy、Volume等概念。基於基礎設施與生俱來的高門檻和宣告式應用管理理論被接納的速度，直到2019年，社群對Kubernetes的認識才剛剛從「類IaaS基礎設施」、「資源管理與調度」，上升到「運維」這個維度。所以，Kubernetes的「複雜」是與生俱來的，這是一個專注於對底層基礎設施能力進行統一抽象的「能力接入層」的價值所在。而作為基礎平台工程師，你應該接受這種「複雜度」，並利用好這種「複雜度」背後各種精妙的設計，構建出真正面向使用者的上層系統來服務自己的使用者。 

 

　　這也是為何本書會反覆強調Kubernetes作為「標準化基礎設施能力接入層」這個定位和理念，帶著這樣的核心思想去審視和研究Kubernetes中的各種功能，去討論它的基礎模型與核心設計。我們希望透過不斷強調，能夠讓讀者在這個複雜而龐大的項目中抓到主線，真正起到「授之以漁」的效果。 

 

　　最後，希望你在學習完本書之後，能夠理解所謂「宣告式API和控制器模式」的本質是將底層基礎設施能力和運維能力接入Kubernetes的一種手段。而這個手段達成的最終效果就是如今Kubernetes生態中數以千計的外掛程式化能力，讓你能夠基於Kubernetes輕鬆構建出各式各樣、面向使用者的上層平台。 

 

　　我們更加希望的是，你能夠將本書內容「學以致用」，使用Kubernetes打造出下一代「以應用為中心」、高可擴展的雲原生平台系統。我們希望這些平台的使用者真正能夠以使用者視角來描述與部署應用，而不是「強迫」自己成為「Kubernetes專家」。這時候，作為基礎平台工程師，你可能就會更加理解「宣告式API」的真諦：把簡單留給使用者，把複雜留給自己。