欢迎关注头条号：老顾聊技术
精品原创技术分享，知识的组装工
前言
上篇文章中老顾介绍了相关pod、容器、node之间的通信，通过pod的ip进行通信，存在一定的问题。
Kubernetes Pod是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束。 通过ReplicationController能够动态地创建和销毁Pod（例如，需要进行扩缩容，或者执行滚动升级）。 每个 Pod 都会获取它自己的 IP 地址，可一旦销毁后，重新创建后，IP地址会产生改变。 这会导致一个问题：在 Kubernetes 集群中，如果一组 Pod（称为 backend）为其它 Pod （称为 frontend）提供服务，一旦backend的Pod重新创建，那么frontend的Pod该如何发现，并连接到这组 Pod 中的哪些 backend 呢？
Service
Service资源用于为pod对象提供一个固定、统一的访问接口及负载均衡的能力 ，并借助新一代DNS系统的服务发现功能，解决客户端发现并访问容器化应用的问题。
注意：service只是在k8s集群内部起作用，集群外部访问是无效的
实现原理
Service通过关注定义出多个POD对象组合而成的逻辑集合，以及访问这组POD的策略，Service关联POD需要标签选择器完成，其基于标签选择器将一组POD定义成一个逻辑集合，并通过自己的IP地址和端口调度代理请求至后端POD之上。
<code>apiVersion: v1
kind: Service
metadata:
name: a-service
spec:
selector:
app: pod-label
ports:
- protocol: TCP
port: 80
targetPort: 9376/<code>上面的例子服务a-service关联着label为【app:pod-label】的pod，这时候另一个服务B可以访问跟a-service服务绑定的service，service信息是固定的提前告诉B就行了，service通过Label Selector跟a服务的pod绑定,无论a的pod如何变化对b来说都是透明的。
虚拟IP
service对象的IP地址称为cluster IP，位于K8S集群配置指定的专用IP地址范围内，其是一种虚拟IP地址，其在service对象创建后保持不变，并且能够被同一集群中的POD资源访问，service端口接受客户端的请求并将其转发至后端POD中的相应端口，因此，其又被称为四层代理，因其工作在TCP/IP层。
一个service对象就是工作节点上的一些iptables或ipvs，用于将到达service对象的IP地址的流量转发到相应的endpoint对象指定的IP地址和端口上，kube-proxy组件通过api-server持续监控着各个service及其相关的POD对象，并将其创建或变动实时反映到工作节点的iptable或ipvs上
服务代理
k8s群集中的每个节点都运行一个kube-proxy的组件，kube-proxy其实是一个代理层负责实现service
userspace模式
客户端访问ServiceIP（clusterIP）请求会先从用户空间到内核中的iptables，然后回到用户空间kube-proxy，kube-proxy负责代理工作。
具体细节：
请求到达service后，其被转发到内核，经由套接字送往用户空间的kube-proxy，而后经由kube-proxy送回内核空间，并调度至后端POD，其传输方式效率太低。在1.1 版本之前，其是默认的转发策略。
iptables模式
客户端访问ServiceIP（clusterIP）请求会由iptables直接重定向到后端
具体细节：
客户端IP请求时，直接请求本地内核service ip，根据iptables的规则直接将请求转发到到各pod上，因为使用iptable NAT来完成转发，也存在不可忽视的性能损耗。另外，如果集群中存在上万的Service/Endpoint，那么Node上的iptables rules将会非常庞大，性能还会再打折扣
Kubernetes v1.2之前默认是userspace之后是iptables模式，iptables模式性能和可靠性更好，但是iptables模式依赖健康检查，在没有健康检查的情况下如果一个pod不响应，iptables模式不会切换另一个pod上
ipvs模型
此模型跟踪API service上的service和endpoints对象的变动，据此来调用netlink接口创建IPVS规则，并确保API server中的变动保持同步，其流量调度策略在IPVS中实现，其余的在iptables中实现。
ipvs 支持众多调度算法，如rr、lc、dh、sh、sed和nq 等。
集群外部访问
我们如何在集群外访问service呢？k8s提供了几种方式
NodePort
通过每个 Node 上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 NodeIP:Port，可以从集群的外部访问一个 NodePort 服务。
这时要访问这个Service的话，只需要通过访问
:Port
LoadBalancer
在NodePort基础上，Kubernetes可以请求底层云平台cloud provider 创建一个外部的负载均衡器，并将请求转发到每个Node作为后端，进行服务分发。
该模式需要底层云平台（例如GCE、AWS）支持。
ExternalName
创建一个dns别名指到service name上，主要是防止service name发生变化，要配合dns插件使用。通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容。
这只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持
Ingress
上面我们提到几种方式，但是当集群服务很多的时候，NodePort方式最大的缺点是会占用很多集群机器的端口；LB方式最大的缺点则是每个service一个LB又有点浪费和麻烦，并且需要k8s之外的支持； 而ingress则只需要一个NodePort或者一个LB就可以满足所有service对外服务的需求。工作机制大致可以用下图表示：
Ingress是基于service实现7层路由转发能力的
总结
K8S中的概念还是比较多的，老顾只是抛砖引玉，小伙伴需要了解更多详细的可以查看更多详细的资料。今天老顾就介绍到这里了，谢谢！！！
---End---
老顾的微服务网关分享课程，请大家多多支持
推荐阅读
b、企业级SpringBoot应用多个子项目配置文件规划、多环境支持（一）
c、企业级SpringBoot应用多个子项目配置文件规划、多环境支持（二）
d、企业级SpringBoot应用多个子项目配置文件之配置中心（三）
1、基于RocketMq的SpringCloud Stream框架实战入门
2、如何搭建消息中间件应用框架之SpringCloud Stream
3、面试必备：网关异常了怎么办？如何做全局异常处理？
4、Gateway网关系列(二)：SpringCloud Gateway入门实战，路由规则
5、Gateway网关系列开篇：SpringCloud的官方网关Gateway介绍
6、API网关在微服务架构中的应用，这一篇就够了
7、学习Lambda表达式看这篇就够了，不会让你失望的哦（续篇）
8、Lambda用在哪里？几种场景？
9、为什么会出现Lambda表达式，你知道吗？
10、不说“分布式事务”理论，直接上大厂阿里的解决方案，绝对实用
11、女程序员问到这个问题，让我思考了半天，Mysql的“三高”架构
12、大厂二面：CAP原则为什么只能满足其中两项？而不能同时满足
13、阿里P7二面：聊聊零拷贝的原理
14、秒杀系统的核心点都在这里，快来取
15、你了解如何利用token方式实现分布式Session吗？
16、Mysql索引结构演变，为什么最终会是那个结构呢？让你一看就懂
17、一场比赛涉及到的知识，用通俗易通的方式介绍并发协调
18、企业实战Redis全方面思考，你思考了吗？
19、面试题：Thread的start和run的区别
20、面试题：什么是CAS？CAS的作用以及缺点
21、如何访问redis中的海量数据？避免事故产生
22、如何解决Redis热点问题？以及如何发现热点？
23、如何设计API接口，实现统一格式返回？
24、你真的知道在生产环境下如何部署tomcat吗？
25、分享一线互联网大厂分布式唯一ID设计 之 snowflake方案
26、分享大厂分布式唯一ID设计方案，快来围观
27、你想了解一线大厂的分布式唯一ID生成方案吗？
28、你知道如何处理大数据量吗？(数据拆分篇)
29、如何永不迁移数据和避免热点? 根据服务器指标分配数据量(揭秘篇)
30、你知道怎么分库分表吗？如何做到永不迁移数据和避免热点吗？
31、你了解大型网站的页面静态化吗？
32、你知道如何更新缓存吗？如何保证缓存和数据库双写一致性？
33、你知道怎么解决DB读写分离，导致数据不一致问题吗？
34、DB读写分离情况下，如何解决缓存和数据库不一致性问题？
35、你真的知道怎么使用缓存吗？
36、如何利用锁，防止缓存击穿？重构思想的重要性
37、海量订单产生的业务高峰期，如何避免消息的重复消费？
38、你知道如何保障生产端100%消息投递成功吗？
39、微服务下的分布式session该如何管理？
40、阿里二面：filter、interceptor、aspect应如何选择？很多人中招
41、互联网架构重要组员CDN，很多高级开发都没有实操过，来看这里
42、阿里二面：CDN缓存控制原理，看看能不能难住你
43、SpringCloud Alibaba之Nacos多环境多项目管理
44、SpringCloud Alibaba系列之Nacos配置中心玩法
45、SpringCloud Alibaba之Nacos注册中心
46、SpringCloud Plus版本之SpringCloud Alibaba
47、SpringCloud Alibaba之Nacos集群、持久化
48、SpringCloud Alibaba之Nacos共享配置、灰度配置
49、SpringCloud Alibaba之Sentinel工作原理
50、SpringCloud Alibaba之Sentinel流控管理
51、SpringCloud Alibaba之Sentinel降级管理
52、SpringCloud Alibaba之Sentinel热点参数限流
53、SpringCloud Alibaba之Sentinel的API实战
