深入明确k8s 网络

源码 · 2024-9-5 07:15:40

[TOC]
媒介

K8s是一个强大的平台，但它的网络比力复杂，涉及许多概念，比方Pod网络，Service网络，Cluster IPs，NodePort，LoadBalancer和Ingress等等，这么多概念足以让新手望而生畏。但是，只有深入明确K8s网络，才气为明确和用好K8s打下坚实根本。为了资助各人明确，模拟TCP/IP协议栈，我把K8s的网络分解为四个抽象层，从0到3，除了第0层，每一层都是构建于前一层之上，如下图所示：

第0层Node节点网络比力好明确，也就是包管K8s节点(物理或捏造机)之间可以大概正常IP寻址和互通的网络，这个一样寻常由底层(公有云或数据中心)网络根本办法支持。第0层我们假定已经存在，以是不睁开。第1到3层网络，分别举行分析。
本文旨在资助各人创建K8s网络的概念模子，而不是对底层技能的准确形貌。实际我们学技能以应用为主，紧张的是快速创建起直观易懂的概念模子，可以大概引导我们正常应用即可，固然明确肯定的技能细节也是有资助的。别的，本文假定读者对根本的网络技能，ip地址空间和容器技能等有肯定的了解。
Pod网络概念模子

Pod相称于是K8s云平台中的捏造机，它是K8s的根本调理单位。所谓Pod网络，就是可以大概包管K8s集群中的全部Pods(包罗同一节点上的，也包罗差别节点上的Pods)，逻辑上看起来都在同一个平面网络内，可以大概相互做IP寻址和通讯的网络，下图是Pod网络的简化概念模子：

Pod网络构建于Node节点网络之上，它又是上层Service网络的根本。为了进一步明确Pod网络，我将对同一节点上的Pod之间的网络，以及差别节点上的Pod之间网络，分别举行分析。
同一节点上的Pod网络

前面提到，Pod相称于是K8s云平台中的捏造机，实际一个Pod中可以住一个大概多个(大多数场景住一个)应用容器，这些容器共享Pod的网络栈和别的资源如Volume。那么什么是共享网络栈？同一节点上的Pod之间怎样寻址和互通？我以下图样例来表明：
上图节点上展示了Pod网络所依靠的3个网络装备，eth0是节点主机上的网卡，这个是支持该节点流量收支的装备，也是支持集群节点间IP寻址和互通的装备。docker0是一个捏造网桥，可以简朴明确为一个捏造互换机，它是支持该节点上的Pod之间举行IP寻址和互通的装备。veth0则是Pod1的捏造网卡，是支持该Pod内容器互通和对外访问的捏造装备。docker0网桥和veth0网卡，都是linux支持和创建的捏造网络装备。
上图Pod1内部住了3个容器，它们都共享一个捏造网卡veth0。内部的这些容器可以通过localhost相互访问，但是它们不能在同一端口上同时开启服务，否则会有端口辩说，这就是共享网络栈的意思。Pod1中另有一个比力特别的叫pause的容器，这个容器运行的唯一目标是为Pod创建共享的veth0网络接口。如果你SSH到K8s集群中一个有Pod运行的节点上去，然后运行docker ps，可以看到通过pause下令运行的容器。
Pod的IP是由docker0网桥分配的，比方上图docker0网桥的IP是172.17.0.1，它给第一个Pod1分配IP为172.17.0.2。如果该节点上再启一个Pod2，那么相应的分配IP为172.17.0.3，如果再启动Pod可依次类推。由于这些Pods都连在同一个网桥上，在同一个网段内，它们可以举行IP寻址和互通，如下图所示

从上图我们可以看到，节点内Pod网络在172.17.0.0/24这个地址空间内，而节点主机在10.100.0.0/24这个地址空间内，也就是说Pod网络和节点网络不在同一个网络内，那么差别节点间的Pod该怎样IP寻址和互通呢？下一节我们来分析这个题目
差别节点间的Pod网络

现在假设我们有两个节点主机，host1(10.100.0.2)和host2(10.100.0.3)，它们在10.100.0.0/24这个地址空间内。host1上有一个PodX(172.17.0.2)，host2上有一个PodY(172.17.1.3)，Pod网络在172.17.0.0/16这个地址空间内。注意，Pod网络的地址，是由K8s同一管理和分配的，包管集群内Pod的IP地址唯一。我们发现节点网络和Pod网络不在同一个网络地址空间内，那么host1上的PodX该怎样与host2上的PodY举行互通？
实际上差别节点间的Pod网络互通，有许多技能实现方案，底层的技能细节也很复杂。为了简化形貌，我把这些方案大要分为两类，一类是路由方案，别的一类是覆盖(Overlay)网络方案。
如果底层的网络是你可以控制的，好比说企业内部自建的数据中心，而且你和运维团队的关系比力好，可以接纳路由方案，如下图所示：
这个方案简朴明确，就是通过路由装备为K8s集群的Pod网络单独分别网段，并设置路由器支持Pod网络的转发。比方上图中，对于目标为172.17.1.0/24这个范围内的包，转发到10.100.0.3这个主机上，同样，对于目标为172.17.0.0/24这个范围内的包，转发到10.100.0.2这个主机上。当主机的eth0接口吸收到来自Pod网络的包，就会向内部网桥转发，如许差别节点间的Pod就可以相互IP寻址和通讯。这种方案依靠于底层的网络装备，但是不引入额外性能开销。
如果底层的网络是你无法控制的，好比说公有云网络，大概企业的运维团队不支持路由方案，可以接纳覆盖(Overlay)网络方案，如下图所示：
所谓覆盖网络，就是在现有网络之上再创建一个捏造网络，实现技能有许多，比方flannel/weavenet等等，这些方案多数接纳隧道封包技能。简朴明确，Pod网络的数据包，在出节点之前，会先被封装成节点网络的数据包，当数据包到达目标节点，包内的Pod网络数据包会被解封出来，再转发给节点内部的Pod网络。这种方案对底层网络没有特别依靠，但是封包解包会引入额外性能开销。
CNI简介

考虑到Pod网络实现技能浩繁，为了简化集成，K8s支持CNI(Container Network Interface)尺度，差别的Pod网络技能可以通过CNI插件情势和K8s举行集成。节点上的Kubelet通过CNI尺度接口操纵Pod网路，比方添加或删除网络接口等，它不须要关心Pod网络的详细实现细节。

小结

K8s的网络可以抽象成四层网络，第0层节点网络，第1层Pod网络，第2层Service网络，第3层外部接入网络。除了第0层，每一层都构建于上一层之上。
一个节点内的Pod网络依靠于捏造网桥和捏造网卡等linux捏造装备，包管同一节点上的Pod之间可以正常IP寻址和互通。一个Pod内容器共享该Pod的网络栈，这个网络栈由pause容器创建。
差别节点间的Pod网络，可以接纳路由方案实现，也可以接纳覆盖网络方案。路由方案依靠于底层网络装备，但没有额外性能开销，覆盖网络方案不依靠于底层网络，但有额外封包解包开销。
CNI是一个Pod网络集成尺度，简化K8s和差别Pod网络实现技能的集成。

有了Pod网络，K8s集群内的全部Pods在逻辑上都可以看作在一个平面网络内，可以正常IP寻址和互通。但是Pod仅仅是K8s云平台中的捏造机抽象，终极，我们须要在K8s集群中运行的是应用大概说服务(Service)，而一个Service背后一样寻常由多个Pods构成集群，这时间就引入了服务发现(Service Discovery)和负载均衡(Load Balancing)等题目
Service 网络

我们假定在K8s集群中摆设了一个Account-App应用，这个应用由4个Pod(捏造机)构成集群一起提供服务，每一个Pod都有自己的PodIP和端口。我们再假定集群内还摆设了别的应用，这些应用中有些是Account-App的斲丧方，也就说有Client Pod要访问Account-App的Pod集群。这个时间自然引入了两个题目：

服务发现(Service Discovery)： Client Pod怎样发现定位Account-App集群中Pod的IP？何况Account-App集群中Pod的IP是有大概会变的(英文叫ephemeral)，这种变革包罗预期的，好比Account-App重新发布，大概非预期的，比方Account-App集群中有Pod挂了，K8s对Account-App举行重新调理摆设。
负载均衡(Load Balancing)：Client Pod怎样以某种负载均衡计谋去访问Account-App集群中的差别Pod实例？以实现负载分摊和HA高可用。

实际上，K8s通过在Client和Account-App的Pod集群之间引入一层Account-Serivce抽象，来办理上述题目：

服务发现：Account-Service提供同一的ClusterIP来办理服务发现题目，Client只需通过ClusterIP就可以访问Account-App的Pod集群，不须要关心集群中的详细Pod数量和PodIP，纵然是PodIP发生变革也会被ClusterIP所屏蔽。注意，这里的ClusterIP实际是个捏造IP，也称Virtual IP(VIP)。
负载均衡：Account-Service抽象层具有负载均衡的本领，支持以差别计谋去访问Account-App集群中的差别Pod实例，以实现负载分摊和HA高可用。K8s中默认的负载均衡计谋是RoundRobin，也可以定制别的复杂计谋。

K8s中为何要引入Service抽象？背后的原理是什么？反面我将以技能演进视角来表明这些题目。
服务发现技能演进

DNS域名服务是一种较老且成熟的尺度技能，实际上DNS可以以为是最早的一种服务发现技能。
在K8s中引入DNS实现服务发实际在并不复杂，实际K8s自己就支持Kube-DNS组件。假设K8s引入DNS做服务发现(如上图所示)，运行时，K8s可以把Account-App的Pod集群信息(IP+Port等)主动注册到DNS，Client应用则通过域名查询DNS发现目标Pod，然后发起调用。这个方案不但简朴，而且对Client也无侵入(现在险些全部的操纵系统都自带DNS客户端)。但是基于DNS的服务发现也有如下题目

差别DNS客户端实现功能有差别，有些客户端每次调用都会去查询DNS服务，造成不须要的开销，而有些客户端则会缓存DNS信息，默认超时时间较长，当目标PodIP发生变革时(在容器云情况中是常态)，存在缓存刷新不实时，会导致访问Pod失效
DNS客户端实现的负载均衡计谋一样寻常都比力简朴，多数是RoundRobin，有些则不支持负载均衡调用。

考虑到上述差别DNS客户端实现的差别，不在K8s控制范围内，以是K8s没有直接接纳DNS技能做服务发现。注意，实际K8s是引入Kube-DNS支持通过域名访问服务的，不外这是创建在CusterIP/Service网络之上，这个我反面会睁开。
别的一种较新的服务发现技能，是引入Service Registry+Client配合实现，在当下微服务期间，这是一个比力流行的做法。现在主流的产物，如Netflix开源的Eureka + Ribbon，HashiCorp开源的Consul，另有阿里新开源Nacos等，都是这个方案的范例代表。
在K8s中引入Service Registry实现服务发现也不复杂，K8s自身带分布式存储etcd就可以实现Service Registry。假设K8s引入Service Registry做服务发现(如上图所示)，运行时K8s可以把Account-App和Pod集群信息(IP + Port等)主动注册到Service Registry，Client应用则通过Service Registry查询发现目标Pod，然后发起调用。这个方案也不复杂，而且客户端可以实现机动的负载均衡计谋，但是须要引入客户端配合，对客户应用有侵入性，以是K8s也没有直接接纳这种方案。
K8s固然没有直接接纳上述方案，但是它的Service网络实现是在上面两种技能的根本上扩展演收支来的。它融合了上述方案的优点，同时办理了上述方案的不敷，下节我会详细分析K8s的Service网络的实现原理。
K8s的Service网络原理

前面提到，K8s的服务发现机制是在上节讲的Service Registry + DNS根本上发展演收支来的，下图展示K8s服务发现的简化原理：
在K8s平台的每个Worker节点上，都摆设有两个组件，一个叫Kubelet，别的一个叫Kube-Proxy，这两个组件+Master是K8s实现服务注册和发现的关键。下面我们看下简化的服务注册发现流程。

起首，在服务Pod实例发布时(可以对应K8s发布中的Kind: Deployment)，Kubelet会负责启动Pod实例，启动完成后，Kubelet会把服务的PodIP列表汇报注册到Master节点。
其次，通过服务Service的发布(对应K8s发布中的Kind: Service)，K8s会为服务分配ClusterIP，干系信息也记录在Master上。
第三，在服务发现阶段，Kube-Proxy会监听Master并发现服务ClusterIP和PodIP列表映射关系，而且修改本地的linux iptables转发规则，指示iptables在吸收到目标为某个ClusterIP哀求时，举行负载均衡并转发到对应的PodIP上。
运行时，当有斲丧者Pod须要访问某个目标服务实例的时间，它通过ClusterIP发起调用，这个ClusterIP会被本地iptables机制截获，然后通过负载均衡，转发到目标服务Pod实例上。

实际斲丧者Pod也并不直接调服务的ClusterIP，而是先调用服务名，由于ClusterIP也会变(比方针对TEST/UAT/PROD等差别情况的发布，ClusterIP会差别)，只有服务名一样寻常稳固。为了屏蔽ClusterIP的变革，K8s在每个Worker节点上还引入了一个KubeDNS组件，它也监听Master并发现服务名和ClusterIP之间映射关系，如许，斲丧者Pod通过KubeDNS可以间接发现服务的ClusterIP。
注意，K8s的服务发现机制和现在微服务主流的服务发现机制(如Eureka + Ribbon)总体原理类似，但是也有显着区别(这些区别紧张体现在客户端)：

起首，两者都是接纳客户端署理(Proxy)机制。和Ribbon一样，K8s的署理转发和负载均衡也是在客户端实现的，但Ribbon是以Lib库的情势嵌入在客户应用中的，对客户应用有侵入性，而K8s的Kube-Proxy是独立的，每个Worker节点上有一个，它对客户应用无侵入。K8s的做法类似ServiceMesh中的边车(sidecar)做法。
第二，Ribbon的署理转发是穿透的，而K8s中的署理转发是iptables转发，固然K8s中有Kube-Proxy，但它只是负责服务发现和修改iptables(或ipvs)规则，实际哀求是不穿透Kube-Proxy的。注意早期K8s中的Kube-Proxy署理是穿透的，考虑到有性能消耗和单点题目，后续的版本就改成不穿透了。
第三，Ribbon实现服务名到服务实例IP地址的映射，它只有一层映射。而K8s中有两层映射，Kube-Proxy实现ClusterIP->odIP的映射，Kube-DNS实现ServiceName->ClusterIP的映射。

个人以为，对比现在微服务主流的服务发现机制，K8s的服务发现机制抽象得更好，它通过ClusterIP同一屏蔽服务发现和负载均衡，一个服务一个ClusterIP，这个模子和传统的IP网络模子更贴近和易于明确。ClusterIP也是一个IP，但这个IP反面跟的不是一个服务实例，而是一个服务集群，以是叫集群ClusterIP。同时，它对客户应用无侵入，且不穿透没有额外性能消耗。
总结

K8s的Service网络构建于Pod网络之上，它紧张目标是办理服务发现(Service Discovery)和负载均衡(Load Balancing)题目。
K8s通过一个ServiceName+ClusterIP同一屏蔽服务发现和负载均衡，底层技能是在DNS+Service Registry根本上发展演收支来。
K8s的服务发现和负载均衡是在客户端通过Kube-Proxy + iptables转发实现，它对应用无侵入，且不穿透Proxy，没有额外性能消耗。
K8s服务发现机制，可以以为是当代微服务发现机制和传统Linux内核机制的优雅团结。

有了Service抽象，K8s中摆设的应用都可以通过一个抽象的ClusterIP举行寻址访问，而且斲丧方不须要关心这个ClusterIP反面毕竟有多少个Pod实例，它们的PodIP是什么，会不会变革，怎样以负载均衡方式去访问等题目。但是，K8s的Service网络只是一个集群内可见的内部网络，集群外部是看不到Service网络的，也无法直接访问。而我们发布应用，有些是须要暴袒露去，要让外网以致公网可以大概访问的，如许才气对外提供服务。K8s怎样将内部服务暴袒露去？
外部接入网络

在讲到K8s怎样接入外部流量的时间，各人常常会听到NodePort，LoadBalancer和Ingress等概念，这些概念都是和K8s外部流量接入干系的，它们既是差别概念，同时又有关联性。下面我们分别表明这些概念和它们之间的关系。
NodePort

先提前夸大一下，NodePort是K8s将内部服务对外袒露的根本，反面的LoadBalancer底层有赖于NodePort。
之前我们讲了K8s网络的4层抽象，Service网络在第2层，节点网络在第0层。实际上，只有节点网络是可以直接对外袒露的，详细袒露方式要看数据中心或公有云的底层网络摆设，但不管接纳何种摆设，节点网络对外袒露是完全没有题目标。那么现在的题目是，第2层的Service网络怎样通过第0层的节点网络暴袒露去？我们可以回看一下K8s服务发现的原理图，如下图所示，然后不妨思索一下，K8s集群中有哪一个角色，即把握Service网络的全部信息，可以和Service网络以及Pod网络互通互联，同时又可以和节点网络买通？

答案是Kube-Proxy。上一篇我们提到Kube-Proxy是K8s内部服务发现的一个关键组件，毕竟上，它照旧K8s将内部服务暴袒露去的关键组件。Kube-Proxy在K8s集群中全部Worker节点上都摆设有一个，它把握Service网络的全部信息，知道怎么和Service网络以及Pod网络互通互联。如果要将Kube-Proxy和节点网络买通(从而将某个服务通过Kube-Proxy暴袒露去)，只须要让Kube-Proxy在节点上袒露一个监听端口即可。这种通过Kube-Proxy在节点上袒露一个监听端口，将K8s内部服务通过Kube-Proxy暴袒露去的方式，术语就叫NodePort(顾名思义，端口袒露在节点上)。下图是通过NodePort袒露服务的简化概念模子
如果我们要将K8s内部的一个服务通过NodePort方式暴袒露去，可以将服务发布(kind: Service)的type设定为NodePort，同时指定一个30000~32767范围内的端口。服务发布以后，K8s在每个Worker节点上都会开启这个监听端口。这个端口的背后是Kube-Proxy，当K8s外部有Client要访问K8s集群内的某个服务，它通过这个服务的NodePort端口发起调用，这个调用通过Kube-Proxy转发到内部的Servcie抽象层，然后再转发到目标Pod上。Kube-Proxy转发以及之后的环节，可以和上面的《Service网络》的内容对接起来。注意，为了直观形象，上图的Service在K8s集群中被画成一个独立组件，实际是没有独立Service如许一个组件的，只是一个抽象概念，如果要明确这个抽象的底层实现细节，可以转头看上一图的K8s服务发现原理，大概回到上面的《Service网络》。
LoadBalancer

上面我们提到，将K8s内部的服务通过NodePort方式暴袒露去，K8s会在每个Worker节点上都开启对应的NodePort端口。逻辑上看，K8s集群中的全部节点都会袒露这个服务，大概说这个服务是以集群方式袒露的(实际支持这个服务的Pod大概就分布在此中有限几个节点上，但是由于全部节点上都有Kube-Proxy，以是全部节点都知道该怎样转发)。既然是集群，就会涉及负载均衡题目，谁负责对这个服务的负载均衡访问？答案是须要引入负载均衡器(Load Balancer)。下图是通过LoadBalancer，将服务对外袒露的概念模子。

假设我们有一套阿里云K8s情况，要将K8s内部的一个服务通过LoadBalancer方式暴袒露去，可以将服务发布(Kind: Service)的type设定为LoadBalancer。服务发布后，阿里云K8s不但会主动创建服务的NodePort端口转发，同时会主动帮我们申请一个SLB，有独立公网IP，而且阿里云K8s会帮我们主动把SLB映射到配景K8s集群的对应NodePort上。如许，通过SLB的公网IP，我们就可以访问到K8s内部服务，阿里云SLB负载均衡器会在背后做负载均衡。
值得一提的是，如果是在本地开发测试情况里头搭建的K8s，一样寻常不支持Load Balancer也没须要，由于通过NodePort做测试访问就够了。但是在生产情况大概公有云上的K8s，比方GCP大概阿里云K8s，根本都支持主动创建Load Balancer。
Ingress

有了前面的NodePort + LoadBalancer，将K8s内部服务袒露到外网以致公网的需求就已经实现了，那么为啥还要引入Ingress如许一个概念呢？它起什么作用？
我们知道在公有云(阿里云/AWS/GCP)上，公网LB+IP是须要费钱买的。我们回看上图的通过LoadBalancer(简称LB)袒露服务的方式，发现要袒露一个服务就须要购买一个独立的LB+IP，如果要袒露十个服务就须要购买十个LB+IP，显然，从资源考虑这是不划算也不可扩展的。那么，有没有办法只需购买一个(大概少量)的LB+IP，但是却可以按需袒露更多服务出去呢？答案实在不复杂，就是想办法在K8内部摆设一个独立的反向署理服务，让它做署理转发。谷歌给这个内部独立摆设的反向署理服务起了一个奇怪的名字，就叫Ingress，它的简化概念模子如下图所示：
Ingress就是一个特别的Service，通过节点的HostPort(80/443)暴袒露去，前置一样寻常也有LB做负载均衡。Ingress转发到内部的别的服务，是通过集群内的Service抽象层/ClusterIP举行转发，终极转发到目标服务Pod上。Ingress的转发可以基于Path转发，也可以基于域名转发等方式，根本上你只需给它设置好转发路由表即可，功能和Nginx无本质差别。
注意，上图的Ingress概念模子是一种更抽象的画法，隐去了K8s集群中的节点，实际HostPort是袒露在节点上的。
以是，Ingress并不是什么神奇的东西，起首，它本质上就是K8s集群中的一个比力特别的Service(发布Kind: Ingress)。其次，这个Service提供的功能紧张就是7层反向署理(也可以提供安全认证，监控，限流和SSL证书等高级功能)，功能类似Nginx。第三，这个Service对外暴袒露去是通过HostPort(80/443)，可以和上面LoadBalancer对接起来。有了这个Ingress Service，我们可以做到只需购买一个LB+IP，就可以通过Ingress将内部多个(以致全部)服务暴袒露去，Ingress会帮助做署理转发。
那么哪些软件可以做这个Ingress？传统的Nginx/Haproxy可以，当代的微服务网关Zuul/SpringCloudGateway/Kong/Envoy/Traefik等等都可以。固然，谷歌别出心裁给这个东东起名叫Ingress，它照旧做了一些包装，以简化对Ingress的操纵。如果你明确了原理，那么完全可以用Zuul大概SpringCloudGateway，大概自己定制开发一个反向署理，来替换这个Ingress。摆设的时间以平凡Service摆设，将type设定为LoadBalancer即可，如下图所示：

注意，Ingress是一个7层反向署理，如果你要袒露的是4层服务，照旧须要走独立LB+IP方式。
Kubectl Proxy & Port Forward

上面提到的服务袒露方案，包罗NodePort/LoadBalancer/Ingress，紧张针对正式生产情况。如果在本地开发测试情况，须要对本地摆设的K8s情况中的服务大概Pod举行快速调试或测试，另有几种浅显办法，这边一并简朴先容下，如下图所示：

办法一，通过kubectl proxy下令，在本机上开启一个署理服务，通过这个署理服务，可以访问K8s集群内的恣意服务。背后，这个Kubectl署理服务通过Master上的API Server间接访问K8s集群内服务，由于Master知道集群内全部服务信息。这种方式只限于7层HTTP转发。
办法二，通过kubectl port-forward下令，它可以在本机上开启一个转发端口，间接转发到K8s内部的某个Pod的端口上。如许我们通过本机端口就可以访问K8s集群内的某个Pod。这种方式是TCP转发，不限于HTTP。
办法三，通过kubectl exec下令直接连到Pod上去实行linux下令，功能类似docker exec。

总结

NodePort是K8s内部服务对外袒露的根本，LoadBalancer底层有赖于NodePort。NodePort背后是Kube-Proxy，Kube-Proxy是沟通Service网络、Pod网络和节点网络的桥梁。
将K8s服务通过NodePort对外袒露是以集群方式袒露的，每个节点上都会袒露相应的NodePort，通过LoadBalancer可以实现负载均衡访问。公有云(如阿里云/AWS/GCP)提供的K8s，都支持主动摆设LB，且提供公网可访问IP，LB背后对接NodePort。
Ingress饰演的角色是对K8s内部服务举行会合反向署理，通过Ingress，我们可以同时对外袒露K8s内部的多个服务，但是只须要购买1个(大概少量)LB。Ingress本质也是一种K8s的特别Service，它也通过HostPort(80/443)对外袒露。
通过Kubectl Proxy大概Port Forward，可以在本地情况快速调试访问K8s中的服务或Pod。
K8s的Service发布紧张有3种type，type=ClusterIP，表现仅内部可访问服务，type=NodePort，表现通过NodePort对外袒露服务，type=LoadBalancer，表现通过LoadBalancer对外袒露服务(底层对接NodePort，一样寻常公有云才支持)。

深入明确k8s 网络

所属分类: 问答交流

新帖推荐: 30日

推荐作品