Service
为什么要使用Service？
- 由于Pods的IP会随着重建而更新，所以导致客户端难以准确访问Pod，所以放了方便客户端请求，需要使用Service创建一个固定访问端点
- 期望使用更弱的依赖的DNS来请求Pod服务
- 使用ingress来坐七层调度
官方的回答：if some set of Pods (let’s call them backends) provides functionality to other Pods (let’s call them frontends) inside the Kubernetes cluster, how do those frontends find out and keep track of which backends are in that set?
Service的特点？
- 生命周期内地址不会发生变化
- 动态感知Pod变化并及时更新调度
- 支持负载均衡与会话保持机制
Service的工作原理？
K8S发展的很快，Service的实现也迭代了三个版本
In Kubernetes v1.0, Services are a “layer 4” (TCP/UDP over IP) construct, the proxy was purely in userspace. In Kubernetes v1.1, the Ingress API was added (beta) to represent “layer 7”(HTTP) services, iptables proxy was added too, and became the default operating mode since Kubernetes v1.2. In Kubernetes v1.8.0-beta.0, ipvs proxy was added.
Proxy-mode: userspace
概述 在这个模式，kube-proxy会监听关于Service的变更以及Endpoint对象(暂时不清楚这是什么)，对于每一个Service，kube-proxy都会选择一个本地的随机端口，姑且称之为代理端口，任何到这个"代理端口"的连接，都会转发到对应后端的Pods，默认情况下调度策略是轮训。
流程图
Proxy-mode: iptables
概述 在这个模式下，kube-proxy不再处理请求的转发了，仅监听关于Service的变更并更新Service调度后端，而客户端连接ServiceIP时会直接通过iptables调度到后端Pods。
流程图
Proxy-mode: ipvs
概述
而在Kubernetes v1.9以后，kubernetes支持了第三种模式，ipvs。
在这个模式下，kube-proxy依旧会检测Service和Endpoint，通过netlink创建i相应的ipvs规则，同时会定期同步Service和Endpoint信息，以确保ipvs运行正常。当客户端连接到达ServiceIP，会自动调度到对应的后端
与iptable类似，ipvs也是基于netfilter钩子函数，但是ipvs使用hash结构作为底层数据结构并且工作在内核空间，所以它的转发会更快，同步规则时性能也更好，除此之外，ipvs还提供了更加丰富的调度策略
- rr: round-robin
- lc: least connection
- dh: destination hashing
- sh: source hashing
- sed: short excepted deplay
- nq: never queue
不过，需要注意一个问题，ipvs模式需要用到IPVS内核模块，所以如何没有安装的话，kube-proxy会退而求其次，使用iptables规则
流程图
补充资料
官方文档：https://kubernetes.io/docs/concepts/services-networking/service/