Điểm:0

Làm cách nào để các giao diện veth kết nối với nhau trên hộp linux?

lá cờ in
JMC

Gần đây tôi đã chơi với cụm Google Kubernetes Engine. Tôi có một câu hỏi liên quan đến CNI của họ. Tôi đã đọc từ các tài liệu GCP và các bài viết khác rằng có một cầu nối mà tất cả các giao diện veth kết nối với. Về cơ bản, đối với mỗi vùng chứa, một cặp veth được tạo. Một đầu của nó nằm trong thùng chứa và đầu kia của nó được kết nối với thiết bị cầu nối. Khi các thùng chứa trên cùng một nút giao tiếp với nhau, việc trao đổi gói đang sử dụng thiết bị cầu nối lớp 2. Đây cũng là cách tài liệu GKE mô tả.

https://cloud.google.com/kubernetes-engine/docs/concepts/network-overview#pods

https://medium.com/cloudzone/gke-networking-options-explained-demonstrated-5c0253415eba

Tôi đã tạo một cụm trên Google, tôi có thể thấy có một thiết bị cầu nối docker0, nhưng không có giao diện nào được liên kết với nó.

gke-xxxxxxxxx /home/uuuuuuu # brctl show
tên cầu id cầu giao diện hỗ trợ STP
docker0 8000.0242fd0b0cf4 không      
gke-xxxxxxxxxx /home/uuuuuuu # 

Sau đó, tôi đã tạo một cụm bằng Virtualbox, tôi có thể thấy các giao diện được liên kết với thiết bị cầu nối.

[root@k8s-2 ~]# brctl show
tên cầu id cầu giao diện hỗ trợ STP
cni0 8000.36dae477639c không veth7f6c1f01
                                        vethccd0d71d
                                        vethe63e4285

Điều tôi đang cố giải thích là tại sao tôi không thể tìm thấy thiết bị cầu nối trên máy ảo của Google? Có tính năng đặc biệt nào của Linux Kernel được sử dụng trong trường hợp này không?

Khi tôi kiểm tra từng giao diện veth trên Google VM, tất cả chúng đều có cùng địa chỉ IP 10.188.2.1

gke-xxxxxxxxxxxxxxxxxxxxx /home/user.name # ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
        inet 169.254.123.1 netmask 255.255.255.0 phát sóng 169.254.123.255
        ether 02:42:fd:0b:0c:f4 txqueuelen 0 (Ethernet)
        Gói RX 0 byte 0 (0,0 B)
        Lỗi RX 0 bị rớt 0 tràn 0 khung hình 0
        Gói TX 0 byte 0 (0,0 B)
        Lỗi TX 0 bị rớt 0 tràn 0 sóng mang 0 va chạm 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
        inet 10.10.1.19 netmask 255.255.255.255 phát sóng 0.0.0.0
        inet6 fe80::4001:aff:fe0a:113 tiền tốlen 64 phạm vi 0x20<link>
        ether 42:01:0a:0a:01:13 txqueuelen 1000 (Ethernet)
        Gói RX 2192921 byte 1682211226 (1,5 GiB)
        Lỗi RX 0 bị rớt 0 tràn 0 khung hình 0
        gói TX 1288701 byte 468627202 (446,9 MiB)
        Lỗi TX 0 bị rớt 0 tràn 0 sóng mang 0 va chạm 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
        inet 127.0.0.1 mặt nạ mạng 255.0.0.0
        inet6 ::1 tiền tốlen 128 phạm vi 0x10<máy chủ>
        vòng lặp txqueuelen 1000 (Local Loopback)
        Gói RX 276348 byte 153128345 (146,0 MiB)
        Lỗi RX 0 bị rớt 0 tràn 0 khung hình 0
        Gói TX 276348 byte 153128345 (146,0 MiB)
        Lỗi TX 0 bị rớt 0 tràn 0 sóng mang 0 va chạm 0

veth27cee774: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
        inet 10.188.2.1 netmask 255.255.255.255 phát sóng 10.188.2.1
        inet6 fe80::10b7:98ff:fe2f:2e08 tiền tốlen 64 phạm vi 0x20<link>
        ether 12:b7:98:2f:2e:08 txqueuelen 0 (Ethernet)
        Gói RX 32 byte 2306 (2,2 KiB)
        Lỗi RX 0 bị rớt 0 tràn 0 khung hình 0
        Gói TX 10 byte 710 (710,0 B)
        Lỗi TX 0 bị rớt 0 tràn 0 sóng mang 0 va chạm 0

veth6eba4cdf: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
        inet 10.188.2.1 netmask 255.255.255.255 phát sóng 10.188.2.1
        inet6 fe80::c4e3:b0ff:fe5f:63da tiền tốlen 64 phạm vi 0x20<link>
        ether c6:e3:b0:5f:63:da txqueuelen 0 (Ethernet)
        Gói RX 537091 byte 138245354 (131,8 MiB)
        Lỗi RX 0 bị rớt 0 tràn 0 khung hình 0
        gói TX 477870 byte 122515885 (116,8 MiB)
        Lỗi TX 0 bị rớt 0 tràn 0 sóng mang 0 va chạm 0

veth8bcf1494: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
        inet 10.188.2.1 netmask 255.255.255.255 phát sóng 10.188.2.1
        inet6 fe80::70cb:c4ff:fe8c:a747 tiền tốlen 64 phạm vi 0x20<link>
        ether 72:cb:c4:8c:a7:47 txqueuelen 0 (Ethernet)
        Gói RX 50 byte 3455 (3,3 KiB)
        Lỗi RX 0 bị rớt 0 tràn 0 khung hình 0
        Gói TX 28 byte 2842 (2,7 KiB)
        Lỗi TX 0 bị rớt 0 tràn 0 sóng mang 0 va chạm 0

vethbb2135c7: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
        inet 10.188.2.1 netmask 255.255.255.255 phát sóng 10.188.2.1
        inet6 fe80::1469:daff:fea0:8b5b tiền tốlen 64 phạm vi 0x20<link>
        ether 16:69:da:a0:8b:5b txqueuelen 0 (Ethernet)
        Gói RX 223995 byte 82725559 (78,8 MiB)
        Lỗi RX 0 bị rớt 0 tràn 0 khung hình 0
        Gói TX 239258 byte 60203574 (57,4 MiB)
        Lỗi TX 0 bị rớt 0 tràn 0 sóng mang 0 va chạm 0

vetheee4e8e3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
        inet 10.188.2.1 netmask 255.255.255.255 phát sóng 10.188.2.1
        inet6 fe80::ec6c:3bff:fef3:70c2 tiền tốlen 64 phạm vi 0x20<link>
        ether ee:6c:3b:f3:70:c2 txqueuelen 0 (Ethernet)
        Gói RX 311669 byte 40562747 (38,6 MiB)
        Lỗi RX 0 bị rớt 0 tràn 0 khung hình 0
        Gói TX 304461 byte 628195110 (599,0 MiB)
        Lỗi TX 0 bị rớt 0 tràn 0 sóng mang 0 va chạm 0

Điều gì đằng sau các giao diện veth này?

Cảm ơn trước

lá cờ vn
Không phải tài liệu thứ 2 mà bạn liên kết giải thích nó sao? "Với Calico, không có cầu nối mạng L2 trong nút và thay vào đó, định tuyến L3 được sử dụng cho tất cả lưu lượng giữa các nhóm"
JMC avatar
lá cờ in
JMC
Cảm ơn Mark. Nếu bạn thấy ví dụ của tôi, tất cả các giao diện đều có tiền tố là veth thay vì cali. Cụm của tôi không sử dụng CNI calico.
Alex G avatar
lá cờ ar
Nếu bạn muốn xem các gói truyền từ/đến pod cidr, hãy chỉ định cbr0, đây là cầu nối Linux có tất cả các giao diện veth được kết nối với tất cả các vùng chứa. Sử dụng `tcpdump -i cbr0` có thể giúp khắc phục sự cố.
JMC avatar
lá cờ in
JMC
@AlexG Có vẻ như cbr0 không tồn tại. Tôi chỉ có thể thấy các giao diện của veth chứ không thể thấy thiết bị cầu nối, đây là một điều bí ẩn. Dù sao đi nữa, những gì tôi phát hiện ra là cbr0 vẫn tồn tại nếu tôi sử dụng phiên bản cũ hơn. Tôi đã thử phiên bản 1.18-gke. Phiên bản này sử dụng docker làm thời gian chạy vùng chứa và nó có thiết bị cbr0. Bắt đầu từ 1.19.x-gke-xxxx, các nút GKE sử dụng containerd làm thời gian chạy và thiết bị cbr0 không còn được tạo nữa.
Điểm:1
lá cờ ar

Nếu cây cầu đã có giao diện, The chương trình brctl lệnh có thể được sử dụng để xem chi tiết giao diện và cầu nối của nút. Có vẻ như bạn chưa giới thiệu bất kỳ giao diện nào cho cây cầu trong tình huống của mình. Bạn có thể thêm giao diện vào cây cầu với Sudo brctl addif docker0 veth0và bạn có thể nhận tất cả các chi tiết giao diện và cầu cần thiết trong một nút bằng cùng một lệnh. Kiểm tra tài liệu này để tham khảo.

JMC avatar
lá cờ in
JMC
Với một cụm hoạt động đầy đủ, không cần thiết phải thêm veth0 vào docker0. Điều này đã được xử lý khi một nhóm mới được tạo. Như tôi đã đề cập trong nhận xét trên, 1.18-gke là phiên bản cuối cùng vẫn sử dụng cbr0. Tôi tin rằng việc định tuyến các gói được thực hiện theo quy tắc định tuyến. Trong 1.19.x, mọi IP nhóm đều có mục nhập bảng định tuyến riêng.
Alex G avatar
lá cờ ar
Có nhóm nào đã đặt `hostNetwork` thành false trên GKE 1.19 của bạn không?

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.