建站
咨詢
售后
建站咨詢
新聞中心
目錄
創(chuàng)新互聯(lián)憑借在網(wǎng)站建設(shè)、網(wǎng)站推廣領(lǐng)域領(lǐng)先的技術(shù)能力和多年的行業(yè)經(jīng)驗(yàn)，為客戶提供超值的營銷型網(wǎng)站建設(shè)服務(wù)，我們始終認(rèn)為：好的營銷型網(wǎng)站就是好的業(yè)務(wù)員。我們已成功為企業(yè)單位、個人等客戶提供了成都做網(wǎng)站、網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè)服務(wù)，以良好的商業(yè)信譽(yù)，完善的服務(wù)及深厚的技術(shù)力量處于同行領(lǐng)先地位。
- 前言
- 架構(gòu)圖
- Master Node組件
- Work Node組件
- Pod發(fā)布
- 反向代理
- NodePort Service
- Label與Selector
- Service發(fā)布
- 總結(jié)
前言
很多小伙伴學(xué)習(xí)K8S的時候，會被K8S里面的概念搞亂了，望而生畏;而且很多文章里面介紹的時候講的太專業(yè)了。老顧今天來幫小伙伴們梳理一下，講的不深入，目的是幫忙小伙伴更好的理解，各個概念的由來。
架構(gòu)圖
5分鐘讓你理解K8S必備架構(gòu)概念，以及網(wǎng)絡(luò)模型(一)
上圖中，有兩種Node節(jié)點(diǎn)，一個是Master、一個是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ù)到哪一臺work node節(jié)點(diǎn)的;可以理解為大管家，它會知道現(xiàn)有work node的資源運(yùn)行情況，決定服務(wù)安排到哪些work nodes上。
在Work Node節(jié)點(diǎn)上面有2個重要的組件，一個是Pod、一個是Container;
Pod是K8S的最小單元，它里面可以有多個Container。
Container就是服務(wù)/組件運(yùn)行的環(huán)境。
一般情況下一個Pod只有一個業(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控制臺去操作k8s。所有的操作都是通過API Server組件，需要持久化的就存儲到etcd。Scheduler、Controller Manager組件一直訂閱API Server的變化。
整體流程
如用戶需要創(chuàng)建服務(wù)A的3個pod，那整體流程：
1)通過Kubectl提交一個創(chuàng)建RC的請求，該請求通過API Server被寫入etcd中
2)此時Controller Manager通過API Server的監(jiān)聽資源變化的接口監(jiān)聽到這個RC事件，分析之后，發(fā)現(xiàn)當(dāng)前集群中還沒有它所對應(yīng)的Pod實(shí)例，于是根據(jù)RC里的Pod模板定義生成一個Pod對象，通過API Server寫入etcd
3)接下來，此事件被Scheduler發(fā)現(xiàn)，它立即執(zhí)行一個復(fù)雜的調(diào)度流程，為這個新Pod選定一個落戶的Work Node，然后通過API Server講這一結(jié)果寫入到etcd中
4)隨后，目標(biāo)Work Node上運(yùn)行的Kubelet進(jìn)程通過API Server監(jiān)測到這個“新生的”Pod，并按照它的定義，啟動該P(yáng)od。
5)用戶的需求是3個pod;那到底有沒有啟動了3個;是由Controller Manager監(jiān)控管理的，它會保證資源達(dá)到用戶的需求。
etcd
用于持久化存儲集群中所有的資源對象，如Node、Service、Pod、RC、Namespace等;API Server提供了操作etcd的封裝接口API，這些API基本上都是集群中資源對象的增刪改查及監(jiān)聽資源變化的接口。
API Server
提供了資源對象的唯一操作入口，其他所有組件都必須通過它提供的API來操作資源數(shù)據(jù)，通過對相關(guān)的資源數(shù)據(jù)“全量查詢”+“變化監(jiān)聽”，這些組件可以很“實(shí)時”地完成相關(guān)的業(yè)務(wù)功能。
Controller Manager
集群內(nèi)部的管理控制中心，其主要目的是實(shí)現(xiàn)Kubernetes集群的故障檢測和恢復(fù)的自動化工作，比如根據(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)需要創(chuàng)建pod;則會通知Container Runtime組件
2)Container Runtime是管理節(jié)點(diǎn)Pod組件，在啟動pod時，如果本地沒有鏡像，則會從docker hub里面拉取鏡像，啟動容器pod
3)kubelet會把相關(guān)信息再傳給Api Server
Kubelet
負(fù)責(zé)本Node節(jié)點(diǎn)上的Pod的創(chuàng)建、修改、監(jiān)控、刪除等全生命周期管理，同時Kubelet定時“上報”本Node的狀態(tài)信息到API Server里。
本質(zhì)Pod的管理是Container Runtime組件負(fù)責(zé)的
kube-proxy
實(shí)現(xiàn)了Service的代理與軟件模式的負(fù)載均衡器，這個是因?yàn)閜od的網(wǎng)絡(luò)ip是經(jīng)常變化的。這個網(wǎng)絡(luò)知識，下一篇文章老顧會介紹
Pod發(fā)布
上面介紹了K8S整體架構(gòu)流程，現(xiàn)在老顧先從pod開始，一步步引出K8S的其他概念。
我們先編輯yaml，定義一個pod對象
- apiVersion: v1 #指定api版本，此值必須在kubectl apiversion中
- kind: Pod #指定創(chuàng)建資源的角色/類型
- metadata: #資源的元數(shù)據(jù)/屬性
- name: mc-user #資源的名字，在同一個namespace中必須唯一
- spec: #specification of the resource content 指定該資源的內(nèi)容
- containers: #容器定義
- - name: mc-user #容器的名字
- image: rainbow/mc-user:1.0.RELEASE #容器鏡像
我們通過kubectl命令，來創(chuàng)建這個pod
- kubectl apply -f mc-user-pod.yaml
我們mc-user:1.0.RELEASE的鏡像就是一個web應(yīng)用，8080端口;但是我們發(fā)現(xiàn)pod啟動后，我們無法通過pod的ip地址訪問此web服務(wù)
那怎么才能訪問pod呢?
反向代理
在要解決訪問pod的問題前，我們先來看看我們之前是如何部署網(wǎng)站的?
外網(wǎng)訪問我們內(nèi)部的網(wǎng)站，一般我們會在中間部署一個nginx，反向代理我們的web服務(wù)。根據(jù)這個思路，K8S體系中也有反向代理這個概念
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需要打上一個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可以有多個，同時打上相同的Label標(biāo)簽，Service會路由轉(zhuǎn)發(fā)到其中一個Pod
- Service Type還可以為 LoadBalancer、ClusterIP
- LoadBalancer：這個是部署到云端(如阿里云)的時候需要用的，也是反向代理+負(fù)載均衡的作用，用作外部訪問K8S內(nèi)部。
- ClusterIP：這個Service是K8S集群內(nèi)部做反向代理用的
Label與Selector
上圖中有2個pod定義了Label為app：nginx;1個pod定義了app：apache;
那么Service的Selector篩選app：nginx，只會路由到nginx的pod。
Service發(fā)布
我們來編寫一個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)都會開放此端口，此端口供外部調(diào)用
- selector:
- app: mc-user #這里選擇器一定要選擇容器的標(biāo)簽
- type: NodePort #這里代表是NodePort類型的
- nodePort的端口范圍：30000～32767
上面是NodePort Service的yaml文件，我們還要修改一個之前的Pod的yaml文件
- apiVersion: v1 #指定api版本，此值必須在kubectl apiversion中
- kind: Pod #指定創(chuàng)建資源的角色/類型
- metadata: #資源的元數(shù)據(jù)/屬性
- name: mc-user #資源的名字，在同一個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的這個組件為什么會產(chǎn)生?他們的解決了是什么問題?后續(xù)老顧會繼續(xù)介紹K8S其他的組件概念，希望能夠幫助小伙伴們理解，減少K8S的學(xué)習(xí)難度;謝謝!!!
本文標(biāo)題：5分鐘讓你理解K8S必備架構(gòu)概念，以及網(wǎng)絡(luò)模型
當(dāng)前網(wǎng)址：http://www.5511xx.com/article/copgdgj.html
