标签：方式 svc 代理 监控 工作 数据 配置文件 默认值 无法
一、service资源及其实现模型
通过规则定义出由多个pod对象组合而成的逻辑集合，以及访问这组pod的策略。service关联pod资源的规则要借助于标签选择器来完成
1、service资源概述
由deploy等控制器管理的pod对象中断后会由新建的资源对象所取代，而扩缩容后的应用则会带来pod对象群体的变动，随之变化的还有pod的IP地址访问接口等。pod规模的扩容又会使得客户端无法有效地使用新增的pod对象，从而影响达成规模扩展的目的。为此，service资源可以解决此类问题。
service资源基于标签选择器将一组pod定义成一个逻辑组合，并通过自己的IP地址和端口调度代理至组内的pod对象之上。service对象的IP地址也称为cluster IP，它位于k8s集群配置指定专用IP地址范围之内，而且是一种虚拟IP地址，它在service对象创建后即保持不变，并且能够被同一集群中的pod资源所访问。service端口用于接收客户端请求并将其转发至其后端的pod中应用的相应端口上，因此，这种代理机制也称为端口代理或四层代理，它工作于TCP/IP协议栈的传输层。
通过其标签选择器匹配到的后端pod资源不止一个时，service资源能够以负载均衡的方式进行流量调度，实现了请求流量的分发机制。service与pod对象之间的关联关系通过标签选择器以松耦合的方式建立，它可以先于pod对象创建而不会发生错误，于是，创建service和pod资源的任务可由不同的用户分别完成。
service资源会通过api server持续监视着标签选择器匹配到的后端pod对象，并实时跟踪各对象的变动。service并不直接链接至pod对象，它们之间还有一个中间层---endpoint资源对象，它是一个由IP地址和端口组成的列表，这些IP地址和端口则来自于由service的标签选择器匹配到的pod资源。
2、虚拟IP和服务代理
一个service对象就是工作节点上的一些iptables或ipvs规则，用于将到达service对象IP地址的流量调度转发至相应的endpoints对象指向的IP地址和端口之上。工作于每个工作节点的kube-proxy组件通过api server持续监控着各service及与其关联的pod对象，并将其创建和更新实时反映至当前节点上相应的iptables或ipvs规则上。
service IP事实上是用于生成iptables或ipvs规则时使用的IP地址，它仅用于实现k8s集群网络的内部通信，并且进能够将规则中定义的转发服务的请求作为目标地址予以响应。kube-proxy将请求代理至相应端点的方式有三种：userspace、iptables和ipvs。
1、userspace代理模型
这种模型中，kube-proxy负责跟踪aip server上service和endpoint对象的变动，并根据此调整service资源的定义，对于每个service对象，它会随机打开一个本地端口，任何到达此端口的连接请求都将被代理至当前service资源后端的各pod对象上。这种代理模型中，请求流量到达内核空间后经由套接字送往用户空间的kube-proxy，而后由它送回内核空间，并调度至后端pod。这种方式中，请求在内核空间和用户空间来回转发必然导致效率低下。
2、iptables代理模型
iptables代理模型中，kube-proxy负责跟踪api server上service和endpoint对象的变动，并据此做出service资源定义的变动。同时，对于每个service，他都会创建iptables规则直接捕获到达cluster IP和pod的流量，并将其重定向至当前service的后端。在创建service资源时，集群中每个节点上的kube-proxy都会收到通知并将其定义为当前节点上的iptables规则，用于转发工作接口接收到的与此service资源的clusterIP和端口的相关流量。客户端发来的请求流量被相关的iptables规则进行调度和目标地址转换后再转发至集群内的pod对象之上。其缺点是iptables代理模型不会在被选中的后端pod资源无响应时自动进行重定向，而userspace可以。
3、ipvs代理模型
此模型中，kube-proxy跟踪apiserver上service和endpoint对象的变动，据此来调用netlink接口创建ipvs规则，并确保与api server中的变动保持同步。类似于iptables模型，ipvs构建于netfilter的钩子函数之上，但它使用hash表作为底层数据结构并工作于内核空间，因此具有流量转发速度快、规则同步性能好的特性。另外，ipvs支持众多调度算法，如rr、lc、dh、sh、sed和nq等。
二、service资源的基础应用
1、创建service资源
创建service资源对象有两种方法：一种是直接使用kubectl expose命令，另一种是使用资源配置文件。定义service对象时，spec的两个较为常用的内嵌字段分别为selector和ports，分别用于定义使用的标签选择器和要暴露的端口。如下：
apiVersion: v1 kind: Service metadata: name: myapp-svc spec: selector: app: myapp ports: - protocol: TCP port: 80 targetPort: 80
service资源myapp-svc通过标签选择器关联至标签为“app=myapp”的各pod对象，它会自动创建名为pyapp-svc的endpoint资源对象，并自动配置一个clusterIP，暴露的端口由port资源进行指定，后端各pod对象的端口则由targetPort给出，也可以使用同port字段的默认值。
标签：方式 svc 代理 监控 工作 数据 配置文件 默认值 无法
原文地址：https://www.cnblogs.com/caibao666/p/11215342.html
