电子商务 网站建设一般通过男性

电子商务 网站建设,一般通过男性,长尾关键词挖掘精灵,建设公司网站计入哪个科目Pod网络概念模型 Pod相当于Kubernetes中的虚拟机#xff0c;是基本调度单位。Pod网络确保集群内所有Pod#xff08;无论是否在同一节点#xff09;在逻辑上处于同一平面网络#xff0c;支持IP寻址和通信。Pod网络构建于节点网络之上#xff0c;为上层Service网络提供基础…Pod网络概念模型Pod相当于Kubernetes中的虚拟机是基本调度单位。Pod网络确保集群内所有Pod无论是否在同一节点在逻辑上处于同一平面网络支持IP寻址和通信。Pod网络构建于节点网络之上为上层Service网络提供基础。同一节点上的Pod网络Pod内容器共享网络栈通过pause容器创建的虚拟网卡veth0。节点上的关键网络设备包括eth0节点物理网卡支持节点间通信。docker0虚拟网桥类似交换机分配Pod IP如172.17.0.0/24网段。veth0Pod的虚拟网卡连接至docker0。同一节点上的Pod通过docker0网桥直接通信。例如Pod1172.17.0.2和Pod2172.17.0.3可通过IP直接互通。不同节点间的Pod网络节点网络如10.100.0.0/24与Pod网络如172.17.0.0/16隔离需通过以下方案实现跨节点通信路由方案适用场景底层网络可控如自建数据中心。原理通过路由器配置Pod网段的路由规则。例如目标为172.17.1.0/24的包转发到节点10.100.0.3。节点收到包后通过docker0网桥转发给Pod。优点无额外性能开销。Overlay网络方案适用场景底层网络不可控如公有云。原理使用隧道技术如Flannel、Weave封装Pod网络包为节点网络包到达目标节点后解封。优点不依赖底层网络配置。缺点封包/解包带来性能开销。CNIContainer Network InterfaceKubernetes通过CNI标准集成不同Pod网络实现如Calico、Cilium。kubelet通过CNI插件管理Pod网络设备如添加/删除网卡无需关注具体实现细节。Service网络概念模型Service网络构建于Pod网络之上解决服务发现与负载均衡问题服务发现ClusterIP为Service分配虚拟IPVIP屏蔽后端Pod IP变化。Client通过固定ClusterIP访问服务无需感知Pod变动。负载均衡策略默认RoundRobin支持自定义策略将请求分发到多个Pod实例。技术演进对比DNS方案问题客户端缓存可能导致Pod IP变更时访问失效负载均衡策略有限。Service Registry如Eureka问题需客户端集成侵入性强。Kubernetes Service优势通过ClusterIP和内置负载均衡屏蔽复杂性结合kube-proxy实现高效流量转发。关键总结Pod网络确保集群内Pod互通依赖CNI插件实现跨节点通信路由或Overlay。Service网络通过ClusterIP和负载均衡抽象后端Pod提供稳定访问入口。设计目标分层解耦下层为上层提供基础能力最终简化应用部署与管理。### 前言K8s是一个强大的平台但它的网络比较复杂涉及很多概念例如Pod网络Service网络Cluster IPsNodePortLoadBalancer和Ingress等等这么多概念足以让新手望而生畏。但是只有深入理解K8s网络才能为理解和用好K8s打下坚实基础。为了帮助大家理解模仿TCP/IP协议栈我把K8s的网络分解为四个抽象层从0到3除了第0层每一层都是构建于前一层之上如下图所示第3层~外部接入网络外部流量接入(NodePort/LoadBalancer/Ingress)第2层~Service网络服务发现和负载均衡(Cluster IP Port)第1层~Pod网络Pod虚拟机互通互联(Pod IP Port)第0层~Node节点网络节点主机互通互联(Node IP Port)第0层Node节点网络比较好理解也就是保证K8s节点(物理或虚拟机)之间能够正常IP寻址和互通的网络这个一般由底层(公有云或数据中心)网络基础设施支持。第0层我们假定已经存在所以不展开。第1到3层网络我将分三篇文章分别进行剖析本文是第一篇Pod网络。注意本文旨在帮助大家建立K8s网络的概念模型而不是对底层技术的精确描述。实际我们学技术以应用为主重要的是快速建立起直观易懂的概念模型能够指导我们正常应用即可当然理解一定的技术细节也是有帮助的。另外本文假定读者对基本的网络技术ip地址空间和容器技术等有一定的了解。Pod网络概念模型Pod相当于是K8s云平台中的虚拟机它是K8s的基本调度单位。所谓Pod网络就是能够保证K8s集群中的所有Pods(包括同一节点上的也包括不同节点上的Pods)逻辑上看起来都在同一个平面网络内能够相互做IP寻址和通信的网络下图是Pod网络的简化概念模型K8s ClusterPod1Pod IPPod2Pod IPPod5 Pod IPPod IPPod3Pod IPPod4Pod网络构建于Node节点网络之上它又是上层Service网络的基础。为了进一步理解Pod网络我将对同一节点上的Pod之间的网络以及不同节点上的Pod之间网络分别进行剖析。### 同一节点上的Pod网络前面提到Pod相当于是K8s云平台中的虚拟机实际一个Pod中可以住一个或者多个(大多数场景住一个)应用容器这些容器共享Pod的网络栈和其它资源如Volume。那么什么是共享网络栈同一节点上的Pod之间如何寻址和互通我以下图样例来解释eth010.100.0.2docker0172.17.0.1Pod1pauseveth0172.17.0.2container 1container 2Hostdn.net/yang75108上图节点上展示了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网络所依赖的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寻址和互通如下图所示eth010.100.0.2docker0172.17.0.1veth0veth1172.17.0.2172.17.0.3Pod1Pod2hosthttps://blog.csdn.net/yang75108从上图我们可以看到节点内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进行互通?10.100.0.210.100.0.3172.17.0.2172.17.1.3Pod XPod Yhost 1host 2?10.100.0.210.100.0.3172.17.0.2172.17.1.3Pod XPod Yhost 1host 2实际上不同节点间的Pod网络互通,有很多技术实现方案,底层的技术细节也很复杂。为了简化描述,我把这些方案大体分为两类,一类是路由方案,另另外一类是覆盖(Overlay)网络方案。如果底层的网络是你可以控制的,比如说企业内部自建的数据中心,并且你和运维团队的关系比较好,可以采用路由方案,如下图所示:10.100.0.210.100.0.3172.17.1.0/24:via 10.100.0.3172.17.0.0/24via 10.100.0.2172.17.0.2172.17.1.3Pod XPod Y这个方案简单理解就是通过路由设备为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)网络方案如下图所示10.100.0.210.100.0.3172.17.0.2172.17.1.3Pod XPod Yhost 1host 2所谓覆盖网络就是在现有网络之上再建立一个虚拟网络实现技术有很多例如flannel/weavenet等等这些方案大都采用隧道封包技术。简单理解Pod网络的数据包在出节点之前会先被封装成节点网络的数据包当数据包到达目标节点包内的Pod网络数据包会被解封出来再转发给节点内部的Pod网络。这种方案对底层网络没有特别依赖但是封包解包会引入额外性能开销。### CNI简介考虑到Pod网络实现技术众多为了简化集成K8s支持CNI(Container Network Interface)标准不同的Pod网络技术可以通过CNI插件形式和K8s进行集成。节点上的Kubelet通过CNI标准接口操作Pod网路例如添加或删除网络接口等它不需要关心Pod网络的具体实现细节Pod X母KubeletInterfacePluginADD/DELETECNIPod Network### 总结1. K8s的网络可以抽象成四层网络第0层节点网络第1层Pod网络第2层Service网络第3层外部接入网络。除了第0层每一层都构建于上一层之上。2. 一个节点内的Pod网络依赖于虚拟网桥和虚拟网卡等linux虚拟设备保证同一节点上的Pod之间可以正常IP寻址和互通。一个Pod内容器共享该Pod的网络栈这个网络栈由pause容器创建。3. 不同节点间的Pod网络可以采用路由方案实现也可以采用覆盖网络方案。路由方案依赖于底层网络设备但没有额外性能开销覆盖网络方案不依赖于底层网络但有额外封包解包开销。4. CNI是一个Pod网络集成标准简化K8s和不同Pod网络实现技术的集成。有了Pod网络K8s集群内的所有Pods在逻辑上都可以看作在一个平面网络内可以正常IP寻址和互通。但是Pod仅仅是K8s云平台中的虚拟机抽象最终我们需要在K8s集群中运行的是应用或者说服务(Service)而一个Service背后一般由多个Pods组成集群这时候就引入了服务发现(Service Discovery)和负载均衡(Load Balancing)等问题。第3层~外部接入网络外部流量接入(NodePort/LoadBalancer/Ingress)第2层~Service网络服务发现和负载均衡(Cluster IP Port)第1层~Pod网络Pod虚拟机互通互联(Pod IP Port)第0层~Node节点网络节点主机互通互联(Node IP Port)### Service网络概念模型我们假定第1层Pod网络已经存在下图是K8s的第2层Service网络的简化概念模型:K8s ClusterAccount-AppPod集群Pod1Pod IPAccount-ServiceClientPod2ClusterPod IPPodIPPod3Pod IPPod4Pod IP**服务发现(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 ClusterAccount-AppPod集群DNSWhere isAccount-App Pod?Pod1Pod IPClientPod2Pod IPPodPod3Pod IPPod4Pod IP在K8s中引入DNS实现服务发现其实并不复杂实际K8s本身就支持Kube-DNS组件。假设K8s引入DNS做服务发现(如上图所示)运行时K8s可以把Account-App的Pod集群信息(IPPort等)自动注册到DNSClient应用则通过域名查询DNS发现目标Pod然后发起调用。这个方案不仅简单而且对Client也无侵入(目前几乎所有的操作系统都自带DNS客户端)。但是基于DNS的服务发现也有如下问题1. 不同DNS客户端实现功能有差异有些客户端每次调用都会去查询DNS服务造成不必要的开销而有些客户端则会缓存DNS信息默认超时时间较长当目标PodIP发生变化时(在容器云环境中是常态)存在缓存刷新不及时会导致访问Pod失效。2. DNS客户端实现的负载均衡策略一般都比较简单大都是RoundRobin有些则不支持负载均衡调用。考虑到上述不同DNS客户端实现的差异不在K8s控制范围内所以K8s没有直接采用DNS技术做服务发现。注意实际K8s是引入Kube-DNS支持通过域名访问服务的不过这是建立在CusterIP/Service网络之上这个我后面会展开。另外一种较新的服务发现技术是引入Service RegistryClient配合实现在当下微服务时代这是一个比较流行的做法。目前主流的产品如Netflix开源的Eureka RibbonHashiCorp开源的Consul还有阿里新开源Nacos等都是这个方案的典型代表。K8s ClusterAccount-AppPod集群Service RegistryRegisterWhere isAccount-App PodAccount-App Pod?PodlPod IPClientPod2Pod IPPodPod3Pod IPPod4Pod IP在K8s中引入Service Registry实现服务发现也不复杂K8s自身带分布式存储etcd就可以实现Service Registry。假设K8s引入Service Registry做服务发现(如上图所示)运行时K8s可以把Account-App和Pod集群信息(IP Port等)自动注册到Service RegistryClient应用则通过Service Registry查询发现目标Pod然后发起调用。这个方案也不复杂而且客户端可以实现灵活的负载均衡策略但是需要引入客户端配合对客户应用有侵入性所以K8s也没有直接采用这种方案。K8s虽然没有直接采用上述方案但是它的Service网络实现是在上面两种技术的基础上扩展演进出来的。它融合了上述方案的优点同时解决了上述方案的不足下节我会详细剖析K8s的Service网络的实现原理前面提到K8s的服务发现机制是在上节讲的Service Registry DNS基础上发展演进出来的下图展示K8s服务发现的简化原理ServiceName - ClusteripClusterIP - PodIPK8s MasterServiceName服务发现服务注册- ClusterIPKube-DNSKubeletPODPODKube-ProxyPodIP 1消费者服务实例PODLBPODPODPODPodIP 2ClusterIPPODPODPodIPPodIP 3Worker NodeWorker Node在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)总体原理类似但是也有显著区别(这些区别主要体现在客户端)1. 首先两者都是采用客户端代理(Proxy)机制。和Ribbon一样K8s的代理转发和负载均衡也是在客户端实现的但Ribbon是以Lib库的形式嵌入在客户应用中的对客户应用有侵入性而K8s的Kube-Proxy是独立的每个Worker节点上有一个它对客户应用无侵入。K8s的做法类似ServiceMesh中的边车(sidecar)做法。2. 第二Ribbon的代理转发是穿透的而K8s中的代理转发是iptables转发虽然K8s中有Kube-Proxy但它只是负责服务发现和修改iptables(或ipvs)规则实际请求是不穿透Kube-Proxy的。注意早期K8s中的Kube-Proxy代理是穿透的考虑到有性能损耗和单点问题后续的版本就改成不穿透了。3. 第三Ribbon实现服务名到服务实例IP地址的映射它只有一层映射。而K8s中有两层映射Kube-Proxy实现ClusterIP-PodIP的映射Kube-DNS实现ServiceName-ClusterIP的映射。个人认为对比目前微服务主流的服务发现机制K8s的服务发现机制抽象得更好它通过ClusterIP统一屏蔽服务发现和负载均衡一个服务一个ClusterIP这个模型和传统的IP网络模型更贴近和易于理解。ClusterIP也是一个IP但这个IP后面跟的不是一个服务实例而是一个服务集群所以叫集群ClusterIP。同时它对客户应用无侵入且不穿透没有额外性能损耗。总结1. K8s的Service网络构建于Pod网络之上它主要目的是解决服务发现(Service Discovery)和负载均衡(Load Balancing)问题。2. K8s通过一个ServiceNameClusterIP统一屏蔽服务发现和负载均衡底层技术是在DNSService Registry基础上发展演进出来。3. K8s的服务发现和负载均衡是在客户端通过Kube-Proxy iptables转发实现它对应用无侵入且不穿透Proxy没有额外性能损耗。4. K8s服务发现机制可以认为是现代微服务发现机制和传统Linux内核机制的优雅结合。有了Service抽象K8s中部署的应用都可以通过一个抽象的ClusterIP进行寻址访问并且消费方不需要关心这个ClusterIP后面究竟有多少个Pod实例它们的PodIP是什么会不会变化如何以负载均衡方式去访问等问题。但是K8s的Service网络只是一个集群内可见的内部网络集群外部是看不到Service网络的也无法直接访问。而我们发布应用有些是需要暴露出去要让外网甚至公网能够访问的这样才能对外提供服务。K8s如何将内部服务暴露出去第3层~外部接入网络外部流量接入(NodePort/LoadBalancer/Ingress)第2层~Service网络服务发现和负载均衡(Cluster IP Port)第1层~Pod网络Pod虚拟机互通互联(Pod IP Port)第0层~Node节点网络节点主机互通互联(Node IP Port)在讲到K8s如何接入外部流量的时候大家常常会听到NodePortLoadBalancer和Ingress等概念这些概念都是和K8s外部流量接入相关的它们既是不同概念同时又有关联性。下面我们分别解释这些概念和它们之间的关系。### NodePort先提前强调一下**NodePort是K8s将内部服务对外暴露的基础**后面的**LoadBalancer底层有赖于NodePort**。之前我们讲了K8s网络的4层抽象Service网络在第2层节点网络在第0层。实际上只有节点网络是可以直接对外暴露的具体暴露方式要看数据中心或公有云的底层网络部署但不管采用何种部署节点网络对外暴露是完全没有问题的。那么现在的问题是第2层的Service网络如何通过第0层的节点网络暴露出去我们可以回看一下K8s服务发现的原理图如下图所示然后不妨思考一下K8s集群中有哪一个角色即掌握Service网络的所有信息可以和Service网络以及Pod网络互通互联同时又可以和节点网络打通ServiceName - ClusteripClusterIP - PodIPK8s MasterServiceName服务发现服务注册- ClusterIPKube-DNSKubeletPODPODKube-ProxyPodIP 1消费者服务实例PODLBPODPODPODPodIP 2ClusterIPPODPOD- PodIPPodIP 3Worker NodeWorker Node答案是**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暴露服务的简化概念模型。ServiceNodePortNodePortKube-ProxyKube-ProxyPodXPodyNode 1Node 2K8s Cluster如果我们要将K8s内部的一个服务通过NodePort方式暴露出去可以将服务发布(kind: Service)的type设定为NodePort同时指定一个30000~32767范围内的端口。服务发布以后K8s在每个Worker节点上都会开启这个监听端口。这个端口的背后是Kube-Proxy当K8s外部有Client要访问K8s集群内的某个服务它通过这个服务的NodePort端口发起调用这个调用通过Kube-Proxy转发到内部的Servcie抽象层然后再转发到目标Pod上。Kube-Proxy转发以及之后的环节可以和上一篇《Kubernetes网络三部曲Service网络》的内容对接起来。注意为了直观形象上图的Service在K8s集群中被画成一个独立组件实际是没有独立Service这样一个组件的只是一个抽象概念如果要理解这个抽象的底层实现细节可以回头看上一图的K8s服务发现原理或者回到上一篇《Kubernetes网络三部曲Service网络》。LoadBalancer上面我们提到将K8s内部的服务通过NodePort方式暴露出去K8s会在每个Worker节点上都开启对应的NodePort端口。逻辑上看K8s集群中的所有节点都会暴露这个服务或者说这个服务是以集群方式暴露的(实际支持这个服务的Pod可能就分布在其中有限几个节点上但是因为所有节点上都有Kube-Proxy所以所有节点都知道该如何转发)。既然是集群就会涉及负载均衡问题谁负责对这个服务的负载均衡访问答案是需要引入负载均衡器(Load Balancer)。下图是通过LoadBalancer将服务对外暴露的概念模型。Load-BalancerServiceNodePortNodePortKube-ProxyKube-ProxyPodXPodYNode 1Node 2K8s Cluster假设我们有一套阿里云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)上公网LBIP是需要花钱买的。我们回看上图的通过LoadBalancer(简称LB)暴露服务的方式发现要暴露一个服务就需要购买一个独立的LBIP如果要暴露十个服务就需要购买十个LBIP显然从成本考虑这是不划算也不可扩展的。那么有没有办法只需购买一个(或者少量)的LBIP但是却可以按需暴露更多服务出去呢答案其实不复杂就是想办法在K8内部部署一个独立的反向代理服务让它做代理转发。谷歌给这个内部独立部署的反向代理服务起了一个奇怪的名字就叫**Ingress**它的简化概念模型如下图所示Load-BalancerHostPort(80/443)path1Path2IngressPath3ClusterIPClusterIPServiceServicePodAPodBPodXPodyK8s ClusterIngress就是一个特殊的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我们可以做到只需购买一个LBIP就可以通过Ingress将内部多个(甚至全部)服务暴露出去Ingress会帮忙做代理转发。那么哪些软件可以做这个Ingress传统的Nginx/Haproxy可以现代的微服务网关Zuul/SpringCloudGateway/Kong/Envoy/Traefik等等都可以。当然谷歌别出心裁给这个东东起名叫Ingress它还是做了一些包装以简化对Ingress的操作。如果你理解了原理那么完全可以用Zuul或者SpringCloudGateway或者自己定制开发一个反向代理来替代这个Ingress。部署的时候以普通Service部署将type设定为LoadBalancer即可如下图所示Load-BalancerNodePortpath1Proxy ServiceNginx/Kong/Traefik/EnvoyPath2/Zuul/SpringCloudGatewayPath3ClusterIPClusterIPServiceServicePodBPodXPodYPodAK8s Cluster注意Ingress是一个7层反向代理如果你要暴露的是4层服务还是需要走独立LBIP方式。Kubectl Proxy Port Forward上面提到的服务暴露方案包括NodePort/LoadBalancer/Ingress主要针对正式生产环境。如果在本地开发测试环境需要对本地部署的K8s环境中的服务或者Pod进行快速调试或测试还有几种简易办法这边一并简单介绍下如下图所示办法一API ServerKubectl proxyClusterIPService办法二KubectlPodXPodYPort-ForwardingK8s Cluster* **办法一**通过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。###总结1. NodePort是K8s内部服务对外暴露的基础LoadBalancer底层有赖于NodePort。NodePort背后是Kube-ProxyKube-Proxy是沟通Service网络、Pod网络和节点网络的桥梁。2. 将K8s服务通过NodePort对外暴露是以集群方式暴露的每个节点上都会暴露相应的NodePort通过LoadBalancer可以实现负载均衡访问。公有云(如阿里云/AWS/GCP)提供的K8s都支持自动部署LB且提供公网可访问IPLB背后对接NodePort。3. Ingress扮演的角色是对K8s内部服务进行集中反向代理通过Ingress我们可以同时对外暴露K8s内部的多个服务但是只需要购买1个(或者少量)LB。Ingress本质也是一种K8s的特殊Service它也通过HostPort(80/443)对外暴露。4. 通过Kubectl Proxy或者Port Forward可以在本地环境快速调试访问K8s中的服务或Pod。5. K8s的Service发布主要有3种typetypeClusterIP表示仅内部可访问服务typeNodePort表示通过NodePort对外暴露服务typeLoadBalancer表示通过LoadBalancer对外暴露服务(底层对接NodePort一般公有云才支持)。至此Kubernetes网络三部曲全部讲解完成希望这三篇文章对你理解和用好K8s有帮助。下表是对三部曲的浓缩总结是希望大家带走记住的作用实现节点网络Master/Worker节点之间网络互通路由器,交换机,网卡Pod网络Pod虚拟机之间互通虚拟网卡,虚拟网桥,网卡,路由器or覆盖网络Service网络服务发现负载均衡Kube-proxy, Kubelet, Master, Kube-DNS将Service暴露在节点网络上NodePortKube-proxyLoadBalancer将Service暴露在公网上负载均衡公有云LBNodePort反向路由,安全,日志监控IngressNginx/Envoy/Traefik/Zuul/SpringCloudGateway...(类似反向代理or网关)