12、Kubernetes中KubeProxy实现之iptables和ipvs_ipvs和iptables

于 2024-09-02 23:34:33 发布
阅读量1k 收藏 30
点赞数 12
文章标签： kubernetes php 容器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/2401_86444443/article/details/141833021
版权

目录

一、概述

二、iptables 代理模式

三、iptables案例分析

四、ipvs案例分析

一、概述

iptables和ipvs其实都是依赖的一个共同的Linux内核模块：Netfilter。Netfilter是Linux 2.4.x引入的一个子系统，它作为一个通用的、抽象的框架，提供一整套的hook函数的管理机制，使得诸如数据包过滤、网络地址转换(NAT)和基于协议类型的连接跟踪成为了可能。

Netfilter的架构就是在整个网络流程的若干位置放置了一些检测点（HOOK），而在每个检测点上登记了一些处理函数进行处理。

在一个网络包进入Linux网卡后，有可能经过这上面五个Hook点，我们可以自己写Hook函数，注册到任意一个点上，而iptables和ipvs都是在这个基础上实现的。

二、iptables 代理模式

iptables模式下 kube-proxy 为每一个pod创建相对应的 iptables 规则，发送给 ClusterIP 的请求会被直接发送给后端pod之上。

在该模式下 kube-proxy 不承担负载均衡器的角色，其只会负责创建相应的转发策略，该模式的优点在于效率较高，但是不能提供灵活的LB策略，当后端Pod不可用的时候无法进行重试。

iptables是把一些特定规则以“链”的形式挂载到每个Hook点，这些链的规则是固定的，而是是比较通用的，可以通过iptables命令在用户层动态的增删，这些链必须串行的执行。执行到某条规则，如果不匹配，则继续执行下一条，如果匹配，根据规则，可能继续向下执行，也可能跳到某条规则上，也可能下面的规则都跳过。

三、iptables案例分析

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx

---

apiVersion: v1
kind: Service
metadata:
  name: nginx-basic
spec:
  type: ClusterIP
  ports:
    - port: 80
      protocol: TCP
      name: http
  selector:
    app: nginx

我们这里创建一个副本数量为3的nginx pod，并创建一个对应的service对外暴露服务，service类型为ClusterIP。

创建完成后，资源如下：

$ kubectl get pod -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP            NODE           NOMINATED NODE   READINESS GATES
nginx-deployment-748c667d99-dtr82   1/1     Running   0          38m   192.168.1.3   node01         <none>           <none>
nginx-deployment-748c667d99-jzpqf   1/1     Running   0          38m   192.168.0.7   controlplane   <none>           <none>
nginx-deployment-748c667d99-whgr5   1/1     Running   0          38m   192.168.1.4   node01         <none>           <none>


$ kubectl get svc nginx-basic -o wide
NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE   SELECTOR
nginx-basic   ClusterIP   10.105.250.129   <none>        80/TCP    39m   app=nginx

可以看到，三个pod的IP分别为192.168.1.3、192.168.0.7、192.168.1.4。service的ClusterIP地址为10.105.250.129。

下面我们通过【iptables-save -t nat】命令输出iptables中nat表的信息，说明iptables如何实现转发。

$ iptables-save -t nat
# Generated by iptables-save v1.8.4 on Mon Feb 20 01:52:41 2023
*nat
:PREROUTING ACCEPT [11:660]
:INPUT ACCEPT [11:660]
:OUTPUT ACCEPT [4706:282406]
:POSTROUTING ACCEPT [4706:282406]
:DOCKER - [0:0]
:KUBE-KUBELET-CANARY - [0:0]
:KUBE-MARK-DROP - [0:0]
:KUBE-MARK-MASQ - [0:0]
:KUBE-NODEPORTS - [0:0]
:KUBE-POSTROUTING - [0:0]
:KUBE-PROXY-CANARY - [0:0]
:KUBE-SEP-ABG426TTTCGMOND7 - [0:0]
:KUBE-SEP-BEMSLTMJA26ZCLYL - [0:0]
:KUBE-SEP-D23ODROEH5R4FSGE - [0:0]
:KUBE-SEP-G44RJ25JKAEOKO42 - [0:0]
:KUBE-SEP-GHNVWKROTCCBFQKZ - [0:0]
:KUBE-SEP-NGZXZA7GIJDM26Z3 - [0:0]
:KUBE-SEP-NH2YM7NDCNPLOCTP - [0:0]
:KUBE-SEP-UF65ZV4QBOPNRP6O - [0:0]
:KUBE-SEP-UG4OSZR4VSWZ27C5 - [0:0]
:KUBE-SEP-WQR67ZLSTPDXXME4 - [0:0]
:KUBE-SERVICES - [0:0]
:KUBE-SVC-ERIFXISQEP7F7OF4 - [0:0]
:KUBE-SVC-JD5MR3NA4I4DYORP - [0:0]
:KUBE-SVC-NPX46M4PTMTKRN6Y - [0:0]
:KUBE-SVC-TCOU7JCQXEZGVUNU - [0:0]
:KUBE-SVC-WWRFY3PZ7W3FGMQW - [0:0]
:cali-OUTPUT - [0:0]
:cali-POSTROUTING - [0:0]
:cali-PREROUTING - [0:0]
:cali-fip-dnat - [0:0]
:cali-fip-snat - [0:0]
:cali-nat-outgoing - [0:0]
-A PREROUTING -m comment --comment "cali:6gwbT8clXdHdC1b1" -j cali-PREROUTING
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT -m comment --comment "cali:tVnHkvAo15HuiPy0" -j cali-OUTPUT
-A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -m comment --comment "cali:O3lYWMrLQYEMJtB5" -j cali-POSTROUTING
-A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 192.168.0.0/16 -d 192.168.0.0/16 -j RETURN
-A POSTROUTING -s 192.168.0.0/16 ! -d 224.0.0.0/4 -j MASQUERADE --random-fully
-A POSTROUTING ! -s 192.168.0.0/16 -d 192.168.0.0/24 -j RETURN
-A POSTROUTING ! -s 192.168.0.0/16 -d 192.168.0.0/16 -j MASQUERADE --random-fully
-A DOCKER -i docker0 -j RETURN
-A KUBE-MARK-DROP -j MARK --set-xmark 0x8000/0x8000
-A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000
-A KUBE-POSTROUTING -m mark ! --mark 0x4000/0x4000 -j RETURN
-A KUBE-POSTROUTING -j MARK --set-xmark 0x4000/0x0
-A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -j MASQUERADE --random-fully
-A KUBE-SEP-ABG426TTTCGMOND7 -s 192.168.1.2/32 -m comment --comment "kube-system/kube-dns:dns-tcp" -j KUBE-MARK-MASQ
-A KUBE-SEP-ABG426TTTCGMOND7 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp" -m tcp -j DNAT --to-destination 192.168.1.2:53
-A KUBE-SEP-BEMSLTMJA26ZCLYL -s 192.168.0.7/32 -m comment --comment "default/nginx-basic:http" -j KUBE-MARK-MASQ
-A KUBE-SEP-BEMSLTMJA26ZCLYL -p tcp -m comment --comment "default/nginx-basic:http" -m tcp -j DNAT --to-destination 192.168.0.7:80
-A KUBE-SEP-D23ODROEH5R4FSGE -s 172.30.1.2/32 -m comment --comment "default/kubernetes:https" -j KUBE-MARK-MASQ
-A KUBE-SEP-D23ODROEH5R4FSGE -p tcp -m comment --comment "default/kubernetes:https" -m tcp -j DNAT --to-destination 172.30.1.2:6443
-A KUBE-SEP-G44RJ25JKAEOKO42 -s 192.168.0.6/32 -m comment --comment "kube-system/kube-dns:dns-tcp" -j KUBE-MARK-MASQ
-A KUBE-SEP-G44RJ25JKAEOKO42 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp" -m tcp -j DNAT --to-destination 192.168.0.6:53
-A KUBE-SEP-GHNVWKROTCCBFQKZ -s 192.168.1.2/32 -m comment --comment "kube-system/kube-dns:dns" -j KUBE-MARK-MASQ
-A KUBE-SEP-GHNVWKROTCCBFQKZ -p udp -m comment --comment "kube-system/kube-dns:dns" -m udp -j DNAT --to-destination 192.168.1.2:53
-A KUBE-SEP-NGZXZA7GIJDM26Z3 -s 192.168.0.6/32 -m comment --comment "kube-system/kube-dns:dns" -j KUBE-MARK-MASQ
-A KUBE-SEP-NGZXZA7GIJDM26Z3 -p udp -m comment --comment "kube-system/kube-dns:dns" -m udp -j DNAT --to-destination 192.168.0.6:53
-A KUBE-SEP-NH2YM7NDCNPLOCTP -s 192.168.0.6/32 -m comment --comment "kube-system/kube-dns:metrics" -j KUBE-MARK-MASQ
-A KUBE-SEP-NH2YM7NDCNPLOCTP -p tcp -m comment --comment "kube-system/kube-dns:metrics" -m tcp -j DNAT --to-destination 192.168.0.6:9153
-A KUBE-SEP-UF65ZV4QBOPNRP6O -s 192.168.1.3/32 -m comment --comment "default/nginx-basic:http" -j KUBE-MARK-MASQ
-A KUBE-SEP-UF65ZV4QBOPNRP6O -p tcp -m comment --comment "default/nginx-basic:http" -m tcp -j DNAT --to-destination 192.168.1.3:80
-A KUBE-SEP-UG4OSZR4VSWZ27C5 -s 192.168.1.2/32 -m comment --comment "kube-system/kube-dns:metrics" -j KUBE-MARK-MASQ
-A KUBE-SEP-UG4OSZR4VSWZ27C5 -p tcp -m comment --comment "kube-system/kube-dns:metrics" -m tcp -j DNAT --to-destination 192.168.1.2:9153
-A KUBE-SEP-WQR67ZLSTPDXXME4 -s 192.168.1.4/32 -m comment --comment "default/nginx-basic:http" -j KUBE-MARK-MASQ
-A KUBE-SEP-WQR67ZLSTPDXXME4 -p tcp -m comment --comment "default/nginx-basic:http" -m tcp -j DNAT --to-destination 192.168.1.4:80
-A KUBE-SERVICES -d 10.96.0.10/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-SVC-ERIFXISQEP7F7OF4
-A KUBE-SERVICES -d 10.96.0.10/32 -p tcp -m comment --comment "kube-system/kube-dns:metrics cluster IP" -m tcp --dport 9153 -j KUBE-SVC-JD5MR3NA4I4DYORP
-A KUBE-SERVICES -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU
-A KUBE-SERVICES -d 10.105.250.129/32 -p tcp -m comment --comment "default/nginx-basic:http cluster IP" -m tcp --dport 80 -j KUBE-SVC-WWRFY3PZ7W3FGMQW
-A KUBE-SERVICES -d 10.96.0.1/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -m tcp --dport 443 -j KUBE-SVC-NPX46M4PTMTKRN6Y
-A KUBE-SERVICES -m comment --comment "kubernetes service nodeports; NOTE: this must be the last rule in this chain" -m addrtype --dst-type LOCAL -j KUBE-NODEPORTS
-A KUBE-SVC-ERIFXISQEP7F7OF4 ! -s 192.168.0.0/16 -d 10.96.0.10/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-MARK-MASQ
-A KUBE-SVC-ERIFXISQEP7F7OF4 -m comment --comment "kube-system/kube-dns:dns-tcp -> 192.168.0.6:53" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-G44RJ25JKAEOKO42
-A KUBE-SVC-ERIFXISQEP7F7OF4 -m comment --comment "kube-system/kube-dns:dns-tcp -> 192.168.1.2:53" -j KUBE-SEP-ABG426TTTCGMOND7
-A KUBE-SVC-JD5MR3NA4I4DYORP ! -s 192.168.0.0/16 -d 10.96.0.10/32 -p tcp -m comment --comment "kube-system/kube-dns:metrics cluster IP" -m tcp --dport 9153 -j KUBE-MARK-MASQ
-A KUBE-SVC-JD5MR3NA4I4DYORP -m comment --comment "kube-system/kube-dns:metrics -> 192.168.0.6:9153" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-NH2YM7NDCNPLOCTP
-A KUBE-SVC-JD5MR3NA4I4DYORP -m comment --comment "kube-system/kube-dns:metrics -> 192.168.1.2:9153" -j KUBE-SEP-UG4OSZR4VSWZ27C5
-A KUBE-SVC-NPX46M4PTMTKRN6Y ! -s 192.168.0.0/16 -d 10.96.0.1/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -m tcp --dport 443 -j KUBE-MARK-MASQ
-A KUBE-SVC-NPX46M4PTMTKRN6Y -m comment --comment "default/kubernetes:https -> 172.30.1.2:6443" -j KUBE-SEP-D23ODROEH5R4FSGE
-A KUBE-SVC-TCOU7JCQXEZGVUNU ! -s 192.168.0.0/16 -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-MARK-MASQ
-A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns -> 192.168.0.6:53" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-NGZXZA7GIJDM26Z3
-A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns -> 192.168.1.2:53" -j KUBE-SEP-GHNVWKROTCCBFQKZ
-A KUBE-SVC-WWRFY3PZ7W3FGMQW ! -s 192.168.0.0/16 -d 10.105.250.129/32 -p tcp -m comment --comment "default/nginx-basic:http cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SVC-WWRFY3PZ7W3FGMQW -m comment --comment "default/nginx-basic:http -> 192.168.0.7:80" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-BEMSLTMJA26ZCLYL
-A KUBE-SVC-WWRFY3PZ7W3FGMQW -m comment --comment "default/nginx-basic:http -> 192.168.1.3:80" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-UF65ZV4QBOPNRP6O
-A KUBE-SVC-WWRFY3PZ7W3FGMQW -m comment --comment "default/nginx-basic:http -> 192.168.1.4:80" -j KUBE-SEP-WQR67ZLSTPDXXME4
-A cali-OUTPUT -m comment --comment "cali:GBTAv2p5CwevEyJm" -j cali-fip-dnat
-A cali-POSTROUTING -m comment --comment "cali:Z-c7XtVd2Bq7s_hA" -j cali-fip-snat
-A cali-POSTROUTING -m comment --comment "cali:nYKhEzDlr11Jccal" -j cali-nat-outgoing
-A cali-PREROUTING -m comment --comment "cali:r6XmIziWUJsdOK6Z" -j cali-fip-dnat
-A cali-nat-outgoing -m comment --comment "cali:flqWnvo8yq4ULQLa" -m set --match-set cali40masq-ipam-pools src -m set ! --match-set cali40all-ipam-pools dst -j MASQUERADE --random-fully
COMMIT

iptables-save命令，可以查看当前所有的iptables规则，涉及到k8s的比较多，基本在每个链上都有，包括一些SNAT的，就是Pod访问外部的地址的时候，需要做一下NAT转换，我们只看涉及到Service负载均衡的。

首先，PREROUTING和OUTPUT都加了一个KUBE-SERVICES规则，也就是进来的包和出去的包都要都走一下KUBE-SERVICES规则。

-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES

-A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES

接着，因为我们service的ClusterIP地址为10.105.250.129，所以我们从nat表中找出跟10.105.250.129有关的转发规则。

-A KUBE-SERVICES -d 10.105.250.129/32 -p tcp -m comment --comment "default/nginx-basic:http cluster IP" -m tcp --dport 80 -j KUBE-SVC-WWRFY3PZ7W3FGMQW

可以看到，当目标地址是10.105.250.129/32并且目标端口是80的，也就是这个服务的ClusterIP，走到KUBE-SVC-WWRFY3PZ7W3FGMQW规则，这个规则其实就是Kube-Proxy。

下面我们查看KUBE-SVC-WWRFY3PZ7W3FGMQW规则：

-A KUBE-SVC-WWRFY3PZ7W3FGMQW -m comment --comment "default/nginx-basic:http -> 192.168.0.7:80" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-BEMSLTMJA26ZCLYL
-A KUBE-SVC-WWRFY3PZ7W3FGMQW -m comment --comment "default/nginx-basic:http -> 192.168.1.3:80" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-UF65ZV4QBOPNRP6O
-A KUBE-SVC-WWRFY3PZ7W3FGMQW -m comment --comment "default/nginx-basic:http -> 192.168.1.4:80" -j KUBE-SEP-WQR67ZLSTPDXXME4

可以看到，KUBE-SVC-WWRFY3PZ7W3FGMQW又对应了三条规则，分别来看下：

1)、第一条规则

-A KUBE-SVC-WWRFY3PZ7W3FGMQW -m comment --comment "default/nginx-basic:http -> 192.168.0.7:80" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-BEMSLTMJA26ZCLYL

# 这条规则对应的又会走KUBE-SEP-BEMSLTMJA26ZCLYL规则
-A KUBE-SEP-BEMSLTMJA26ZCLYL -p tcp -m comment --comment "default/nginx-basic:http" -m tcp -j DNAT --to-destination 192.168.0.7:80

# 可以看到， 有33%的概率将会被转发到【192.168.0.7:80】这个pod

2)、第二条规则

-A KUBE-SVC-WWRFY3PZ7W3FGMQW -m comment --comment "default/nginx-basic:http -> 192.168.1.3:80" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-UF65ZV4QBOPNRP6O

# 这条规则对应的又会走KUBE-SEP-UF65ZV4QBOPNRP6O规则
-A KUBE-SEP-UF65ZV4QBOPNRP6O -p tcp -m comment --comment "default/nginx-basic:http" -m tcp -j DNAT --to-destination 192.168.1.3:80

# 可以看到， 有50%的概率将会被转发到【192.168.1.3:80】这个pod

3)、第三条规则

-A KUBE-SVC-WWRFY3PZ7W3FGMQW -m comment --comment "default/nginx-basic:http -> 192.168.1.4:80" -j KUBE-SEP-WQR67ZLSTPDXXME4

# 这条规则对应的又会走KUBE-SEP-WQR67ZLSTPDXXME4规则
-A KUBE-SEP-WQR67ZLSTPDXXME4 -p tcp -m comment --comment "default/nginx-basic:http" -m tcp -j DNAT --to-destination 192.168.1.4:80

# 可以看到，这条规则没有加--probability，所以有100%的概率将会被转发到【192.168.1.4:80】这个pod

可以看到，最重要的就是KUBE-SVC-WWRFY3PZ7W3FGMQW规则，它以不同的概率走到了不同的规则，这些规则最终走到了Pod里，这就是负载均衡策略。

我们把这个负载均衡用图画出来，大体就是如下：

上述我们演示的是ClusterIP类型的Service，我们可以尝试修改为NodePort类型，实际上，在iptables规则里，最终也是会转发到KUBE-SVC-WWRFY3PZ7W3FGMQW规则，综上，不管是ClusterIP，还是NodePort，都走到了同一个规则上。

四、ipvs案例分析

IPVS模式工作在内核态，在同步代理规则时具有更好的性能，同时提高网络吞吐量为大型集群提供了更好的可扩展性，同时提供了大量的负责均衡算法。

还是通过一个例子说明ipvs怎么转发的，首先我们需要修改kube-proxy的代理模式为ipvs，我们可以通过修改configmap来实现：

$ kubectl edit configmap kube-proxy -n kube-system
configmap/kube-proxy edited

将mode修改为ipvs即可，如下图：

image.png

apiVersion: apps/v1
2401_86444443
关注
Kubernetes kube-proxy的iptables与ipvs模式
✨ 欢迎来到【Seal ^_^ 的CSDN博客】！这里是我记录技术心得、分享经验的地方。✨
07-28 5976
kube-proxy支持多种不同的代理模式，其中iptables和ipvs是最常用的两种。
kubernetes / IPVS 和 IPTABLES
Yosigo_的博客
09-06 862
IPVS（IP 虚拟服务器）实现传输层负载平衡，通常称为第 4 层 LAN 交换，作为 Linux 内核的一部分。IPVS 在主机上运行并充当真实服务器集群前面的负载平衡器。IPVS 可以将基于 TCP 和 UDP 的服务的请求定向到真实服务器，并使真实服务器的服务在单个 IP 地址上表现为虚拟服务。
12、Kubernetes中KubeProxy实现之iptables和ipvs
weixiaohuai的博客
09-30 1460
iptables和ipvs其实都是依赖的一个共同的Linux内核模块：Netfilter。Netfilter是Linux 2.4.x引入的一个子系统，它作为一个通用的、抽象的框架，提供一整套的hook函数的管理机制，使得诸如数据包过滤、网络地址转换(NAT)和基于协议类型的连接跟踪成为了可能。Netfilter的架构就是在整个网络流程的若干位置放置了一些检测点（HOOK），而在每个检测点上登记了一些处理函数进行处理。
iptables和ipvs
jingzhiz 专属移动笔记
10-14 3672
一、service和iptables的关系 service 的代理是 kube-proxy kube-proxy 运行在所有节点上，它监听 apiserver 中 service 和 endpoint 的变化情况，创建路由规则以提供服务 IP 和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上，而kube...
kube-proxy中使用ipvs与iptables的比较
linus.lin的博客
10-24 7069
Iptables模式 kube-proxy 就可以通过 Service 的 Informer 感知到API Server中service和endpoint的变化情况。而作为对这个事件的响应，它就会在宿主机上创建这样一条 iptables 规则（你可以通过 iptables-save 看到它）。这些规则捕获到service的clusterIP和port的流量，并将这些流量随机重定向到service后端Pod。对于每个endpoint对象，它生成选择后端Pod的iptables规则。 如果选择的第一个Pod没有
比较kube-proxy模式：iptables还是IPVS？
最新发布
didiplus
05-23 1450
kube-proxy是任何Kubernetes部署中的关键组件。它的作用是将流向服务（通过集群 IP 和节点端口）的流量负载均衡到正确的后端pod。kube-proxyuserspaceiptables或IPVS。userspace模式非常旧且慢，绝对不推荐！但是，应该如何权衡选择iptables还是IPVS模式呢？在本文中，我们将比较这两种模式，在实际的微服务环境中衡量它们的性能，并解释在何种情况下你可能会选择其中一种。首先，我们将简要介绍这两种模式的背景，然后深入测试和结果……
k8s中iptables和ipvs选择哪个
04-28
在Kubernetes中，Iptables和IPVS都可以用于负载均衡。两者都有其优缺点。 Iptables是一个基于Linux内核的防火墙，可以通过规则匹配实现负载均衡。它适用于较小规模的集群，具有广泛的支持和易于使用的优点。但是，...
Kubernetes大规模优化实战：Iptables与IPVS比较与解决方案
总结来说，本篇文章详尽地介绍了如何在Kubernetes中通过Iptables和IPVS进行Service的优化，包括解决大规模场景下的性能问题、会话保持、以及适应容器环境变化等挑战。对于从事Kubernetes运维或开发的人员，理解和...
[Kubernetes]K8S中的Service实现方式以及IPVS介绍
qq_24164157的博客
08-11 779
service通过什么方式实现的? 正常情况下，service是一个抽象的概念，它是通过调用iptables工具实现的pod之间的通信，而iptables是系统内核netfiter模块的一个工具，主要是用来管理一张端口转发表，每一次的转发都需要轮询一遍转发表，因此，当集群数量较大的时候，相应的转发性能会下降。所以在kubernets1.11版本以后，将IPVS引入GA，通过IPVS实现SVC。 实现service功能，通过kube-proxy，是kubernets核心组件，能否替代？ 常见概念
kube-proxy模式之iptables
Blue summer的博客
09-18 2158
注：本文基于K8S v1.21.2版本编写 1 默认模式 2 关于iptables 3 针对一个特定服务分析数据流
k8s-service底层之 Iptables与 IPVS
huahua1999的博客
04-17 7865
service底层之 Iptables与 IPVS service底层实现主要由两个网络模式组成：iptables与IPVS。他们都是有kube-proxy维护 service工作流程图 Iptables 以k8s中的nginx这个service举例，这是一个nodePort类型的service 用命令 iptables-save |grep nginx 可以看到这个service中的iptables规则 找到他对外暴露的端口30601 ...
ipvs和iptables的区别？
lbzrl的博客
04-13 801
1）实现方式：iptables是基于Netfilter框架的网络过滤工具，它使用链表（chain）和规则（rule）来处理网络数据包。2）功能：iptables主要用于实现网络地址转换（NAT）、端口转发（forwarding）、流量过滤等功能，而ipvs主要用于实现负载均衡（load balancing）和服务器健康检查（health check）。4）使用场景：iptables更适合用于防火墙、NAT和端口转发等场景，而ipvs更适合用于负载均衡和服务器集群管理。
iptables与ipvs的异同
Q先生
12-14 1181
Kubernetes 1.29 新版将抛弃 iptables那么我们就来聊一下iptables与ipvs的异同iptables和ipvs都是Linux系统中用于网络流量控制和管理的工具，但它们在实现方式、功能和性能上有所不同。本文将对iptables和ipvs进行比较，以帮助读者更好地了解它们之间的区别。
kube-proxy配置 ipvs模式
weixin_33829657的博客
11-14 1929
在k8s中，提供相同服务的一组pod可以抽象成一个service，通过service提供的统一入口对外提供服务，每个service都有一个虚拟IP地址（clusterip）和端口号供客户端访问。 Kube-proxy存在于各个node节点上，主要用于Service功能的实现，具体来说，就是实现集群内的客户端pod访问service，或者是集群外的主机通过NodePort等方式访问service。...
kube_proxy iptables
qq_36980207的博客
09-06 171
//将table中所有来自srcChain链中的数据包跳转到dstChain链中 type iptablesJumpChain struct { table utiliptables.Table //iptables的表 dstChain utiliptables.Chain //需要创建的chain的名字 srcChain utiliptables.Chain //需要进行判定的chain的名字 comment string //添加的注释 extraArgs []strin.
kube-proxy模式之ipvs
Blue summer的博客
09-26 3860
注：本文基于K8S v1.21.2版本编写
k8s中iptables与ipvs详解——2023.05
我是小bā吖的博客
05-30 4398
从k8s的1.8版本开始，kube-proxy引入了IPVS模式，IPVS模式与iptables同样基于Netfilter，但是ipvs采用的hash表，iptables采用一条条的规则列表。iptables又是为了防火墙设计的，集群数量越多iptables规则就越多，而iptables规则是从上到下匹配，所以效率就越是低下。因此当service数量达到一定规模时，hash查表的速度优势就会显现出来，从而提高service的服务性能。
kube-proxy ipvs模式
oneslide
12-27 1654
IPVS() 基于linux内核模块Netfilter实现的传输层负载均衡技术LVS中负载均衡使用的技术就是IPVS, IPVS能够代理TCP,UDP协议，因此基于IPVS作为kubernetes Service负载均衡实现再好不过。iptables最初设计用于创建主机防火墙，其规则采用线性遍历方式，因此随着Service数量的增大，效率会出现问题。举个例子，一个5000个节点的集群，如果有2000个Service,每个Service有10个Pod. 那么每个工作节点上的iptables记录是个。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值