- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框,下拉多选树,多级节点
- 【学习笔记】基础数据结构:猫树
kube-proxy 是 Kubernetes 集群中负责服务发现和负载均衡的组件之一。它是一个网络代理,运行在每个节点上, 用于 service 资源的负载均衡。它有两种模式:iptables 和 ipvs.
iptables 是 Linux 系统中的一个用户空间实用程序,用于配置内核的网络包过滤和网络地址转换(NAT)规则。它是 Linux 内核中的 netfilter 框架的一部分,并负责在网络包进入、转发或离开计算机时进行筛选和处理。其主要功能和用途包括:
iptables 是通过链(chains)和表(tables)来组织规则的。每个链由一组规则组成,当网络数据包经过时,这些规则会逐一执行。常用的表包括:
链的流向为:
所以,根据上图,我们能够想象出某些常用场景中,报文的流向:
到本机某进程的报文:PREROUTING –> INPUT 。
由本机转发的报文:PREROUTING –> FORWARD –> POSTROUTING 。
由本机的某进程发出报文(通常为响应报文):OUTPUT –> POSTROUTING 。
尽管在某些情况下配置 iptables 规则可能复杂,但它提供了高度的灵活性和强大的功能,使其成为 Linux 网络安全的重要组成部分.
我启动了一个 3 个 nginx pod,和一个对应的 service,service 的类型是 ClusterIP,这样 service 就会有一个虚拟 IP,这个 IP 会被 kube-proxy 代理到后端的 pod 上.
~ » k get pod -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-59f546cb79-2k9ng 1/1 Running 2 (31m ago) 50m 10.244.0.28 minikube <none> <none>
nginx-deployment-59f546cb79-wfw84 1/1 Running 2 (31m ago) 50m 10.244.0.30 minikube <none> <none>
nginx-deployment-59f546cb79-zr9xm 1/1 Running 2 (31m ago) 50m 10.244.0.27 minikube <none> <none>
----------------------------------------------------------------------------------------------------------------------------------------------------
~ » k get svc nginx-service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-service ClusterIP 10.101.57.97 <none> 80/TCP 29m
当我们在 master 使用 curl 10.101.57.97 访问 service 的时候,首先会进入 PREROUTING 链:
root@minikube:/# iptables-save |grep PREROUTING
:PREROUTING ACCEPT [0:0]
:PREROUTING ACCEPT [34:2040]
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A PREROUTING -d 192.168.49.1/32 -j DOCKER_OUTPUT
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
首先会尝试匹配 KUBE-SERVICES 链,这个链是 kube-proxy 生成的,用于处理 service 的请求。后两个是 docker 的链,用于处理 docker 的请求.
root@minikube:/# iptables-save |grep "\-A KUBE-SERVICES"
-A KUBE-SERVICES -d 10.96.0.1/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -j KUBE-SVC-NPX46M4PTMTKRN6Y
-A KUBE-SERVICES -d 10.101.57.97/32 -p tcp -m comment --comment "default/nginx-service cluster IP" -j KUBE-SVC-V2OKYYMBY3REGZOG
-A KUBE-SERVICES -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -j KUBE-SVC-TCOU7JCQXEZGVUNU
-A KUBE-SERVICES -d 10.96.0.10/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -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" -j KUBE-SVC-JD5MR3NA4I4DYORP
-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
我们这个 nginx-service 的 cluster IP 是 10.101.57.97, 所以会走 KUBE-SVC-V2OKYYMBY3REGZOG 链:
root@minikube:/# iptables-save |grep "\-A KUBE-SVC-V2OKYYMBY3REGZOG"
-A KUBE-SVC-V2OKYYMBY3REGZOG ! -s 10.244.0.0/16 -d 10.101.57.97/32 -p tcp -m comment --comment "default/nginx-service cluster IP" -j KUBE-MARK-MASQ
-A KUBE-SVC-V2OKYYMBY3REGZOG -m comment --comment "default/nginx-service -> 10.244.0.27:80" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-POZMZY2HDLRATSJV
-A KUBE-SVC-V2OKYYMBY3REGZOG -m comment --comment "default/nginx-service -> 10.244.0.28:80" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-Z3HXRORN5VDCFRJU
-A KUBE-SVC-V2OKYYMBY3REGZOG -m comment --comment "default/nginx-service -> 10.244.0.30:80" -j KUBE-SEP-S46ZL6MIFVWDY42O
-A KUBE-SVC-V2OKYYMBY3REGZOG ! -s 10.244.0.0/16 -d 10.101.57.97/32 -p tcp -m comment --comment "default/nginx-service cluster IP" -j KUBE-MARK-MASQ 这条规则的如果源ip 不是 10.244.0.0/16 的 ip(也就是不是 pod发出来的请求),目的ip 是 service ip,jump 跳转到 这个链 KUBE-MARK-MASQ 。
root@minikube:/# iptables-save |grep "\-A KUBE-MARK-MASQ"
-A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000
这条规则的作用是给数据包打上 0x4000 这个标记。这个标记会被后续的 NAT 规则识别到,从而让这些数据包通过特定的 NAT 规则进行 IP 地址转换.
接下来看主要的三条规则:
-A KUBE-SVC-V2OKYYMBY3REGZOG -m comment --comment "default/nginx-service -> 10.244.0.27:80" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-POZMZY2HDLRATSJV
-A KUBE-SVC-V2OKYYMBY3REGZOG -m comment --comment "default/nginx-service -> 10.244.0.28:80" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-Z3HXRORN5VDCFRJU
-A KUBE-SVC-V2OKYYMBY3REGZOG -m comment --comment "default/nginx-service -> 10.244.0.30:80" -j KUBE-SEP-S46ZL6MIFVWDY42O
第一条是说有 33.33% 的几率会被转发到 KUBE-SEP-POZMZY2HDLRATSJV, 第二条是 50% 的几率会被转发到 KUBE-SEP-Z3HXRORN5VDCFRJU, 第三条是一定会被转发到 KUBE-SEP-S46ZL6MIFVWDY42O。 转到第一条的概率是 33.33%,转到第二条的概率是 66.67%(没有到第一条的概率) * 50% = 33.33%,第三条就是 66.67%(没有到第一条的概率) * 50%(没有到第二条的概率) = 33.33%。所以这三条规则的概率是一样的。都是 33.33%。 那么 KUBE-SEP-POZMZY2HDLRATSJV 又是什么呢?
root@minikube:/# iptables-save |grep "\-A KUBE-SEP-POZMZY2HDLRATSJV"
-A KUBE-SEP-POZMZY2HDLRATSJV -s 10.244.0.27/32 -m comment --comment "default/nginx-service" -j KUBE-MARK-MASQ
-A KUBE-SEP-POZMZY2HDLRATSJV -p tcp -m comment --comment "default/nginx-service" -m tcp -j DNAT --to-destination 10.244.0.27:80
root@minikube:/# iptables-save |grep "\-A KUBE-SEP-POZMZY2HDLRATSJV"
-A KUBE-SEP-Z3HXRORN5VDCFRJU -s 10.244.0.28/32 -m comment --comment "default/nginx-service" -j KUBE-MARK-MASQ
-A KUBE-SEP-Z3HXRORN5VDCFRJU -p tcp -m comment --comment "default/nginx-service" -m tcp -j DNAT --to-destination 10.244.0.28:80
root@minikube:/# iptables-save |grep "\-A KUBE-SEP-S46ZL6MIFVWDY42O"
-A KUBE-SEP-S46ZL6MIFVWDY42O -s 10.244.0.30/32 -m comment --comment "default/nginx-service" -j KUBE-MARK-MASQ
-A KUBE-SEP-S46ZL6MIFVWDY42O -p tcp -m comment --comment "default/nginx-service" -m tcp -j DNAT --to-destination 10.244.0.30:80
第一条规则确保流量从 10.244.0.20 发出时被打上 MASQUERADE 标记,以便通过 NAT 机制进行 IP 伪装。 第二条是将流量转发到 10.244.0.20:80 并使用 DNAT 机制进行目标地址转换, 转换的 ip 10.244.0.27:80 就是 pod 的 ip 和端口。 KUBE-SEP-Z3HXRORN5VDCFRJU 和 KUBE-SEP-S46ZL6MIFVWDY42O 的规则和这条同理.
IPVS(IP Virtual Server)是 Linux 内核中实现负载均衡功能的模块。是一种高效的负载均衡技术,可以在第 4 层(传输层)进行流量转发和调度。IPVS 通常被用于构建高性能、高可用性的负载均衡集群.
查看 ipvs 的规则:
root@minikube:/etc/apt# sudo ipvsadm -Ln|grep -A 4 10.101.57.97
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.101.57.97:80 rr
-> 10.244.0.27:80 Masq 1 0 0
-> 10.244.0.28:80 Masq 1 0 0
-> 10.244.0.30:80 Masq 1 0 0
UDP 10.96.0.10:53 rr
这个的意思是到10.101.57.97:80 的 tcp 浏览会使用 rr(轮询)的方式转发到 10.244.0.27:80,10.244.0.28:80,10.244.0.30:80 这三个 pod 上。Masq:指示 "Masquerading",表示通过 NAT 来处理网络流量。 所以 ipvs 的模式比 iptables 性能高的多,第一因为 ipvs 是轮询选,iptables 是逐条百分比匹配的,这个还是可以接受的。更要命的是第二条,当 pod 频繁变更的时候 service 对应的 endpoint 的 ENDPOINTS 就会增加或者是减少。那么 iptables 对应 service 的所有规则的百分比都会变化,就会导致一个 service 的规则全部要重刷,当 pod 变化太频繁时,会吃掉大量的 CPU.
不是说开启了 ipvs 就不会有 iptables 了,还需要 iptables 的 SNAT 规则来处理返回的数据包.
-A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING
-A KUBE-POSTROUTING -m comment --comment "Kubernetes endpoints dst ip:port, source ip for solving hairpin purpose" -m set --match-set KUBE-LOOP-BACK dst,dst,src -j MASQUERADE
-m set --match-set KUBE-LOOP-BACK dst,dst,src 的意思是匹配 KUBE-LOOP-BACK 这个 set,这个 set 里面存放的是 pod 的 ip,这个规则的作用是将数据包的源地址替换为本机的地址,以便数据包能够正确返回到客户端。 为什么是 pod ip 而不是 service cluster ip 呢?因为已经通过 ipvs DNAT 过了,所以这里是 pod ip.
root@minikube:/etc/apt# ipset -L|grep -A 15 KUBE-LOOP-BACK
Name: KUBE-LOOP-BACK
Type: hash:ip,port,ip
Revision: 6
Header: family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0xe4e21451
Size in memory: 544
References: 1
Number of entries: 6
Members:
10.244.0.28,tcp:80,10.244.0.28
10.244.0.30,tcp:80,10.244.0.30
10.244.0.29,tcp:9153,10.244.0.29
10.244.0.29,tcp:53,10.244.0.29
10.244.0.27,tcp:80,10.244.0.27
10.244.0.29,udp:53,10.244.0.29
很明显我们的三个 pod 都在这个 set 里面.
-A KUBE-POSTROUTING -m comment --comment "Kubernetes endpoints dst ip:port, source ip for solving hairpin purpose" -m set --match-set KUBE-LOOP-BACK dst,dst,src -j MASQUERADE 这条规则的作用是将数据包的源地址替换为本机的地址,以便数据包能够正确返回到客户端。现在我们使用 curl 发出的包目标 ip 是 pod ip了,源 ip 是 node ip。等到数据包返回的时候,kernel 会根据 链路追踪 中的数据记录,会把包的源ip 的pod ip 替换为 serice cluster ip, 目标 ip 从 node ip 替换为我发起请求的 ip。这样包就能正确返回到客户端了.
最后此篇关于kube-proxy流量流转方式的文章就讲到这里了,如果你想了解更多关于kube-proxy流量流转方式的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我在这里阅读了有关代理的示例: http://docs.oracle.com/javase/1.3/docs/guide/reflection/proxy.html 可以看到,'invoke'方法中的
在我的通用 nuxt 应用程序中,我将代理设置为 true 并重写了我的 url 以避免 CORS 问题。但是当我将代理设置为 true 时,我所有的发布请求都会更改为获取请求。不明白为什么以及如何将
我正在开发一个连接到 SFTP 服务器并使用 Apache Commons VFS 下载文件的应用程序,它工作得很好,但系统需要允许用户根据需要指定代理。 现在,我知道 Apache Commons
跟随线程[实体无法转换为javassist.util.proxy.Proxy,我现在确实有服务器端错误(tks thomas) 我无法在我的应用程序中面对真正的问题。 java.lang.ClassC
我正在使用 Charles Proxy 重写 API 的响应以进行测试。 如果我设置断点,我就可以按照自己的意愿完全重写原始响应。 但是,如果我想通过“重写”工具自动化它,我就陷入困境了,似乎你无法修
让我解释一下困境。 我使用 Amazon 的 3 项服务:EC2、S3 和 CloudFront。 EC2 接收上传的文件,并将其存储在 S3 存储桶中。然后 CloudFront 镜像 S3 存储桶
我正在使用 Caddy 在 DigitalOcean Ubuntu droplet 上反向代理某些站点。 这是我的 Caddy 文件,非常简单:upside_down: my-site.com {
我正在尝试测试承受多台计算机负载的 SOCKS 代理。我的代码大纲类似于 使用一个客户端直接连接到服务器,下载测试文件,并记录所花费的时间。 通过代理与一个客户端连接,下载测试文件,并记录所花费的时间
以下情况: 如果我将浏览器的 http/https 代理设置为 Charles 为 (127.0.0.1:8888) 配置的端口,使用 Charles 代理拦截 Web 流量就可以正常工作 如果我将浏
我有一个使用 grunt 构建的 angularJs 应用程序和一个用 Java 编写的在 tomcat 服务器上运行的服务器后端。为了在开发时将它们连接在一起,我想使用 grunt-connect-
对于文件上传,我试图在我的 Spring Controller 中注入(inject)并使用 validator ,如下所示: @RestController @RequestMapping("/ap
我需要使用 CaSTLe DynamicProxy 来代理接口(interface),方法是向 ProxyGenerator.CreateInterfaceProxyWithTarget 提供接口(i
我已经看到,当不同框架(例如实现 EJB 规范的框架或某些 JPA 提供程序)中发生错误时,堆栈跟踪包含像 com.sun.proxy.$Proxy 这样的类。我知道代理是什么,但我正在寻找更技术性和
我正在使用带有多个 apiserver 的集群设置,它们前面有一个负载均衡器,用于外部访问,并安装在裸机上。 就像 High Availability Kubernetes Clusters 中提到的
我使用 Charles 代理(在 OS X 10.9.3 下,Mavericks 下)修改 Origin header ,以便我连接的 API(开发中)接受来自开发环境的传入请求。 我设法通过一个简单
我已经在 Python 中实现了一个“网络服务”父类(super class),如下所示: class NetworkService (threading.Thread): """
我正在使用node.js代理。但是它工作成功: proxy.on('proxyResponse', function (proxyRes, req, res) { console.log("h
我正在尝试使用Nginx-Proxy在Ubuntu VPS的docker容器内运行WordPress网站。 我创建了以下docker-compose.yml文件 version: '3.4' serv
我一直在使用 DataKinds 扩展以类型安全的方式将类型级别 Nats 传递给函数,我只是想知道是否有更好的编写方式: (Proxy :: Proxy 42) 例如,如果类型系统看到参数需要,是否
已关闭。此问题旨在寻求有关书籍、工具、软件库等的建议。不符合Stack Overflow guidelines .它目前不接受答案。 我们不允许提问寻求书籍、工具、软件库等的推荐。您可以编辑问题,以
我是一名优秀的程序员,十分优秀!