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

  • 2021 年 5 月 21 日
  • 筆記

寫在前面

在這用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文件；這樣就可以通過外網直接訪問了。//localhost:31001埠不要忘了是 nodePort定義的埠哦。

總結

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

看完三件事❤️

​
如果你覺得這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：
​

  1. 點贊，轉發，有你們的 『點贊和評論』，才是我創造的動力。
  2. 關注公眾號 『 阿風的架構筆記 』，不定期分享原創知識。
  3. 同時可以期待後續文章ing🚀
  4. 關注後回復【666】掃碼即可獲取架構進階學習資料包

VirMach 便宜 VPS

QNews

QNews