目录
服务service
service是一个抽象概念，定义了一个服务的多个pod逻辑合集和访问pod的策略，一般把service称为微服务
举个例子一个a服务运行3个pod，b服务怎么访问a服务的pod，pod的ip都不是持久化的重启之后就会有变化。这时候b服务可以访问跟a服务绑定的service，service信息是固定的提前告诉b就行了，service通过Label Selector跟a服务的pod绑定,无论a的pod如何变化对b来说都是透明的
kind: Service apiVersion: v1 metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376port 端口是service对外暴露的端口，任何人访问80端口都会被service代理到后端pod的9376端口
服务代理
k8s群集中的每个节点都运行一个kube-proxy的组件，kube-proxy其实是一个代理层负责实现service
kube-proxy代理模式有三种：
代理模式：userspace
客户端访问ServiceIP（clusterIP）请求会先从用户空间到内核中的iptables，然后回到用户空间kube-proxy，kube-proxy负责代理工作。
具体细节：
每个service都会由kube-proxy在node节点上起一个随机的代理端口，iptables会捕捉clusterIP上的端口(port)流量重定向代理端口，访问代理端口的任何连接都会被代理到service后端的某一个pod，默认情况下对后端pod的选择是轮询
代理模式：iptables
客户端访问ServiceIP（clusterIP）请求会由iptables直接重定向到后端
具体细节：
每个service都会由kube-proxy（监控 kube-control）生成一组iptables规则，iptables（nat 表）会捕捉clusterIP上的端口(targetPort)流量重定向后端某一个pod，默认对pod的选择是随机的
Kubernetes v1.2之前默认是userspace之后是iptables模式，iptables模式性能和可靠性更好，但是iptables模式依赖健康检查，在没有健康检查的情况下如果一个pod不响应，iptables模式不会切换另一个pod上
Kubernetes v1.9版本会支持lvs的ipvs模式目前还是beta版
代理模式：ipvs模型
它是直接有内核中的ipvs规则来接受Client Pod请求，并处理该请求,再有内核封包后，直接发给指定的Server Pod。