目錄前言架構圖Master Node元件Work Node元件Pod釋出反向代理NodePort ServiceLabel與SelectorService釋出總結前言
很多小夥伴學習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
本質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 ServiceK8S中我們可以採用型別為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: v1kind: Servicemetadata: name: mc-userspec: 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定義的埠哦
---End---
老顧的微服務閘道器分享課程，請大家多多支援
推薦閱讀
大廠如何基於binlog解決多機房同步mysql資料（一）？
大廠如何基於binlog解決多機房同步mysql資料（二）？
基於binlog的canal元件有哪些使用場景（三）？
可用於大型應用的微服務生態灰度釋出如何實現？
一線大廠級別公共Redis叢集監控，細化到每個專案例項
Sharding-jdbc的實戰入門之水平分表（一）
Sharding-Jdbc之水平分庫和讀寫分離（二）
a、dubbo如何處理業務異常，這個一定要知道哦！
b、企業級SpringBoot應用多個子專案配置檔案規劃、多環境支援（一）
c、企業級SpringBoot應用多個子專案配置檔案規劃、多環境支援（二）
d、企業級SpringBoot應用多個子專案配置檔案之配置中心（三）
e、利用阿里開源工具進行排查線上CPU居高問題
f、阿里二面：如何快速排查死鎖？如何避免死鎖？
g、微服務分散式架構中，如何實現日誌鏈路跟蹤？
h、閘道器如何聚合各個微服務的介面文件？
i、Kubernetes之POD、容器之間的網路通訊
j、K8S中的Service的存在理由
k、企業微服務專案如何進入K8S的全過程
l、阿里開源專案Sentinel限流、降級的統一處理
m、大廠二面：Redis的分散式布隆過濾器是什麼原理？
1、基於RocketMq的SpringCloud Stream框架實戰入門
2、如何搭建訊息中介軟體應用框架之SpringCloud Stream
3、面試必備：閘道器異常了怎麼辦？如何做全域性異常處理？
4、Gateway網關係列(二)：SpringCloud Gateway入門實戰，路由規則
5、Gateway網關係列開篇：SpringCloud的官方閘道器Gateway介紹
6、API閘道器在微服務架構中的應用，這一篇就夠了
7、學習Lambda表示式看這篇就夠了，不會讓你失望的哦（續篇）
8、Lambda用在哪裡？幾種場景？
9、為什麼會出現Lambda表示式，你知道嗎？
10、不說“分散式事務”理論，直接上大廠阿里的解決方案，絕對實用
11、女程式設計師問到這個問題，讓我思考了半天，Mysql的“三高”架構
12、大廠二面：CAP原則為什麼只能滿足其中兩項？而不能同時滿足
13、阿里P7二面：聊聊零複製的原理
14、秒殺系統的核心點都在這裡，快來取
15、你瞭解如何利用token方式實現分散式Session嗎？
16、Mysql索引結構演變，為什麼最終會是那個結構呢？讓你一看就懂
17、一場比賽涉及到的知識，用通俗易通的方式介紹併發協調
18、企業實戰Redis全方面思考，你思考了嗎？
19、面試題：Thread的start和run的區別
20、面試題：什麼是CAS？CAS的作用以及缺點
21、如何訪問redis中的海量資料？避免事故產生
22、如何解決Redis熱點問題？以及如何發現熱點？
23、如何設計API介面，實現統一格式返回？
24、你真的知道在生產環境下如何部署tomcat嗎？
25、分享一線網際網路大廠分散式唯一ID設計 之 snowflake方案
26、分享大廠分散式唯一ID設計方案，快來圍觀
27、你想了解一線大廠的分散式唯一ID生成方案嗎？
28、你知道如何處理大資料量嗎？(資料拆分篇)
29、如何永不遷移資料和避免熱點? 根據伺服器指標分配資料量(揭秘篇)
30、你知道怎麼分庫分表嗎？如何做到永不遷移資料和避免熱點嗎？
31、你瞭解大型網站的頁面靜態化嗎？
32、你知道如何更新快取嗎？如何保證快取和資料庫雙寫一致性？
33、你知道怎麼解決DB讀寫分離，導致資料不一致問題嗎？
34、DB讀寫分離情況下，如何解決快取和資料庫不一致性問題？
35、你真的知道怎麼使用快取嗎？
36、如何利用鎖，防止快取擊穿？重構思想的重要性
37、海量訂單產生的業務高峰期，如何避免訊息的重複消費？
38、你知道如何保障生產端100%訊息投遞成功嗎？
39、微服務下的分散式session該如何管理？
40、阿里二面：filter、interceptor、aspect應如何選擇？很多人中招
41、網際網路架構重要組員CDN，很多高階開發都沒有實操過，來看這裡
42、阿里二面：CDN快取控制原理，看看能不能難住你
43、SpringCloud Alibaba之Nacos多環境多專案管理
44、SpringCloud Alibaba系列之Nacos配置中心玩法
45、SpringCloud Alibaba之Nacos註冊中心
46、SpringCloud Plus版本之SpringCloud Alibaba
47、SpringCloud Alibaba之Nacos叢集、持久化
48、SpringCloud Alibaba之Nacos共享配置、灰度配置
49、SpringCloud Alibaba之Sentinel工作原理
50、SpringCloud Alibaba之Sentinel流控管理
51、SpringCloud Alibaba之Sentinel降級管理
52、SpringCloud Alibaba之Sentinel熱點引數限流
53、SpringCloud Alibaba之Sentinel的API實戰