深入剖析 Kubernetes
张磊
Kubernetes 社区资深成员与项目维护者
116708 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 57 讲
再谈开源与社区 (1讲)
结束语 (1讲)
深入剖析 Kubernetes
15
15
1.0x
00:00/00:00
登录|注册

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

优势
工作原理
IPVS模式
iptables实现
Round Robin方式
自定义A记录
Pod自动分配的A记录
Headless Service
ClusterIP模式
A记录格式
kube-proxy
负载均衡
工作原理
DNS A记录
Headless Service
ClusterIP模式
思考题
总结
Service
找到容器不容易:Service、DNS与服务发现

该思维导图由 AI 生成,仅供参考

你好,我是张磊。今天我和你分享的主题是:找到容器不容易之 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
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

Kubernetes中的Service对象是实现负载均衡和服务发现的重要组件。通过Service对象,可以将一组Pod实例进行代理,并提供Round Robin方式的负载均衡。Service对象由kube-proxy组件和iptables共同实现,通过创建iptables规则来实现负载均衡。然而,随着Pod数量增加,基于iptables的Service实现会占用大量CPU资源,限制了Kubernetes项目承载更多Pod的能力。为了解决这一问题,Kubernetes还支持IPVS模式的Service,通过IPVS模块实现负载均衡,有效减少了资源占用。文章详细介绍了Service的工作原理和IPVS模式的实现方式,对于想要深入了解Kubernetes服务发现和负载均衡的读者来说,是一篇值得阅读的技术文章。 IPVS模块只负责负载均衡和代理功能,而辅助性的包过滤、SNAT等操作则需要依靠iptables来实现。在大规模集群中,建议为kube-proxy设置--proxy-mode=ipvs来开启IPVS模式,以获得性能提升。此外,文章还介绍了Service与DNS的关系,以及ClusterIP模式和Headless Service的A记录格式。总结来说,Service机制和Kubernetes里的DNS插件帮助解决服务发现问题,提供了Pod的稳定IP地址和DNS名字。读者应根据具体需求进行合理选择。

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

全部留言(52)

  • 最新
  • 精选
  • 纳爱斯
    老师,是每个 node 上都会有 iptables 的全部规则吗

    作者回复: 对

    2019-04-11
    37
  • 甘陵笑笑生
    请教一下 service的VIP设置后会变吗 如果变 什么时候会变

    作者回复: 不会的,除非删除svc

    2019-05-14
    2
    5
  • AmyHuang
    老师 现在有个问题请教:service 三副本 把一个副本所在节点驱逐,pod迁移到新的节点有一段时间可以telnet podip +port,但是直接curl service +port 会有数据中断,这个可能是我们设置什么导致呢?

    作者回复: 这个很复杂,需要跟踪整个数据链路来做判断,尤其是iptables规则是不是被周期性改动了

    2020-03-10
    2
    1
  • 追寻云的痕迹
    iptables是万恶之源,在复杂系统中,网络处理越简单越好。现在k8s这套玩法,给实际工作中的运维排错带来极大的麻烦。
    2018-11-16
    2
    88
  • 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,好像没得到支持。
    2019-04-30
    2
    35
  • DJH
    老师,..svc.cluster.local这些点前面的东西能写全吗?录音听了N次也没记下来。文字不行的话能不能弄个图片?
    2018-11-16
    29
  • 勤劳的小胖子-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
    2019-01-04
    27
  • djfhchdh
    ipvs负载均衡:round robin least connection destination hashing source hashing shortest expected delay never queue overflow-connection
    2019-11-25
    17
  • runner
    请问老师,每个节点会有全部的iptables规则么,还是只有自己所属服务的规则? 如果服务是nodePort类型,它会在所有节点上占用端口?还是容器所在的几个节点占用端口?
    2018-11-16
    2
    11
  • 双叶
    不太赞同 ipvs 比 iptables 快是因为把更多的操作放到了内核里面,不管 ipvs 还是 iptables,他的所有逻辑都是在内核里面跑的,只是 iptables 需要遍历规则,而规则数量会跟随 pod 数量增长,导致时间复杂度是 O(n),而 ipvs 是专门做负载均衡的,时间复杂度是 O(1)。 这篇文章里面有比较细致的说明:https://www.tigera.io/blog/comparing-kube-proxy-modes-iptables-or-ipvs/ 基本来说,就是 iptables 不能放太多规则
    2022-07-11
    9
收起评论
显示
设置
留言
52
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部