service详解

最新推荐文章于 2024-05-17 16:47:44 发布

原创

最新推荐文章于 2024-05-17 16:47:44 发布 · 1k 阅读

6 ·

CC 4.0 BY-SA版权

一、service（智能负载均衡器）

service主要是提供负载均衡和服务自动发现。它是 k8s 中最核心的资源之一，每一个 Service 就是我们平常所说的一个“微服务”。命名空间级资源
在这里插入图片描述
如上图所示，Kubernetes 的 Service 定义了一个服务的访问入口，前端的应用（Pod）通过这个入口地址访问其背后的一组由 Pod 副本组成的集群实例，Service 与其后端的 Pod 副本集群之间是通过 Label 来实现关联的，而 Deployment 则是保证 Service 的服务能力和服务质量始终处于预期的标准。

通过分析，识别并建模系统中的所有服务为微服务，最终我们的系统是由多个提供不同业务能力而彼此独立的微服务单元所组成，服务之间通过 TCP/IP 进行通信，从而形成了强大而又灵活的弹性网络，拥有强大的分布式能力、弹性扩展能力、容错能力。

vim service.yaml
apiVersion: v1
kind: Service
metadata:
  name: service
spec:
  selector:
    release: stable
  ports:
    - name: http
      #负载均衡端口
      port: 80
      #容器内端口
      targetPort: 80
      #网络代理的类型默认tcp
      protocol: "TCP"
    - name: https
      port: 443
      targetPort: 443
      protocol: "TCP"

二、service的工作方式

在 Kubernetes 迭代过程中，给 Service 设置里三种工作方式，分别是：Userspace 方式、Iptables 以及 Ipvs，这三种方式到现在为止，官方推荐使用 IPVS，当集群不支持 IPVS 的时候，集群会降级到 Iptables。

2.1.userspace

Client Pod 要访问 Server Pod 时,它先将请求发给本机内核空间中的 service 规则，由它再将请求,转给监听在指定套接字上的 kube-proxy，kube-proxy 处理完请求，并分发请求到指定 Server Pod 后,再将请求递交给内核空间中的 service,由 service 将请求转给指定的 Server Pod。由于其需要来回在用户空间和内核空间交互通信，因此效率很差
在这里插入图片描述

2.2.Iptables 模型（软件转发）

直接由内核中的 iptables 规则，接受 Client Pod 的请求，并处理完成后，直接转发给指定 ServerPod。这种方式不再将请求转发给 kube-proxy，性能提升很多。
在这里插入图片描述

2.3.Ipvs 模型（内核转发）

在 ipvs 模式下，kube-proxy 监视 Kubernetes 服务和端点，调用 netlink 接口相应地创建 IPVS 规则，并定期将 IPVS 规则与 Kubernetes 服务和端点同步。该控制循环可确保 IPVS 状态与所需状态匹配。访问服务时，IPVS 将流量定向到后端 Pod 之一。 IPVS 代理模式基于类似于 iptables 模式的 netfilter 挂钩函数，但是使用哈希表作为基础数据结构，并且在内核空间中工作。这意味着，与 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。与其他代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。
在这里插入图片描述
总结：kube-proxy 都通过 watch 的方式监控着 kube-APIServer 写入 etcd 中关于 Pod 的最新状态信息,它一旦检查到一个 Pod 资源被删除了或新建，它将立即将这些变化，反应在 iptables 或 ipvs 规则中，以便 iptables 和 ipvs 在调度 Clinet Pod 请求到 Server Pod 时，不会出现 Server Pod 不存在的情况。 自 k8s1.1 以后,service 默认使用 ipvs 规则，若 ipvs 没有被激活，则降级使用 iptables 规则. 但在 1.1 以前， service 使用的模式默认为 userspace。