版權(quán)聲明：本文為CSDN博主「開著拖拉機(jī)回家」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。
主頁地址：開著拖拉機(jī)回家的博客_CSDN博客-Linux,Java基礎(chǔ)學(xué)習(xí),MySql數(shù)據(jù)庫領(lǐng)域博主
目錄
一、概述
1.1 Service
1.2 kube-proxy與Service
1.3VIP和Service代理
二、Pod與Service 的關(guān)系
三、Service類型
四、代理模式分類
五、Service定義與創(chuàng)建
5.1 創(chuàng)建ClusterIP類型的Service
5.2 創(chuàng)建NodePort類型的Service
5.3創(chuàng)建LoadBalancer類型的Service
六、Service 代理模式
6.1iptables簡介
6.2iptables規(guī)則鏈在NodePort的應(yīng)用
6.3IPVS
6.4iptables和IPVS對比
6.5Service工作流程
一、概述
1.1 Service
Service引入主要是解決Pod的動態(tài)變化，提供統(tǒng)一訪問入口。Kubernetes Service定義了這樣一種抽象： Service是一種可以訪問 Pod邏輯分組的策略， Service通常是通過 Label Selector訪問 Pod組。
Service能夠提供負(fù)載均衡的能力，但是在使用上有以下限制：只提供 4 層負(fù)載均衡能力，而沒有 7 層功能，但有時我們可能需要更多的匹配規(guī)則來轉(zhuǎn)發(fā)請求，這點上 4 層負(fù)載均衡是不支持的。Service的作用：
? 防止Pod失聯(lián)，準(zhǔn)備找到提供同一個服務(wù)的Pod（服務(wù)發(fā)現(xiàn)）
? 定義一組Pod的訪問策略（負(fù)載均衡）
1.2 kube-proxy與Service
- 客戶端訪問節(jié)點時通過 iptables 實現(xiàn)的；
- iptables規(guī)則是通過 kube-proxy寫入的；
- apiserver通過監(jiān)控 kube-proxy去進(jìn)行對服務(wù)和端點的監(jiān)控；
- kube-proxy通過 pod的標(biāo)簽（ lables）去判斷這個斷點信息是否寫入到 Endpoints里
1.3VIP和Service代理
在 Kubernetes集群中，每個 Node運行一個 kube-proxy進(jìn)程。 kube-proxy負(fù)責(zé)為 Service實現(xiàn)了一種 VIP（虛擬 IP）的形式，而不是 ExternalName的形式。在 Kubernetes v1.0版本，代理完全在 userspace。在 Kubernetes v1.1版本，新增了 iptables代理，但并不是默認(rèn)的運行模式。從 Kubernetes v1.2起，默認(rèn)就是 iptables代理。在 Kubernetes v1.8.0-beta.0中，添加了 ipvs代理。
在 Kubernetes v1.0版本， Service是 4 層（ TCP/ UDP over IP）概念。在 Kubernetes v1.1版本，新增了 Ingress API（ beta版），用來表示 7 層（ HTTP）服務(wù)為何不使用 round-robin DNS？
DNS會在很多的客戶端里進(jìn)行緩存，很多服務(wù)在訪問 DNS進(jìn)行域名解析完成、得到地址后不會對 DNS的解析進(jìn)行清除緩存的操作，所以一旦有他的地址信息后，不管訪問幾次還是原來的地址信息，導(dǎo)致負(fù)載均衡無效。
二、Pod與Service 的關(guān)系
? Service通過標(biāo)簽關(guān)聯(lián)一組Pod
? Service使用iptables或者ipvs為一組Pod提供負(fù)載均衡能力
三、Service類型
- ClusterIP：集群內(nèi)部使用，默認(rèn)類型，自動分配一個僅Cluster內(nèi)部可以訪問的虛擬IP
- NodePort：對外暴露應(yīng)用（集群外），在ClusterIP基礎(chǔ)上為Service在每臺機(jī)器上綁定一個端口
- LoadBalancer：對外暴露應(yīng)用，適用公有云
- ExternalName：把集群外部的服務(wù)引入到集群內(nèi)部來，在集群內(nèi)部直接使用。
四、代理模式分類
- iptables 代理模式
- userspace 代理模式
- ipvs 代理模式
ipvs代理模式中 kube-proxy會監(jiān)視 Kubernetes Service對象和 Endpoints，調(diào)用 netlink接口以相應(yīng)地創(chuàng)建 ipvs規(guī)則并定期與 Kubernetes Service對象和 Endpoints對象同步 ipvs規(guī)則，以確保 ipvs狀態(tài)與期望一致。訪問服務(wù)時，流量將被重定向到其中一個后端 Pod。
與 iptables類似， ipvs于 netfilter的 hook功能，但使用哈希表作為底層數(shù)據(jù)結(jié)構(gòu)并在內(nèi)核空間中工作。這意味著 ipvs可以更快地重定向流量，并且在同步代理規(guī)則時具有更好的性能。此外， ipvs為負(fù)載均衡算法提供了更多選項，例如：rr：輪詢調(diào)度lc：最小連接數(shù)dh：目標(biāo)哈希sh：源哈希sed：最短期望延遲nq：不排隊調(diào)度
五、Service定義與創(chuàng)建
5.1 創(chuàng)建ClusterIP類型的Service
ClusterIP主要在每個node節(jié)點使用iptables，將發(fā)向ClusterIP對應(yīng)端口的數(shù)據(jù)，轉(zhuǎn)發(fā)到kube-proxy中。然后kube-proxy自己內(nèi)部實現(xiàn)有負(fù)載均衡的方法，并可以查詢到這個service下對應(yīng)pod的地址和端口，進(jìn)而把數(shù)據(jù)轉(zhuǎn)發(fā)給對應(yīng)的pod的地址和端口。
?主要需要以下幾個組件的協(xié)同工作：
apiserver：用戶通過 kubectl命令向 apiserver發(fā)送創(chuàng)建 service的命令， apiserver接收到請求后將數(shù)據(jù)存儲到 etcd中
kube-proxy： Kubernetes的每個節(jié)點中都有一個叫做 kube-porxy的進(jìn)程，這個進(jìn)程負(fù)責(zé)感知 service、 pod的變化，并將變化的信息寫入本地的 iptables規(guī)則中
iptables：使用 NAT等技術(shù)將 virtualIP的流量轉(zhuǎn)至 endpoint中
創(chuàng)建 service.yaml文件：
apiVersion: v1
kind: Service
metadata:
name: web
namespace: default
spec:
ports:
- port: 8090 # service端口
protocol: TCP # 協(xié)議
targetPort: 80 # 容器端口
selector: # 標(biāo)簽選擇器
app: nginx # 指定關(guān)聯(lián)Pod的標(biāo)簽
type: ClusterIP # 服務(wù)類型
###
kubectl apply -f service.yaml
### 查看service
kubectl get svc
### 查看pod 標(biāo)簽
kubectl get pods --show-labels?關(guān)聯(lián) Labels app=nginx 的pod，然后使用 service 提供的 IP 訪問
ClusterIP 默認(rèn)分配一個穩(wěn)定的IP地址，即VIP，只能在集群內(nèi)部訪問。
5.2 創(chuàng)建NodePort類型的Service
NodePort：在每個節(jié)點上啟用一個端口來暴露服務(wù)，可以在集群外部訪問，將向該端口的流量導(dǎo)入到 kube-proxy，然后由 kube-proxy進(jìn)一步到給對應(yīng)的 pod。。也會分配一個穩(wěn)定內(nèi)部集群IP地址。
訪問地址：<任意NodeIP>:<NodePort> 端口范圍：30000-32767示例?
apiVersion: v1
kind: Service
metadata:
name: web-nodeport
namespace: default
spec:
ports:
- port: 80 # service 端口
protocol: TCP # 協(xié)議
targetPort: 80 # 容器內(nèi)部端口
nodePort: 30008 # NodePort端口
selector: # 標(biāo)簽選擇器
app: nginx # 指定關(guān)聯(lián)Pod的標(biāo)簽
type: NodePort # service類型使用 NodePort類型的服務(wù)將nginx 的服務(wù)端口暴露出來。
端口30553 加任意一臺服務(wù)器IP成功訪問
NodePort：會在每臺Node上監(jiān)聽端口接收用戶流量，在實際情況下，對用戶暴露的只會有一個IP和端口，那這么多臺Node該使用哪臺讓用戶訪問呢？
這時就需要前面加一個公網(wǎng)負(fù)載均衡器為項目提供統(tǒng)一訪問入口了。
負(fù)載均衡器：
開源：Nginx 、LVS、haproxy
公有云：SLB
部署Nginx：
?## 安裝 nginx ,并啟動
yum install epel-release -y
yum install nginx -y
systemctl start nginx
vim /etc/nginx/nginx.conf
#在server 的上面插入以下代碼
upstream webservers {
server 192.168.2.118:30553;
server 192.168.2.210:30553;
}
server{
listen 8553;
location / {
proxy_pass http://webservers;
}
}
server {
listen 80 default_server;
listen [::]:80 default_server;
.....
## 配置關(guān)系重新 加載
[root@k8s-devops ~]# nginx -s reload
## 查看 8553 端口是否監(jiān)聽
[root@k8s-devops ~]# netstat -anlp | grep 8553
tcp 0 0 0.0.0.0:8553 0.0.0.0:* LISTEN 16715/nginx: master
[root@k8s-devops ~]#
?監(jiān)聽端口如下：
IP+8553 端口訪問 nginx 應(yīng)用 ：
5.3創(chuàng)建LoadBalancer類型的Service
LoadBalancer：與NodePort類似，在每個節(jié)點上啟用一個端口來暴露服務(wù)。除此之外，Kubernetes會請求底層云平臺（例如阿里云、騰訊云、AWS等）上的負(fù)載均衡器，將每個Node
（[NodeIP]:[NodePort]）作為后端添加進(jìn)去。
六、Service 代理模式
6.1iptables簡介
表（tables）提供特定的功能，iptables內(nèi)置了4個表，即filter表、nat表、mangle表和raw表，分別用于實現(xiàn)包過濾，網(wǎng)絡(luò)地址轉(zhuǎn)換、包重構(gòu)(修改)和數(shù)據(jù)跟蹤處理。
鏈（chains）是數(shù)據(jù)包傳播的路徑，每一條鏈其實就是眾多規(guī)則中的一個檢查清單，每一條鏈中可以有一 條或數(shù)條規(guī)則。當(dāng)一個數(shù)據(jù)包到達(dá)一個鏈時，iptables就會從鏈中第一條規(guī)則開始檢查，看該數(shù)據(jù)包是否滿足規(guī)則所定義的條件。如果滿足，系統(tǒng)就會根據(jù) 該條規(guī)則所定義的方法處理該數(shù)據(jù)包；否則iptables將繼續(xù)檢查下一條規(guī)則，如果該數(shù)據(jù)包不符合鏈中任一條規(guī)則，iptables就會根據(jù)該鏈預(yù)先定 義的默認(rèn)策略來處理數(shù)據(jù)包。
使用-j可以指定動作，比如
-j ACCEPT
-j DROP
-j REJECT
原文鏈接：Iptables 詳解與實戰(zhàn)案例_開著拖拉機(jī)回家的博客-CSDN博客_iptables 實戰(zhàn)
6.2iptables規(guī)則鏈在NodePort的應(yīng)用
我們將 web-nodeport Service 的iptables 規(guī)則鏈 搜索出來?！?/p>
iptables規(guī)則鏈方位步驟：
第一步 ：在瀏覽器訪問
http://192.168.2.119:30553
第二步 ： 規(guī)則鏈重定向
### 數(shù)據(jù)包經(jīng)過iptables規(guī)則匹配，重定向另一個鏈， KUBE-SVC-GCYSPZR5VVR6P7RM，
## -A 表示在指定鏈的末尾添加（append）一條新的規(guī)則
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/web-nodeport" -m tcp --dport 30553 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/web-nodeport" -m tcp --dport 30553 -j KUBE-SVC-GCYSPZR5VVR6P7RM第三步 ： 實現(xiàn)規(guī)則鏈轉(zhuǎn)發(fā)負(fù)載
### 一組規(guī)則，有幾個pod就會創(chuàng)建幾條，我們這個三個 pod（這里實現(xiàn)了負(fù)載均衡器, probability 匹配到規(guī)則鏈的概率）
-A KUBE-SVC-GCYSPZR5VVR6P7RM -m comment --comment "default/web-nodeport" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-KYDJN3GW7WZ2VGX2
-A KUBE-SVC-GCYSPZR5VVR6P7RM -m comment --comment "default/web-nodeport" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-MC5SFNONWFPVUITK
-A KUBE-SVC-GCYSPZR5VVR6P7RM -m comment --comment "default/web-nodeport" -j KUBE-SEP-7GGWNYUUPHQRXI76第四步： 使用DNAT轉(zhuǎn)發(fā)到具體的Pod
### 使用DNAT轉(zhuǎn)發(fā)到具體的Pod
# 匹配鏈：KUBE-SEP-7GGWNYUUPHQRXI76， KUBE-SEP-MC5SFNONWFPVUITK，KUBE-SEP-MC5SFNONWFPVUITK
# -s 源服務(wù)器
# to-destination 目標(biāo)服務(wù)器
# -j 指定動作 ACCEPT DROP
-A KUBE-SEP-7GGWNYUUPHQRXI76 -s 10.244.2.16/32 -m comment --comment "default/web-nodeport" -j KUBE-MARK-MASQ
-A KUBE-SEP-7GGWNYUUPHQRXI76 -p tcp -m comment --comment "default/web-nodeport" -m tcp -j DNAT --to-destination 10.244.2.16:80
-A KUBE-SEP-KYDJN3GW7WZ2VGX2 -s 10.244.1.11/32 -m comment --comment "default/web-nodeport" -j KUBE-MARK-MASQ
-A KUBE-SEP-KYDJN3GW7WZ2VGX2 -p tcp -m comment --comment "default/web-nodeport" -m tcp -j DNAT --to-destination 10.244.1.11:80
-A KUBE-SEP-MC5SFNONWFPVUITK -s 10.244.2.15/32 -m comment --comment "default/web-nodeport" -j KUBE-MARK-MASQ
-A KUBE-SEP-MC5SFNONWFPVUITK -p tcp -m comment --comment "default/web-nodeport" -m tcp -j DNAT --to-destination 10.244.2.15:80針對ClusterIP實現(xiàn)的轉(zhuǎn)發(fā)后面與nodeport一樣，回到了上面第三步
#### 針對ClusterIP實現(xiàn)的轉(zhuǎn)發(fā)，后面與nodeport一樣，回到了上面第三步
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.96.186.242/32 -p tcp -m comment --comment "default/web-nodeport cluster IP" -m tcp --dport 8090 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.96.186.242/32 -p tcp -m comment --comment "default/web-nodeport cluster IP" -m tcp --dport 8090 -j KUBE-SVC-GCYSPZR5VVR6P7RM6.3IPVS
?kube-proxy?是configmap 配置文件 部署的，我們修改下 kube-proxy 配置文件
?編輯 修改 mode為IPVA：
## 編輯 kube-proxy 配置文件
kubectl edit configmap kube-proxy -n kube-system
40 tcpTimeout: 0s
41 udpTimeout: 0s
42 kind: KubeProxyConfiguration
43 metricsBindAddress: ""
44 mode: "ipvs" ## 修改 kube-proxy 配置中的mode為:ipvs
45 nodePortAddresses: null
46 oomScoreAdj: null
47 portRange: ""
48 showHiddenMetricsForVersion: ""
49 udpIdleTimeout: 0s可以使用如下的命令查看 IPVS數(shù)據(jù)鏈
## 安裝IPVS 命令
yum install ipvsadm
ipvsadm -L -n
### 刪除POD kube-proxy-tg889
kubectl -n kube-system delete pod kube-proxy-tg889?刪除node1 上的pod ，重新啟動
?查看新的kube-proxy pod日志，顯示“Using ipvs Proxier” 表示開啟了ipvs模式：
[root@node1 ~]# kubectl -n kube-system logs kube-proxy-tg889
I0512 20:46:39.128357 1 node.go:172] Successfully retrieved node IP: 192.168.2.118
I0512 20:46:39.128553 1 server_others.go:142] kube-proxy node IP is an IPv4 address (192.168.10.136), assume IPv4 operation
I0512 20:46:39.153956 1 server_others.go:258] Using ipvs Proxier.
I0512 20:46:39.166860 1 proxier.go:372] missing br-netfilter module or unset sysctl br-nf-call-iptables; proxy may not work as intended
E0512 20:46:39.167001 1 proxier.go:389] can't set sysctl net/ipv4/vs/conn_reuse_mode, kernel version must be at least 4.1
W0512 20:46:39.167105 1 proxier.go:445] IPVS scheduler not specified, use rr by default
I0512 20:46:39.167274 1 server.go:650] Version: v1.19.06.4iptables和IPVS對比
Iptables：
- 靈活，功能強(qiáng)大
- 規(guī)則遍歷匹配和更新，呈線性時延
IPVS：
- 工作在內(nèi)核態(tài)，為大型集群提供了更好的可擴(kuò)展性和性能
- ?調(diào)度算法豐富：最小負(fù)載、最少連接、加權(quán)等（rr，wrr，lc，wlc，ip hash...）
- ipvs 支持服務(wù)器健康檢查和連接重試等功能
6.5Service工作流程
- 用戶執(zhí)行kubectl/userClient向apiserver發(fā)起一個命令，經(jīng)過認(rèn)證授權(quán)后，經(jīng)過scheduler的各種策略，得到一個目標(biāo)node，然后告訴apiserver，apiserver 會請求相關(guān)node的kubelet，通過kubelet把pod運行起來，apiserver還會將pod的信息保存在etcd；
- pod運行起來后，controllermanager就會負(fù)責(zé)管理pod的狀態(tài)，如，若pod掛了，controllermanager就會重新創(chuàng)建一個一樣的pod，或者像擴(kuò)縮容等；
- pod有一個獨立的ip地址，但pod的IP是易變的，如異常重啟，或服務(wù)升級的時候，IP都會變，這就有了service；完成service工作的具體模塊是kube-proxy，在每個node上都會有一個kube-proxy，在任何一個節(jié)點上訪問一個service的虛擬ip，都可以訪問到pod；
- service的IP可以在集群內(nèi)部訪問到，在集群外呢？service可以把服務(wù)端口暴露在當(dāng)前的Node上，外面的請求直接訪問到node上的端口就可以訪問到service了
參考：一文講透K8s的Service概念
文章來源：http://www.zghlxwxcb.cn/news/detail-721725.html
?版權(quán)聲明：本文為CSDN博主「開著拖拉機(jī)回家」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。
主頁地址：開著拖拉機(jī)回家的博客_CSDN博客-Linux,Java基礎(chǔ)學(xué)習(xí),MySql數(shù)據(jù)庫領(lǐng)域博主文章來源地址http://www.zghlxwxcb.cn/news/detail-721725.html
到了這里，關(guān)于【云原生】kubernetes深入理解之Service的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
