k8s系列教程2 - 核心概念和架構設計

集羣架構設計

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...