Kubernetes的前世今生和未來

在深入研究Kubernetes之前，要認識到如果沒有容器的出現，Kubernetes也不會存在。從高層看，容器看上去像虛擬機器，但是最大的區別是容器和其他容器共享主機系統的核心。這是最主要的差異要素，因為容器共享物理主機的OS，所以它們很容易移動。使用者也可以在同一臺主機上啟動比VM數量多得多的容器，因為它們共享核心，庫和二進位制檔案。比如，一個VM的大小大概是20GB，而執行著相同應用程式的容器大概只有200MB。

使用Kubernetes很容易。可以使用REST API來操作Kubernetes所包含的主要元件 。Kubernetes的定位是平臺，但是它包含多個元件，每個都有各自的角色。Master是Kubernetes集群裡的控制服務（也稱為control plane），Master很重要，因為它會API呼叫和其互動的其他元件。叢集單元管理髮生在Master裡，排程服務也在這裡。

Master之下就是Kubernetes工作單元，這裡定義特定工作的物體。既然最終標的是要交付一個應用程式，那麼這些單元還有更多其他的特定功能。

Pod：最基礎的單元是Pod，當指派容器時，容器實際上並不會指派到物理硬體上，相反，容器會被分配到一個Pod裡。Pod通常負責託管服務於單個應用程式的容器。這意味著Pod內的所有容器都能夠共享捲和IP空間，允許它們擴充套件為單個應用程式。

Service（服務）：如果想要構建更為穩健的容器化策略，那麼“服務”的概念就更加重要。服務的功能是資源均衡器，將工作負載在容器間導流。這使得後臺容器可以透過單一穩定的接入點和前端應用程式通訊。這個特性讓使用者更易於使用並且可擴充套件。

Replication Controller（副本控制器）：這些單元的目的是確保在某個時間點，有所需數量的特定容器在執行。比如說突然某個核心出錯了，導致某個容器（多個容器組內的）崩潰了，那麼RC的責任是新啟動一個副本Pod，直至之前的Pod在重啟後恢復為止。一旦之前的Pod啟動並且再次運行了，RC就會殺死副本Pod。

在最基礎的級別上，這些是組成Kubernetes平臺的物體。

想一想我們現在都很熟悉的技術，透過虛擬化類比一下Kubernetes。

雖然Kubernetes並不是市場裡唯一的容器管理平臺（還有Docker Swarm和Mesos），但是它更受歡迎。為什麼呢？從高層看，Kubernetes正獲得關註，因為它提供了這樣一個平臺，容器化的應用程式可以只編寫一次，就能夠在所有型別的雲供應商以及私有雲上執行，無論底層使用的是哪種基礎架構。而且，Kubernetes還在發展，讓開發人員能夠在Kubernetes上執行任意適合的應用程式。Sam Ghods，Box的聯合創始人認為只要是能執行的二進位制檔案，就可以執行在Kubernetes上。

使用Kubernetes，開發人員可以快速部署應用程式，而無需擔心傳統平臺上的諸多風險（想想跨多OS環境的垂直擴充套件），可以隨時擴充套件應用程式，並且更好地分配資源。

硬體使用量的下降是使用Kubernetes帶來的另一個好處。一些公司報告由於容器的輕量天性，以及能夠快速殺死不需要的物體（和傳統架構相比），硬體使用量減少了40-50%。eBay是Kubernetes的支持者和使用者，聲稱自從他們切換了平臺之後，看到了伺服器上overhead的急劇降低[1]。

Kubernetes受到了廣泛的稱贊，但是它也有一些缺點。當第一次使用它做部署（大規模）時，它很複雜，並且很難搭建。它要求具有特定技能的工程師，在現在的行業裡可能很難找到。

第二，Kubernetes作為容器的第三方管理系統。容器技術本身的缺陷和成長之痛會影響到Kubernetes所能夠提供的服務。

Kubernetes欠缺的領域是排程器。預設的Kubernetes排程器依賴於應用程式所有者提供的分配資源的需求，而不管實時使用量。這個方案會加重每個節點上的資源分片情況。

最後，能夠在容器裡執行的工作負載範圍將影響Kubernetes的廣泛使用，但是這並非Kubernetes可以直接解決的問題。比如，很多工程師還不想把“核心”工作負載放到容器裡，因為它可能會崩潰，而容器從設計上就不是為了儲存資料的。常見的實踐是隻在容器裡執行那些崩潰後也不會導致下線時間的應用程式。

相關連結：

1. https://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/