k8s部署的兩種策略-[公粽號(hào)：堆棧future]

原文
干貨：

domain+slb+ingress+svc+pod 模式

gateway+registry+pod 模式

通過(guò)這篇文章我們可以看出，為啥上篇文章需要講解網(wǎng)關(guān)了，因?yàn)檫@篇文章需要用到它，網(wǎng)關(guān)很重要哦。

還有一個(gè)問(wèn)題就是面試官老是會(huì)問(wèn)你們的部署架構(gòu)是怎樣的，其實(shí)這個(gè)問(wèn)題挺簡(jiǎn)單的，只不過(guò)各大公司業(yè)務(wù)不同，體量不同還有場(chǎng)景不同選擇的部署架構(gòu)有差別，但是總體而言基于k8s的部署無(wú)非就這兩種，只不過(guò)細(xì)節(jié)上略有差別，今天主要聊聊這兩種最基本的基礎(chǔ)部署架構(gòu)。

1. 名詞介紹

1. ingress

ingress是公開(kāi)了集群外部訪(fǎng)問(wèn)集群內(nèi)部服務(wù)的HTTP(S)路由，流量路由ingress定義的規(guī)則控制。

也就是說(shuō)：ingress是創(chuàng)建一組路由規(guī)則，這個(gè)規(guī)則會(huì)經(jīng)過(guò)k8s API Server存儲(chǔ)到etcd中，而處理ingress規(guī)則的controller就是ingress controller。它實(shí)時(shí)監(jiān)聽(tīng)ingress資源對(duì)象，然后在本地生成反向代理upstream負(fù)載均衡配置，這里大家可以想像下Nginx的upstream配置，忘記的話(huà)我貼一張圖就知道了。

圖片

1. server name：域名
2. proxy_pass: 反向代理
3. upstream：負(fù)載均衡
4. server：就是后端服務(wù)IP，對(duì)應(yīng)在k8s中就是一組pod ip。

2. service 即svc

有ingress必須得有svc，因?yàn)閕ngress中的upstream必須要有server ip，而這些server ip就是來(lái)自svc的endpoints(pod ip集合)。

3. pod

真正運(yùn)行docker容器的(我們的服務(wù)就跑在這個(gè)上面)，它有自己的ip地址，在建立svc之后，當(dāng)我們通過(guò)yaml資源創(chuàng)建pod的時(shí)候，pod根據(jù)label會(huì)走自動(dòng)掛載到svc上，這樣svc就能獲取到后端pod ip列表，即endpoints。

好了，有了這些概念我們就開(kāi)啟講解兩套部署模式吧。

2. domain+slb+ingress+svc+pod 模式

圖片

從上圖可以看出基于ingress的這套架構(gòu)模式基本上是利用k8s核心對(duì)象構(gòu)建起來(lái)的。

我們這里以nginx為例：

1. 用戶(hù)先創(chuàng)建Pod運(yùn)行自己的服務(wù)。
2. 然后創(chuàng)建service關(guān)聯(lián)相關(guān)Pod。
3. 最后研發(fā)人員提交ingress.yaml創(chuàng)建ingress對(duì)象，關(guān)聯(lián)service。
4. ingress controller就會(huì)實(shí)時(shí)watch到ingress的變化然后創(chuàng)建upstream負(fù)載均衡和反向代理。

按照1-4創(chuàng)建完成之后我們接下來(lái)做兩件事：

1. 創(chuàng)建slb負(fù)載均衡器(后面掛載Node)，拿到公網(wǎng)IP地址。
2. 申請(qǐng)域名解析，將域名解析到slb上(A記錄)。

到這里我們的服務(wù)就算是搭建起來(lái)了，接下來(lái)跑通它：

1. 用戶(hù)先訪(fǎng)問(wèn)baidu.com
2. dns解析返回slb地址是192.169.1.1
3. slb選擇一臺(tái)機(jī)器，假如選中Node1
4. 請(qǐng)求轉(zhuǎn)發(fā)到Node1這個(gè)機(jī)器上
5. Node1上的ingress controller就會(huì)收到用戶(hù)的請(qǐng)求
6. ingress controller就會(huì)根據(jù)server name(baidu.com)通過(guò)proxy_pass代理到upstream這個(gè)負(fù)載均衡上
7. upstream就會(huì)按照RR或者其它方式去訪(fǎng)問(wèn)后端的Pod IP
8. Pod將請(qǐng)求轉(zhuǎn)到服務(wù)進(jìn)程(iptables的portmapping插件實(shí)現(xiàn)的)
9. 服務(wù)進(jìn)程處理完成之后做出響應(yīng)

那大家可能會(huì)問(wèn)，既然將請(qǐng)求轉(zhuǎn)發(fā)到一個(gè)Node上了，為啥這個(gè)Node可以輪訓(xùn)或者別的方式訪(fǎng)問(wèn)別的Node的Pod呢？答案就是CNI，這個(gè)大家自己下去了解哈，聽(tīng)有意思的。

好了，至此我們微服務(wù)部署架構(gòu)就搭建好了，贊。

3. gateway+registry+pod 模式

圖片

從上圖可以看出基于網(wǎng)關(guān)的這套架構(gòu)模式基本上也是利用k8s核心對(duì)象構(gòu)建起來(lái)的，只不過(guò)將原來(lái)的ingress用現(xiàn)在的網(wǎng)關(guān)代替了而已。

服務(wù)搭建流程：

1. 先創(chuàng)建pod，把服務(wù)跑起來(lái)
2. pod將自己的服務(wù)名稱(chēng)以及IP:Port注冊(cè)到注冊(cè)中心，這里以nacos為例
3. 注冊(cè)中心記錄服務(wù)名稱(chēng)到Pod IP：Port的映射
4. 網(wǎng)關(guān)也將自己的地址注冊(cè)到服務(wù)注冊(cè)中心

用戶(hù)訪(fǎng)問(wèn)流程：

1. 用戶(hù)訪(fǎng)問(wèn)網(wǎng)關(guān)地址http://baidu.com/order
2. dns返回網(wǎng)關(guān)ip
3. 發(fā)起tcp連接(網(wǎng)關(guān)ip+端口)
4. 網(wǎng)關(guān)收到服務(wù)請(qǐng)求之后根據(jù)path(/order)路由到nacos-order-service
5. 網(wǎng)關(guān)去服務(wù)注冊(cè)中心去找nacos-order-service的映射
6. 根據(jù)pod IP:Port發(fā)起后端服務(wù)請(qǐng)求
7. Pod將請(qǐng)求轉(zhuǎn)到服務(wù)進(jìn)程(iptables的portmapping插件實(shí)現(xiàn)的)
8. 服務(wù)進(jìn)程處理完成之后做出響應(yīng)

到這里基于網(wǎng)關(guān)的這套部署架構(gòu)就講解完了，贊。

4. 小結(jié)

目前據(jù)我了解就是這兩種基于k8s的部署方案，這兩套部署方案都在被廣泛使用，所以誰(shuí)好誰(shuí)壞不好說(shuō)，因?yàn)闃I(yè)務(wù)不同或者場(chǎng)景不同可能選擇的部署架構(gòu)方案有差別，但是無(wú)論選擇那種部署方案，相關(guān)人員都要有基本的維護(hù)能力，否則出了問(wèn)題就兩眼抹黑了。