K8s服务无法Ping

时间:2019-01-26 02:27:35

标签: kubernetes ping minikube nslookup coredns

我在minikube集群(amq名称空间中的名称default)中有一个k8s服务/部署:

D20181472:argo-k8s gms$ kubectl get svc --all-namespaces
NAMESPACE     NAME         TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
argo          argo-ui      ClusterIP      10.97.242.57     <none>        80/TCP            5h19m
default       amq          LoadBalancer   10.102.205.126   <pending>     61616:32514/TCP   4m4s
default       kubernetes   ClusterIP      10.96.0.1        <none>        443/TCP           5h23m
kube-system   kube-dns     ClusterIP      10.96.0.10       <none>        53/UDP,53/TCP     5h23m

我启动了infoblox / dnstools,并尝试了nslookup中的digpingamq.default,结果如下:

dnstools# nslookup amq.default
Server:     10.96.0.10
Address:    10.96.0.10#53

Name:   amq.default.svc.cluster.local
Address: 10.102.205.126

dnstools# ping amq.default
PING amq.default (10.102.205.126): 56 data bytes
^C
--- amq.default ping statistics ---
28 packets transmitted, 0 packets received, 100% packet loss
dnstools# dig amq.default

; <<>> DiG 9.11.3 <<>> amq.default
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15104
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;amq.default.           IN  A

;; Query time: 32 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Sat Jan 26 01:58:13 UTC 2019
;; MSG SIZE  rcvd: 29

dnstools# ping amq.default
PING amq.default (10.102.205.126): 56 data bytes
^C
--- amq.default ping statistics ---
897 packets transmitted, 0 packets received, 100% packet loss

(注意:直接ping IP地址会得到相同的结果)

我承认我对DNS的深入了解不是很了解,所以我不确定为什么我可以查找并挖掘主机名,但不能ping通它。

2 个答案:

答案 0 :(得分:6)

  

我承认我对DNS的深入了解不是很了解,所以我不确定为什么我可以查找并挖掘主机名,但不能ping通它。

由于Service IP地址是群集想象力的虚构部分,由iptables或ipvs引起,实际上并不存在。您可以在运行iptables -t nat -L -n(或kube-proxy)的任何节点上通过ipvsadm -ln看到它们,如有用的Debug[-ing] Services页所述

由于它们不是绑定到实际NIC的真实IP,因此它们不会响应Service资源中注册的端口号以外的任何流量。测试服务连接性的正确方法是使用curlnetcat之类的东西,并使用您希望应用程序通信通过的端口号。

答案 1 :(得分:0)

这是因为服务的群集IP是虚拟IP,并且仅在与服务端口结合使用时才有意义。

每当API服务器创建服务时,都会立即为其分配虚拟IP地址,此后,API服务器会通知工作节点上运行的所有kube-proxy代理已创建新服务。然后,让该服务在其运行的节点上可寻址是kube-proxy的工作。 kube-proxy通过设置一些iptables规则来做到这一点,该规则可确保截获目的地为服务IP /端口对的每个数据包,并修改其目标地址,因此该数据包将重定向至支持该服务的Pod之一。

IPs and VIPs