kubernetes是什么，為什么上手這么難？

Kubernetes是一個基于容器技術的分布式集群管理系統。它是谷歌在大規模應用容器技術方面數十年經驗的實際成果。因此，支持大規模的集群管理承載著非常多的組件，分布式本身的復雜度非常高。

Kubernetes到底有什么？

接下來我們一步步來看看Kubernetes到底有什么？

首先，既然是分布式系統，那么肯定有多個Node節點（物理主機或者虛擬機），它們共同構成了一個分布式集群，而這些節點之間會有一個Master節點，統一管理Node節點。如圖所示：

問題1：Master節點和Worker節點如何通信？

首先，當Master節點啟動時，會運行一個Kube-apiserver進程，它提供了集群管理的API接口，是集群中各個功能模塊之間進行數據交互和通信的中心樞紐，同時也提供了一個完善的集群安全機制。

在Node節點上，利用Kubernetes中的kubelet組件，每個Node節點上都會運行一個kubelet進程，負責向Master匯報本節點的運行狀態，如Node節點注冊、終止、定期健康報告等等，并接收來自Master的命令并創建相應的Pod。

在Kubernetes中，Pod是最基本的運行單元。它與Docker容器略有不同，因為Pod中可能包含一個或多個容器（可以是Docker容器），這些容器內部共享網絡資源，即可以通過localhost相互訪問。

關于如何在Pod中實現網絡共享，每個Pod啟動，內部都會啟動一個pause容器（谷歌的image）。它使用默認的網絡模式，其他容器的網絡設置為它，完成網絡共享問題。

如圖所示：

問題2：Master如何將Pod調度到指定的Node上？

這項工作由Kube-scheduler完成。整個調度過程通過執行一系列復雜的算法，最終為每個Pod計算出一個最優的目標Node，這是由Kube-scheduler進程自動完成的。

最常見的是循環調度（RR）。當然也有可能我們需要將Pod調度到指定的Node上。我們可以通過將節點的標簽（Label）與Pod的節點選擇器屬性進行匹配來達到指定的效果。

如圖所示：

問題3：各個節點和Pod的信息統一在哪里維護，誰來維護？

從上面的Pod調度來看，我們必須有一個存儲中心來存儲每個節點的每個Pod的資源使用情況、健康狀態和基本信息，這樣Pod調度才能正常進行。

在Kubernetes中，etcd組件被用作高可用和一致的存儲庫。該組件可以內置在Kubernetes中，也可以外部構建供Kubernetes使用。

集群上的所有配置信息都存儲在etcd中。考慮到各個組件的相對獨立性和整體的可維護性，這些存儲的數據的增刪改查都是統一由Kube-apiserver來調用的，并且apiserver還提供了REST支持，不僅為各個內部組件提供服務但也向集群外的用戶公開服務。

外部用戶可以通過REST接口或kubectl命令行工具管理集群，該工具內部與apiserver通信。

如圖所示：

問題4：外部用戶如何訪問集群中運行的Pod？

前面我們講了外部用戶如何管理Kubernetes，但我們更關心的是內部運行的Pod如何對外訪問。

用過Docker的同學應該都知道，如果使用bridge模式，在創建容器的時候會分配一個虛擬IP，外部無法訪問該IP。我們需要做一層端口映射，將容器中的端口映射到宿主機的端口Map并綁定，這樣外部就可以通過訪問宿主機的指定端口來訪問容器內部的端口。

那么，Kubernetes的外部訪問也是這樣實現的嗎？答案是否定的，Kubernetes中的情況更加復雜。因為上面說的Docker是單機模式，一個容器對外暴露一個服務。在分布式集群中，服務往往由多個應用提供，以分擔訪問壓力，而這些應用可能分布在多個節點上，這就涉及到跨主機通信。

這里Kubernetes引入了Service的概念，將多個相同的Pod包裝成一個完整的服務，對外提供服務。至于獲取這些相同的Pod，每個Pod在啟動時都會設置labels為attribute。

在服務中，我們傳遞選擇器Selector，選擇與整體服務具有相同Name標簽屬性的Pod，將服務信息通過Apiserver存儲到etcd中，由Service Controller完成。同時在每個節點上啟動一個kube-proxy進程，負責從服務地址到Pod地址的代理和負載均衡。

如圖所示：

問題5：Pod如何動態擴容和伸縮？

既然我們知道服務是由Pod組成的，那么服務的擴展也意味著Pod的擴展。通俗地說，就是在需要的時候將Pod做多個副本，在不需要的時候將Pod縮減到指定的副本數。

在Kubernetes中，使用Replication Controller進行管理，為每個Pod設置一個預期的副本數。當實際副本數量不符合預期時，動態調整數量以達到預期值。所需值可以由我們手動更新，也可以由自動縮放代理更新。如圖所示：

問題6：各個組件如何協同工作？

最后說一下Kube-controller-manager進程的作用。我們知道ectd是作為集群數據的存儲中心，而apiserver是用來管理數據中心，充當其他進程與數據中心通信的橋梁。

Service Controller和Replication Controller由Kube-controller-manager管理。作為一個守護進程，每個Controller都是一個控制回路，通過apiserver監控集群的共享狀態，并嘗試將實際狀態中不符合預期的變化。關于Controller，管理器還包括Node Controller、ResourceQuota Controller、Namespace Controller等。

如圖所示：

總結

本文通過問答的方式不涉及任何深入的實現細節。從整體的角度，從概念上介紹了Kubernetes涉及的基本概念。

編輯：黃飛

?