啥是kubernetes？

眾所周知，kubernetes(以下簡稱k8s)是google基於Blog進行改進後，開源出來的一款“容器管理應用”。由於近幾年來容器技術的火爆，許許多多的服務都不會直接部署在linux主機或各大雲廠商的虛擬機器上；利用Docker，將每個服務做成一個Image，把他們跑在各自的Container中。

這樣做的好處有非常多，比如環境配置隔離、服務啟動快、移植便捷等等。但是使用的Container多到一定程度，就會帶來容器管理上的問題：使用docker ps命令之後有一大堆Container，如果標識的不清楚也很容易混淆；某些分散式服務，需要將Docker部署到許多不同的機器上，這也會增加我們運維的難度。因此，我們現在需要一款“專門管理容器”的平臺，為我們提供視覺化介面，方便我們對各個容器進行管理。

k8s就是這樣一款輔助我們管理容器的平臺，支援管理在分散式環境(即多臺伺服器上)啟動的Container。有了他，再也不用愁容器多的管理不過來了、或者找不到容器在不同主機上的位置了！

kubernetes的基本概念和架構示意

k8s的基礎架構示意圖如下：

我們分別來理解這幅架構圖示意圖中的一些概念：

Kubernetes Master / Node : 如果大家對諸如hadoop這樣的分散式叢集有所瞭解，就會發現k8s的設計理念和其他分散式架構的非常類似的：Master節點負責接收使用者的指令、分配任務以及記錄各個node的情況；而node節點負責接收Master的指令，啟動相應的Pod（k8s的最小執行單元，是一個Container的集合)。

安裝k8s時會指定Master和Node節點，部署好之後，我們通過k8s的api與Master節點進行互動。Master節點收到了我們的指令(比如新啟動一個Pod)，會排程Node節點去完成它們。當然，其中底層的排程策略、具體的實現細節對於我們使用者來說都是隱蔽的，不需要我們去了解。

Container : 容器。由於k8s是容器管理平臺，因此如果你使用k8s管理Docker的容器的話，那麼這裡的Container就是Docker的Container。作為啟動一個元件的最小單元（比如我可以用一個Container啟動一個mysql ，另一個Container啟動一個tomcat。而mysql和tomcat的各種配置檔案都在它們自己的Container中，因此不會相互干擾，也不會汙染linux主機的配置環境。）。

Pod : 一組Container的集合，是k8s中最小的執行單元。由於一個服務往往是要基於許許多多的元件才能完成的，因此一個Pod就是“能夠完整執行這個服務”的最小個體，也是k8s將其指定為原子單元的初衷（比如我要啟動一個簡單的網站服務，至少需要一個tomcat、一個mysql以及我自己編寫的網站業務流程程式。因此在k8s中，我就會啟動一個Pod，這個Pod中包含三個Container，每個Container包含了它們相應的元件。）。每個Pod中的所有Container是共享IP地址和檔案系統的，這點要特別注意。

原意是“豌豆莢”，我覺得這個比喻很形象。每個容器就像豌豆一樣，而Pod就像豌豆莢一樣把它們包住，使之成為一個整體。

ReplicaSet : 用於指定每個Pod的備份數量。由於k8s採用的是分散式架構，為了保證高可靠性，萬一哪臺node節點突然宕機了，也必須要保證我的網站服務能夠正常執行；因此，每個Pod都會被複製成3份(預設設定3份)，執行在不同的node節點上。ReplicaSet就是用來管理Pod備份數量，保證高可靠性的元件。

Service : 用於各種資訊的抽象（這是個抽象概念，理解起來比較難，回頭我再總結一個k8s的工作流程，大家就能更清楚地理解啦）。

Label : 每個Pod的唯一識別符號，資訊會存在etcd資料庫中。Service就是通過這個識別各個Pod誰是誰的。就像工號一樣。

kubelet : 每個node節點都有一個，用於啟動、管理和監測各個node中Pod。k8s會將所有的容器資訊記錄在etcd資料庫中，kubelet就是不斷地去資料庫中檢視這些Pod的資訊，保證其與node中實際執行的情況相同。我的理解，kubelet就類似於每個工地裡工頭兒的角色，負責具體派活兒和監督。

kube-proxy : 在k8s中，每個node都用自己的一個IP地址。而kube-proxy就是負責每個node與其他node或Matser節點通訊的樞紐。資訊的流入和流出、請求的轉發都是通過kube-proxy進行操作的。

以上，就是k8s中的一些基本概念。由於是初學k8s，其中部分概念包含了我自己的個人理解，如果有錯誤歡迎各位大牛在留言區批評指正。謝謝！