k8s的service为什么不能ping通？——所有的service都不能ping通吗

前提：kube-proxy使用iptables模式

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不通的，这里简单分析一下

objectivec 复制代码

// 这是一个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，如图

sql 复制代码

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通

bash 复制代码

# 添加一个网桥设备
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