10.实践篇：Service资源的五种代理模式
10.实践篇：Service资源的五种代理模式
Service资源是Kubernetes中最核心的资源对象之一，其定义了一个统一访问的服务入口地址，客户端可以通过这个入口地址访问其背后的一组由Pod副本组成的集群实例。 Service与其后端Pod副本集群之间则是通过Label Selector标签选择器来实现动态注册和调度的。
1.为什么需要Service资源?
我们之前提到过一个控制器：deployment，他会根据rs控制器中定义的用户期望数量，去平衡现有状态和用户状态；也有自己的选择器，关联新增的pod资源。
这两点听上去，貌似也解决了pod动态变更的问题，那我们为什么还需要引入service呢？
service的引入最重要的一点，就是给访问者提供一个固定访问入口的抽象。客户端应该直接向service发起请求，而不是pod；
同时，service通过Label Selector标签选择器来实现与后端pod进行动态注册和调度。
2.Service资源如何管理Pod
1.service通过标签选择器关联至拥有相关标签的Pod对象
2.客户端向Service进行请求，而非直接请求Pod对象
3.Service默认类型为ClusterIP，还有ExternalName，NodePort，LoadBalancer和Headless，共5种类型
service配置字段的查看命令：kubectl explain svc
2.1.ClusterIP
客户端Pod对象访问服务端Pod对象时不会进行源地址转换:
-
二者在同一主机时，源地址为客户端pod地址；
-
二者不在同一主机时，源地址为客户端pod所在节点的flannel或cni地址。
只能在集群内部被访问
2.2.NodePort
可以被集群外部访问到，节点的请求会DNAT到Serviceip，然后再调度至PodIP
2.3.LoadBalancer
需要结合公有云的LBAAS（需要付费），支持动态接入功能。
2.4.ExternalName
将集群外部Service引入集群内部供各客户端使用，需要设置标签选择器，并手动定义一个endpoint资源，指向外部的资源地址。
2.5.Headless
这是一个比较特殊的service类型，有时候，你没必要或者不需要负载均衡和一个对外提供服务的ip地址。
在这种情况下，你可以在.spec.clusterIp中定义None字段，来申明一个Headless Service。
他可以通过coredns组件内部的解析功能，以完成相关地址解析的支持作用。
此外，我们之后会讲到StatefulSet控制器，它就是基于Headless网络所构筑的。
3.Endpoints
endpoints为service中的网络端点，用于接收service发来的请求，并将其转发至相关的上游服务（deployment）。
1) 命令补充
#API配置查看 kubectl explain endpoints #endpoints信息查看 kubectl get endpoints -A
2) 注意：自定义endpoints时，需要与service同名
[root@centos-1 dingqishi]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 4d23h ngx-new ClusterIP 10.96.232.218 <none> 80/TCP 2d5h [root@centos-1 dingqishi]# kubectl get endpoints NAME ENDPOINTS AGE kubernetes 192.168.0.104:6443 4d23h ngx-new 10.244.2.8:80,10.244.2.9:80 2d5h
@版权声明：51CTO独家出品，未经允许不能转载，否则追究法律责任