《Kubernetes》，你需要掌握的 Service 和 Ingress

大家好，我是小菜~

本文主要介紹 k8s中的網(wǎng)絡(luò)設(shè)置

如有需要，可以參考

如有幫助，不忘 點(diǎn)贊 ?

微信公眾號(hào)已開(kāi)啟，小菜良記，沒(méi)關(guān)注的同學(xué)們記得關(guān)注哦！

k8s 我們已經(jīng)從 NameSpace、Pod、PodController到Volumn都介紹過(guò)了，相信看完的小伙伴們也會(huì)很有收獲的~那么今天我們繼續(xù)來(lái)到k8s的課堂，這節(jié)我們將要來(lái)說(shuō)下 k8S 搭建完服務(wù)后如何訪問(wèn)！

首先我們要清楚什么是Service 和 Ingress。簡(jiǎn)單來(lái)說(shuō)，這兩個(gè)組件都是用來(lái)做流量負(fù)載的。那么什么又是流量負(fù)載呢？當(dāng)我們?cè)诩簝?nèi)部已經(jīng)通過(guò) pod 部署了我們的應(yīng)用服務(wù)，那么下一步要干啥？那就是讓用戶訪問(wèn)到我們的應(yīng)用服務(wù)，這個(gè)才是最重要的，不然你部署完了，用戶卻訪問(wèn)不了，那豈不是無(wú)用功~

一、Service

在 k8s 中，pod 是應(yīng)用程序的載體，我們可以通過(guò) pod的 IP 來(lái)訪問(wèn)我們的應(yīng)用程序，但是我們已經(jīng)清楚了 pod 是具有生命周期的，一旦 pod 出現(xiàn)問(wèn)題，pod控制器將會(huì)將pod銷毀進(jìn)行重新創(chuàng)建。那么這個(gè)時(shí)候 pod 的Ip就會(huì)發(fā)生變化，因此利用 pod IP 訪問(wèn)應(yīng)用程序的方式直接 pass了，那么為了解決這個(gè)問(wèn)題，k8s 引入了 Service 的資源概念，通過(guò)這個(gè)資源，可以整合多個(gè)pod，提供一個(gè)統(tǒng)一的入口地址，通過(guò)訪問(wèn) Service 的入口地址就能訪問(wèn)到后面的 pod服務(wù)！

Service不是憑空出現(xiàn)的，不知道你是否還記得 Node 節(jié)點(diǎn)上的關(guān)鍵組件 kube-proxy！關(guān)鍵點(diǎn)來(lái)了哦~我們看個(gè)老圖回憶一下：

這張圖有看過(guò)之前的博文都不會(huì)陌生，是的！kube-proxy 在這里面起到了關(guān)鍵性的作用，每個(gè) Node 節(jié)點(diǎn)上都運(yùn)行著一個(gè) kube-proxy 服務(wù)進(jìn)程，當(dāng)創(chuàng)建 Service 的時(shí)候會(huì)通過(guò) api-server 向 etc寫(xiě)入創(chuàng)建的 service 的信息，而 kube-proxy 會(huì)基于監(jiān)聽(tīng)的機(jī)制發(fā)現(xiàn)這種 Service 的變動(dòng)，然后  它會(huì)將最新的Service信息轉(zhuǎn)換成對(duì)應(yīng)的訪問(wèn)規(guī)則

到這里，應(yīng)該對(duì)Service有個(gè)大概的概念，起碼知道了它的用處，接下來(lái)我們不妨更加深入的了解一下~

1）工作模式

kube-proxy 支持 3 種工作模式，如下：

1. userSpace

這個(gè)模式比較穩(wěn)定，但是效率比較低！在 userSpace 模式下，kube-proxy 會(huì)為每一個(gè) Service 創(chuàng)建一個(gè)監(jiān)聽(tīng)端口，當(dāng)有請(qǐng)求發(fā)往Cluster IP 的時(shí)候，會(huì)被 Iptables 規(guī)則重定向到 kube-proxy 監(jiān)聽(tīng)的端口上，kube-proxy 會(huì)根據(jù) LB 算法選擇一個(gè) Pod 提供服務(wù)并建立起連接。

這個(gè)模式下，kube-proxy 充當(dāng)?shù)慕巧且粋€(gè) 四層負(fù)責(zé)均衡器，由于 kube-proxy 運(yùn)行在 userSpace 模式下，在進(jìn)行轉(zhuǎn)發(fā)處理的時(shí)候會(huì)增加內(nèi)核和用戶空間之間的數(shù)據(jù)拷貝，因此效率比較低。

2. iptables

在 iptables 模式下，kube-proxy 會(huì)為 Service 后端的每個(gè) pod 都創(chuàng)建對(duì)應(yīng)的 iptable 規(guī)則，直接將發(fā)往 Cluster IP 的請(qǐng)求重定向到一個(gè) pod IP 上。該模式下 kube-proxy 不承擔(dān)四層負(fù)載均衡器的角色，只負(fù)責(zé)創(chuàng)建 iptables 的規(guī)則。該模式的優(yōu)點(diǎn)便是較 userspace 模式來(lái)說(shuō)效率更高，但是不能提供靈活的 LB 策略。當(dāng)后端Pod不可用的時(shí)候也無(wú)法進(jìn)行重試。

3. ipvs

這種模式與 iptables 模式形似，kube-proxy 會(huì)監(jiān)控pod的變化并且創(chuàng)建相應(yīng)的 ipvs 規(guī)則。但是 ipvs 規(guī)則相對(duì)于 iptables 來(lái)說(shuō)轉(zhuǎn)發(fā)效率更高，而且支持更多的 LB 算法。

實(shí)踐

上面了解到3種工作模式。我們來(lái)簡(jiǎn)單試一下  ipvs 的作用。首先準(zhǔn)備一份資源清單：

這份清單上半部分是創(chuàng)建一個(gè) Pod控制器，下半部分是創(chuàng)建一個(gè) Service。

然后我們輸入 ipvsadm -Ln命令即可看到 ipvs規(guī)則策略：

10.108.230.12 是 service 提供的訪問(wèn)入口，當(dāng)訪問(wèn)這個(gè)入口的時(shí)候，可以發(fā)現(xiàn)后面有三個(gè) pod 的服務(wù)在等待調(diào)用，kube-proxy 會(huì)基于 rr（輪詢）的策略，將請(qǐng)求分發(fā)到其中一個(gè)pod上去，這個(gè)規(guī)則會(huì)同時(shí)在集群內(nèi)的所有節(jié)點(diǎn)上都生成，所以在任何一個(gè)節(jié)點(diǎn)上訪問(wèn)都可以！

此模式必須安裝 ipvs 內(nèi)核模塊，否則會(huì)降低為 iptables

開(kāi)啟 ipvs：

1. kubectl edit cm kube-proxy -n kube-system

編輯后保存（:wq） 退出

2. kubectl delete pod -l k8s-app=kube-proxy -n kube-system
3. ipvsadm -Ln

2）Service 使用

上面已經(jīng)介紹完了 Service 的幾種工作模式。下面我們進(jìn)入Service 的使用階段。我們上面已經(jīng)做了簡(jiǎn)單的實(shí)踐，創(chuàng)建了一個(gè) Deploy ，一個(gè) Service ，然后我們可以通過(guò) serviceIp + targetPort 或 nodeIp + nodePort訪問(wèn)資源

但是在學(xué)習(xí) Service 的使用，僅僅這個(gè)是不夠的，Service又分為5種類型，下面將一一介紹。

1. ClusterIP

我們先看下 ClusterIP 類型的Service的資源清單：

通過(guò)創(chuàng)建后測(cè)試訪問(wèn) clusterIp + port

我們?cè)俨榭聪?ipvs 規(guī)則，可以看到該service已經(jīng)可以轉(zhuǎn)發(fā)到對(duì)應(yīng)的3個(gè)pod上

接下來(lái)我們可以通過(guò) describe  指令查看該service有哪些信息：

掃了一遍發(fā)現(xiàn) Endpoints 和 Session Affinity 都是我們之間沒(méi)有見(jiàn)過(guò)的。那這個(gè)又是個(gè)什么東西呢？

Endpoint

Endpoint 是 k8s 中的一個(gè)資源對(duì)象，存儲(chǔ)在etcd中，用來(lái)記錄一個(gè) service 對(duì)應(yīng)的所有Pod 的訪問(wèn)地址，它是根據(jù) service 配置文件中 selector 描述產(chǎn)生的。一個(gè)Service由一組Pod組成，這些Pod通過(guò) Endpoint 暴露出來(lái)，可以說(shuō) Endpoint 是實(shí)際實(shí)現(xiàn)服務(wù)的端口的集合。通俗來(lái)說(shuō)，Endpoint 是 service 和 pod 之間的橋梁

既然是一個(gè)資源，那么我們就可以獲取到

負(fù)載分發(fā)

我們上面已經(jīng)成功的實(shí)現(xiàn)了通過(guò) Service 訪問(wèn)到Pod 資源，那么我們?cè)僮鲆恍┬薷模謩e進(jìn)入3個(gè)pod編輯 usr/share/nginx/index.html 文件：

# pod01
Pod01 :  ip - 10.244.1.73
# pod02
Pod01 :  ip - 10.244.1.73
# pod03
Pod03 :  ip - 10.244.2.63

然后我們?cè)俅螄L試通過(guò) curl 10.96.10.10:80命令查看結(jié)果：

眼尖的你是否有發(fā)現(xiàn)，這種負(fù)載分發(fā)策略不就是輪詢嗎！對(duì)于 Service 的訪問(wèn)，k8s提供了兩種負(fù)載分發(fā)策略：

• 如果未定義分發(fā)策略，默認(rèn)使用 kube-proxy  的策略，比如隨機(jī)、輪詢
• 基于客戶端地址的會(huì)話保持模式，即來(lái)自同一個(gè)客戶端發(fā)起的所有請(qǐng)求都會(huì)轉(zhuǎn)發(fā)到固定的一個(gè)pod上。而這里就需要用到我們上面提到的沒(méi)有見(jiàn)過(guò)的東西 sessionAffinity

之前我們用 ipvsadm -Ln 命令查看分發(fā)策略的時(shí)候，里面有個(gè) rr 字段不知道你有沒(méi)有注意到，沒(méi)錯(cuò)，這個(gè) rr 值得就是輪詢的意思

如果我們想要開(kāi)啟會(huì)話保持的分發(fā)策略，那么只需要在spec中添加 sessionAffinity:ClientIP 選項(xiàng)

再次通過(guò)  ipvsadm -Ln 命令查看分發(fā)策略就可以發(fā)現(xiàn)結(jié)果已經(jīng)發(fā)生變化了

我們簡(jiǎn)單測(cè)試一下：

這樣子就已經(jīng)實(shí)現(xiàn)了會(huì)話保持的分發(fā)策略！

注意：ClusterIp 的 Service，不支持外部訪問(wèn)，也就是說(shuō)通過(guò)瀏覽器訪問(wèn)是不生效的，只能在集群內(nèi)部訪問(wèn)

2. HeadLiness

很多服務(wù)都需要支持定制化，如果將產(chǎn)品定位為服務(wù)，那么這個(gè)產(chǎn)品毋庸是成功。在某些場(chǎng)景中，開(kāi)發(fā)人員并不想要使用 service 提供的負(fù)載均衡功能，而是希望自己來(lái)控制負(fù)載均衡策略。針對(duì)這種情況的發(fā)生，k8s也是很好的支持了，引入了 HeadLiness Service，這類 Service 不會(huì)分配 ClusterIp，如果想要訪問(wèn) service，只能通過(guò) Service 域名進(jìn)行查詢。

我們來(lái)看下 HeadLiness 的資源清單模板：

唯一跟 ClusterIp 不同的便是 clusterIP: None  屬性的變化。

通過(guò)創(chuàng)建后可以發(fā)現(xiàn)，ClusterIP并未分配，我們繼續(xù)查看 Service 的詳情

通過(guò)詳情我們可以發(fā)現(xiàn) Endpoints 已經(jīng)生效了，然后我們?nèi)我膺M(jìn)入到一個(gè)pod中，查看域名解析情況：

可以看到域名也已經(jīng)解析完成，默認(rèn)域名為service名稱.命名空間.svc.cluster.local

3. NodePort

上面的兩個(gè)service類型，都是只能在集群內(nèi)部才能訪問(wèn)，但是我們部署服務(wù)肯定是想讓用戶通過(guò)集群外部可以使用的。那么這個(gè)時(shí)候就需要用到我們開(kāi)頭創(chuàng)建的service類型，那就是 NodePort  service。

這種類型的Service的工作原理也不難，其實(shí) 就是將 service的端口映射到 Node 的一個(gè)端口上，然后通過(guò) NodeIp+NodePort進(jìn)行訪問(wèn)

看了原理圖是不是感覺(jué)豁然開(kāi)朗啦。那么來(lái)看看是怎么通過(guò)資源清單創(chuàng)建的：

我們通過(guò)以上資源清單創(chuàng)建service，然后訪問(wèn)：

可以看出通過(guò)兩種方式都是可以訪問(wèn)的，我們也可以在瀏覽器試試看：

這結(jié)果也是如我們所愿！

不要感覺(jué)到這里就已經(jīng)心滿意足了哦，雖然說(shuō)已經(jīng)可以成功讓用戶訪問(wèn)到了~我們趁熱打鐵繼續(xù)再了解剩下的兩種類型~

4. LoadBalancer

LoadBalancer 聽(tīng)名字就知道跟負(fù)載均衡有關(guān)。這個(gè)類型與 NodePort 很相似，目的都是向外部暴露一個(gè)端口，主要的區(qū)別在于 LoadBalancer 會(huì)在集群的外部再做一個(gè)負(fù)載均衡器，而這個(gè)設(shè)備是需要外部環(huán)境支持的，外部環(huán)境發(fā)送到這個(gè)設(shè)備的請(qǐng)求，會(huì)被設(shè)備負(fù)載之后轉(zhuǎn)發(fā)到集群中。

圖中有個(gè)Vip的概念，這里的Vip指的是 Vitual IP，也就是虛擬IP，外部用戶通過(guò)訪問(wèn)這個(gè)虛擬IP，可以負(fù)載到我們不同的service上，達(dá)到負(fù)載均衡和高可用的特點(diǎn)

5. ExternalName

ExternalName 類型的service 是用于引入集群外部的服務(wù)，它通過(guò) externalName 屬性指定外部一個(gè)服務(wù)的地址，然后在集群內(nèi)部訪問(wèn)此service就可以訪問(wèn)到外部服務(wù)了。

資源清單：

創(chuàng)建后我們可以查看域名解析，發(fā)現(xiàn)已經(jīng)解析成功：

dig @10.96.0.10 svc-externalname.cbuc-test.svc.cluster.local

二、Ingress

1）工作模式

上面我們已經(jīng)講完了 Service幾種類型的用法，我們已經(jīng)知曉了想讓外部用戶訪問(wèn)到我們pod中的服務(wù)有兩種類型的service是支持的，分別是：NodePort和LoadBalancer，但是其實(shí)認(rèn)真分析一下，我們不難發(fā)現(xiàn)這兩種service 的缺點(diǎn):

• NodePort：會(huì)占用集群機(jī)器的很多端口，當(dāng)集群服務(wù)變多的時(shí)候，這個(gè)缺點(diǎn)就越發(fā)明顯
• LoadBalancer：每個(gè)Service都需要一個(gè)LB，比較麻煩和浪費(fèi)資源，并且需要 k8s之外的負(fù)載均衡設(shè)備支持

這種缺點(diǎn)當(dāng)然不只是我們能夠發(fā)現(xiàn)，作為k8s的啟動(dòng)者早已意識(shí)到了，緊接著便推出了 Ingress 的概念。Ingress 僅需要一個(gè) NodePort或 LB 就可以滿足暴露多個(gè)Service的需求：

實(shí)際上，Ingress就相當(dāng)于一個(gè)7層的負(fù)載均衡器，是 K8s 對(duì)反向代理的一個(gè)抽象，它的工作原理類似于 Nginx，可以理解成在 Ingress 里 建立諸多的隱射規(guī)則，然后 Ingress Controller通過(guò)監(jiān)聽(tīng)這些配置規(guī)則轉(zhuǎn)化成 Nginx 的反向代理配置，然后對(duì)外提供該服務(wù)。這邊涉及到了兩個(gè)重要的概念：

• Ingress：K8s 中的一個(gè)資源對(duì)象，作用是定義請(qǐng)求如何轉(zhuǎn)發(fā)到 service 的規(guī)則
• Ingress Controller：具體實(shí)現(xiàn)反向代理及負(fù)載均衡的程序，對(duì)Ingress定義的規(guī)則進(jìn)行解析，根據(jù)配置的規(guī)則來(lái)實(shí)現(xiàn)請(qǐng)求轉(zhuǎn)發(fā)，有很多種實(shí)現(xiàn)方式，如 Nginx、Contor、Haproxy等

Ingress 控制器 有很多中可以實(shí)現(xiàn)請(qǐng)求轉(zhuǎn)發(fā)的方式，我們通常上也會(huì)選擇我們比較熟悉的 Nginx 作為負(fù)載，接下來(lái)我們就以 Nginx 為例，我們先來(lái)了解一下其工作原理：

1. 用戶編寫(xiě) Ingress Service規(guī)則， 說(shuō)明每個(gè)域名對(duì)應(yīng) K8s集群中的哪個(gè)Service
2. Ingress控制器會(huì)動(dòng)態(tài)感知到 Ingress 服務(wù)規(guī)則的變化，然后生成一段對(duì)應(yīng)的Nginx反向代理配置
3. Ingress控制器會(huì)將生成的Nginx配置寫(xiě)入到一個(gè)運(yùn)行中的Nginx服務(wù)中，并動(dòng)態(tài)更新
4. 然后客戶端通過(guò)訪問(wèn)域名，實(shí)際上Nginx會(huì)將請(qǐng)求轉(zhuǎn)發(fā)到具體的Pod中，到此就完成了整個(gè)請(qǐng)求的過(guò)程

了解了工作原理，我們就來(lái)落地實(shí)現(xiàn)~

2）Ingress使用

1. 環(huán)境搭建

在使用 Ingress之前，我們需要先搭建一個(gè) Ingress 環(huán)境

步驟一：

# 拉取我們需要的資源清單
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml

步驟二：

# 創(chuàng)建資源
kubectl apply -f ./

步驟三：

查看資源是否創(chuàng)建成功

到這里我們就已經(jīng)準(zhǔn)備好了 Ingress 環(huán)境，接下來(lái)來(lái)到測(cè)試環(huán)節(jié)~

我們準(zhǔn)備了兩個(gè)Service，兩個(gè) Deployment，和創(chuàng)建了6個(gè)副本的Pod

如果到現(xiàn)在還準(zhǔn)備不出這些資源的小伙伴得回頭做功課了哦~

大致結(jié)構(gòu)圖如下：

那我們現(xiàn)在就準(zhǔn)備一個(gè) Ingress 來(lái)達(dá)到以下的結(jié)果

準(zhǔn)備 Ingress 的資源清單：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-htpp
  namespace: cbuc-test
spec:
  rules:
  - host: dev.cbuc.cn
    http: 
      paths:
      - path: /
        backend:
          serviceName: svc-nodeport-dev
          servicePort: 80
  - host: pro.cbuc.cn
    http:
      paths:
      - path: /
        backend:
          serviceName: svc-nodeport-pro
          servicePort: 80

通過(guò)創(chuàng)建后我們還需要在我們電腦的本地 hosts 添加域名映射：

然后在網(wǎng)頁(yè)上通過(guò) 域名+nodePort 的方式就可以訪問(wèn)到了

到這里我們就實(shí)現(xiàn)了Ingress 的訪問(wèn)方式！

到現(xiàn)在為止，我們也已經(jīng)講完了 K8s 的使用過(guò)程，從最基本的 nameSpace 到這節(jié)的網(wǎng)絡(luò)配置，不知道你學(xué)廢了么~！k8s 已經(jīng)告一段落，我們下個(gè)章節(jié)會(huì)寫(xiě)出什么新的花樣呢？那么記得關(guān)注點(diǎn)起來(lái)~

今天的你多努力一點(diǎn)，明天的你就能少說(shuō)一句求人的話！

我是小菜，一個(gè)和你一起學(xué)習(xí)的男人。 ??

微信公眾號(hào)已開(kāi)啟，小菜良記，沒(méi)關(guān)注的同學(xué)們記得關(guān)注哦！