示例终于都可以工作了，深化理解。
一种是通过<serviceName>.<namespace>.svc.cluster.local访问。对应于clusterIP
另一种是通过<podName>.<serviceName>.<namesapce>.svc.cluster.local访问,对应于headless service.
/ # nslookup *.default.svc.cluster.local
Server: 10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name: *.default.svc.cluster.local
Address 1: 10.244.1.7 busybox-3.default-subdomain.default.svc.cluster.local
Address 2: 10.96.0.1 kubernetes.default.svc.cluster.local
Address 3: 10.97.103.223 hostnames.default.svc.cluster.local

描述一个实际使用中遇到kube-proxy的一个问题。我使用service的nodeport模式对外发布服务，前端使用openresty做代理的，upstream就配置node ip+nodeport。在使用过程中发现openresty经常不定期报104:connection reset by peer when read response head这个错误，从错误看出openstry从nodeport读取数据的时候tcp连接被重置了，使用同一openresty的后端是普通虚拟机的节点的服务却没有这个问题，问题还有个特点就是某个服务长时间没有被访问，第一次点击的时候就会出现，然后后面就好了。nodeport是被kube-proxy监听的，问题就出在openresty与kube-proxy的tcp连接上，能否帮忙分析kube-proxy为何会重置连接？

看到也有同学问pod DNS，希望能讲得更详细些。我查阅官方文档及自己实践后的了解是这两种pod有DNS记录：
1. statefulset的pod。有人问之前讲DNS的是在哪，就是“20 | 深入理解StatefulSet（三）：有状态应用实践”这一篇。
2. pod显式指定了hostname和subdomain，并且有个headless service的名字和subdomain一样。在“27 | 聪明的微创新：Operator工作原理解读”一篇中讲到的etcd operator就是这样让pod拥有了DNS记录。Deployment的pod template也可以指定hostname和subdomain，但是却没办法给每个pod分配不同的hostname。指定hostname和subdomain之后，hostname.subdomain.default.svc.cluster.local这样的域名确实可以解析，但是因为多个pod都是这个FQDN，所以解析出来的效果和headless service一样，多个A记录，也就失去意义了。github上有个issue想让deployment管理的pod也有独立的DNS，好像没得到支持。

您好，我使用coreDNS插件版本是1.2.6
配置文件的内容：
Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local. in-addr.arpa ip6.arpa {
            pods insecure
            upstream
            fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        proxy . 100.64.255.100 223.5.5.5 11.125.1.12
        cache 30
        loop
        reload
        loadbalance
    }
在解析公网的域名的时候会有小概率随机出现unknown host，请问会是什么问题

"我在前面的文章中还介绍过 Service 与 DNS 的关系."可以帮忙指明一下是第几章吗？找了一圈没找到。

另外：试着通过域名访问hostanmes，不行。通过ip可以。
vagrant@kubeadm1:~/37ServiceDns$ curl hostnames.svc.cluster.local:80
curl: (6) Could not resolve host: hostnames.svc.cluster.local

vagrant@kubeadm1:~/37ServiceDns$ curl 10.110.252.216:80
hostnames-84985c9fdd-sgwpp

ipvs负载均衡：round robin
    least connection
    destination hashing
    source hashing
    shortest expected delay
    never queue
    overflow-connection

示例里这里打出来的 endpoints ip：
kubectl get endpoints hostnames
NAME ENDPOINTS
hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376

与下面的 iptables 规则里的 endpoint ip 对不上
-A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
-A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376

-A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
-A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.1.7:9376

-A KUBE-SEP-X3P2623AGDH6CDF3 -s 10.244.2.3/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
-A KUBE-SEP-X3P2623AGDH6CDF3 -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.2.3:9376

是不是中间重新部署过？