对k8s service的一些理解

服务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: 9376

port 端口是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版

service的类型

• ClusterIP               默认模式，只能在集群内部访问
• NodePort              在每个节点上都监听一个同样的端口号(30000-32767)，ClusterIP和路由规则会自动创建。集群外部可以访问<NodeIP>:<NodePort>联系到集群内部服务，可以配合外部负载均衡使用（我现在公司用的就是这个模式配合阿里云的SLB）
• LoadBalancer       要配合支持公有云负载均衡使用比如GCE、AWS。其实也是NodePort，只不过会把<NodeIP>:<NodePort>自动添加到公有云的负载均衡当中
• ExternalName       创建一个dns别名指到service name上，主要是防止service name发生变化，要配合dns插件使用