GCE 容器网络调试
经常在网上各种找各种命令，感觉非常麻烦。难得放假有空了，我决定以 Kubernetes GCE 部署方式，整理出整个网络架构，记录下常用命令。
首要问题，怎样才能给每个容器分配一个独立 IP？GCE 上的 VM 可以在 VPC 下划分 subnet。也就是说一个 VM 有相当于一个小 VPC了，每个容器又在这小 VPC 上分一个 IP。在主机上看 route (note: 也可使用 route -n):
# ip route
default via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.3 metric 1024
default via 10.240.0.1 dev eth0 proto dhcp metric 1024
10.28.6.0/24 dev cbr0 proto kernel scope link src 10.28.6.1
10.240.0.1 dev eth0 proto dhcp scope link src 10.240.0.3 metric 1024
10.240.0.1 dev eth0 proto dhcp scope link metric 1024
169.254.123.0/24 dev docker0 proto kernel scope link src 169.254.123.1 linkdown
这里我们发现有容器 subnet "10.28.6.0/24", 对 subnet 的访问是通过 cbr0。进一步检测可以发现 cbr0 是一个网桥:
# ip -d link list
4: cbr0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1460 qdisc htb state UP mode DEFAULT group default qlen 1000
link/ether 0a:58:0a:1c:06:01 brd ff:ff:ff:ff:ff:ff promiscuity 1
bridge forward_delay 1500 hello_time 200 max_age 2000 ageing_time 30000 stp_state 0 priority 32768 vlan_filtering 0 bridge_id 8000.a:58:a:1c:6:1 designated_root 8000.a:58:a:1c:6:1 root_port 0 root_path_cost 0 topology_change 0 topology_change_detected 0 hello_timer 0.00 tcn_timer 0.00 topology_change_timer 0.00 gc_timer 216.69 group_fwd_mask 0 group_address 01:80:c2:00:00:00 mcast_snooping 1 mcast_router 1 mcast_query_use_ifaddr 0 mcast_querier 0 mcast_hash_elasticity 4 mcast_hash_max 512 mcast_last_member_count 2 mcast_startup_query_count 2 mcast_last_member_interval 100 mcast_membership_interval 26000 mcast_querier_interval 25500 mcast_query_interval 12500 mcast_query_response_interval 1000 mcast_startup_query_interval 3125 nf_call_iptables 0 nf_call_ip6tables 0 nf_call_arptables 0 addrgenmode eui64 numtxqueues 1 numrxqueues 1
容器又是怎样被分配 IP 的呢？这个跟 Kubelet "--network-plugin" 有关。同时也涉及到大家耳熟能详的 CNI 了。但是 GCE 上的使用的是 kubenet:
# ps aux | grep kubelet
/home/kubernetes/bin/kubelet ... --network-plugin=kubenet
kubenet 文档 link。其实就两句话能说清：
Kubenet creates a Linux bridge named
cbr0and creates a veth pair for each pod with the host end of each pair connected tocbr0. The pod end of the pair is assigned an IP address allocated from a range assigned to the node either through configuration or by the controller-manager.
跟 cnitool 基本类似。
下面进一步检测这里提及的 veth pair。
首先，在本机上是没法看到任何 network namespace:
# ip netns list
啥都没有。读 ip-netns 文档 可以知道需要有 /var/run/netns/NAME。
首先我们选个容器去找 PID:
# docker ps
fd3943d09a51 ...
# docker inspect fd3943d09a51 | grep -i pid
"Pid": 2497,
然后通过 PID link 它的 netns 到 /var/run/netns/$NAME
# ln -s /proc/2497/ns/net /var/run/netns/test
# ip netns list
test
现在我们就可以看到这个 netns 了。
然后进入这个 netns 找出这个容器的 veth interface:
注：还有其他方式如 nsenter
# ip netns exec test ip -d addr list
3: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default
link/ether 0a:58:0a:1c:06:05 brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0
veth numtxqueues 1 numrxqueues 1
inet 10.28.6.5/24 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::544d:c1ff:fe20:9732/64 scope link
valid_lft forever preferred_lft forever
可以看到这个容器里面 eth0是 veth，IP 是 "10.28.6.5/24"。
进一步找出它的 peer index:
# ip netns exec test ethtool -S eth0
NIC statistics:
peer_ifindex: 8
在 host 上找到对应的 interface:
# ip link list
8: veth044b5046@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue master cbr0 state UP mode DEFAULT group default
link/ether 26:1c:5a:35:e0:3b brd ff:ff:ff:ff:ff:ff link-netnsid 3
确定这个 veth 在 cbr0 上:
# brctl show
bridge name bridge id STP enabled interfaces
cbr0 8000.0a580a1c0601 no veth044b5046
...
Voila! 这样整条链路就清晰了。如下图所示:
container network.png
