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

前言

很多小夥伴學習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的學習難度；謝謝！！！