k8s部署的兩種策略

gongzhonghao：堆棧future
干貨：

domain+slb+ingress+svc+pod 模式

gateway+registry+pod 模式

通過這篇文章我們可以看出，為啥上篇文章需要講解網(wǎng)關(guān)了，因?yàn)檫@篇文章需要用到它，網(wǎng)關(guān)很重要哦。 還有一個問題就是面試官老是會問你們的部署架構(gòu)是怎樣的，其實(shí)這個問題挺簡單的，只不過各大公司業(yè)務(wù)不同，體量不同還有場景不同選擇的部署架構(gòu)有差別，但是總體而言基于k8s的部署無非就這兩種，只不過細(xì)節(jié)上略有差別，今天主要聊聊這兩種最基本的基礎(chǔ)部署架構(gòu)。

1. 名詞介紹

1. ingress

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

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

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

2. service 即svc

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

3. pod

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

好了有了這些概念我們就開啟講解兩套部署模式吧。

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

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

我們這里以nginx為例：

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

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

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

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

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

那大家可能會問，既然將請求轉(zhuǎn)發(fā)到一個Node上了，為啥這個Node可以訪問別的Node的Pod呢？答案就是CNI，這個大家自己下去了解哈，挺簡單的。

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

3. gateway+registry+pod 模式

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

服務(wù)搭建流程：

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

用戶訪問流程：

1. 用戶訪問網(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ù)請求之后根據(jù)path(/order)路由到nacos-order-service
5. 網(wǎng)關(guān)去服務(wù)注冊中心去找nacos-order-service的映射
6. 根據(jù)pod IP:Port發(fā)起后端服務(wù)請求
7. Pod內(nèi)存將流向轉(zhuǎn)到服務(wù)進(jìn)程(iptables的portmapping插件實(shí)現(xiàn)的)
8. 服務(wù)進(jìn)程處理完成之后做出響應(yīng)

4. 小結(jié)

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

gongzhonghao：堆棧future