[[387130]]

 目錄

• 前言
• 架構(gòu)圖
• Master Node組件
• Work Node組件
• Pod發(fā)布
• 反向代理
• NodePort Service
• Label與Selector
• Service發(fā)布
• 總結(jié)

前言

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

架構(gòu)圖

5分鐘讓你理解K8S必備架構(gòu)概念，以及網(wǎng)絡(luò)模型(一)

上圖中，有兩種Node節(jié)點(diǎn)，一個(gè)是Master、一個(gè)是Work。

從字面上來看Work Node就是用來工作的，也就是真正承擔(dān)服務(wù)的機(jī)器節(jié)點(diǎn)。如服務(wù)A部署到K8S后，它的運(yùn)行環(huán)境就在WorkNode節(jié)點(diǎn)。

那么Master Node是干嘛用的?小伙伴可以認(rèn)為是用來分配服務(wù)到哪一臺(tái)work node節(jié)點(diǎn)的;可以理解為大管家，它會(huì)知道現(xiàn)有work node的資源運(yùn)行情況，決定服務(wù)安排到哪些work nodes上。

在Work Node節(jié)點(diǎn)上面有2個(gè)重要的組件，一個(gè)是Pod、一個(gè)是Container;

Pod是K8S的最小單元，它里面可以有多個(gè)Container。

Container就是服務(wù)/組件運(yùn)行的環(huán)境。

一般情況下一個(gè)Pod只有一個(gè)業(yè)務(wù)服務(wù)Container，而其他的Container是系統(tǒng)所需要的容器(其實(shí)就是一些進(jìn)程組件，如網(wǎng)絡(luò)組件、Volume組件等)。所以一般可以理解為我們的服務(wù)就在Pod里面

上面只是簡單的介紹了K8S基本的架構(gòu)，以及核心點(diǎn)

小伙伴們基本使用，理解到這里也就可以了

當(dāng)然需要深入了解具體Master和Work節(jié)點(diǎn)有哪些組件，以及組件之間的發(fā)布流程是什么?繼續(xù)往下看哦

Master Node組件

上面中，用戶一般采用kubectl命令，以及dashboard控制臺(tái)去操作k8s。所有的操作都是通過API Server組件，需要持久化的就存儲(chǔ)到etcd。Scheduler、Controller Manager組件一直訂閱API Server的變化。

整體流程

如用戶需要?jiǎng)?chuàng)建服務(wù)A的3個(gè)pod，那整體流程：

1)通過Kubectl提交一個(gè)創(chuàng)建RC的請求，該請求通過API Server被寫入etcd中

2)此時(shí)Controller Manager通過API Server的監(jiān)聽資源變化的接口監(jiān)聽到這個(gè)RC事件，分析之后，發(fā)現(xiàn)當(dāng)前集群中還沒有它所對應(yīng)的Pod實(shí)例，于是根據(jù)RC里的Pod模板定義生成一個(gè)Pod對象，通過API Server寫入etcd

3)接下來，此事件被Scheduler發(fā)現(xiàn)，它立即執(zhí)行一個(gè)復(fù)雜的調(diào)度流程，為這個(gè)新Pod選定一個(gè)落戶的Work Node，然后通過API Server講這一結(jié)果寫入到etcd中

4)隨后，目標(biāo)Work Node上運(yùn)行的Kubelet進(jìn)程通過API Server監(jiān)測到這個(gè)“新生的”Pod，并按照它的定義，啟動(dòng)該P(yáng)od。

5)用戶的需求是3個(gè)pod;那到底有沒有啟動(dòng)了3個(gè);是由Controller Manager監(jiān)控管理的，它會(huì)保證資源達(dá)到用戶的需求。

etcd

用于持久化存儲(chǔ)集群中所有的資源對象，如Node、Service、Pod、RC、Namespace等;API Server提供了操作etcd的封裝接口API，這些API基本上都是集群中資源對象的增刪改查及監(jiān)聽資源變化的接口。

API Server

提供了資源對象的唯一操作入口，其他所有組件都必須通過它提供的API來操作資源數(shù)據(jù)，通過對相關(guān)的資源數(shù)據(jù)“全量查詢”+“變化監(jiān)聽”，這些組件可以很“實(shí)時(shí)”地完成相關(guān)的業(yè)務(wù)功能。

Controller Manager

集群內(nèi)部的管理控制中心，其主要目的是實(shí)現(xiàn)Kubernetes集群的故障檢測和恢復(fù)的自動(dòng)化工作，比如根據(jù)RC的定義完成Pod的復(fù)制或移除，以確保Pod實(shí)例數(shù)符合RC副本的定義;根據(jù)Service與Pod的管理關(guān)系，完成服務(wù)的Endpoints對象的創(chuàng)建和更新;其他諸如Node的發(fā)現(xiàn)、管理和狀態(tài)監(jiān)控、死亡容器所占磁盤空間及本地緩存的鏡像文件的清理等工作也是由Controller Manager完成的。

Scheduler

集群中的調(diào)度器，負(fù)責(zé)Pod在集群節(jié)點(diǎn)中的調(diào)度分配。

Work Node組件

上圖右側(cè)是Work Node的組件，整體流程

1)kubelet監(jiān)聽到Api Server的變化后，如果有本work node節(jié)點(diǎn)需要?jiǎng)?chuàng)建pod;則會(huì)通知Container Runtime組件

2)Container Runtime是管理節(jié)點(diǎn)Pod組件，在啟動(dòng)pod時(shí)，如果本地沒有鏡像，則會(huì)從docker hub里面拉取鏡像，啟動(dòng)容器pod

3)kubelet會(huì)把相關(guān)信息再傳給Api Server

Kubelet

負(fù)責(zé)本Node節(jié)點(diǎn)上的Pod的創(chuàng)建、修改、監(jiān)控、刪除等全生命周期管理，同時(shí)Kubelet定時(shí)“上報(bào)”本Node的狀態(tài)信息到API Server里。

本質(zhì)Pod的管理是Container Runtime組件負(fù)責(zé)的

kube-proxy

實(shí)現(xiàn)了Service的代理與軟件模式的負(fù)載均衡器，這個(gè)是因?yàn)閜od的網(wǎng)絡(luò)ip是經(jīng)常變化的。這個(gè)網(wǎng)絡(luò)知識(shí)，下一篇文章老顧會(huì)介紹

Pod發(fā)布

上面介紹了K8S整體架構(gòu)流程，現(xiàn)在老顧先從pod開始，一步步引出K8S的其他概念。

我們先編輯yaml，定義一個(gè)pod對象

apiVersion: v1  #指定api版本，此值必須在kubectl apiversion中 
kind: Pod       #指定創(chuàng)建資源的角色/類型 
metadata:       #資源的元數(shù)據(jù)/屬性   
  name: mc-user #資源的名字，在同一個(gè)namespace中必須唯一  
spec:           #specification of the resource content 指定該資源的內(nèi)容 
  containers:    #容器定義 
    - name: mc-user   #容器的名字   
      image: rainbow/mc-user:1.0.RELEASE    #容器鏡像 

我們通過kubectl命令，來創(chuàng)建這個(gè)pod

kubectl apply -f mc-user-pod.yaml 

我們mc-user:1.0.RELEASE的鏡像就是一個(gè)web應(yīng)用，8080端口;但是我們發(fā)現(xiàn)pod啟動(dòng)后，我們無法通過pod的ip地址訪問此web服務(wù)

那怎么才能訪問pod呢?

反向代理

在要解決訪問pod的問題前，我們先來看看我們之前是如何部署網(wǎng)站的?

外網(wǎng)訪問我們內(nèi)部的網(wǎng)站，一般我們會(huì)在中間部署一個(gè)nginx，反向代理我們的web服務(wù)。根據(jù)這個(gè)思路，K8S體系中也有反向代理這個(gè)概念

NodePort Service

K8S中我們可以采用類型為NodePort的Service實(shí)現(xiàn)反向代理

K8S的Service很多，其中NodePort Service是提供反向代理的實(shí)現(xiàn)

這樣外網(wǎng)就可以訪問內(nèi)部的pod了。實(shí)現(xiàn)流程：

• 1)pod需要打上一個(gè)Label標(biāo)簽
• 2)外部流量請求到NodePort Service，通過Selector 進(jìn)行路由，
• 3)NodePort Service根據(jù)Label標(biāo)簽進(jìn)行路由轉(zhuǎn)發(fā)到后端的Pod

從上面的流程中，其實(shí)Service也起到了負(fù)載均衡的作用;后端Pod可以有多個(gè)，同時(shí)打上相同的Label標(biāo)簽，Service會(huì)路由轉(zhuǎn)發(fā)到其中一個(gè)Pod

• Service Type還可以為 LoadBalancer、ClusterIP
• LoadBalancer：這個(gè)是部署到云端(如阿里云)的時(shí)候需要用的，也是反向代理+負(fù)載均衡的作用，用作外部訪問K8S內(nèi)部。
• ClusterIP：這個(gè)Service是K8S集群內(nèi)部做反向代理用的

Label與Selector

上圖中有2個(gè)pod定義了Label為app：nginx;1個(gè)pod定義了app：apache;

那么Service的Selector篩選app：nginx，只會(huì)路由到nginx的pod。

Service發(fā)布

我們來編寫一個(gè)NodePort Service發(fā)布文件

apiVersion: v1 
kind: Service 
metadata:  
  name: mc-user 
spec:  
  ports: 
    - name: http     #通訊協(xié)議 
      port: 8080     #這里的端口和clusterIP對應(yīng)，即ip:8080,供內(nèi)部訪問。 
      targetPort: 8080   #端口一定要和container暴露出來的端口對應(yīng) 
      nodePort: 31001  #節(jié)點(diǎn)都會(huì)開放此端口，此端口供外部調(diào)用 
  selector: 
    app: mc-user  #這里選擇器一定要選擇容器的標(biāo)簽 
  type: NodePort         #這里代表是NodePort類型的 
nodePort的端口范圍：30000～32767 

上面是NodePort Service的yaml文件，我們還要修改一個(gè)之前的Pod的yaml文件

apiVersion: v1  #指定api版本，此值必須在kubectl apiversion中 
kind: Pod       #指定創(chuàng)建資源的角色/類型 
metadata:       #資源的元數(shù)據(jù)/屬性   
  name: mc-user #資源的名字，在同一個(gè)namespace中必須唯一  
  labels:       #標(biāo)簽定義 
    app: mc-user  #標(biāo)簽值 
spec:           #specification of the resource content 指定該資源的內(nèi)容 
  containers:    #容器定義 
    - name: mc-user   #容器的名字   
      image: rainbow/mc-user:1.0.RELEASE    #容器鏡像 

我們可以利用kubectl命令去分別執(zhí)行pod和service的yaml文件;這樣就可以通過外網(wǎng)直接訪問了。http://localhost:31001 端口不要忘了是 nodePort定義的端口哦

總結(jié)

今天老顧介紹了K8S的基本概念，以及架構(gòu)流程;核心的是小伙伴們需要理解Pod、Service、Labels、Selector的這個(gè)組件為什么會(huì)產(chǎn)生?他們的解決了是什么問題?后續(xù)老顧會(huì)繼續(xù)介紹K8S其他的組件概念，希望能夠幫助小伙伴們理解，減少K8S的學(xué)習(xí)難度;謝謝!!!