【Kubernetes】虚拟 IP 与 Service 的代理模式

虚拟 IP 与 Service 的代理模式

  • [1.userspace 代理模式](#1.userspace 代理模式)
  • [2.iptables 代理模式](#2.iptables 代理模式)
  • [3.IPVS 代理模式](#3.IPVS 代理模式)

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

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

Cluster IP 地址是一个虚拟的 IP 地址,它是 Kubermetes 集群拥有的独立网络空间。它具有以下 3 3 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 命名空间的转换),从而有性能上的损耗。

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,并在其中输入以下内容。

yaml 复制代码
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx 
  name: nginx
spec:
  replicas: 3 
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        imagePullPolicy: IfNotPresent

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

yaml 复制代码
apiVersion: v1
kind: Service
metadata:
  name: service-demo2
  namespace: default
spec:
  # 这里使用 NodePort 类型的 Service 将应用程序暴露给外部
  type: NodePort 
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  # 定义标签选择器,将服务 Service 与匹配便签的一组 Pod 关联起来
  selector:     
    app: nginx

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

bash 复制代码
kubectl apply -f service-demo1.yaml
kubectl apply -f service-demo2.yaml

查看 Service 的信息。

bash 复制代码
kubectl get svc

输出的信息如下:

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

bash 复制代码
iptables-save | grep 10.107.186.32

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

删除 Service。

bash 复制代码
kubectl delete -f service-demo2.yaml

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

bash 复制代码
iptables-save | grep 10.107.186.32

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

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

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

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

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 模块。

bash 复制代码
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

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

bash 复制代码
chmod 755 /etc/sysconfig/modules/ipvs.modules
bash 复制代码
bash /etc/sysconfig/modules/ipvs.modules

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

bash 复制代码
lsmod | grep -e ip_vs -e nf_conntrack

修改 kube-proxy 的配置文件。

bash 复制代码
kubectl edit configmap kube-proxy -n kube-system

mode 字段改为以下形式(默认 mode: "" 为空,使用 iptables)。

bash 复制代码
mode: "ipvs"

重启 kube-proxy

bash 复制代码
kubectl get pod -n kube-system --show-labels | grep kube-proxy
bash 复制代码
kubectl delete pod -n kube-system -l k8s-app=kube-proxy

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

yaml 复制代码
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx 
  name: nginx
spec:
  replicas: 3 
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        imagePullPolicy: IfNotPresent
---
apiVersion: v1
kind: Service
metadata:
  name: service-ipvs
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:     
    app: nginx

执行 kubectl apply -f 命令。

bash 复制代码
kubectl apply -f service-ipvs.yaml

查看 Pod 和 Service 的信息。

bash 复制代码
kubectl get pod,svc -o wide

输出的信息如下:

查看 IPVS 路由转发规则。

bash 复制代码
ipvsadm -Ln

输出的信息如下:

相关推荐
陈聪.1 小时前
Kubernetes Service 与 Ingress 知识总结
云原生·容器·kubernetes
A-刘晨阳2 天前
K8s集群中的数据库新范式:KES-Operator解锁部署、扩缩容、备份全链路自动化
运维·数据库·云原生·kubernetes·自动化
江畔柳前堤2 天前
云原生 × AI 全景图谱:从 Kubernetes 到 Agent 基础设施的一次认知跃迁
人工智能·分布式·gpt·云原生·kubernetes·原型模式·agi
kruptos2 天前
动态规划:暴力递归如何变优雅?
代理模式·算法优化·斐波那契
2601_962299242 天前
云原生时代的技术进阶:从零到精通掌握Kubernetes实战
云原生·kubernetes·学习路径·技术进阶·实战指南
名字还没想好☜3 天前
Docker 数据卷实战:volume、bind mount、tmpfs 到底怎么选,数据持久化与权限坑
运维·docker·容器·kubernetes
探索云原生3 天前
Kueue + HAMi vGPU 实战:显存与算力配额管理
docker·ai·云原生·kubernetes·gpu
玉&心3 天前
通过helm在k8s上面一键部署前端和后端代码
云原生·容器·kubernetes·helm
ZzzZZzzzZZZzzzz…3 天前
K8s---网络:从 Pod 网络模型到 Calico 三种模式
运维·网络·云原生·容器·kubernetes·calico·pod网络模型
上火的金鱼妹4 天前
K8S基础组件作用和关系整理
linux·运维·服务器·kubernetes