2. 程式人生 > >Kubernetes K8S在IPVS代理模式下Service服務的ClusterIP型別訪問失敗處理

Kubernetes K8S在IPVS代理模式下Service服務的ClusterIP型別訪問失敗處理

阿新 • • 發佈：2020-09-09

 

Kubernetes K8S使用IPVS代理模式，當Service的型別為ClusterIP時，如何處理訪問service卻不能訪問後端pod的情況。

 

背景現象

Kubernetes K8S使用IPVS代理模式，當Service的型別為ClusterIP時，出現訪問service卻不能訪問後端pod的情況。

 

主機配置規劃

伺服器名稱(hostname)系統版本配置內網IP外網IP(模擬)
k8s-master CentOS7.7 2C/4G/20G 172.16.1.110 10.0.0.110
k8s-node01 CentOS7.7 2C/4G/20G 172.16.1.111 10.0.0.111
k8s-node02 CentOS7.7 2C/4G/20G 172.16.1.112 10.0.0.112

 

場景復現

Deployment的yaml資訊

yaml檔案

 1 [root@k8s-master service]# pwd
 2 /root/k8s_practice/service
 3 [root@k8s-master service]# cat myapp-deploy.yaml 
 4 apiVersion: apps/v1
 5 kind: Deployment
 6 metadata:
 7   name: myapp-deploy
 8   namespace: default
 9 spec:
10   replicas: 3
11   selector:
12     matchLabels:
13       app: myapp
14       release: v1
15   template:
16     metadata:
17       labels:
18         app: myapp
19         release: v1
20         env: test
21     spec:
22       containers:
23       - name: myapp
24         image: registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1
25         imagePullPolicy: IfNotPresent
26         ports:
27         - name: http
28           containerPort: 80

 

啟動Deployment並檢視狀態

 1 [root@k8s-master service]# kubectl apply -f myapp-deploy.yaml 
 2 deployment.apps/myapp-deploy created
 3 [root@k8s-master service]# 
 4 [root@k8s-master service]# kubectl get deploy -o wide
 5 NAME           READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                                                      SELECTOR
 6 myapp-deploy   3/3     3            3           14s   myapp        registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1   app=myapp,release=v1
 7 [root@k8s-master service]# kubectl get rs -o wide
 8 NAME                      DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES                                                      SELECTOR
 9 myapp-deploy-5695bb5658   3         3         3       21s   myapp        registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1   app=myapp,pod-template-hash=5695bb5658,release=v1
10 [root@k8s-master service]#
11 [root@k8s-master service]# kubectl get pod -o wide --show-labels
12 NAME                            READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES   LABELS
13 myapp-deploy-5695bb5658-7tgfx   1/1     Running   0          39s     10.244.2.111   k8s-node02   <none>           <none>            app=myapp,env=test,pod-template-hash=5695bb5658,release=v1
14 myapp-deploy-5695bb5658-95zxm   1/1     Running   0          39s     10.244.3.165   k8s-node01   <none>           <none>            app=myapp,env=test,pod-template-hash=5695bb5658,release=v1
15 myapp-deploy-5695bb5658-xtxbp   1/1     Running   0          39s     10.244.3.164   k8s-node01   <none>           <none>            app=myapp,env=test,pod-template-hash=5695bb5658,release=v1

 

curl訪問

1 [root@k8s-master service]# curl 10.244.2.111/hostname.html
2 myapp-deploy-5695bb5658-7tgfx
3 [root@k8s-master service]# 
4 [root@k8s-master service]# curl 10.244.3.165/hostname.html
5 myapp-deploy-5695bb5658-95zxm
6 [root@k8s-master service]# 
7 [root@k8s-master service]# curl 10.244.3.164/hostname.html
8 myapp-deploy-5695bb5658-xtxbp

 

Service的ClusterIP型別資訊

yaml檔案

 1 [root@k8s-master service]# pwd
 2 /root/k8s_practice/service
 3 [root@k8s-master service]# cat myapp-svc-ClusterIP.yaml 
 4 apiVersion: v1
 5 kind: Service
 6 metadata:
 7   name: myapp-clusterip
 8   namespace: default
 9 spec:
10   type: ClusterIP  # 可以不寫，為預設型別
11   selector:
12     app: myapp
13     release: v1
14   ports:
15   - name: http
16     port: 8080  # 對外暴露埠
17     targetPort: 80  # 轉發到後端埠

 

啟動Service並檢視狀態

1 [root@k8s-master service]# kubectl apply -f myapp-svc-ClusterIP.yaml 
2 service/myapp-clusterip created
3 [root@k8s-master service]# 
4 [root@k8s-master service]# kubectl get svc -o wide
5 NAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE   SELECTOR
6 kubernetes        ClusterIP   10.96.0.1        <none>        443/TCP    16d   <none>
7 myapp-clusterip   ClusterIP   10.102.246.104   <none>        8080/TCP   6s    app=myapp,release=v1

 

檢視ipvs資訊

1 [root@k8s-master service]# ipvsadm -Ln
2 IP Virtual Server version 1.2.1 (size=4096)
3 Prot LocalAddress:Port Scheduler Flags
4   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
5 ………………
6 TCP  10.102.246.104:8080 rr
7   -> 10.244.2.111:80              Masq    1      0          0  
8   -> 10.244.3.164:80              Masq    1      0          0  
9   -> 10.244.3.165:80              Masq    1      0          0

由此可見，正常情況下：當我們訪問Service時，訪問鏈路是能夠傳遞到後端的Pod並返回資訊。

 

Curl訪問結果

直接訪問Pod，如下所示是能夠正常訪問的。

1 [root@k8s-master service]# curl 10.244.2.111/hostname.html
2 myapp-deploy-5695bb5658-7tgfx
3 [root@k8s-master service]# 
4 [root@k8s-master service]# curl 10.244.3.165/hostname.html
5 myapp-deploy-5695bb5658-95zxm
6 [root@k8s-master service]# 
7 [root@k8s-master service]# curl 10.244.3.164/hostname.html
8 myapp-deploy-5695bb5658-xtxbp

 

但通過Service訪問結果異常，資訊如下。

1 [root@k8s-master service]# curl 10.102.246.104:8080
2 curl: (7) Failed connect to 10.102.246.104:8080; Connection timed out

 

處理過程

抓包核實

使用如下命令進行抓包，並通過Wireshark工具進行分析。

tcpdump -i any -n -nn port 80 -w ./$(date +%Y%m%d%H%M%S).pcap

 

結果如下圖：

可見，已經向Pod發了請求，但是沒有得到回覆。結果TCP又重傳了【TCP Retransmission】。

 

檢視kube-proxy日誌

 1 [root@k8s-master service]# kubectl get pod -A | grep 'kube-proxy'
 2 kube-system            kube-proxy-6bfh7                             1/1     Running   1          3h52m
 3 kube-system            kube-proxy-6vfkf                             1/1     Running   1          3h52m
 4 kube-system            kube-proxy-bvl9n                             1/1     Running   1          3h52m
 5 [root@k8s-master service]# 
 6 [root@k8s-master service]# kubectl logs -n kube-system kube-proxy-6bfh7
 7 W0601 13:01:13.170506       1 feature_gate.go:235] Setting GA feature gate SupportIPVSProxyMode=true. It will be removed in a future release.
 8 I0601 13:01:13.338922       1 node.go:135] Successfully retrieved node IP: 172.16.1.112
 9 I0601 13:01:13.338960       1 server_others.go:172] Using ipvs Proxier.  ##### 可見使用的是ipvs模式
10 W0601 13:01:13.339400       1 proxier.go:420] IPVS scheduler not specified, use rr by default
11 I0601 13:01:13.339638       1 server.go:571] Version: v1.17.4
12 I0601 13:01:13.340126       1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_max' to 131072
13 I0601 13:01:13.340159       1 conntrack.go:52] Setting nf_conntrack_max to 131072
14 I0601 13:01:13.340500       1 conntrack.go:83] Setting conntrack hashsize to 32768
15 I0601 13:01:13.346991       1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_tcp_timeout_established' to 86400
16 I0601 13:01:13.347035       1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_tcp_timeout_close_wait' to 3600
17 I0601 13:01:13.347703       1 config.go:313] Starting service config controller
18 I0601 13:01:13.347718       1 shared_informer.go:197] Waiting for caches to sync for service config
19 I0601 13:01:13.347736       1 config.go:131] Starting endpoints config controller
20 I0601 13:01:13.347743       1 shared_informer.go:197] Waiting for caches to sync for endpoints config
21 I0601 13:01:13.448223       1 shared_informer.go:204] Caches are synced for endpoints config 
22 I0601 13:01:13.448236       1 shared_informer.go:204] Caches are synced for service config

可見kube-proxy日誌無異常

 

網絡卡設定並修改

備註：在k8s-master節點操作的

之後進一步搜尋表明，這可能是由於“Checksum offloading” 造成的。資訊如下：

1 [root@k8s-master service]# ethtool -k flannel.1 | grep checksum
2 rx-checksumming: on
3 tx-checksumming: on     ##### 當前為 on
4     tx-checksum-ipv4: off [fixed]
5     tx-checksum-ip-generic: on    ##### 當前為 on
6     tx-checksum-ipv6: off [fixed]
7     tx-checksum-fcoe-crc: off [fixed]
8     tx-checksum-sctp: off [fixed]

 

flannel的網路設定將傳送端的checksum打開了，而實際應該關閉，從而讓物理網絡卡校驗。操作如下：

 1 # 臨時關閉操作
 2 [root@k8s-master service]# ethtool -K flannel.1 tx-checksum-ip-generic off  
 3 Actual changes:
 4 tx-checksumming: off
 5     tx-checksum-ip-generic: off
 6 tcp-segmentation-offload: off
 7     tx-tcp-segmentation: off [requested on]
 8     tx-tcp-ecn-segmentation: off [requested on]
 9     tx-tcp6-segmentation: off [requested on]
10     tx-tcp-mangleid-segmentation: off [requested on]
11 udp-fragmentation-offload: off [requested on]
12 [root@k8s-master service]# 
13 # 再次查詢結果
14 [root@k8s-master service]# ethtool -k flannel.1 | grep checksum
15 rx-checksumming: on
16 tx-checksumming: off     ##### 當前為 off
17     tx-checksum-ipv4: off [fixed]
18     tx-checksum-ip-generic: off     ##### 當前為 off
19     tx-checksum-ipv6: off [fixed]
20     tx-checksum-fcoe-crc: off [fixed]
21     tx-checksum-sctp: off [fixed]

當然上述操作只能臨時生效。機器重啟後flannel虛擬網絡卡還會開啟Checksum校驗。

 

之後我們再次curl嘗試

 1 [root@k8s-master ~]# curl 10.102.246.104:8080
 2 Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
 3 [root@k8s-master ~]# 
 4 [root@k8s-master ~]# curl 10.102.246.104:8080/hostname.html
 5 myapp-deploy-5695bb5658-7tgfx
 6 [root@k8s-master ~]# 
 7 [root@k8s-master ~]# curl 10.102.246.104:8080/hostname.html
 8 myapp-deploy-5695bb5658-95zxm
 9 [root@k8s-master ~]# 
10 [root@k8s-master ~]# curl 10.102.246.104:8080/hostname.html
11 myapp-deploy-5695bb5658-xtxbp
12 [root@k8s-master ~]# 
13 [root@k8s-master ~]# curl 10.102.246.104:8080/hostname.html
14 myapp-deploy-5695bb5658-7tgfx

由上可見，能夠正常訪問了。

 

永久關閉flannel網絡卡傳送校驗

備註：所有機器都操作

使用以下程式碼建立服務

 1 [root@k8s-node02 ~]# cat /etc/systemd/system/k8s-flannel-tx-checksum-off.service 
 2 [Unit]
 3 Description=Turn off checksum offload on flannel.1
 4 After=sys-devices-virtual-net-flannel.1.device
 5 
 6 [Install]
 7 WantedBy=sys-devices-virtual-net-flannel.1.device
 8 
 9 [Service]
10 Type=oneshot
11 ExecStart=/sbin/ethtool -K flannel.1 tx-checksum-ip-generic off

 

 

開機自啟動，並啟動服務

1 systemctl enable k8s-flannel-tx-checksum-off
2 systemctl start  k8s-flannel-tx-checksum-off

 

相關閱讀

1、關於k8s的ipvs轉發svc服務訪問慢的問題分析(一)

2、Kubernetes + Flannel: UDP packets dropped for wrong checksum – Workaround

 

 

 

———END———
如果覺得不錯就關注下唄 (-^O^-) ！

&n

相關推薦

Kubernetes K8S在IPVS代理模式下Service服務的ClusterIP型別訪問失敗處理

  Kubernetes K8S使用IPVS代理模式，當Service的型別為ClusterIP時，如何處理訪問service卻不能訪問後端pod的情況。   背景現象 Kubernetes K8S使用IPVS代理模式，當Service的型別為ClusterIP時，出現訪問servic

ATS 5.3.0在反向代理模式下實現正向代理功能方法

以前，我在records.config中一般是配置成正向+反向的形式： 現在我打算改為反向代理模式，但是需要實現正向代理的功能： 同時在remap.config中配置 regex_map http

組合語言of保護模式下的描述符型別

保護模式下的描述符可以分為三種類型，就是儲存段描述符，系統段描述符，控制描述符。不同型別的描述符長度都是相同的，都是8個位元組。 儲存段描述符描述程式碼和資料區域，包括程式碼段和資料段的起始地址和範圍。 系統段描述符描述一些特定的資料區域，主要是區域性描述符表和任務狀態段

Nginx+Tomcat代理環境下JS無法完全載入問題的處理

問題場景   Nginx+Tomcat搭建，且cms由Nginx進行代理轉發。如常見的8080埠轉到80，或者其他伺服器的80或8080埠等情況。之後通過80埠訪問cms的時候發現前端以及後臺很多的js載入一半，出現如圖錯誤： 1 直接訪問相關js也發現內容確實

設計模式系列之代理模式(Proxy Pattern)——物件的間接訪問

說明：設計模式系列文章是讀`劉偉`所著`《設計模式的藝術之道(軟體開發人員內功修煉之道)》`一書的閱讀筆記。個人感覺這本書講的不錯，有興趣推薦讀一讀。詳細內容也可以看看此書作者的部落格`https://blog.csdn.net/LoveLion/article/details/17517213` ## 模

Docker Kubernetes Service 網絡服務代理模式詳解

docker mes 內核 外部 docke 支持 用戶空間 bec 標簽 Docker Kubernetes Service 網絡服務代理模式詳解 Service service是實現kubernetes網絡通信的一個服務 主要功能：負載均衡、網絡規則分布到具體pod

Docker Kubernetes Service 網路服務代理模式詳解

Docker Kubernetes  Service 網路服務代理模式詳解 Service service是實現kubernetes網路通訊的一個服務 主要功能：負載均衡、網路規則分佈到具體pod 注：kubernetes deployment服務分配伺服器負載均衡VIP只能NO

Django -&gt; debug模式下的靜態文件服務(/media/)

相同 pytho web容器 文件服務 document mat clas str location 正式公布django項目的時候，假設存在靜態文件（通常會統一放在名稱為media或static的文件夾下），則須要建立url到文件系統的映射，比如。使用nginx的

配置lvs nat模式下real server服務器端lvsrs腳本

linux lvs nat real server 配置因為lvs nat模式下，只有入站方向的流量經過lvs服務器，出站流量直接由Real server服務器響應，所以Real Server服務器必須做相應的配置才能響應客戶數據包，即修改Real server做負載均衡時回包的源地址要改為VIP，另外要修改

vue-router規則下 history模式在iis服務器上配置

比較 html url重寫 ges 刷新 mic https 分組 src vue默認模式是hash模式 url地址欄會帶有“#”這個字符。 例如：http：//www.xxx.com/#/index 感覺和正常的url相比有點醜。 如何讓此地址如正常的url一樣

如何在SAP雲平臺的Cloud Foundry環境下添加新的Service(服務)

SAP SCP SAP雲平臺 微服務 Cloud Foundry 我想在SAP雲平臺的Cloud Foundry環境下使用MongoDB的服務，但是我在Service Marketplace上找不到這個服務。 cf marketplace返回的結果也沒有。 解決方案 退回到Global

微服務架構下 Service Mesh 會是閃亮的明天嗎？

在一起 7月 部署 服務發現 代理 負載 開源項目 images 我們 7月7日，時速雲企業級容器 PaaS 技術沙龍第 10 期在上海成功舉辦，時速雲容器架構負責人魏巍為大家詳細講解了 Service Mesh 中代表性的實踐方案、並以 Istio 為例詳細講解了 Ser

Squid緩存服務器（緩存機制、代理模式、ACL訪問控制、squid用戶認證功能等）

數量 connect ren tun nes 瀏覽器 本機 安全措施 path squid代理服務器概述： Squid是Linux系統中最常用的一款開元代理服務軟件（官方網站：http://www.squid-cache.org) ，可以很好的實現HTTP、FTP、DNS

深入了解kubernetes 中Service服務的內在邏輯

端口 支持 選擇 地址轉換 由於 相同 多個service 默認 stat 背景深入了解Service服務的內在邏輯 Servicek8s中service是一個面向微服務架構的設計，它從k8s本身解決了容器集群的負載均衡，並開放式地支持了用戶所需要的各種負載均衡方案和使用

2018-08-28微服務筆記（四）之 代理模式

1.靜態代理Demo interface Action{ public void say(); } class Person implements Action{ @Override public void say() { System.out.println("人說話"); }

不同雲服務模式下的安全策略解析

無論是IaaS、PaaS，還是SaaS，都應該關注一些安全點，比如資料安全、加密和金鑰管理、身份識別和訪問管理、安全事件管理、業務連續性等等。但是對於不同的雲服務模式（IaaS、PaaS、SaaS），需要採取不同的安全策略。 IaaS層安全策略： IaaS涵蓋了從機房裝置到其中的硬體平

.net core i上 K8S(六).netcore程式的service網路代理模式

上一章我們講了pod的hostip模式，但在生產環境中，我們都是通過service來訪問k8s叢集的，service有兩種模式來暴漏埠，今天我們來分享一下 1.clusterIP模式 我們在建立service的時候，預設建立的時clusterIP模式，clusterIP模式的特點是隻能在node節點上訪問

Nginx作為代理服務_代理模式和模組介紹

Nginx作為代理服務_代理模式和模組介紹 1、Nginx可支援的代理協議          GRPC：go語言可以使用的遠端過程呼叫協議 2、常見的Nginx作為反向代理支援的協議    &nb

設計模式之服務定位器模式（Service Locator Pattern）

服務定位器模式（Service Locator Pattern）用在我們想使用 JNDI 查詢定位各種服務的時候。考慮到為某個服務查詢 JNDI 的代價很高，服務定位器模式充分利用了快取技術。在首次請求某個服務時，服務定位器在 JNDI 中查詢服務，並快取該服務物件。當再次請求相同的服務時，

chkconfig使用，service 服務 start模式的使用

1.步驟1 在/etc/rc.d/init.d這個檔案中進行建立相對應的shell指令碼 2.例如一下的xunsearch服務的指令碼 #!/bin/bash #chkconfig: 2345 55 25 #descript: Start xunsearch mode=$1 # sta