代码之家  ›  专栏  ›  技术社区  ›  horcle_buzz

K8S服务不可Ping

  •  1
  • horcle_buzz  · 技术社区  · 6 年前

    我在Minikube集群中有一个K8S服务/部署(名称 amq 在里面 default 命名空间:

    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 , dig ping 属于 amq.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 回复  |  直到 6 年前
        1
  •  6
  •   mdaniel    6 年前

    诚然,我不太了解DNS的深层次工作,所以我不知道为什么我可以查找和挖掘主机名,但不能ping它。

    因为 Service IP地址是集群想象中的虚构,由IPtables或IPV引起,实际上并不存在。你可以看到他们 iptables -t nat -L -n 在任何正在运行的节点上 kube-proxy (或) ipvsadm -ln ,如帮助者所述 Debug[-ing] Services

    由于它们不是绑定到实际NIC的真正IP,因此除了在 服务 资源。针对服务测试连接性的正确方法是 curl netcat 并使用您期望应用程序流量通过的端口号。

        2
  •  0
  •   Vikram Jakhar    6 年前

    这是因为服务的群集IP是一个虚拟IP,只有与服务端口结合时才有意义。

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

    IPs and VIPs