点击阅读原文

前提: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

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐