kube-proxy工作原理

最新推荐文章于 2024-01-08 16:09:46 发布
最新推荐文章于 2024-01-08 16:09:46 发布
阅读量7.5k 收藏 19
点赞数 2
分类专栏： K8S 文章标签： k8s kubeletes kube-proxy

本文对kube-proxy做了一些总结说明，对其内部的实现原理进行了研究，并对userspace和iptables两种mode的缺点进行的描述，都通过例子说明了iptable的工作。在下一篇博文中，我将对k8s v1.5中kube-proxy的源码进行分析，有兴趣的同学可以关注。

kube-proxy和service背景

说到kube-proxy，就不得不提到k8s中service，下面对它们两做简单说明：

kube-proxy其实就是管理service的访问入口，包括集群内Pod到Service的访问和集群外访问service。 kube-proxy管理sevice的Endpoints，该service对外暴露一个Virtual IP，也成为Cluster IP, 集群内通过访问这个Cluster IP:Port就能访问到集群内对应的seri vc e下的Pod。 service是通过Selector选择的一组Pods的服务抽象，其实就是一个微服务，提供了服务的LB和反向代理的能力，而kube-proxy的主要作用就是负责service的实现。 service另外一个重要作用是，一个服务后端的Pods可能会随着生存灭亡而发生IP的改变，service的出现，给服务提供了一个固定的IP，而无视后端Endpoint的变化。

服务发现

k8s提供了两种方式进行服务发现：

环境变量： 当你创建一个Pod的时候，kubelet会在该Pod中注入集群内所有Service的相关环境变量。需要注意的是，要想一个Pod中注入某个Service的环境变量，则必须S这个ervice必须先于该Pod的创建。这一点，几乎使得这种方式进行服务发现不可用。

比如，一个ServiceName为redis-master的Service，对应的ClusterIP:Port为10.0.0.11:6379，则其对应的环境变量为：

REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11

 DNS：这也是k8s官方强烈推荐的方式。

    可以通过cluster add-on的方式轻松的创建KubeDNS来对集群内的Service进行服务发现。

    更多关于KubeDNS的内容，请查看: Kubernetes DNS Service技术研究。

发布(暴露)服务

k8s原生的，一个Service的ServiceType决定了其发布服务的方式。

  1.ClusterIP：这是k8s默认的ServiceType。通过集群内的ClusterIP在内部发布服务。

  2.NodePort：这种方式是常用的，用来对集群外暴露Service，你可以通过访问集群内的每个NodeIP:NodePort的方式，访问到对应Service后端的Endpoint。

  3.LoadBalancer: 这也是用来对集群外暴露服务的，不同的是这需要Cloud Provider的支持，比如AWS等。 ExternalName：这个也是在集群内发布服务用的，需要借助KubeDNS(version >= 1.7)的支持，就是用KubeDNS将该service和ExternalName做一个Map，KubeDNS返回一个CNAME记录。

kube-proxy内部原理

kube-proxy当前实现了两种proxyMode：userspace和iptables。其中userspace mode是v1.0及之前版本的默认模式，从v1.1版本中开始增加了iptables mode，在v1.2版本中正式替代userspace模式成为默认模式。

kube-proxy转发的两种模式

kube-proxy在转发时主要有两种模式Userspace和Iptables。

 

使用Userspace模式（k8s版本为1.2之前默认模式），外部网络可以直接访问cluster IP。 
使用Iptables模式（k8s版本为1.2之后默认模式），外部网络不能直接访问cluster IP。 
从效率上看，Iptables会更高一些，但是需要Iptables version >=1.4.11.

userspace mode

userspace是在用户空间，通过kube-proxy来实现service的代理服务。废话不多说，其原理如下如图所示：
输入图片说明

可见，这种mode最大的问题是，service的请求会先从用户空间进入内核iptables，然后再回到用户空间，由kube-proxy完成后端Endpoints的选择和代理工作，这样流量从用户空间进出内核带来的性能损耗是不可接受的。这也是k8s v1.0及之前版本中对kube-proxy质疑最大的一点，因此社区就开始研究iptables mode。

Example
$ kubectl get service
NAME             LABELS                                    SELECTOR              IP(S)            PORT(S)
kubernetes       component=apiserver,provider=kubernetes                   10.254.0.1       443/TCP
ssh-service1     name=ssh,role=service                     ssh-service=true      10.254.132.107   2222/TCP

$ kubectl describe service ssh-service1 
Name:           ssh-service1
Namespace:      default
Labels:         name=ssh,role=service
Selector:       ssh-service=true
Type:           LoadBalancer
IP:         10.254.132.107
Port:              2222/TCP
NodePort:          30239/TCP
Endpoints:      
Session Affinity:   None
No events.

NodePort的工作原理与ClusterIP大致相同，发送到某个NodeIP:NodePort的请求，通过iptables重定向到kube-proxy对应的端口(Node上的随机端口)上，然后由kube-proxy再将请求发送到其中的一个Pod:TargetPort。

这里，假如Node的ip为10.0.0.5，则对应的iptables如下：

$ sudo iptables -S -t nat
...
-A KUBE-NODEPORT-CONTAINER -p tcp -m comment --comment "default/ssh-service1:" -m tcp --dport 30239 -j REDIRECT --to-ports 36463
-A KUBE-NODEPORT-HOST -p tcp -m comment --comment "default/ssh-service1:" -m tcp --dport 30239 -j DNAT --to-destination 10.0.0.5:36463
-A KUBE-PORTALS-CONTAINER -d 10.254.132.107/32 -p tcp -m comment --comment "default/ssh-service1:" -m tcp --dport 2222 -j REDIRECT --to-ports 36463
-A KUBE-PORTALS-HOST -d 10.254.132.107/32 -p tcp -m comment --comment "default/ssh-service1:" -m tcp --dport 2222 -j DNAT --to-destination 10.0.0.5:36463

可见：访问10.0.0.5:30239端口会被转发到node上的36463端口（随机监听端口）。而且在访问clusterIP 10.254.132.107的2222端口时，也会把请求转发到本地的36463端口。 36463端口实际被kube-proxy所监听，将流量进行导向到后端的pod上。

iptables mode

另一种mode是iptables，它完全利用内核iptables来实现service的代理和LB。是v1.2及之后版本默认模式，其原理图如下所示：
输入图片说明

iptables mode因为使用iptable NAT来完成转发，也存在不可忽视的性能损耗。另外，如果集群中存在上万的Service/Endpoint，那么Node上的iptables rules将会非常庞大，性能还会再打折扣。

这也导致，目前大部分企业用k8s上生产时，都不会直接用kube-proxy作为服务代理，而是通过自己开发或者通过Ingress Controller来集成HAProxy, Nginx来代替kube-proxy。

Example

iptables的方式则是利用了linux的iptables的nat转发进行实现。

apiVersion: v1
kind: Service
metadata:
  labels:
    name: mysql
    role: service
  name: mysql-service
spec:
  ports:
    - port: 3306
      targetPort: 3306
      nodePort: 30964
  type: NodePort
  selector:
    mysql-service: "true"

mysql-service对应的nodePort暴露出来的端口为30964，对应的cluster IP(10.254.162.44)的端口为3306，进一步对应于后端的pod的端口为3306。

mysql-service后端代理了两个pod，ip分别是192.168.125.129和192.168.125.131。先来看一下iptables。

$iptables -S -t nat
...
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING
-A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/mysql-service:" -m tcp --dport 30964 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/mysql-service:" -m tcp --dport 30964 -j KUBE-SVC-67RL4FN6JRUPOJYM
-A KUBE-SEP-ID6YWIT3F6WNZ47P -s 192.168.125.129/32 -m comment --comment "default/mysql-service:" -j KUBE-MARK-MASQ
-A KUBE-SEP-ID6YWIT3F6WNZ47P -p tcp -m comment --comment "default/mysql-service:" -m tcp -j DNAT --to-destination 192.168.125.129:3306
-A KUBE-SEP-IN2YML2VIFH5RO2T -s 192.168.125.131/32 -m comment --comment "default/mysql-service:" -j KUBE-MARK-MASQ
-A KUBE-SEP-IN2YML2VIFH5RO2T -p tcp -m comment --comment "default/mysql-service:" -m tcp -j DNAT --to-destination 192.168.125.131:3306
-A KUBE-SERVICES -d 10.254.162.44/32 -p tcp -m comment --comment "default/mysql-service: cluster IP" -m tcp --dport 3306 -j KUBE-SVC-67RL4FN6JRUPOJYM
-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-67RL4FN6JRUPOJYM -m comment --comment "default/mysql-service:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-ID6YWIT3F6WNZ47P
-A KUBE-SVC-67RL4FN6JRUPOJYM -m comment --comment "default/mysql-service:" -j KUBE-SEP-IN2YML2VIFH5RO2T

首先如果是通过node的30964端口访问，则会进入到以下链:

-A KUBE-NODEPORTS -p tcp -m comment --comment "default/mysql-service:" -m tcp --dport 30964 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/mysql-service:" -m tcp --dport 30964 -j KUBE-SVC-67RL4FN6JRUPOJYM

然后进一步跳转到KUBE-SVC-67RL4FN6JRUPOJYM的链:

-A KUBE-SVC-67RL4FN6JRUPOJYM -m comment --comment "default/mysql-service:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-ID6YWIT3F6WNZ47P
-A KUBE-SVC-67RL4FN6JRUPOJYM -m comment --comment "default/mysql-service:" -j KUBE-SEP-IN2YML2VIFH5RO2T

这里利用了iptables的–probability的特性，使连接有50%的概率进入到KUBE-SEP-ID6YWIT3F6WNZ47P链，50%的概率进入到KUBE-SEP-IN2YML2VIFH5RO2T链。

KUBE-SEP-ID6YWIT3F6WNZ47P的链的具体作用就是将请求通过DNAT发送到192.168.125.129的3306端口。

-A KUBE-SEP-ID6YWIT3F6WNZ47P -s 192.168.125.129/32 -m comment --comment "default/mysql-service:" -j KUBE-MARK-MASQ
-A KUBE-SEP-ID6YWIT3F6WNZ47P -p tcp -m comment --comment "default/mysql-service:" -m tcp -j DNAT --to-destination 192.168.125.129:3306

同理KUBE-SEP-IN2YML2VIFH5RO2T的作用是通过DNAT发送到192.168.125.131的3306端口。

-A KUBE-SEP-IN2YML2VIFH5RO2T -s 192.168.125.131/32 -m comment --comment "default/mysql-service:" -j KUBE-MARK-MASQ
-A KUBE-SEP-IN2YML2VIFH5RO2T -p tcp -m comment --comment "default/mysql-service:" -m tcp -j DNAT --to-destination 192.168.125.131:3306

分析完nodePort的工作方式，接下里说一下clusterIP的访问方式。 对于直接访问cluster IP(10.254.162.44)的3306端口会直接跳转到KUBE-SVC-67RL4FN6JRUPOJYM。

-A KUBE-SERVICES -d 10.254.162.44/32 -p tcp -m comment --comment "default/mysql-service: cluster IP" -m tcp --dport 3306 -j KUBE-SVC-67RL4FN6JRUPOJYM

接下来的跳转方式同NodePort方式。

转自 https://www.2cto.com/net/201702/599920.html

大树叶
关注
  • 2
    点赞
  • 踩
  • 19
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Kubernetes中kube-proxy的作用
✨ 欢迎来到【Seal ^_^ 的CSDN博客】！这里是我记录技术心得、分享经验的地方。✨
07-31 4029
`kube-proxy`是Kubernetes集群中不可或缺的一部分，它作为服务发现和内部网络通信的重要桥梁，确保了集群内部服务之间的无缝通信和高效负载均衡。
Kubernetes kube-proxy的iptables与ipvs模式
最新发布
✨ 欢迎来到【Seal ^_^ 的CSDN博客】！这里是我记录技术心得、分享经验的地方。✨
07-28 5910
kube-proxy支持多种不同的代理模式，其中iptables和ipvs是最常用的两种。
kubectl proxy 是什么
xiphi_6的专栏
02-16 3948
kubectl proxy 是一个本地的Kubernetes API的反向代理。 通过kubectl，除了可以访问API外，还可以通过API访问POD中的业务。
kube-proxy 原理
Johnny_Li的博客
03-15 1689
kube-proxy & service必要说明 kube-proxy其实就是管理service的访问入口，包括集群内Pod到Service的访问和集群外访问service。 kube-proxy管理sevice的Endpoints，该service对外暴露一个Virtual IP，也成为Cluster IP, 集群内通过访问这个Cluster IP:Port就能访问到集群内对应的ser...
kube-proxy 工作原理
qq1010267837的博客
07-20 2444
kube-proxy是Kubernetes的核心组件，部署在每个Node节点上，它是实现KubernetesService的通信与负载均衡机制的重要组件;kube-proxy负责为Pod创建代理服务，从apiserver获取所有server信息，并根据server信息创建代理服务，实现server到Pod的请求路由和转发，从而实现K8s层级的虚拟转发网络。kube-proxy有三种模式userspace、iptables和IPVS，其中userspace模式不太常用。...
kube-proxy实现原理
bangchongwu5831的博客
09-17 247
1.service概念 　　service是一组pod的服务抽象，相当于一组pod的LB，负责将请求分发给对应的pod。service会为这个LB提供一个IP，一般称为cluster IP。kube-proxy的作用主要是负责service的实现，具体来说，就是实现了内部从pod到service和外部的从node port向service的访问。 　　举个例子，现在有podA，pod...
Kube-proxy 使用 iptables 模式时,通过 Service 服务发布入口如何到达 Pod ？
山河已无恙
04-09 608
被问到这个问题，整理相关的笔记当 kube-proxy 模式设置为 iptables 的时候，通过 SVC 服务发布入口如何到达 Pod？博文内容涉及：问题简单介绍三种常用的服务发布方式到Pod报文路径解析当前集群为版本为v1.25.1Demo 演示使用了ansible理解不足小伙伴帮忙指正食用需要了解iptables生命的火花不是目标，而是对生活的热情。——《心灵奇旅》
Kubernetes入门：深入解析kube-proxy实现原理
SyDjango的博客
09-29 43
本文详细介绍了kube-proxy的实现原理，并提供了使用Userspace、Iptables和IPVS代理模式的示例代码。这些规则将请求的目标IP和端口重定向到kube-proxy所在的节点上的一个代理端口。Iptables代理模式相对于Userspace代理模式具有更好的性能，因为它在内核态中进行请求转发，减少了上下文切换的开销。在IPVS代理模式中，kube-proxy通过将服务的虚拟IP和端口注册到IPVS内核表中来实现请求的转发。Iptables代理模式是kube-proxy的默认代理模式。
kube-proxy参数ClusterCIDR做什么
期待幸福
10-24 366
可以看到这里做了几个链，在 *KUBE-SERVICES* 链中指明了非来自 ClusterCIDR 的 IP 都做一个，并且访问的目的地址是 *KUBE-CLUSTER-IP* (ipset 里配置的地址) 那么将跳转到 *KUBE-MARK-MASQ* 链做一个 ` --set-xmark 0x4000/0x4000` ，而在 *KUBE-POSTROUTING* 中对没有被标记 `0x4000/0x4000` 的操作不做处理。但实际上做了什么并不知道，那么就从源码解决这个问题。
k8s网络架构、k8s实战、实现原理、kube-proxy架构和Kubernetes分享
soshow2011的博客
05-26 654
0）SEO优化（大家可忽略此行）：K8S、Kubernetes、Linux、运维、Ops、SRE、DB 1）前言： 近期在做K8S的技术积累，发现网络各个社区极少有经验化的介绍K8S架构，小弟才疏学浅，尝试跟大家分享 2）K8S各种Service - nodePort： 可对外提供服务， 通常关联Ingress、nginx-ingress、haproxy-ingress， 实测LB入口只能关联NodePort无法关联ClusterIP - ClusterIP： 相信大家是非常熟悉的...
kube-proxy的工作原理 k8s网络原理 kube-proxy三种工作模式
yuezhilangniao的博客
06-24 261
Service是k8s中资源的一种，也是k8s能够实现减少运维工作量，甚至免运维的关键点，我们公司的运维都要把服务搭在我们集群里，接触过的人应该都能体会到其方便之处。Service能将pod的变化屏蔽在集群内部，同时提供负载均衡的能力，自动将请求流量分布到后端的pod，这一功能的实现靠的就是kube-proxy的流量代理，一共有三种模式，userspace、iptables以及ipvs。
kube-proxy的功能
weixin_30737433的博客
04-09 504
Kube-proxy的功能 我们知道POD的IP是动态分配的而且经常会变，所以为了可以通过一个不太容易变化的IP访问POD就会使用一个叫做service的东西，通过标签选择器和POD进行关联。 Service提供常用的类型有： ClusterIP，也是默认方式。Service会分配一个集群内部的固定虚拟IP，实现集群内通过该IP来对POD进行访问。这个又有两类，上面说到的最普通的Serv...
Kubernetes学习笔记之kube-proxy service实现原理
HULK一线技术杂谈
03-24 323
女主宣言今天小编为大家分享kube-proxy service的实现原理，希望能对大家有所帮助。PS：丰富的一线技术、多元化的表现形式，尽在“360云计算”，点关注哦！1Overview我...
kube-proxy 实现原理
lmix___的博客
03-28 774
Service是k8s中的一个概念，是对一组pod的服务抽象，主要负责将请求分发给对应的pod，完成反向代理和负载均衡(负载均衡一般采用Round Robin算法)。 kube-proxy来具体实现Service。 kube-proxy实现转发的方式有两种方式：Userspace，iptables。k8s1.2版本后默认用iptables的方式，实现一系列的包过滤、转发、nat操作。(1.8版本...
Kubernetes核心组件之kube-proxy实现原理
JavaEdge全是干货的技术号
01-08 1261
了解不同网络组件的工作原理有助于正确设计和配置它们，以满足你的应用程序需求。在Kubernetes网络的背后，有一个在幕后工作的组件。它将你的服务（Services）转化为一些可用的网络规则。这个组件被称为Kube-Proxy。本文展示Kube-Proxy的工作原理。我们将解释创建服务时发生的流程。并展示Kube-Proxy创建的一些示例规则。Kubernetes中的Pods是临时的，可随时被终止或重启。由于这种行为，我们不能依赖于它们的IP地址，因为它们总是在变。这就是Service。
kube-proxy的工作原理(实例说明)
kozazyh的专栏
03-13 3925
service是一组pod的服务抽象，相当于一组pod的LB，负责将请求分发给对应的pod。service会为这个LB提供一个IP，一般称为cluster IP。kube-proxy的作用主要是负责service的实现，具体来说，就是实现了内部从pod到service和外部的从node port向service的访问。以下，我们使用kubernetes + flannel(xvlan) 的网络配置...
kube-proxy 原理分析和技术演进
shida's blog
12-21 1060
一、引言        谈到 kube-proxy，就不得不提到 k8s 中的 Service，下面就对二者的关系作简单介绍： kube-proxy 其实就是管理 Service 的访问入口，包括集群内 Pod 到 Service 的访问和集群外访问 Service； kube-proxy 管理 Service 的 Endpoints，该 Service 对外暴露一个 Virtual IP...
kubernetes之kube-proxy工作原理和源码分析
菲宇运维
09-09 1784
本文对kube-proxy做了一些总结说明，对其内部的实现原理进行了研究，并对userspace和iptables两种mode的缺点进行的描述，都通过例子说明了iptable的工作。在下一篇博文中，我将对k8s v1.5中kube-proxy的源码进行分析，有兴趣的同学可以关注。 kube-proxy和service背景 说到kube-proxy，就不得不提到k8s中service，下面对...
k8s组件和工作原理
09-22
Kubernetes（简称K8s）是一个用于自动化容器操作的开源平台。它主要由一系列核心组件组成，包括kube-apiserver、kube-scheduler、kube-controller-manager和kubelet，以及用于存储和网络的etcd和kube-proxy。 首先，kube-apiserver是Kubernetes的核心组件之一，它提供了Kubernetes API的接口，用于管理集群的各种操作和资源。 其次，kube-scheduler负责决定将哪个Pod分配到哪个Node上运行。它会根据节点资源的使用情况、健康状况和Pod的约束条件等因素进行调度决策。 kube-controller-manager包含了多个控制器，用于监控并保证集群中的各种资源的状态保持在预期的状态。例如，Replication Controller用于对应用程序进行水平扩展和自动恢复，Namespace Controller用于管理命名空间，Service Account和Endpoint Controller则用于管理Service和Endpoint等资源。 kubelet是运行在每个Node上的代理组件，它负责管理Node上的容器和Pod。它会从kube-apiserver获取Pod的配置信息，并根据这些信息来管理容器的生命周期，同时还会主动上报节点的状态和资源使用情况给kube-apiserver。 etcd是Kubernetes中的分布式键值存储系统，用于存储集群的状态和配置信息。它为整个集群的各种组件提供数据的持久性存储和共享。 kube-proxy是负责在集群的Node节点上实现Kubernetes Service的代理组件。它通过监听kube-apiserver中Service和Endpoint的变化，动态地将访问Service的请求转发到后端的Pod上。 总体来说，Kubernetes的工作原理是基于Master-Slave架构的，Master节点上的核心组件负责管理整个集群的状态和配置，而Node节点上的kubelet和kube-proxy则负责管理容器和服务的运行。通过这些组件之间的协同工作，Kubernetes实现了容器的自动化部署、伸缩、调度和管理，提供了高可用、高效、可靠的容器环境。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值