01Service简介Kubernetes Pod 是有生命周期的它们可以被创建也可以被销毁然而一旦被销毁生命就永远结束。通过 ReplicationController 能够动态地创建和销毁 Pod例如需要进行扩缩容或者执行 滚动升级。每个 Pod 都会获取它自己的 IP 地址即使这些 IP 地址不总是稳定可依赖的。这会导致一个问题在 Kubernetes 集群中如果一组 Pod称为 backend为其它 Pod 称为 frontend提供服务那么那些 frontend 该如何发现并连接到这组 Pod 中的哪些 backend 呢Kubernetes Service 定义了这样一种抽象一个 Pod 的逻辑分组一种可以访问它们的策略 —— 通常称为微服务。这一组 Pod 能够被 Service 访问到通常是通过 Label Selector实现的。Service 通过标签来选取服务后端一般配合 Replication Controller 或者 Deployment 来保证后端容器的正常运行。这些匹配标签的 Pod IP 和端口列表组成 endpoints由 kube-proxy 负责将服务 IP 负载均衡到这些 endpoints 上。1、Service定义服务入口即k8s的Service定义了一个服务的访问入口地址前端的应用通过这个入口地址访问其背后的一组由Pod副本组成的集群实例来自外部的访问请求被负载均衡到后端的各个容器应用上。2、Service与podService与其后端Pod副本集群之间则是通过Label Selector来实现对接的。而RC的作用相当于是保证 Service的服务能力和服务质量始终处于预期的标准。通过分析、识别并建模系统中的所有服务为微服务-Kubernetes Service,最终我们的系统由多个提供不同业务能力而又彼此独立的微服务单元所组成,服务之间通过TCP/IP进行通信,从而形成了我们强大而又灵活的弹性网格,拥有了强大的分布式能力、弹性扩展能力、容错能力,与此同时,我们的程序架构也变得简单和直观许多。3、Service的负载均衡器kube-proxyKubernetes也遵循了上述常规做法,运行在每个Node上的kube-proxy进程其实就是一个智能的软件负载均衡器,它负责把对Service的请求转发到后端的某个Pod实例上,并在内部实现服务的负载均衡与会话保持机制。但Kubernetes发明了一种很巧妙又影响深远的设计: Service不是共用一个负载均衡器的IP地址,而是每个Service分配了一个全局唯一的虚拟IP地址,这个虚拟IP被称为Cluster IP,这样一来,每个服务就变成了具备唯一IP地址的“通信节点”,服务调用就变成了最基础的TCP网络通信问题.02kube-proxyservice工作的核心是kube-proxykube-proxy负责为Service提供cluster内部的服务发现和负载均衡它运行在每个Node计算节点上负责Pod网络代理, 它会定时从etcd服务获取到service信息来做相应的策略维护网络规则和四层负载均衡工作。在K8s集群中微服务的负载均衡是由Kube-proxy实现的它是K8s集群内部的负载均衡器也是一个分布式代理服务器在K8s的每个节点上都有一个这一设计体现了它的伸缩性优势需要访问服务的节点越多提供负载均衡能力的Kube-proxy就越多高可用节点也随之增多。service是一组pod的服务抽象相当于一组pod的LB负责将请求分发给对应的pod。service会为这个LB提供一个IP一般称为cluster IP。kube-proxy的作用主要是负责service的实现具体来说就是实现了内部从pod到service和外部的从node port向service的访问。kube-proxy有三种代理模式userspace、 iptables和ipvs。1.userspacekube-proxy 会监视 Kubernetes 控制平面对 Service 对象和 Endpoints 对象的添加和移除操作。对每个 Service它会在本地 Node 上打开一个端口随机选择。请求先经过iptables规则当捕获到达Service 的 clusterIP和 Port 的请求并重定向到代理端口kube-proxy再由代理端口再代理请求到后端Podv1.2版本之前的默认模式userspace是在用户空间通过kube-proxy来实现service的代理服务service的请求会先从用户空间进入内核iptables然后再回到用户空间由kube-proxy完成后端Endpoints的选择和代理工作这样流量从用户空间进出内核带来的性能损耗是不可接受的因此这种方式已经不用了。2.iptables这种模式kube-proxy 会监视 Kubernetes 控制节点对 Service 对象和 Endpoints 对象的添加和移除。对每个 Service它会配置 iptables 规则从而捕获到达该 Service 的 clusterIP和端口的请求进而将请求重定向到 Service 的一组后端中的某个 Pod 上面。对于每个 Endpoints 对象它也会配置iptables 规则这个规则会选择一个后端组合。默认的策略是kube-proxy 在 iptables 模式下随机选择一个后端。使用 iptables 处理流量具有较低的系统开销因为流量由 Linux netfilter 处理而无需在用户空间和内核空间之间切换。这种方法也可能更可靠。如果 kube-proxy 在 iptables 模式下运行并且所选的第一个 Pod 没有响应 则连接失败。这与用户空间模式不同在这种情况下kube-proxy 将检测到与第一个 Pod 的连接已失败 并会自动使用其他后端 Pod 重试。可以使用 Pod 就绪探测器 验证后端 Pod 可以正常工作以便 iptables 模式下的 kube-proxy仅看到测试正常的后端。这样做意味着你避免将流量通过 kube-proxy 发送到已知已失败的 Pod。通过以下命令可以查看iptables规则iptables -t nat -nvL|grep gateway-svckube-proxy 在 iptables 模式下随机选择一个后端Pod利用Pod 就绪探测器验证Pod是否正常kube-proxy只会把正常的Pod写入iptables避免流量进入不正常的Pod。3. ipvs在 ipvs 模式下kube-proxy 监视 Kubernetes 服务和端点调用 netlink 接口相应地创建 IPVS 规则并定期将 IPVS 规则与 Kubernetes 服务和端点同步。该控制循环可确保IPVS 状态与所需状态匹配。访问服务时IPVS将流量定向到后端Pod之一。IPVS代理模式基于类似于 iptables 模式的 netfilter 挂钩函数但是使用哈希表作为基础数据结构并且在内核空间中工作。这意味着与 iptables 模式下的 kube-proxy 相比IPVS模式下的 kube-proxy重定向通信的延迟要短并且在同步代理规则时具有更好的性能。与其他代理模式相比IPVS模式还支持更高的网络流量吞吐量。IPVS 提供了更多选项来平衡后端 Pod 的流量。要在 IPVS 模式下运行 kube-proxy必须在启动 kube-proxy 之前使 IPVS 在节点上可用。当 kube-proxy 以 IPVS 代理模式启动时它将验证 IPVS 内核模块是否可用。如果未检测到 IPVS 内核模块则kube-proxy 将退回到以 iptables 代理模式运行。Service 是由 kube-proxy 组件加上 iptables 来共同实现的.kube-proxy 通过 iptables 处理 Service 的过程需要在宿主机上设置相当多的 iptables规则如果宿主机有大量的Pod不断刷新iptables规则会消耗大量的CPU资源。IPVS模式的service可以使K8s集群支持更多量级的Pod。**开启kube-proxy的ipvs模式**所有节点安装yum install -y ipvsadmmaster端修改为ipvs模式kubectl edit cm kube-proxy -n kube-system #将mode字段内容改为ipvs mode: ipvsmaster端更新kube-proxy​​​​​​​[rootmaster ~]# kubectl get pod -n kube-system |grep kube-proxy | awk {system(kubectl delete pod $1 -n kube-system)} pod kube-proxy-4gp79 deleted pod kube-proxy-jdhlk deleted pod kube-proxy-twxdz deleted [rootmaster ~]# kubectl get pod -n kube-system |grep kube-proxy kube-proxy-nrb4g 1/1 Running 0 51s kube-proxy-p2lvh 1/1 Running 0 57s kube-proxy-z48pl 1/1 Running 0 54s03资源清单Service的资源清单文件如下:​​​​​​​kind: Service # 资源类型 apiVersion: v1 # 资源版本 metadata: # 元数据 name: service # 资源名称 namespace: dev # 命名空间 spec: # 描述 selector: # 标签选择器用于确定当前 service 代理哪些 pod app: nginx type: # Service 类型指定 service 的访问方式 clusterIP: # 虚拟服务的 ip 地址 sessionAffinity: # session 亲和性支持 ClientIP、None 两个选项 ports: # 端口信息 - protocol: TCP port: 3017 # service 端口 targetPort: 5003 # pod 端口 nodePort: 31122 # 主机端口type 的类型有下面几种1. ClusterIP默认值它是 Kubernetes 系统自动分配的虚拟 IP只能在集群内部访问;2. NodePort将 Service 通过指定的 Node 上的端口暴露给外部通过此方法就可以在集群外部访问服务;3. LoadBalancer使用外接负载均衡器完成到服务的负载分发注意此模式需要外部云环境支持;4. ExternalName把集群外部的服务引入集群内部直接使用;