5分鐘讓你理解K8S必備架構概念，以及網絡模型（上）

寫在前面

在這用XMind畫了一張導圖記錄Redis的學習筆記和一些面試解析（源文件對部分節點有詳細備註和參考資料，歡迎關注個人公衆號：阿風的架構筆記 後臺發送【導圖】拿下載連接， 已經完善更新）：

前言

不少小夥伴學習K8S的時候，會被K8S裏面的概念搞亂了，望而生畏；並且不少文章裏面介紹的時候講的太專業了。今天來幫小夥伴們梳理一下，講的不深刻，目的是幫忙小夥伴更好的理解，各個概念的由來。

架構圖

上圖中，有兩種Node節點，一個是Master、一個是Work。

從字面上來看Work Node就是用來工做的，也就是真正承擔服務的機器節點。如服務A部署到K8S後，它的運行環境就在WorkNode節點。

那麼Master Node是幹嗎用的？小夥伴能夠認爲是用來分配服務到哪一臺work node節點的；能夠理解爲大管家，它會知道現有work node的資源運行狀況，決定服務安排到哪些work nodes上。

在Work Node節點上面有2個重要的組件，一個是Pod、一個是Container；

Pod是K8S的最小單元，它裏面能夠有多個Container。Container就是服務/組件運行的環境。

通常狀況下一個Pod只有一個業務服務Container，而其餘的Container是系統所須要的容器（其實就是一些進程組件，如網絡組件、Volume組件等）。因此通常能夠理解爲咱們的服務就在Pod裏面。

上面只是簡單的介紹了K8S基本的架構，以及核心點。

小夥伴們基本使用，理解到這裏也就能夠了

固然須要深刻了解具體Master和Work節點有哪些組件，以及組件之間的發佈流程是什麼？繼續往下看哦。

Master Node組件

上面中，用戶通常採用kubectl命令，以及dashboard控制檯去操做k8s。全部的操做都是經過API Server組件，須要持久化的就存儲到etcd。Scheduler、Controller Manager組件一直訂閱API Server的變化。

總體流程

如用戶須要建立服務A的3個pod，那總體流程：

1）經過Kubectl提交一個建立RC的請求，該請求經過API Server被寫入etcd中。

2）此時Controller Manager經過API Server的監聽資源變化的接口監聽到這個RC事件，分析以後，發現當前集羣中尚未它所對應的Pod實例，因而根據RC裏的Pod模板定義生成一個Pod對象，經過API Server寫入etcd。

3）接下來，此事件被Scheduler發現，它當即執行一個複雜的調度流程，爲這個新Pod選定一個落戶的Work Node，而後經過API Server講這一結果寫入到etcd中。

4）隨後，目標Work Node上運行的Kubelet進程經過API Server監測到這個「新生的」Pod，並按照它的定義，啓動該Pod。

5）用戶的需求是3個pod；那到底有沒有啓動了3個；是由Controller Manager監控管理的，它會保證資源達到用戶的需求。

etcd

用於持久化存儲集羣中全部的資源對象，如Node、Service、Pod、RC、Namespace等；API Server提供了操做etcd的封裝接口API，這些API基本上都是集羣中資源對象的增刪改查及監聽資源變化的接口。

API Server

提供了資源對象的惟一操做入口，其餘全部組件都必須經過它提供的API來操做資源數據，經過對相關的資源數據「全量查詢」+「變化監聽」，這些組件能夠很「實時」地完成相關的業務功能。

Controller Manager

集羣內部的管理控制中心，其主要目的是實現Kubernetes集羣的故障檢測和恢復的自動化工做，好比根據RC的定義完成Pod的複製或移除，以確保Pod實例數符合RC副本的定義；根據Service與Pod的管理關係，完成服務的Endpoints對象的建立和更新；其餘諸如Node的發現、管理和狀態監控、死亡容器所佔磁盤空間及本地緩存的鏡像文件的清理等工做也是由Controller Manager完成的。

Scheduler

集羣中的調度器，負責Pod在集羣節點中的調度分配。

Work Node組件

上圖右側是Work Node的組件，總體流程

1）kubelet監聽到Api Server的變化後，若是有本work node節點須要建立pod；則會通知Container Runtime組件

2）Container Runtime是管理節點Pod組件，在啓動pod時，若是本地沒有鏡像，則會從docker hub裏面拉取鏡像，啓動容器pod

3）kubelet會把相關信息再傳給Api Server

Kubelet

負責本Node節點上的Pod的建立、修改、監控、刪除等全生命週期管理，同時Kubelet定時「上報」本Node的狀態信息到API Server裏。本質Pod的管理是Container Runtime組件負責的

kube-proxy

實現了Service的代理與軟件模式的負載均衡器，這個是由於pod的網絡ip是常常變化的。這個網絡知識，下一篇文章會介紹

Pod發佈

上面介紹了K8S總體架構流程，如今先從pod開始，一步步引出K8S的其餘概念。

咱們先編輯yaml，定義一個pod對象

apiVersion: v1  #指定api版本，此值必須在kubectl apiversion中
kind: Pod       #指定建立資源的角色/類型
metadata:       #資源的元數據/屬性  
  name: mc-user #資源的名字，在同一個namespace中必須惟一 
spec:           #specification of the resource content 指定該資源的內容
  containers:    #容器定義
    - name: mc-user   #容器的名字  
      image: rainbow/mc-user:1.0.RELEASE    #容器鏡像
複製代碼

咱們經過kubectl命令，來建立這個pod

kubectl apply -f mc-user-pod.yaml
複製代碼

咱們mc-user:1.0.RELEASE的鏡像就是一個web應用，8080端口；可是咱們發現pod啓動後，咱們沒法經過pod的ip地址訪問此web服務

那怎麼才能訪問pod呢？

反向代理

在要解決訪問pod的問題前，咱們先來看看咱們以前是如何部署網站的？

外網訪問咱們內部的網站，通常咱們會在中間部署一個nginx，反向代理咱們的web服務。根據這個思路，K8S體系中也有反向代理這個概念

NodePort Service

K8S中咱們能夠採用類型爲NodePort的Service實現反向代理

K8S的Service不少，其中NodePort Service是提供反向代理的實現

這樣外網就能夠訪問內部的pod了。實現流程：

1）pod須要打上一個Label標籤
2）外部流量請求到NodePort Service，經過Selector 進行路由，
3）NodePort Service根據Label標籤進行路由轉發到後端的Pod
複製代碼

從上面的流程中，其實Service也起到了負載均衡的做用；後端Pod能夠有多個，同時打上相同的Label標籤，Service會路由轉發到其中一個Pod。

Service Type還能夠爲 LoadBalancer、ClusterIP LoadBalancer：這個是部署到雲端（如阿里雲）的時候須要用的，也是反向代理+負載均衡的做用，用做外部訪問K8S內部。ClusterIP：這個Service是K8S集羣內部作反向代理用的

Label與Selector

上圖中有2個pod定義了Label爲app：nginx；1個pod定義了app：apache；

那麼Service的Selector篩選app：nginx，只會路由到nginx的pod。

Service發佈

咱們來編寫一個NodePort Service發佈文件

apiVersion: v1
kind: Service
metadata: 
  name: mc-user
spec: 
  ports:
    - name: http     #通信協議
      port: 8080     #這裏的端口和clusterIP對應，即ip:8080,供內部訪問。
      targetPort: 8080   #端口必定要和container暴露出來的端口對應
      nodePort: 31001  #節點都會開放此端口，此端口供外部調用
  selector:
    app: mc-user  #這裏選擇器必定要選擇容器的標籤
  type: NodePort         #這裏表明是NodePort類型的

複製代碼

nodePort的端口範圍：30000～32767

上面是NodePort Service的yaml文件，咱們還要修改一個以前的Pod的yaml文件

apiVersion: v1  #指定api版本，此值必須在kubectl apiversion中
kind: Pod       #指定建立資源的角色/類型
metadata:       #資源的元數據/屬性  
  name: mc-user #資源的名字，在同一個namespace中必須惟一 
  labels:       #標籤訂義
    app: mc-user  #標籤值
spec:           #specification of the resource content 指定該資源的內容
  containers:    #容器定義
    - name: mc-user   #容器的名字  
      image: rainbow/mc-user:1.0.RELEASE    #容器鏡像
複製代碼

咱們能夠利用kubectl命令去分別執行pod和service的yaml文件；這樣就能夠經過外網直接訪問了。http://localhost:31001端口不要忘了是 nodePort定義的端口哦。

總結

今天介紹了K8S的基本概念，以及架構流程；核心的是小夥伴們須要理解Pod、Service、Labels、Selector的這個組件爲何會產生？他們的解決了是什麼問題？後續會繼續介紹K8S其餘的組件概念，但願可以幫助小夥伴們理解，減小K8S的學習難度；謝謝！！！

看完三件事❤️

​ 若是你以爲這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙： ​

1. 點贊，轉發，有大家的 『點贊和評論』，纔是我創造的動力。
2. 關注公衆號 『 阿風的架構筆記 』，不按期分享原創知識。
3. 同時能夠期待後續文章ing🚀
4. 關注後回覆【666】掃碼便可獲取架構進階學習資料包