k8s安裝calico時如何選擇網(wǎng)卡問題
1.了解calico的通信
默認情況下calico使用的是IPIP模式進行通信，所有節(jié)點之間建立tunl0隧道。
每創(chuàng)建一個pod在宿主機上都會產(chǎn)生一個以cali開頭的虛擬接口，如下圖pod1生成了一個calixxxxx網(wǎng)卡，pod2生成了一個caliyyyyy虛擬網(wǎng)卡。
每個pod發(fā)出去的數(shù)據(jù)包會直接轉(zhuǎn)發(fā)到cali開頭的網(wǎng)卡，這個接口跟pod里的網(wǎng)卡是veth pair的關(guān)系。
veth pair最直接的理解就是“網(wǎng)線直連”，pod1發(fā)出去的所有數(shù)據(jù)包，“閉著眼”轉(zhuǎn)發(fā)給calixxxxx，calixxxxx從其他地方收到的數(shù)據(jù)包“閉著眼”轉(zhuǎn)發(fā)給pod1。
cali開頭的網(wǎng)卡會連接到tunl0上，pod1和pod2通信時，pod1發(fā)出的數(shù)據(jù)包先到達calixxxxx，然后進入vms71的tunl0接口，再然后到達隧道的另一端vms72的tunl0接口，然后轉(zhuǎn)發(fā)到caliyyyy，最終到達了pod2。所以tunl0隧道的作用就是封裝所有pod之間的流量。
現(xiàn)在的問題是tunl0隧道所走的物理線路是哪條呢？默認情況下calico會自動選擇，但是如果有多張網(wǎng)卡的話我們想手動選擇網(wǎng)卡，下面分成5種情況來看tunl0如何選擇物理線路。
2.實驗準(zhǔn)備
本實驗共兩臺節(jié)點，如下。
[root@vms71 ~]# kubectl get nodes NAME STATUS ROLES AGE VERSION vms71.rhce.cc Ready control-plane,master 54m v1.23.2 vms72.rhce.cc Ready <none> 54m v1.23.2 [root@vms71 ~]#
為了測試，特地把vms72上的網(wǎng)卡名做了修改，原來的ens32修改名為eth0，原來的ens33修改名為eth1。
vms71上ens32 ----- vms72上eth1 同一網(wǎng)段。 vms71上ens33 ----- vms72上eth0 同一網(wǎng)段。
同一網(wǎng)段的網(wǎng)卡，結(jié)合上圖，我這里并沒寫錯。
練習(xí)時會在vms71上創(chuàng)建pod1，在vms72上創(chuàng)建pod2，所編寫的pod.yaml內(nèi)容如下
[root@vms71 ~]# cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod1
name: pod1
spec:
nodeName: vms71.rhce.cc
terminationGracePeriodSeconds: 0
containers:
- image: localhost/centos:test
imagePullPolicy: IfNotPresent
command: ["sh","-c","sleep 1d"]
name: pod1
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
---
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod2
name: pod2
spec:
nodeName: vms72.rhce.cc
terminationGracePeriodSeconds: 0
containers:
- image: localhost/centos:test
imagePullPolicy: IfNotPresent
command: ["sh","-c","sleep 1d"]
name: pod2
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
[root@vms71 ~]#
第一種情況 指定網(wǎng)卡1
修改calico.yaml的內(nèi)容，找到IP_AUTODETECTION_METHOD
- name: IP_AUTODETECTION_METHOD
value: "interface=ens33,eth0"這里指定tunl0隧道所對應(yīng)的物理接口為ens33或者eth0。
在vms71上他會選擇ens33，在vms72上會選擇eth0。
安裝calico。
[root@vms71 ~]# kubectl apply -f calico.yaml
configmap/calico-config created
...輸出...
[root@vms71 ~]#
創(chuàng)建測試用的pod。
[root@vms71 ~]# kubectl apply -f pod.yaml pod/pod1 created pod/pod2 created [root@vms71 ~]# [root@vms71 ~]# kubectl get pods -owide NAME READY STATUS RESTARTS AGE IP NODE pod1 1/1 Running 0 14s 10.244.118.193 vms71.rhce.cc pod2 1/1 Running 0 14s 10.244.5.194 vms72.rhce.cc [root@vms71 ~]#
整個拓撲圖應(yīng)該如下。
進入到pod1里去，然后通過traceroute訪問 pod2的IP即 10.244.5.194。
[root@vms71 ~]# kubectl exec -it pod1 -- bash [root@pod1 /]# [root@pod1 /]# traceroute 10.244.5.194 traceroute to 10.244.5.194 (10.244.5.194), 30 hops max, 60 byte packets 1 192-168-26-71.kubernetes.default.svc.cluster.local (192.168.26.71) 0.049 ms 0.009 ms 0.007 ms 2 10.244.5.192 (10.244.5.192) 0.477 ms 0.414 ms 0.378 ms 3 10.244.5.194 (10.244.5.194) 0.615 ms 0.577 ms 0.540 ms [root@pod1 /]# exit [root@vms71 ~]#
從這里可以看到在pod1發(fā)出去的包，直接到達隧道另一端即vms72上的tunl0，然后再轉(zhuǎn)發(fā)到pod2的。
那么vms71和vms72之間的隧道之間是怎么走的呢？
先查看vms71的路由。
[root@vms71 ~]# ip route | grep tunl0 10.244.5.192/26 via 192.168.30.72 dev tunl0 proto bird onlink [root@vms71 ~]#
凡是去往網(wǎng)段10.244.5.192/26的數(shù)據(jù)包都發(fā)送到192.168.30.72（這是vms72的eth0接口，也是隧道tunl0的另一端）。
查看vms72的路由。
[root@vms72 ~]# ip route | grep tunl0 10.244.118.192/26 via 192.168.30.71 dev tunl0 proto bird onlink [root@vms72 ~]# 凡是去往網(wǎng)段10.244. ```118.192/26的數(shù)據(jù)包都發(fā)送到192.168.30.71（這是vms71的ens33接口，也是隧道tunl0的另一端）。 刪除pod1和pod2。 ```shell [root@vms71 ~]# kubectl delete -f pod.yaml pod "pod1" deleted pod "pod2" deleted [root@vms71 ~]# 刪除calico。
[root@vms71 ~]# kubectl delete -f calico.yaml
configmap "calico-config" deleted
...輸出...
[root@vms71 ~]#
第二種情況 指定網(wǎng)卡2
修改calico.yaml的內(nèi)容，修改IP_AUTODETECTION_METHOD的值。
- name: IP_AUTODETECTION_METHOD
value: "interface=ens32,eth1"這里指定tunl0所使用的物理線路是ens32或者eth1，vms71上有ens32所以選擇ens32，vms72上有eth1則選擇eth1。
安裝calico。
[root@vms71 ~]# kubectl apply -f calico.yaml
configmap/calico-config created
...輸出...
[root@vms71 ~]#
創(chuàng)建pod。
[root@vms71 ~]# kubectl apply -f pod.yaml pod/pod1 created pod/pod2 created [root@vms71 ~]# [root@vms71 ~]# kubectl get pods -owide NAME READY STATUS RESTARTS AGE IP NODE pod1 1/1 Running 0 3s 10.244.118.193 vms71.rhce.cc pod2 1/1 Running 0 3s 10.244.5.194 vms72.rhce.cc [root@vms71 ~]#
兩個pod的IP保持和之前一樣。
進入到pod1里去，然后通過traceroute訪問 pod2的IP即 10.244.5.194。
[root@vms71 ~]# kubectl exec -it pod1 -- bash [root@pod1 /]# traceroute 10.244.5.194 traceroute to 10.244.5.194 (10.244.5.194), 30 hops max, 60 byte packets 1 192-168-26-71.kubernetes.default.svc.cluster.local (192.168.26.71) 0.050 ms 0.009 ms 0.007 ms 2 10.244.5.192 (10.244.5.192) 0.493 ms 0.407 ms 0.365 ms 3 10.244.5.194 (10.244.5.194) 0.482 ms 0.468 ms 0.461 ms [root@pod1 /]# exit exit [root@vms71 ~]#
查看vms71的路由。
[root@vms71 ~]# ip route | grep tunl0 10.244.5.192/26 via 192.168.26.72 dev tunl0 proto bird onlink [root@vms71 ~]#
凡是去往網(wǎng)段10.244.5.192/26的數(shù)據(jù)包都發(fā)送到192.168.26.72（這是vms72的eth1接口，也是隧道tunl0的另一端）。
查看vms72的路由。
[root@vms72 ~]# ip route | grep tunl0 10.244.118.192/26 via 192.168.26.71 dev tunl0 proto bird onlink [root@vms72 ~]#
凡是去往網(wǎng)段10.244.118.192/26的數(shù)據(jù)包都發(fā)送到192.168.26.71（這是vms71的ens32接口，也是隧道tunl0的另一端）。
刪除pod1和pod2。
[root@vms71 ~]# kubectl delete -f pod.yaml pod "pod1" deleted pod "pod2" deleted [root@vms71 ~]#
刪除calico。
[root@vms71 ~]# kubectl delete -f calico.yaml
configmap "calico-config" deleted
...輸出...
[root@vms71 ~]#
第三種情況 跳過指定網(wǎng)卡
修改calico.yaml的內(nèi)容，修改IP_AUTODETECTION_METHOD的值
- name: IP_AUTODETECTION_METHOD
value: "skip-interface=eth1,ens32"tunl0選擇物理網(wǎng)卡時跳過eth1或者ens32。
在vms71上跳過ens32的話只能選擇ens33，在vms72上跳過eth1的話只能選擇eth0。
安裝calico。
[root@vms71 ~]# kubectl apply -f calico.yaml
configmap/calico-config created
...輸出...
[root@vms71 ~]#
先查看vms71的路由
[root@vms71 ~]# ip route | grep tunl0 10.244.5.192/26 via 192.168.30.72 dev tunl0 proto bird onlink [root@vms71 ~]#
凡是去往網(wǎng)段10.244.5.192/26的數(shù)據(jù)包都發(fā)送到192.168.30.72（這是vms72的eth0接口，也是隧道tunl0的另一端）。
先查看vms72的路由
[root@vms72 ~]# ip route | grep tunl0 10.244.118.192/26 via 192.168.30.71 dev tunl0 proto bird onlink [root@vms72 ~]#
凡是去往網(wǎng)段10.244.118.192/26的數(shù)據(jù)包都發(fā)送到192.168.30.71（這是vms71的ens33接口，也是隧道tunl0的另一端）。刪除calico。
[root@vms71 ~]# kubectl delete -f calico.yaml
configmap "calico-config" deleted
...輸出...
[root@vms71 ~]#
第四種情況 通過網(wǎng)絡(luò)連通性判斷
修改calico.yaml的內(nèi)容，修改IP_AUTODETECTION_METHOD的值。
- name: IP_AUTODETECTION_METHOD value: "can-reach=192.168.30.1"
tunl0要選擇能和192.168.30.1通信的那張網(wǎng)卡，在vms71上ens33網(wǎng)卡和192.168.30.1是同一個網(wǎng)段，能夠和192.168.30.1通信，被選中。
在vms72上eth0網(wǎng)卡和192.168.30.1是同一網(wǎng)段可以通信，被選中。
創(chuàng)建calico。
[root@vms71 ~]# kubectl apply -f calico.yaml
configmap/calico-config created
...輸出...
[root@vms71 ~]#先查看vms71的路由
[root@vms71 ~]# ip route | grep tunl0 10.244.5.192/26 via 192.168.30.72 dev tunl0 proto bird onlink [root@vms71 ~]#
凡是去往網(wǎng)段10.244.5.192/26的數(shù)據(jù)包都發(fā)送到192.168.30.72（這是vms72的eth0接口，也是隧道tunl0的另一端）。
先查看vms72的路由
[root@vms72 ~]# ip route | grep tunl0 10.244.118.192/26 via 192.168.30.71 dev tunl0 proto bird onlink [root@vms72 ~]#
凡是去往網(wǎng)段10.244.118.192/26的數(shù)據(jù)包都發(fā)送到192.168.30.71（這是vms71的ens33接口，也是隧道tunl0的另一端）。
刪除calico。
[root@vms71 ~]# kubectl delete -f calico.yaml
configmap "calico-config" deleted
...輸出...
[root@vms71 ~]#第五種情況 通過cidr判斷
修改calico.yaml的內(nèi)容，修改IP_AUTODETECTION_METHOD的值。
- name: IP_AUTODETECTION_METHOD value: "cidr=192.168.26.0/24"
tunl0選擇選擇192.168.26.0/24網(wǎng)段的網(wǎng)卡，vms71選中的是ens32，vms72上選中的應(yīng)該是eth1了，因為他們都是屬于192.168.26.0/24網(wǎng)段的。
創(chuàng)建calico。
[root@vms71 ~]# kubectl apply -f calico.yaml
configmap/calico-config created
...輸出...
[root@vms71 ~]#查看vms71的路由。
[root@vms71 ~]# ip route | grep tunl0 10.244.5.192/26 via 192.168.26.72 dev tunl0 proto bird onlink [root@vms71 ~]#
凡是去往網(wǎng)段10.244.5.192/26的數(shù)據(jù)包都發(fā)送到192.168.26.72（這是vms72的eth1接口，也是隧道tunl0的另一端）。
查看vms72的路由。
[root@vms72 ~]# ip route | grep tunl0 10.244.118.192/26 via 192.168.26.71 dev tunl0 proto bird onlink [root@vms72 ~]#
凡是去往網(wǎng)段10.244.118.192/26的數(shù)據(jù)包都發(fā)送到192.168.26.71（這是vms71的ens32接口，也是隧道tunl0的另一端）。
刪除calico。
[root@vms71 ~]# kubectl delete -f calico.yaml
configmap "calico-config" deleted
...輸出...
[root@vms71 ~]#總結(jié)
以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。
相關(guān)文章
Kubernetes臨時容器用于調(diào)試無shell容器,通過shareProcessNamespace參數(shù)實現(xiàn)安全登錄與故障排查,排查后可刪除,版本1.25及以上默認啟用,需使用預(yù)裝debug工具的鏡像（如busybox）2025-08-08
Kubernetes集群中Calico網(wǎng)絡(luò)插件報錯問題分析及解決過程
Kubernetes集群中Calico網(wǎng)絡(luò)插件報錯（如FailedCreatePodSandBox）通常由配置錯誤、RBAC權(quán)限缺失或組件故障導(dǎo)致,解決方法包括重啟Calico組件、驗證配置和權(quán)限,定期監(jiān)控與維護以確保網(wǎng)絡(luò)正常運行2025-10-10
kubernetes k8s 存儲動態(tài)掛載配置詳解
這篇文章主要為大家介紹了kubernetes k8s 存儲動態(tài)掛載配置詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪2022-11-11
本文詳細描述了如何在VMware虛擬機上基于CentOS8操作系統(tǒng)搭建Kubernetes集群,包括環(huán)境準(zhǔn)備、Docker安裝、Kubernetes組件安裝、網(wǎng)絡(luò)插件配置以及KuboardUI的安裝和訪問2025-01-01
k8s跨服務(wù)調(diào)用入門到實戰(zhàn)示例詳解
這篇文章主要為大家介紹了k8s跨服務(wù)調(diào)用入門到實戰(zhàn)示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2023-09-09
k8s?clientConfig和rawConfig區(qū)別解析
k8s clientConfig和rawConfig區(qū)別k8s.io/client-gov0.28.2基于kubeconfig可以創(chuàng)建clientConfig和rawConfig,兩者區(qū)別在于,clientConfig包含了訪問kube-apiserver的地址和認證鑒權(quán)信息,感興趣的朋友一起看看吧2025-03-03
本次部署方式為setafulset的方式部署rabbitmq集群，使用svc的無頭服務(wù)，本次涉及使用到的服務(wù)有setafulset、secret、configmap、service、pv、pvc、sa，在rabbitmq的官網(wǎng)中使用的是operator的方式，感興趣的朋友一起看看吧2024-03-03
這篇文章主要介紹了Kubernetes(k8s)常用yaml配置和注釋方式,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2025-05-05
本文介紹了Kubernetes中Token的生成、管理和使用方法,包括生成默認24小時Token和永久有效Token,以及查看、刪除Token和獲取CA證書Hash值,此外,還提供了Node節(jié)點加入K8s集群的完整命令2026-01-01
Kubernetes中使用PersistentVolume掛載云盤方式
這篇文章主要介紹了Kubernetes中使用PersistentVolume掛載云盤方式,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-02-02