Service的定义
-
定义一组pod的访问规则，我们通过Controller创建Pod,通过Service创建的规则去访问pod
Service存在的意义
防止pod失联
-
当我们一个pod想要访问另一个pod暴露的服务时，比如现在我有两个pod,分别部署了前端项目后后端项目，此时前端pod想要访问我的后端pod，但是pod的生命周期是短暂的，随着版本的升级回滚或者弹性伸缩都会导致IP的变化
-
此时Service以一个注册中心得身份出现
-
后端Pod的ip变化都会在Service中更新ip状态，前端pod也是来Service这里所有后端Pod的有效IP,然后进行访问
定义一组pod的访问策略（负载均衡）
-
加入此时我们四个pod,一个前端pod，三个后台pod,此时前端pod想向后台pod发起请求
-
前端Pod去找Service要当前有效的后端Pod的IP,此时Service发现有效的后端Pod有三个之多，
-
在提供给前端有效IP之前，Service会对这三个后端Pod做负载均衡
Pod和Service的关系
-
之前我们已经说到Controller和Pod之间是如何建立关系的。Service与Pod取得联系的方式如出一辙
-
也是通过标签lebel和selector选择器来建立关联
-
上面说到的服务注册&发现，负载均衡也是基于此建立联系
常用的Service类型
-
kubectl expose --help 查看服务的暴露帮助文档，在最下可以看到几个关键字眼
-
ClusterIP
-
一般用于集群的内部使用，比如上面所说的前端Pod访问后端Pod,使用的就是集群内部的IP,对外无效
-
-
NodePort
-
对外访问应用时使用，比如我们的前端Pod是要对外暴露的，面向集群外部的访问
-
-
LoadBalancer
-
对外访问应用时使用，公有云的服务调用
-
环境初始化
-
我们先清空我们所有的pod 、deployment、service
-
kubectl get pods
-
s删除Pod ：kubectl delete pod podName
-
-
kubectl get deployments
-
删除部署信息：kubectl delete deployment depName
-
-
kubectl get service
-
删除Service(SVC)：kubectl delete service serviceName
-
-
ClusterIP：集群内部访问
-
然后我们通过之前web1.yaml部署一下应用
-
kubectl apply -f web1.yaml
-
-
导出web1的发布yaml
-
kubectl expose deployment web1 --port=80 --target-port=80 --dry-run -o yaml > web1Expose.yaml
-
-
查看其内的内容，默认使用的ClusterIP，集群内部访问
-
大致流程为
-
可以看到Service Web1的类型为：ClusterIP ，也就是集群内部所通用的IP,
-
我们可以去集群任意节点做如下测试
-
集群外的服务器是访问不到该服务的
-
NodePort：对集群外暴露服务
-
我们对发布的yaml进行修改一下，修改类型为NodePort
-
然后部署这个yaml，再查看Service信息得到如下所示：
-
测试web2的的类型为NodePort，然后我们看PORT栏，会得到对外暴露的端口信息为：32553
-
此时局域网内所有浏览器是可以通过集群节点节点的Ip:32253访问该Nginx服务
-
LoadBalancer：公有云的服务调用
-
ClusterIP是最基本，只要创建一个Service,就会创建一个ClusterIP
-
创建一个 NodePort 的 Service 时，它也会创建一个 ClusterIP。
-
而如果你创建一个 LoadBalancer，它就会创建一个 NodePort，然后创建一个 ClusterIP。
-
在这里你可以看到LoadBalancer是封装最外层的，也是功能最强大的
node节点一般是内网部署的，外网一般不能直接访问到，若想访问，以下有两种实现方式
在集群节点中，找到一台可以外网访问的机器，安装Nginx，做反向代理，手动把可以访问的节点添加到Nginx里面
LoadBalancer的介入，在基于ClusterIP和已经以NodePort开放的一个服务Service的基础上，向云提供者申请一个负载均衡器，将流量转发到已经以NodePort形式开发的服务Service上。
演示成本过大，不做演示，嘻嘻嘻嘻嘻....