当前位置:   article > 正文

k8s的svc流量通过iptables和ipvs转发到pod的流程解析

k8s的svc流量通过iptables和ipvs转发到pod的流程解析

在常用的k8s环境中,通常会通过iptables将流量进行负载均衡、snat、dnat等操作,从而流量转发到pod或者外部的服务。本文重点介绍iptables是如何进行流量转发的以及相关转发的iptables和ipvs解析。


1. k8s的svc流量转发

1.1 service 说明

service只是一个抽象概念,在逻辑上将一组pod(功能相同)给抽象出来一个统一入口。可以将他简单理解为做了一个服务的负载均衡。我们知道pod在重新部署之后ip会改变,所以一般会通过service来访问pod。core-dns会给service分配一个内部的虚拟ip(节点上根本查询不到这个ip,ping是不通的,具体是怎么访问到的继续往下看),因此内部服务可以通过这个ip或者是serviceName来访问到pod的服务。

service提供的常用type

  • ClusterIP,也是默认方式。Service会分配一个集群内部的固定虚拟IP,实现集群内通过该IP来对POD进行访问。这个又有两类,上面说到的最普通的Service,ClusterIP还有一种是Headless Service,这种形式不会分配IP也不会通过kube-proxy做反向代理或者负载均衡,而是通过DNS提供稳定的网络ID来访问,DNS会将headless service的后端直接解析为POD的IP列表,这种主要是共StatefulSet类型使用。
  • NodePort,这种类型的Service是除了使用ClusterIP的功能外还会映射一个宿主机随机端口到service上,这样集群外部可以通过宿主机IP+随机端口来访问。这样得保证每一个node节点的该端口都可用才行,直接使用任意node节点的ip+端口就能直接访问pod。
  • HostPort,他这个和nodeport的区别是,只在某一个node节点打开端口。
    LoadBalancer:和nodePort类似,不过除了使用ClusterIP和NodePort之外还会向使用的公有云申请一个负载均衡器,从而实现集群外部通过LB来访问服务。这个主要是依托云lb。
  • ExternalName:是Service的一种特例,此模式主要面对运行在集群外部的服务,通过它可以将外部服务映射到k8s集群,具备k8s内服务的一些特性,来为集群内部提供服务
apiVersion: v1
kind: Service
metadata:
  namespace: app
  name: eureka-server
  labels:
    name: eureka-server
spec:
  type: NodePort ##这个位置来指定service的类型
  selector:
    app: eureka-server
  ports:
    - port: 80
      targetPort: 9101
      nodePort: 31101
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

1.2 endpoints说明

endpoints也是k8s的一个资源,我们在创建service的时候如果我们设置了selector选中了需要关联的pod,那么就会创建一个与service同名的endpoints。他是用来记录service对应pod的访问地址。

[root@aliyun168-37 nginx]# kubectl get endpoints nginx-svc -n test
NAME        ENDPOINTS                                         AGE
nginx-svc   10.244.4.139:80,10.244.4.140:80,10.244.4.141:80   18m
  • 1
  • 2
  • 3

1.3 pod 说明

Kubernetes(简称K8s)中的Pod是最小的可部署单元,它是一组相关容器的集合。一个Pod可以包含一个或多个容器,这些容器共享相同的资源(如网络和存储)。Pod提供了一种逻辑上独立的环境,使得应用可以在自己的虚拟空间中运行。

Service、Endpoint 和 Pod 的关系(下图)
在这里插入图片描述

1.4 svc流量转发的主要工作

Kubernetes服务(svc)能够感知Pod的变化是通过kube-proxy实现的,kube-proxy会监视Kubernetes API中的服务和端点对象,并根据Pod的变化来更新服务的endpoint信息,并进行流量转发。

总的说来,k8s的流量从svc转发到pod,一般来说需要做2个事情

  • 流量负载均衡
  • 包过滤,并针对来源ip、目的ip进行nat转换

如上2个功能需求,

  • 通过iptables规则都能够实现,并且iptables规则主要集中在流量负载均衡
  • ipvs只能实现负载均衡部分,包过滤和nat转换需要iptables规则来实现,但是相关的iptables规则数量很少

2. iptables规则解析

集群内调用service,通常采用如下方式

  • 集群内POD调用service,通常是使用Cluster IP。
  • 集群内发起调用,通过cluster ip访问到service。
  • 集群外发起调用,通过nodeport访问到service。

整体的转发流程图如下
在这里插入图片描述
node节点的iptables是由kube-proxy生成的,kube-proxy只修改了filter和nat表,它对iptables的链进行了扩充,自定义了KUBE-SERVICES,KUBE-NODEPORTS,KUBE-POSTROUTING,KUBE-MARK-MASQ和KUBE-MARK-DROP五个链,并主要通过为 KUBE-SERVICES链(附着在PREROUTING和OUTPUT)增加rule来配制traffic routing 规则

2.1 svc涉及的iptables链流程说明

svc涉及的iptables链路过程中的相关流程情况流程图如下

destination:172.30.5.207
destination:172.30.5.207
destination:172.30.5.207
destination:
destination:
loadbalancer的IP在节点上截获后转给service
内部流量/PREROUTING
KUBE-SERVICES
外部流量/OUTPUT
KUBE-MARK-MASQ
KUBE-SVC-M42ZCW2EYUCRBVAF
KUBE-SEP-EA7TYKWK2S6G4PQR
KUBE-SEP-ZJI36FVTROQF5MX7
KUBE-FW-M42ZCW2EYUCRBVAF
KUBE-XLB-M42ZCW2EYUCRBVAF
KUBE-SVC-M42ZCW2EYUCRBVAF

2.2 svc涉及的iptables规则实例

我们将针对一个iptables规则进行解析。

# 获取svc的
kubectl get svc -nkube-system -owide |grep kubernetes-lb 

kube-system                                kubernetes-lb                                                     LoadBalancer   192.168.11.23    172.29.163.9            6443:31714/TCP                                                                                                                                                                                                            2y47d   cluster.infra.tce.io/component=kube-apiserver,component=kube-apiserver
  • 1
  • 2
  • 3
  • 4
# 获取svc后段的pod
kubectl get pods -n kube-system -owide |grep kube-apiserver

kube-system                                kube-apiserver-172.33.0.11                                          1/1     Running                      7          247d    172.33.0.11      172.33.0.11    <none>           <none>
kube-system                                kube-apiserver-172.33.0.25                                          1/1     Running                      1          247d    172.33.0.25      172.33.0.25    <none>           <none>
kube-system                                kube-apiserver-172.33.0.30                                          1/1     Running                      0          247d    172.33.0.30      172.33.0.30    <none>           <none>
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
#  获取对应iptables情况
iptables-save |egrep "kubernetes-lb|KUBE-XLB-EFPSQH5654KMWHJ5|KUBE-SEP-LCXGRT47CYQENZGP|KUBE-SVC-EFPSQH5654KMWHJ5|KUBE-SEP-KJQQYC6E4EGY4UJE|KUBE-SEP-4DJFF4PKJG2GTZWW"

:KUBE-SEP-4DJFF4PKJG2GTZWW - [0:0]
:KUBE-SEP-KJQQYC6E4EGY4UJE - [0:0]
:KUBE-SEP-LCXGRT47CYQENZGP - [0:0]
:KUBE-SVC-EFPSQH5654KMWHJ5 - [0:0]
:KUBE-XLB-EFPSQH5654KMWHJ5 - [0:0]
-A KUBE-FW-EFPSQH5654KMWHJ5 -m comment --comment "kube-system/kubernetes-lb: loadbalancer IP" -j KUBE-XLB-EFPSQH5654KMWHJ5
-A KUBE-FW-EFPSQH5654KMWHJ5 -m comment --comment "kube-system/kubernetes-lb: loadbalancer IP" -j KUBE-MARK-DROP
-A KUBE-NODEPORTS -s 127.0.0.0/8 -p tcp -m comment --comment "kube-system/kubernetes-lb:" -m tcp --dport 31714 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "kube-system/kubernetes-lb:" -m tcp --dport 31714 -j KUBE-XLB-EFPSQH5654KMWHJ5
-A KUBE-SEP-4DJFF4PKJG2GTZWW -s 172.33.0.30/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-4DJFF4PKJG2GTZWW -p tcp -m tcp -j DNAT --to-destination :0 --persistent --to-destination :0 --persistent --to-destination 0.0.0.0 --persistent
-A KUBE-SEP-KJQQYC6E4EGY4UJE -s 172.33.0.25/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-KJQQYC6E4EGY4UJE -p tcp -m tcp -j DNAT --to-destination :0 --persistent --to-destination :0 --persistent --to-destination 0.0.0.0 --persistent
-A KUBE-SEP-LCXGRT47CYQENZGP -s 172.33.0.11/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-LCXGRT47CYQENZGP -p tcp -m tcp -j DNAT --to-destination :0 --persistent --to-destination :0 --persistent --to-destination 0.0.0.0 --persistent
-A KUBE-SERVICES ! -s 172.16.21.0/24 -d 192.168.11.23/32 -p tcp -m comment --comment "kube-system/kubernetes-lb: cluster IP" -m tcp --dport 6443 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 192.168.11.23/32 -p tcp -m comment --comment "kube-system/kubernetes-lb: cluster IP" -m tcp --dport 6443 -j KUBE-SVC-EFPSQH5654KMWHJ5
-A KUBE-SVC-EFPSQH5654KMWHJ5 -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-LCXGRT47CYQENZGP
-A KUBE-SVC-EFPSQH5654KMWHJ5 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-KJQQYC6E4EGY4UJE
-A KUBE-SVC-EFPSQH5654KMWHJ5 -j KUBE-SEP-4DJFF4PKJG2GTZWW
-A KUBE-XLB-EFPSQH5654KMWHJ5 -s 172.16.21.0/24 -m comment --comment "Redirect pods trying to reach external loadbalancer VIP to clusterIP" -j KUBE-SVC-EFPSQH5654KMWHJ5
-A KUBE-XLB-EFPSQH5654KMWHJ5 -m comment --comment "masquerade LOCAL traffic for kube-system/kubernetes-lb: LB IP" -m addrtype --src-type LOCAL -j KUBE-MARK-MASQ
-A KUBE-XLB-EFPSQH5654KMWHJ5 -m comment --comment "route LOCAL traffic for kube-system/kubernetes-lb: LB IP to service chain" -m addrtype --src-type LOCAL -j KUBE-SVC-EFPSQH5654KMWHJ5
-A KUBE-XLB-EFPSQH5654KMWHJ5 -m comment --comment "Balancing rule 0 for kube-system/kubernetes-lb:" -j KUBE-SEP-LCXGRT47CYQENZGP
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27

2.2.1 KUBE-SERVICES规则链

# 将访问svc的流量访问打标记,后续流量进出节点时进行NAT转换
-A KUBE-SERVICES ! -s 172.16.21.0/24 -d 192.168.11.23/32 -p tcp -m comment --comment "kube-system/kubernetes-lb: cluster IP" -m tcp --dport 6443 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 192.168.11.23/32 -p tcp -m comment --comment "kube-system/kubernetes-lb: cluster IP" -m tcp --dport 6443 -j KUBE-SVC-EFPSQH5654KMWHJ5
  • 1
  • 2
  • 3

访问192.168.11.23/32:6443的流量跳转到KUBE-SVC-EFPSQH5654KMWHJ5链路进行处理。

2.2.2 KUBE-SVC-EFPSQH5654KMWHJ5规则链

-A KUBE-SVC-EFPSQH5654KMWHJ5 -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-LCXGRT47CYQENZGP
-A KUBE-SVC-EFPSQH5654KMWHJ5 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-KJQQYC6E4EGY4UJE
-A KUBE-SVC-EFPSQH5654KMWHJ5 -j KUBE-SEP-4DJFF4PKJG2GTZWW
  • 1
  • 2
  • 3

将流量进行负载均衡,给各个规则连分配权重

规则链权重
KUBE-SEP-LCXGRT47CYQENZGP0.33333333349
KUBE-SEP-KJQQYC6E4EGY4UJE0.50000000000
KUBE-SEP-4DJFF4PKJG2GTZWW1-0.33333333349-0.50000000000=0.16666666651000006

其中KUBE-SEP-4DJFF4PKJG2GTZWW不需要设置probability,因为可以计算出来

1 − K U B E − S E P − L C X G R T 47 C Y Q E N Z G P − K U B E − S E P − K J Q Q Y C 6 E 4 E G Y 4 U J E 1- KUBE-SEP-LCXGRT47CYQENZGP - KUBE-SEP-KJQQYC6E4EGY4UJE 1KUBESEPLCXGRT47CYQENZGPKUBESEPKJQQYC6E4EGY4UJE

2.2.3 KUBE-SEP-LCXGRT47CYQENZGP规则链

# 第1条规则:Pod通过Service访问自身时匹配,此规则仅作标记(MARK)处理;
-A KUBE-SEP-4DJFF4PKJG2GTZWW -s 172.33.0.30/32 -j KUBE-MARK-MASQ
# 第2条规则:通过DNAT重定向到后端Pod实例上,至此,通过Service最终将流量导向到后端实例上;
-A KUBE-SEP-4DJFF4PKJG2GTZWW -p tcp -m tcp -j DNAT --to-destination :0 --persistent --to-destination :0 --persistent --to-destination 0.0.0.0 --persistent
-A KUBE-SEP-KJQQYC6E4EGY4UJE -s 172.33.0.25/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-KJQQYC6E4EGY4UJE -p tcp -m tcp -j DNAT --to-destination :0 --persistent --to-destination :0 --persistent --to-destination 0.0.0.0 --persistent
-A KUBE-SEP-LCXGRT47CYQENZGP -s 172.33.0.11/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-LCXGRT47CYQENZGP -p tcp -m tcp -j DNAT --to-destination :0 --persistent --to-destination :0 --persistent --to-destination 0.0.0.0 --persistent
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

按照KUBE-SVC-EFPSQH5654KMWHJ5配置的负载均衡相关的权重,将相关流量转发到后段的pod,完成流量转发和负载均衡。

2.2.4 KUBE-FW-EFPSQH5654KMWHJ5规则链

-A KUBE-FW-EFPSQH5654KMWHJ5 -m comment --comment "kube-system/kubernetes-lb: loadbalancer IP" -j KUBE-XLB-EFPSQH5654KMWHJ5
-A KUBE-FW-EFPSQH5654KMWHJ5 -m comment --comment "kube-system/kubernetes-lb: loadbalancer IP" -j KUBE-MARK-DROP
  • 1
  • 2

KUBE-MARK-DROP设置标记的报文则会在KUBE_FIREWALL中全部丢弃

2.2.5 KUBE-XLB-EFPSQH5654KMWHJ5规则链

-A KUBE-XLB-EFPSQH5654KMWHJ5 -s 172.16.21.0/24 -m comment --comment "Redirect pods trying to reach external loadbalancer VIP to clusterIP" -j KUBE-SVC-EFPSQH5654KMWHJ5
-A KUBE-XLB-EFPSQH5654KMWHJ5 -m comment --comment "masquerade LOCAL traffic for kube-system/kubernetes-lb: LB IP" -m addrtype --src-type LOCAL -j KUBE-MARK-MASQ
-A KUBE-XLB-EFPSQH5654KMWHJ5 -m comment --comment "route LOCAL traffic for kube-system/kubernetes-lb: LB IP to service chain" -m addrtype --src-type LOCAL -j KUBE-SVC-EFPSQH5654KMWHJ5
-A KUBE-XLB-EFPSQH5654KMWHJ5 -m comment --comment "Balancing rule 0 for kube-system/kubernetes-lb:" -j KUBE-SEP-LCXGRT47CYQENZGP
  • 1
  • 2
  • 3
  • 4

2.2.6 KUBE-XLB-EFPSQH5654KMWHJ5规则链

在KUBE-XLB后,loadbalancer的IP在节点上截获后转给service

-A KUBE-SVC-EFPSQH5654KMWHJ5 -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-LCXGRT47CYQENZGP
-A KUBE-SVC-EFPSQH5654KMWHJ5 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-KJQQYC6E4EGY4UJE
-A KUBE-SVC-EFPSQH5654KMWHJ5 -j KUBE-SEP-4DJFF4PKJG2GTZWW
  • 1
  • 2
  • 3

由此完成了流量转发。

2.3 iptables转发链路总结

  • 可以发现当流量在本机节点/pod进出时,需要进行流量的过滤和通过KUBE-MARK-MASQ进行流量打标,从而进行NAT转换。
  • 通过KUBE-SVC-EFPSQH5654KMWHJ5和KUBE-SEP-LCXGRT47CYQENZGP进行流量的负载均衡和转发,当svc和pod很多时,iptables相关的转发规则会很多
    单个节点的 i p t a b l e s 规则大体上可以 = s v c 数量 ∗ e n d p o i n t 数量 单个节点的iptables规则大体上可以=svc数量*endpoint数量 单个节点的iptables规则大体上可以=svc数量endpoint数量

单个 k 8 s 集群的 i p t a b l e s 规则数量 = 单节点的 i p t a b l e s 规则数量 ∗ 节点数量 单个k8s集群的iptables规则数量=单节点的iptables规则数量*节点数量 单个k8s集群的iptables规则数量=单节点的iptables规则数量节点数量

  • 由于iptables规则通过list类型数据结构进行管理,执行时间O(n),当svc和node节点数量很多时,iptables规则过多时,新规则的查询和创建会越来越慢

3. ipvs规则解析

在 IPVS 模式下,kube-proxy监视Kubernetes服务和端点,调用 netlink 接口创建 IPVS 规则, 并定期将 IPVS 规则与 Kubernetes 服务和端点同步。访问服务时,IPVS 将流量定向到后端Pod之一。IPVS代理模式基于类似于 iptables 模式的 netfilter 挂钩函数, 但是使用哈希表作为基础数据结构,执行时间O(1),并且在内核空间中工作。这意味着,与 iptables 模式下的 kube-proxy 相比,IPVS 模式下的 kube-proxy 重定向通信的延迟要短,并且在同步代理规则时具有更好的性能。与其他代理模式相比,IPVS 模式还支持更高的网络流量吞吐量。

3.1 ipvs工作原理

IPVS 模式的工作原理,其实跟 iptables 模式类似。当我们创建了前面的 Service 之后,kube-proxy 首先会在宿主机上创建一个虚拟网卡(叫作:kube-ipvs0),并为它分配 Service VIP 作为 IP 地址。接下来,kube-proxy 就会通过 Linux 的 IPVS 模块,为这个 IP 地址设置三个 IPVS 虚拟主机,并设置这三个虚拟主机之间使用轮询模式 (rr) 来作为负载均衡策略。拓扑图如下所示拓扑图:
在这里插入图片描述

查看绑定的虚拟网卡

# ip addr
  ...
  73:kube-ipvs0:<BROADCAST,NOARP>  mtu 1500 qdisc noop state DOWN qlen 1000
  link/ether  1a:ce:f5:5f:c1:4d brd ff:ff:ff:ff:ff:ff
  inet 10.0.1.175/32  scope global kube-ipvs0
  valid_lft forever  preferred_lft forever
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

查看内部的转发规则

# ipvsadm -ln
 IP Virtual Server version 1.2.1 (size=4096)
  Prot LocalAddress:Port Scheduler Flags
    ->  RemoteAddress:Port           Forward  Weight ActiveConn InActConn     
  TCP  10.102.128.4:80 rr
    ->  10.244.3.6:9376    Masq    1       0          0         
    ->  10.244.1.7:9376    Masq    1       0          0
    ->  10.244.2.3:9376    Masq    1       0          0
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

3.2 ipvs支持的负载均衡算法

  • rr:轮询调度
  • lc:最小连接数
  • dh:目标地址散列
  • sh:源地址散列
  • sed:最短期望延迟
  • nq:最少队列

3.3 svc涉及的ipvs链流程说明

  • 使用ipvs进行负载均衡和流量转发时,相对于iptables来说,svc的流量转发流程整体上跟使用iptables是一致的。
  • 差别是ipvs代替了iptables的KUBE-SVC-EFPSQH5654KMWHJ5和KUBE-SEP-LCXGRT47CYQENZGP进行流量的负载均衡和转发
  • 针对流量过滤和NAT,还是基于iptables实现,但是这样的辅助性的规则数量有限,不会造成性能瓶颈

因此ipvs模式下,实际上是 ipvs负载均衡 + iptables过滤和NAT,实现svc的流量转发整体流程

4. 疑问和思考

4.1 KUBE-MARK-MASQ规则说明

KUBE-MARK-MASQ的作用是确保Kubernetes集群中的流量在转发到外部网络时可以正确地进行NAT处理,并提供网络隔离、安全性、负载均衡和故障转移等功能。

  • 首先 KUBE-MARK-MASQ 的作用是把报文打上 0x4000/0x4000 的标记,在 KUBE-POSTROUTING 时,如果报文中包含这个标记,会执行 -j MASQUERADE 操作,而这个操作的作用就是做源地址转换(SNAT)。
  • Kubernetes集群中的每个节点上都有一个名为KUBE-MARK-MASQ的iptables规则。当流量进入节点时,该规则将被应用于这些流量,将源IP地址和源端口替换为节点的IP地址和随机端口。这样可以确保流量在从集群中的任何节点转发到外部网络时,都具有相同的源IP地址和端口。

4.2 KUBE-MARK-DROP规则说明

KUBE-MARK-DROP设置标记的报文则会在KUBE_FIREWALL中全部丢弃

4.3 使用iptables规则有什么问题?

iptables规则通过list类型数据结构进行管理,执行时间O(n),当svc和node节点数量很多时,iptables规则过多时,新规则的查询和创建会越来越慢,并引发性能问题

  • 规则顺序匹配延迟大
  • 访问 service 时需要遍历每条链知道匹配,时间复杂度 O(N),当规则数增加时,匹配时间也增加。
  • 规则更新延迟大
  • iptables 规则更新不是增量式的,每更新一条规则,都会把全部规则加载刷新一遍。
  • 规则数大时,会出现 kernel lock
  • svc 数增加到 5000 时,会频繁出现 Another app is currently holding the xtables lock. Stopped waiting after 5s, 导致规则更新延迟变大,kube-proxy 定期同步时也会因为 超时导致 CrashLoopBackOff。

4.4 iptables和ipvs两者的优劣势如何?

  • iptables和ipvs均是基于内核的netfilter进行流量转发,虽然实现方式上又差异,ipvs将相关操作转移到内核台进行,在性能上优于iptables,但是差别并不大,因此整体上认为性能上是相近的
  • 在集群中不超过1000个服务的时候,iptables 和 ipvs 并无太大的差异。而且由于iptables 与网络策略实现的良好兼容性,iptables 是个非常好的选择
  • 如果svc和节点数量持续增加,svc数量超过5000后,ipvs和iptables的性能差异开始显现出来,并且随着svc增加iptables的性能越来越差,而ipvs并不会随着svc增加出现性能上的差异

出现这样的差异,最主要的原因是

  • iptables使用list类型作为基础数据结构,执行时间O(n)
  • ipvs使用哈希表作为基础数据结构,执行时间O(1)

两者的性能压测情况,可以参考 对比 iptables 和 ipvs 的性能差异
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

5. 参考文档

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/我家小花儿/article/detail/136741
推荐阅读
相关标签
  

闽ICP备14008679号