[[387130]]

 目錄

• 前言
• 架構圖
• Master Node組件
• Work Node組件
• Pod發布
• 反向代理
• NodePort Service
• Label與Selector
• Service發布
• 總結

前言

很多小伙伴學習K8S的時候，會被K8S里面的概念搞亂了，望而生畏;而且很多文章里面介紹的時候講的太專業了。老顧今天來幫小伙伴們梳理一下，講的不深入，目的是幫忙小伙伴更好的理解，各個概念的由來。

架構圖

5分鐘讓你理解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的學習難度;謝謝!!!