点击阅读原文
前提：kube-proxy使用iptables模式
Q service能不能ping通？
A: 不能，因为k8s的service禁止了icmp协议
B: 不能，因为clusterIP是一个虚拟IP，只是用于配置netfilter规则，不会实际绑定设备，无法ping通
C: 不同类型的service情况不同，ClusterIP/NodePort类型不能ping通，Headless类型能ping通，Loadbalancer和ExternalName则要实现情况可能通也可能不通
不看文章你的答案是什么？看完文章你懂了吗，留言看你选对了吗
带着上面的问题来分析各个类型的service到底能不能ping通
ClusterIP/NodePort
结论：在Kubernetes中，ClusterIP/NodePort类型的Service的IP地址是虚拟的，并不分配给任何实体【没有实际的mac地址】，因此无法响应ICMP请求，也就是说，它们不能被ping通。这是因为Kubernetes的Service仅仅是一个IP地址和端口的组合，用于负载均衡和服务发现，而不是一个实际的网络接口。
原因
要理解这个问题，首先需要了解一下icmp协议，icmp协议用于探测两台主机之间是否能够通信，而icmp是位于网络层的协议，网络层下还有数据链路层【mac地址在这一层进行封装】主机在接收到一个icmp的【Echo request】请求时，必须回复一个 【Echo replay】才能确认两个主机之间能够通信， 但是在回复 【Echo replay】之前，主机会确认请求中的ip是否是自己，以及Mac地址是否是自己的。【然而虚拟IP是没有mac地址的，所有这个数据被直接丢弃了】
网上有人说是iptables规则导致icmp不通的，这里简单分析一下
// 这是一个service，指向一个nginx服务
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-svc ClusterIP 10.107.203.170 <none> 80/TCP 46h
// 看一下iptables规则
iptables -t nat -nL
KUBE-SVC-MPDWO5I7F77Y2TO2 tcp -- 0.0.0.0/0 10.107.203.170 /* test-istio/nginx-svc:port cluster IP */ tcp dpt:80
// 将tcp协议流量转到 KUBE-SVC-MPDWO5I7F77Y2TO2这个自定义链的规则
这两条规则的意思是 如果不是从30.30.0.0/16【pod的网段】过来的流量统一转到【KUBE-MARK-MASQ，这条规则后续是直接扔给主机进行处理】
第二条规则是统一转到 KUBE-SEP-UWUUHZ6VJ6LOQPVL这条规则处理
iptables -t nat -L KUBE-SEP-UWUUHZ6VJ6LOQPVL -n
规则就是将流量都转到30.30.31.202【只有一个pod】,iptables并没有拒绝icmp协议的数据包
结论： iptables只针对该service的tcp协议做了流量转发，并没有对其他协议进行额外处理，因此与iptables规则无关
补充内容
为什么ipvs的的clusterIP类型的service能够ping通？
因为ipvs将所有的clusterIP都设置在了一个kube-ipvs0的网卡上不再是虚拟IP，如图
51: ipvs0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether ce:8b:5d:28:59:28 brd ff:ff:ff:ff:ff:ff
inet 172.20.42.51/22 scope global ipvs0
valid_lft forever preferred_lft forever
inet6 fe80::cc8b:5dff:fe28:5928/64 scope link
valid_lft forever preferred_lft forever手动模仿ipvs这个实现，也可以让service能够ping通
# 添加一个网桥设备
ip link add br0 type bridge
# 将service的ip绑定到网桥上
ip addr add 10.107.203.170 dev br0
能够ping通，并且不影响正常访问服务
Headless: ClusterIP=None
Headless svc 不会分配 clusterIP，而是返回对应 DNS 的 A 记录，如果 svc 后端有3个 pod 则返回 3 个 pod IP。访问 svc 时会随机选择一个 IP，所以 headless svc 是可以 ping 通的。【ping service的名称，就和ping baidu.com 的原理是一样的】
Loadbalancer
【这个没有现成的环境，没有实验，下面内容是从网上抄下来的】
Loadbalancer 类型 svc 也要看云厂商的具体实现。
-
普通模式：基于 NodePort，LB -> node:nodePort -> pod。ping 的结果跟 NodePort 一致。
-
直连模式：LB 和 pod 处于同一个 VPC 子网，LB -> pod。ping 的结果跟 Headless 一致。
ExternalName
ExternalName 对应 DNS 的 CNAME，如果配置的ExternalName 可以 ping 通则 svc 可以 ping 通。
例如配置为suxueit.com
ping不通，因为我的网站后天服务器设置了禁止icmp协议
再配置为baidu.com
经过分析，可以得到文章开头的答案就是： C
