Pod 的 Service 介绍

641 views

一、Service 介绍

Kubernetes Service 定义了这样一种抽象：

一个 Pod 的逻辑分组，一种可以访问它们的策略，通常称为微服务。 这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector 。

69.png

Service能够提供负载均衡的能力，但是在使用上有以下限制：

只提供4层负载均衡能力，而没有7层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的

Service的网络类型

ClusterIp： 默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP

70.png

NodePort： 在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 : NodePort 来访问该服务

71.png

LoadBalancer： 在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到: NodePort

ExternalName： 把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 kubernetes 1.7 或更高版本的 kube-dns 才支持

二、Service 的代理模式分类

VIP 和 Service 代理

在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。 kube-proxy 负责为 Service 实现了一种VIP（虚拟 IP）的形式，而不是 ExternalName 的形式。 在 Kubernetes v1.0 版本，代理完全在 userspace。在Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。 从 Kubernetes v1.2 起，默认就是iptables 代理。

在 Kubernetes v1.8.0-beta.0 中，添加了 ipvs 代理

在 Kubernetes 1.14 版本开始默认使用 ipvs 代理

在 Kubernetes v1.0 版本， Service 是 “4层”（TCP/UDP over IP）概念

在 Kubernetes v1.1 版本，新增了 Ingress API（beta 版），用来表示 “7层”（HTTP）服务

userspace 代理模式

72.png

iptables 代理模式

73.png

ipvs 代理模式

这种模式，kube-proxy 会监视 Kubernetes Service 对象和 Endpoints ，调用 netlink 接口以相应地创建ipvs 规则并定期与 Kubernetes Service 对象和 Endpoints 对象同步 ipvs 规则，以确保 ipvs 状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod

与 iptables 类似，ipvs 于 netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs 为负载均衡算法提供了更多选项，例如：

rr ：轮询调度

lc ：最小连接数

dh ：目标哈希

sh ：源哈希

sed ：最短期望延迟

nq ： 不排队调度

三、Endpoint

在 Kubernetes (k8s) 中，Endpoint 是一个重要的资源对象，用于表示服务的后端 Pod 的网络地址。Endpoint 资源与 Service 资源紧密相关，用于将服务请求路由到正确的 Pod。

基本概念

1.Service：

  • Service 是一个抽象，它定义了一个逻辑集的 Pod 以及一个策略，用于访问这些 Pod（通常是负载均衡策略）。
  • Service 通过标签选择器（label selector）来查找和管理后端的 Pod。

2.Endpoint：

  • Endpoint 是一个 Kubernetes 资源，它包含了 Service 后端 Pod 的网络地址（IP 地址和端口号）。
  • Endpoint 由 kube-controller-manager 自动创建和管理，当 Service 的后端 Pod 发生变化时，Endpoint 会自动更新。

示例

假设你有一个 Service 和一些匹配的 Pod，Endpoint 资源将包含这些 Pod 的网络地址。

创建一个 Service

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

创建匹配的 Pod

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
  labels:
    app: my-app
spec:
  containers:
  - name: my-app-container
    image: nginx
    ports:
    - containerPort: 80

查看 Endpoint

创建 Service 后，Kubernetes 会自动生成相应的 Endpoint 资源。你可以使用 kubectl 命令查看 Endpoint：

kubectl get endpoints my-service

输出可能如下：

NAME         ENDPOINTS                         AGE
my-service   10.244.1.4:80,10.244.2.5:80   5m

重要特性

1.自动管理：

  • Endpoint 由 kube-controller-manager 自动管理，当 Service 的标签选择器匹配的 Pod 发生变化时，Endpoint 会自动更新。
  • 如果 Pod 被删除或创建，Endpoint 会相应地添加或移除该 Pod 的地址。

2.Headless Service：

  • 有时你可能不希望 Kubernetes 为 Service 创建一个集群 IP。在这种情况下，可以创建一个 Headless Service（无头服务），Service 将不会创建集群 IP，但仍然会创建 Endpoint 资源。
  • 在 Headless Service 中，DNS 响应将直接返回后端 Pod 的 IP 地址，而不是集群 IP。

3.手动管理 Endpoint：

  • 虽然通常由 Kubernetes 自动管理 Endpoint，但在某些情况下，你也可以手动创建和管理 Endpoint。例如，当你需要将 Service 路由到集群外部的服务时，可以手动创建 Endpoint。

总结

Endpoint 资源是 Kubernetes 中 Service 和后端 Pod 之间的重要桥梁。它确保了服务请求能够正确地路由到具体的 Pod，从而实现了服务的高可用性和负载均衡。理解 Endpoint 的工作原理对于管理 Kubernetes 集群中的网络通信非常有帮助。