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

阿風的架構筆記發表於2021-05-21
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】掃碼即可獲取架構進階學習資料包

相關文章