集羣架構設計

Kubernetes 可以管理大規模的集羣，使集羣中的每一個節點彼此連接，能夠像控制一台單一的計算機一樣控制整個集羣。

集羣的節點有兩種角色，一種是 master ，一種是 worker。

• master 是集羣的"大腦"，負責管理整個集羣：像應用的調度、更新、擴縮容等。
• worker 就是具體"幹活"的，它上面事先運行着 docker 服務和 kubelet 服務（ Kubernetes 的一個組件），當接收到 master 下發的"任務"後，Node 就要去完成任務（用 docker 運行一個指定的應用）

ETCD 作為存儲的組件，負責存儲k8s 的所有相關信息。

Scheduler 負責集羣相關資源的調配，通過一系列的算法（預選、優選策略），調度某一個應用具體要運行在哪一個節點上。

ControllerManager 負責所有應用的控制，譬如應用的多副本控制。

ApiServer 是負責集羣的通信，ETCD，Scheduler，ControllerManager 之間的通信都是通過該組件，是操作 kubernetes 的唯一入口。

核心概念

Deployment - 應用管理者

當我們擁有一個 Kubernetes 集羣后，就可以在上面跑我們的應用了，前提是我們的應用必須支持在 docker 中運行，也就是我們要事先準備好docker鏡像。

有了鏡像之後，一般我們會通過Kubernetes的 Deployment 的配置文件去描述應用，比如應用叫什麼名字、使用的鏡像名字、要運行幾個實例、需要多少的內存資源、cpu 資源等等。

有了配置文件就可以通過Kubernetes提供的命令行客户端 - kubectl 去管理這個應用了。kubectl 會跟 Kubernetes 的 master 通過RestAPI通信，最終完成應用的管理。創建應用之後，就由 Kubernetes 來保證我們的應用處於運行狀態，當某個實例運行失敗了或者運行着應用的 Node 突然宕機了，Kubernetes 會自動發現並在新的 Node 上調度一個新的實例，保證我們的應用始終達到我們預期的結果。

Pod - Kubernetes最小調度單位

出於易用性、靈活性、穩定性等的考慮，Kubernetes 提出了一個叫做 Pod 的概念，作為 Kubernetes 的最小調度單位。我們的應用在每個 Node 上運行的其實是一個 Pod。Pod 也只能運行在 Node 上。

那麼什麼是 Pod 呢？Pod 是一組容器（當然也可以只有一個）。容器本身就是一個小盒子了，Pod 相當於在容器上又包了一層小盒子。這個盒子裏面的容器有什麼特點呢？

• 可以共享存儲。
• 有相同的網絡空間，通俗點説就是有一樣的ip地址，有一樣的網卡和網絡設置。
• 多個容器之間可以“瞭解”對方，比如知道其他人的鏡像，知道別人定義的端口等。

其中的 Pause 容器

• 作為根容器，把其他容器link 到一起
• 負責整個pod的監控檢查

至於這樣設計的好處呢，還是要大家深入學習後慢慢體會啦~

ReplicaSet - 管理Pod的組件

kubernetes 官方現在已經弱化了 ReplicaSet 的概念，在實際的操作，我們一般不會接觸到 ReplicaSet，但 Pod 的實際管理是由ReplicaSet負責的。

Service - 服務發現 - 找到每個Pod

上面的 Deployment 創建了，Pod 也運行起來了。如何才能訪問到我們的應用呢？

最直接想到的方法就是直接通過 Pod-ip+port 去訪問，但如果實例數很多呢？好，拿到所有的 Pod-ip 列表，配置到負載均衡器中，輪詢訪問。但上面我們説過，Pod 可能會死掉，甚至 Pod 所在的 Node 也可能宕機，Kubernetes 會自動幫我們重新創建新的Pod。再者每次更新服務的時候也會重建 Pod。而每個 Pod 都有自己的 ip。所以 Pod 的ip 是不穩定的，會經常變化的。

面對這種變化我們就要藉助另一個概念：Service。它就是來專門解決這個問題的。不管Deployment的Pod有多少個，不管它是更新、銷燬還是重建，Service總是能發現並維護好它的ip列表。Service對外也提供了多種入口：

1. ClusterIP：Service 在集羣內的唯一 ip 地址，我們可以通過這個 ip，均衡的訪問到後端的 Pod，而無須關心具體的 Pod。
2. NodePort：Service 會在集羣的每個 Node 上都啓動一個端口，我們可以通過任意Node 的這個端口來訪問到 Pod。
3. LoadBalancer：在 NodePort 的基礎上，藉助公有云環境創建一個外部的負載均衡器，並將請求轉發到 NodeIP:NodePort。
4. ExternalName：將服務通過 DNS CNAME 記錄方式轉發到指定的域名（通過 spec.externlName 設定）。

好，看似服務訪問的問題解決了。但大家有沒有想過，Service是如何知道它負責哪些 Pod 呢？是如何跟蹤這些 Pod 變化的？

最容易想到的方法是使用 Deployment 的名字。一個 Service 對應一個 Deployment 。當然這樣確實可以實現。但k ubernetes 使用了一個更加靈活、通用的設計 - Label 標籤，通過給 Pod 打標籤，Service 可以只負責一個 Deployment 的 Pod 也可以負責多個 Deployment 的 Pod 了。Deployment 和 Service 就可以通過 Label 解耦了。

RollingUpdate - 滾動升級

滾動升級是Kubernetes中最典型的服務升級方案，主要思路是一邊增加新版本應用的實例數，一邊減少舊版本應用的實例數，直到新版本的實例數達到預期，舊版本的實例數減少為0，滾動升級結束。在整個升級過程中，服務一直處於可用狀態。並且可以在任意時刻回滾到舊版本。

參考: https://coding.imooc.com/lear...