“/sys/class/net/eth0/iflink”如何在容器中擁有系統範圍的資訊

我一直在尋找 tcpdump Kubernetes pod 的方法。每個 pod 創建一個虛擬介面，很難知道哪個介面屬於實際的 pod。我找到了一種有助於辨識系統範圍介面索引的方法。基本上，可以cat /sys/class/net/eth0/iflink在目標 pod 中執行的容器內部，它會顯示主機網路介面索引。這樣你就可以知道屬於 pod 的 veth。

所以，它起作用了，但它讓我思考……如果我應該在容器的網路命名空間中，為什麼我可以在網路上獲取系統範圍的資訊。所以，我不應該訪問系統範圍的索引，我應該只看到虛擬介面的虛擬“命名空間”索引。

是否有任何解釋如何/sys/class/net/eth0/iflink與 K8s 內部的網路命名空間相關？

該iflink值不是系統範圍的值。它是對等網路 nsid 中​​有效的值，例如顯示為 all ip link show dev eth0（因為它是veth與其他網路命名空間中的對等方的介面）。對於小細節，對等網路 nsid 不是系統範圍的值，而是僅在將（系統範圍）對等網路連結到此（系統範圍）網路命名空間的目前網路命名空間中有效的值，因為在某些情況下移動相關界面的時間。

這是一個範例，使用ip netns addand ip netns exec（它也正確（重新）安裝/sys在自己的安裝命名空間中，以便能夠使用 中的網路條目/sys）。

# ip netns add n1
# ip netns add n2
# ip netns add n3
# ip netns add n4

# ip -n n1 link add name ton2 index 42 type veth peer netns n2 name eth0
# ip -n n3 link add name ton4 index 42 type veth peer netns n4 name eth0


# ip netns exec n2 cat /sys/class/net/eth0/iflink
42
# ip -n n2 link show dev eth0
2: eth0@if42: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
   link/ether 0e:27:6f:19:05:02 brd ff:ff:ff:ff:ff:ff link-netns n1
# ip netns exec n4 cat /sys/class/net/eth0/iflink
42
# ip -n n4 link show dev eth0
2: eth0@if42: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
   link/ether fe:09:53:11:84:d6 brd ff:ff:ff:ff:ff:ff link-netns n3

兩個介面都有一個索引值為 42 的對等鏈路，但這並不代表同一個介面：一個值 42 是ton2netns n1 中的索引值，另一個是ton4netns n3 中的索引值。如果現代版本ip link沒有將 link-nsid 解析為ip netns add對等命名空間指定的實際名稱，它們都將顯示link-netnsid 0如下（因為這是唯一的對等網路命名空間，並且連結 nsid 預設從 0 開始，除非設置否則，在每個網路命名空間中），同樣 0 不是系統範圍的。

# stat -f -c %T /run/netns/n1 /run/netns/n3
nsfs
nsfs
# stat -c %i /run/netns/n1 /run/netns/n3
4026533318
4026533590

對等點的實際系統範圍值是網路命名空間 + 索引。這將是 4026533318:42 和 4026533590:42 。ip netns但是，如果一個人不知道它是如何創建的（這裡留下了一個掛載的引用） ，那麼當它恰好不是初始網路命名空間（如本例中）時，簡單地找出這個網路命名空間可能會非常具有挑戰性/run/netns。

我所做的這個答案中提供了有關此的其他資訊。

引用自：https://unix.stackexchange.com/questions/687546