一。service的介绍
在K8S中，pod是访问应用程序的载体，我们可以通过pod的ip来访问应用程序，但是pod的ip地址不是固定的，这也意味着不方便直接采用pod的ip对服务进行访问，为了解决这个问题，K8S提供了service资源，service资源会对提供同一个服务的多个pod进行聚合，并且提供统一的入口地址，通过访问service的入口地址就能访问后面的pod服务
service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每一个节点node节点都运行着一个kube-proxy进程，当创建了service的时候会通过api-server向etcd写入创建的service进程，而kube-proxy会基于监听的机制发现这种service的变动，然后它会将最新的service信息转化为对应的访问规则
二。kube-proxy目前支持的三种工作模式：
1.userspace模式：
在该模式下，kube-proxy回味每一个service常见一个监听端口，发向cluster ip的请求被iptables规则重定向到kube-proxy监听的端口上，kube-proxy会根据LB算法选择一个提供服务的pod并创建连接，将请求转发到pod上，kube-proxy充当一个四层负载负责均衡器的角色，由于kube-proxy运行在userspace上，在进行转发处理时会增加内核和用户空间之间的数据拷贝，虽然比较稳点，但是效率低
2.iptables模式：
iptables模式下，kube-proxy为service后端的每一个pod创建对应的iptables规则，直接向cluster ip请求重定向一个pod ip，该模式下kube-proxy不承担四层负载均衡的角色，只负责创建iptable规则，该模式的优点是效率高，但是不能提供灵活的LB策略，当后端pod不可用也无法进行重试
3.ipvs模式：
ipvs模式和iiptables模式相似，kube-proxy监控pod的变化而创建的相应的ipvs规则，ipvs相对iptables转发效率高，除此以外，ipvs支持更多的LB算法
三。Service集群的四大类型
一个service由一组pod组成，这些pod通过endpoint暴漏出来，endpoint是实现实际服务的端口集合，换句话说，service和pod之间的联系是通过endpoint实现的
1.ClusterIP：默认值，它是K8S系统自动分配的虚拟IP，只能在集群内部pod访问
创建service：kubectl create service clusterip nginx-sv1 --tcp=80:80 -n dev --dry-run=client -o yaml > nginx-svc1.yml：生成文件nginx-svc1.yml
启动service：kubectl apply -f nginx-svc1.yml
--------------------------------------------------------------------------------------------------------------------------------
2.NodePort：将service通过指定的Node上的端口暴露给外部，通过此方法，就可以在集群外部访问服务，将service的端口映射到Node的一个端口上，然后就可以通过NodePort来访问servce
-------------------------------------------------------------------------------------------------------------------------------
3.LoadBalancer：使用负载均衡完成服务的分载转发，注意此模式需要外部的云环境支持，目的都是向外部暴露一个端口，区别在于loadbalancer会在集群的外部再来一个负载均衡设备，而这个设备需要外部环境的支持，外部服务发送到这个设备上去请求，会被设备负载之后转发到集群上
三款开源K8S负载均衡器：MetalLB PureLB OpenELB
-------------------------------------------------------------------------------------------------------------------------------
4.ExternaLName：把集群外的服务引入集群内部，直接使用
创建deployment：
kubectl apply -f deploy.ymx：启动文件
为每一个nginx的pod创建页面
测试页面：
四。Headliness类型的service：
在某些场景，不想使用service提供的负载均衡功能，而希望自己来控制负载均衡策略，针对这种情况，K8S提供了Headliness Service，这类service不会分配cluster ip，如果想要访问service，这类service不会分配给cluster ip，如果想要访问service，只能通过service的域名来进行访问
查看域名解析的情况：
访问：dig @10.96.0.10 service-headliness.dev.svc.cluster.local
