【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

输出的信息如下:

相关推荐
魏 无羡5 小时前
linux CentOS系统上卸载docker
linux·kubernetes·centos
Karoku0666 小时前
【k8s集群应用】kubeadm1.20高可用部署(3master)
运维·docker·云原生·容器·kubernetes
凌虚7 小时前
Kubernetes APF(API 优先级和公平调度)简介
后端·程序员·kubernetes
biubiubiu07068 小时前
代理模式(JDK,CGLIB动态代理,AOP切面编程)
代理模式
探索云原生11 小时前
在 K8S 中创建 Pod 是如何使用到 GPU 的: nvidia device plugin 源码分析
ai·云原生·kubernetes·go·gpu
启明真纳11 小时前
elasticache备份
运维·elasticsearch·云原生·kubernetes
jwolf213 小时前
基于K8S的微服务:一、服务发现,负载均衡测试(附calico网络问题解决)
微服务·kubernetes·服务发现
nangonghen13 小时前
在华为云通过operator部署Doris v2.1集群
kubernetes·华为云·doris·operator
会飞的土拨鼠呀15 小时前
chart文件结构
运维·云原生·kubernetes
自在的LEE17 小时前
当 Go 遇上 Windows:15.625ms 的时间更新困局
后端·kubernetes·go