由于 Service 的默认发布类型是 ClusterlP，因此也可以把 ClusterIP 地址叫作 虚拟 IP 地址。在 Kubernetes 创建 Service 时，每个节点上运行的 kube-proxy 会自动为 Service 分配一个虚拟 IP 地址，即通过 转发代理 kube-proxy 来实现 路由转发功能。kube-proxy 在具体实现 流量代理转发 与 负载均衡 时，有 $3$ 种模式：

• userspace 代理模式
• iptables 代理模式
• IPVS 代理模式

Cluster IP 地址是一个虚拟的 IP 地址，它是 Kubermetes 集群拥有的独立网络空间。它具有以下 $3$ 个特征:

• 1️⃣ Cluster IP 地址仅作用于 Kubernetes 的 Service 对象，并由 Kubernetes 进行管理和分配。
• 2️⃣ Cluster IP 地址无法被直接访问，也没有实体的网络元素与其对应。
• 3️⃣ 不同 Service 中的 Pod 在集群内部可以通过 Cluster IP 地址进行相互访问。

1.userspace 代理模式

在 userspace 代理模式下，访问 Service 的请求首先访问 Node 节点的 iptable 表，再回到 Kubernetes 的命名空间中被 kube-proxy 转发到后端的 Pod 中。在默认情况下，userspace 代理模式下的 kube-proxy 通过轮询算法选择后端的 Pod。

🚀 userspace 代理模式最大的问题是：请求会存在一次状态转换过程（即从 Node 节点的命名空间到 Kubermetes 命名空间的转换），从而有性能上的损耗。

iptables__17">2.iptables 代理模式

iptables 代理模式是目前 Service 实现代理的默认方式。iptables 代理模式是通过 添加或移除 iptable 表中的路由规则 ，从而实现路由转发功能。在这种模式下，kube-proxy 会通过 API Server 监听集群中 Service 对象和 Endpoint 对象的创建和删除，从而创建 iptable 表中的规则，以实现将访问 Service 的请求重定向到后端的一组 Pod 中。

iptables 代理模式的工作机制如下图所示。iptables 代理模式的默认重定向策略会使用随机选择一个后端的 Pod。Kubernetes 也允许用户将 .service.spec.sessionAffinity 字段的值设置为 ClientIP，以实现基于客户端会话的 IP 地址亲和性的重定向策略。

由于在 iptables 中记录了路由的规则，因此 iptables 代理模式会占用较少的系统资源。当 kube-proxy 运行在 iptables 代理模式下且与后端的 Pod 连接失败时，它会自动对后端的其他 Pod 进行连接重试。

接下来以一个示例来验证 iptables 代理模式。

使用 Deployment 控制器来部署应用，创建文件 service-demo1.yaml，并在其中输入以下内容。

apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginx name: nginx
spec:replicas: 3 selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- image: nginxname: nginximagePullPolicy: IfNotPresent

创建 Service：编辑文件 service-demo2.yaml，在其中输入以下内容。

apiVersion: v1
kind: Service
metadata:name: service-demo2namespace: default
spec:# 这里使用 NodePort 类型的 Service 将应用程序暴露给外部type: NodePort ports:- name: httpport: 80protocol: TCPtargetPort: 80# 定义标签选择器，将服务 Service 与匹配便签的一组 Pod 关联起来selector:     app: nginx

执行以下语句创建 Deployment 和 Service。

kubectl apply -f service-demo1.yaml
kubectl apply -f service-demo2.yaml

查看 Service 的信息。

kubectl get svc

输出的信息如下：

查看节点的 iptable 表中的路由规则。

iptables-save | grep 10.107.186.32

输出的 iptable 表中的路由规则信息如下：

删除 Service。

kubectl delete -f service-demo2.yaml

重新查看节点的 iptable 表中的路由规则。

iptables-save | grep 10.107.186.32

这时在 iptable 表中没有任何路由信息了。

iplables 代理模式尽管使用简单，占用的资源也较少。但它却有以下的不足：

• ⭕ 当存在大量的 Service 时，需要在 iptable 表中创建大量的路由规则，从而难以维护。
• ⭕ 在 iplable 表中进行路由规则匹配时，可能会造成转发的延时。

这时可以将 kube-proxy 运行在 IPVS 代理模式下。

IPVS__118">3.IPVS 代理模式

与 iptables 代理模式一样，IPVS 代理模式通过 API Server 监听集群中 Service 对象和 Endpoint 对象的创建和删除，从而创建 IPVS 路由转发规则，并定期与 Service 对象和 Endpoint 对象同步 IPVS 路由转发规则，以达到路由转发的目的。请求在访问 Service 时，会被重定向到后端的一个 Pod 中。

IPVS 代理模式的工作机制如下图所示。

• IPVS 代理模式创建的是 IPVS 路由转发规则，而不是 iptables 路由转发规则。
• kube-proxy 会定期与 Service 对象和 Endpoints 对象同步 IPVS 路由转发规则。

以下步骤将在 Kubernetes 集群中使用 Service 的 IPVS 代理模式。

在所有节点上安装 IPVS 模块。

apt install ipvsadm

让所有节点启用 IPVS 模块。

创建一个配置文件 /etc/sysconfig/modules/ipvs.modules，并写入以下内容。

modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack

然后，将配置文件设置为可执行，并运行它，以加载所需的内核模块：

chmod 755 /etc/sysconfig/modules/ipvs.modules

bash /etc/sysconfig/modules/ipvs.modules

最后，您可以使用以下命令检查加载的内核模块：

lsmod | grep -e ip_vs -e nf_conntrack

修改 kube-proxy 的配置文件。

kubectl edit configmap kube-proxy -n kube-system

将 mode 字段改为以下形式（默认 mode: "" 为空，使用 iptables）。

mode: "ipvs"

重启 kube-proxy。

kubectl get pod -n kube-system --show-labels | grep kube-proxy

kubectl delete pod -n kube-system -l k8s-app=kube-proxy

编辑 service-ipvs.yaml 文件创建 Service 和 Deployment。

apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginx name: nginx
spec:replicas: 3 selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- image: nginxname: nginximagePullPolicy: IfNotPresent
---
apiVersion: v1
kind: Service
metadata:name: service-ipvsnamespace: default
spec:ports:- name: httpport: 80protocol: TCPtargetPort: 80selector:     app: nginx

执行 kubectl apply -f 命令。

kubectl apply -f service-ipvs.yaml

查看 Pod 和 Service 的信息。

kubectl get pod,svc -o wide

输出的信息如下：

查看 IPVS 路由转发规则。

ipvsadm -Ln

输出的信息如下：