37 | 找到容器不容易：Service、DNS与服务发现

张磊

你好，我是张磊。今天我和你分享的主题是：找到容器不容易之 Service、DNS 与服务发现。
在前面的文章中，我们已经多次使用到了 Service 这个 Kubernetes 里重要的服务对象。而 Kubernetes 之所以需要 Service，一方面是因为 Pod 的 IP 不是固定的，另一方面则是因为一组 Pod 实例之间总会有负载均衡的需求。
一个最典型的 Service 定义，如下所示：
apiVersion: v1
kind: Service
metadata:
  name: hostnames
spec:
  selector:
    app: hostnames
  ports:
  - name: default
    protocol: TCP
    port: 80
    targetPort: 9376
这个 Service 的例子，相信你不会陌生。其中，我使用了 selector 字段来声明这个 Service 只代理携带了 app=hostnames 标签的 Pod。并且，这个 Service 的 80 端口，代理的是 Pod 的 9376 端口。
然后，我们的应用的 Deployment，如下所示：
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hostnames
spec:
  selector:
    matchLabels:
      app: hostnames
  replicas: 3
  template:
    metadata:
      labels:
        app: hostnames
    spec:
      containers:
      - name: hostnames
        image: k8s.gcr.io/serve_hostname
        ports:
        - containerPort: 9376
          protocol: TCP
这个应用的作用，就是每次访问 9376 端口时，返回它自己的 hostname。
而被 selector 选中的 Pod，就称为 Service 的 Endpoints，你可以使用 kubectl get ep 命令看到它们，如下所示：
$ kubectl get endpoints hostnames
NAME        ENDPOINTS
hostnames   10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376
需要注意的是，只有处于 Running 状态，且 readinessProbe 检查通过的 Pod，才会出现在 Service 的 Endpoints 列表里。并且，当某一个 Pod 出现问题时，Kubernetes 会自动把它从 Service 里摘除掉。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《深入剖析 Kubernetes》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(51)

最新
精选

纳爱斯
老师，是每个 node 上都会有 iptables 的全部规则吗
作者回复: 对

36
甘陵笑笑生
请教一下 service的VIP设置后会变吗如果变什么时候会变
作者回复: 不会的，除非删除svc
2
3
AmyHuang
老师现在有个问题请教：service 三副本把一个副本所在节点驱逐，pod迁移到新的节点有一段时间可以telnet podip +port，但是直接curl service +port 会有数据中断，这个可能是我们设置什么导致呢？
作者回复: 这个很复杂，需要跟踪整个数据链路来做判断，尤其是iptables规则是不是被周期性改动了
2
1
追寻云的痕迹
iptables是万恶之源，在复杂系统中，网络处理越简单越好。现在k8s这套玩法，给实际工作中的运维排错带来极大的麻烦。
2
86
qingbo
看到也有同学问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，好像没得到支持。
2
35
DJH
老师，..svc.cluster.local这些点前面的东西能写全吗？录音听了N次也没记下来。文字不行的话能不能弄个图片？

28
勤劳的小胖子-libo
示例终于都可以工作了，深化理解。一种是通过<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

26
djfhchdh
ipvs负载均衡：round robin least connection destination hashing source hashing shortest expected delay never queue overflow-connection

16
runner
请问老师，每个节点会有全部的iptables规则么，还是只有自己所属服务的规则？如果服务是nodePort类型，它会在所有节点上占用端口？还是容器所在的几个节点占用端口？
2
11
李康
-A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 -A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 -A KUBE-SEP-X3P2623AGDH6CDF3 -s 10.244.2.3/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 问下为啥源地址是这个啊？现在数据包源地址不应该是客户端的地址吗？
1
8

收起评论