5分鐘讓你理解K8S必備架構(gòu)概念，以及網(wǎng)絡(luò)模型
目錄
- 前言
- 架構(gòu)圖
- Master Node組件
- Work Node組件
- Pod發(fā)布
- 反向代理
- NodePort Service
- Label與Selector
- Service發(fā)布
- 總結(jié)
前言
很多小伙伴學(xué)習(xí)K8S的時(shí)候，會(huì)被K8S里面的概念搞亂了，望而生畏;而且很多文章里面介紹的時(shí)候講的太專業(yè)了。老顧今天來(lái)幫小伙伴們梳理一下，講的不深入，目的是幫忙小伙伴更好的理解，各個(gè)概念的由來(lái)。
架構(gòu)圖
5分鐘讓你理解K8S必備架構(gòu)概念，以及網(wǎng)絡(luò)模型(一)
上圖中，有兩種Node節(jié)點(diǎn)，一個(gè)是Master、一個(gè)是Work。
從字面上來(lái)看Work Node就是用來(lái)工作的，也就是真正承擔(dān)服務(wù)的機(jī)器節(jié)點(diǎn)。如服務(wù)A部署到K8S后，它的運(yùn)行環(huán)境就在WorkNode節(jié)點(diǎn)。
那么Master Node是干嘛用的?小伙伴可以認(rèn)為是用來(lái)分配服務(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里面
上面只是簡(jiǎn)單的介紹了K8S基本的架構(gòu)，以及核心點(diǎn)
小伙伴們基本使用，理解到這里也就可以了
當(dāng)然需要深入了解具體Master和Work節(jié)點(diǎn)有哪些組件，以及組件之間的發(fā)布流程是什么?繼續(xù)往下看哦
Master Node組件
上面中，用戶一般采用kubectl命令，以及dashboard控制臺(tái)去操作k8s。所有的操作都是通過(guò)API Server組件，需要持久化的就存儲(chǔ)到etcd。Scheduler、Controller Manager組件一直訂閱API Server的變化。
整體流程
如用戶需要?jiǎng)?chuàng)建服務(wù)A的3個(gè)pod，那整體流程：
1)通過(guò)Kubectl提交一個(gè)創(chuàng)建RC的請(qǐng)求，該請(qǐng)求通過(guò)API Server被寫(xiě)入etcd中
2)此時(shí)Controller Manager通過(guò)API Server的監(jiān)聽(tīng)資源變化的接口監(jiān)聽(tīng)到這個(gè)RC事件，分析之后，發(fā)現(xiàn)當(dāng)前集群中還沒(méi)有它所對(duì)應(yīng)的Pod實(shí)例，于是根據(jù)RC里的Pod模板定義生成一個(gè)Pod對(duì)象，通過(guò)API Server寫(xiě)入etcd
3)接下來(lái)，此事件被Scheduler發(fā)現(xiàn)，它立即執(zhí)行一個(gè)復(fù)雜的調(diào)度流程，為這個(gè)新Pod選定一個(gè)落戶的Work Node，然后通過(guò)API Server講這一結(jié)果寫(xiě)入到etcd中
4)隨后，目標(biāo)Work Node上運(yùn)行的Kubelet進(jìn)程通過(guò)API Server監(jiān)測(cè)到這個(gè)“新生的”Pod，并按照它的定義，啟動(dòng)該P(yáng)od。
5)用戶的需求是3個(gè)pod;那到底有沒(méi)有啟動(dòng)了3個(gè);是由Controller Manager監(jiān)控管理的，它會(huì)保證資源達(dá)到用戶的需求。
etcd
用于持久化存儲(chǔ)集群中所有的資源對(duì)象，如Node、Service、Pod、RC、Namespace等;API Server提供了操作etcd的封裝接口API，這些API基本上都是集群中資源對(duì)象的增刪改查及監(jiān)聽(tīng)資源變化的接口。
API Server
提供了資源對(duì)象的唯一操作入口，其他所有組件都必須通過(guò)它提供的API來(lái)操作資源數(shù)據(jù)，通過(guò)對(duì)相關(guān)的資源數(shù)據(jù)“全量查詢”+“變化監(jiān)聽(tīng)”，這些組件可以很“實(shí)時(shí)”地完成相關(guān)的業(yè)務(wù)功能。
Controller Manager
集群內(nèi)部的管理控制中心，其主要目的是實(shí)現(xiàn)Kubernetes集群的故障檢測(cè)和恢復(fù)的自動(dòng)化工作，比如根據(jù)RC的定義完成Pod的復(fù)制或移除，以確保Pod實(shí)例數(shù)符合RC副本的定義;根據(jù)Service與Pod的管理關(guān)系，完成服務(wù)的Endpoints對(duì)象的創(chuàng)建和更新;其他諸如Node的發(fā)現(xiàn)、管理和狀態(tài)監(jiān)控、死亡容器所占磁盤(pán)空間及本地緩存的鏡像文件的清理等工作也是由Controller Manager完成的。
Scheduler
集群中的調(diào)度器，負(fù)責(zé)Pod在集群節(jié)點(diǎn)中的調(diào)度分配。
Work Node組件
上圖右側(cè)是Work Node的組件，整體流程
1)kubelet監(jiān)聽(tīng)到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í)，如果本地沒(méi)有鏡像，則會(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開(kāi)始，一步步引出K8S的其他概念。
我們先編輯yaml，定義一個(gè)pod對(duì)象
- 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 #容器鏡像
我們通過(guò)kubectl命令，來(lái)創(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)后，我們無(wú)法通過(guò)pod的ip地址訪問(wèn)此web服務(wù)
那怎么才能訪問(wèn)pod呢?
反向代理
在要解決訪問(wèn)pod的問(wèn)題前，我們先來(lái)看看我們之前是如何部署網(wǎng)站的?
外網(wǎng)訪問(wèn)我們內(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)就可以訪問(wèn)內(nèi)部的pod了。實(shí)現(xiàn)流程：
- 1)pod需要打上一個(gè)Label標(biāo)簽
- 2)外部流量請(qǐng)求到NodePort Service，通過(guò)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ù)載均衡的作用，用作外部訪問(wèn)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ā)布
我們來(lái)編寫(xiě)一個(gè)NodePort Service發(fā)布文件
- apiVersion: v1
- kind: Service
- metadata:
- name: mc-user
- spec:
- ports:
- - name: http #通訊協(xié)議
- port: 8080 #這里的端口和clusterIP對(duì)應(yīng)，即ip:8080,供內(nèi)部訪問(wèn)。
- targetPort: 8080 #端口一定要和container暴露出來(lái)的端口對(duì)應(yīng)
- nodePort: 31001 #節(jié)點(diǎn)都會(huì)開(kāi)放此端口，此端口供外部調(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文件;這樣就可以通過(guò)外網(wǎng)直接訪問(wèn)了。http://localhost:31001 端口不要忘了是 nodePort定義的端口哦
總結(jié)
今天老顧介紹了K8S的基本概念，以及架構(gòu)流程;核心的是小伙伴們需要理解Pod、Service、Labels、Selector的這個(gè)組件為什么會(huì)產(chǎn)生?他們的解決了是什么問(wèn)題?后續(xù)老顧會(huì)繼續(xù)介紹K8S其他的組件概念，希望能夠幫助小伙伴們理解，減少K8S的學(xué)習(xí)難度;謝謝!!!
