K8S四层网络是什么? 请详细讲解
K8S（Kubernetes）四层网络指的是Kubernetes中实现的四层（传输层）网络，其主要功能是在集群内部提供基于TCP和UDP的负载均衡服务。Kubernetes集群中的四层网络通常由三个主要组件构成：kube-proxy、Service和Endpoint。
首先，kube-proxy是Kubernetes的核心组件之一，主要作用是实现Kubernetes服务的负载均衡。kube-proxy会根据Service对象的定义，创建虚拟IP地址，并将这个虚拟IP地址映射到一组后端Pod的IP地址上。当一个客户端发送一个请求到这个虚拟IP地址时，kube-proxy会选择其中一个后端Pod的IP地址，然后将请求重定向到这个Pod上。
其次，Service是Kubernetes中的另一个核心概念，用于提供稳定的服务访问。每个Service都有一个虚拟IP地址（ClusterIP），可以通过这个IP地址访问到这个Service提供的服务。在集群内，这个虚拟IP地址是唯一的，这意味着无论后端Pod的数量如何变化，客户端只需要访问这个虚拟IP地址就可以访问到Service。
最后，Endpoint是一个Kubernetes资源对象，用于存储与一个Service相关的后端Pod的IP地址。Endpoint可以手动创建，也可以由Kubernetes自动创建。当一个Service被创建时，Kubernetes会自动创建一个Endpoint对象，并将该Service指定的所有Pod的IP地址添加到这个Endpoint对象中。当一个客户端请求访问Service时，kube-proxy会查询Endpoint对象，然后选择其中一个Pod的IP地址，将请求重定向到这个Pod上。
综上所述，Kubernetes的四层网络提供了基于TCP和UDP的负载均衡服务，并通过Service和Endpoint对象来管理这些服务。这些组件的协同工作，使得在Kubernetes集群内部，客户端可以访问到稳定的服务，而无需关心后端Pod的具体数量或位置。
能画个图吗
当然可以，下面是一个简单的Kubernetes四层网络的示意图：
1 | +---------+ +-----------+ |
在这个示意图中，客户端向Service发送请求，Service将请求转发到Endpoint，Endpoint再将请求转发到后端的Pod中。kube-proxy负责将客户端请求重定向到其中一个后端Pod上，同时还会实现Pod的健康检查和负载均衡等功能。通过这些组件的协同工作，Kubernetes可以实现基于TCP和UDP的负载均衡服务，同时提供高可用性和稳定性的服务访问。
- Container - Container 之间通信
- Pod - Pod 之间通信
- Pod - Service之间通信 （一个服务访问集群中另一个服务）
- Internet - Service之间通信 (互联网与集群内部如何通信)
- 一些k8s网络通信潜在问题
参考资料:
https://kubernetes.io/docs/concepts/cluster-administration/networking/
https://opensource.com/article/22/6/kubernetes-networking-fundamentals
- Pod有自己的Network和Namespace，相当于一个独立的网络环境，Pod中存在多个Container，多个Container之间是通过Pod的localhost来通信
- Pod的运行需要一个宿主机，也就是我们常说的node。Pod的网络环境与node之间的通信，需要一个虚拟网卡，即veth pair (node即宿主机)
node中存在virtual bridge虚拟网桥，用以发现宿主机上拥有独立ip的主机
这里的virtual bridge就是cbr0，它对应10.1.0段的地址。10.1.0.13在其中，经过虚拟网桥数据包就被发送到了Pod B
node中的ip routes table
10.1.0段走cbr0，其余默认走node eth0的网卡。。
- Pod和Service之间的通信:
假设现在service1的一个pod(记为A)和service2的一个pod(记为C)，分别位于两个节点(node,即宿主机)。
目标ip是 10.0.x.x，而virtual bridge cbr0是10.1.0段，所以没法走虚拟网桥。
走iptables或ipvs。会随机分配service中的一个pod ip，这时目标ip会变为 10.1.x.x,即pod C的ip
(iptables怎么会知道pod C的ip呢？是通过kube-proxy通过监听API Server的entrypoint。有变动会实时更新)
然后数据包通过node的eth0网卡，来到集群所在的网络，被路由到pod C所在的那台机器(node),再通过eth0，iptables/ipvs，virtual bridge，找到对应的pod C
- 互联网是如何访问集群服务的？
一个比较直接的方式是经由Load Balancer，再路由到集群内部
- 一些潜在问题
这里就会牵扯到CNI,Cilium，ebpf等热门话题
更多参考:
K8s Ingress Provider 为什么选择 MSE 云原生网关？
k8s中 Service, endpoint, kube-proxy 三者之间的关系
Kubernetes 中 Service、Endpoint 和 kube-proxy 三者之间的关系如下:
Service:
- Service 是 Kubernetes 中一个抽象层,定义了一个或一组 Pod 实例以及它们的访问规则。
- 它作为 Pod 的负载均衡器,将请求分发给后端的 Pod 实例。
- Service 通过标签选择器来关联对应的 Pod。
Endpoint:
- Endpoint 是 Kubernetes 集群中能够被 Service 发现的 IP 地址列表。
- Endpoint 由 Kubernetes 控制平面自动创建和维护,用于映射 Service 和 Pod 之间的关系。
- 当 Service 关联的 Pod 发生变化时,Endpoint 也会做相应的更新。
kube-proxy:
- kube-proxy 是 Kubernetes 的网络代理,它运行在每个节点上。
- kube-proxy 监视 Service 和 Endpoint 的变化,并根据这些变化在节点上创建、更新或删除相应的网络规则。
- kube-proxy 通过管理 iptables 或 IPVS 规则,实现 Service 的负载均衡和转发功能。
这三者的关系如下:
- Service 定义了一组 Pod 的访问入口,通过标签选择器关联 Pod。
- Endpoint 记录了 Service 关联的 Pod 实际 IP,由 Kubernetes 控制平面自动维护。
- kube-proxy 监视 Service 和 Endpoint 的变化,并在每个节点上配置网络规则,实现流量负载均衡和转发。
总的来说,Service 提供了一个统一的入口地址,Endpoint 记录了 Pod 的实际 IP,而 kube-proxy 则通过管理网络规则将流量转发到后端 Pod。这种设计使得 Service 能够屏蔽后端 Pod 实例的变化,为外部提供稳定的服务访问入口。
好的,我会尽量保持内容的完整性,并使其变得合理通顺。
深入理解k8s网络(1): 概述
大家好,我是李华明,Kubernetes(k8s)网络一直是它的重点和难点。在这个系列课程中,我会分享k8s网络服务的各个方面,希望帮助大家理解它。网络实现了一些内部的机制,下面我把相关的一些内容给大家简单介绍一下。
第一部分是关于k8s网络概述,主要讲授k8s的一个总体情况、网络服务、网络在宏观介绍,以及为了更好地理解网络,我会根据家里的网络为例子来介绍网络的一些基础知识。
第二部分是关于CNI插件,k8s本身不负责网络的功能,它把网络的创建与维护交给了CNI插件。所以我会从一个Pod网络的创建过程,来帮助大家理解CNI插件的内部工作机制。在此之后会讲解基于Vxlan的Flannel网络插件,以及基于BGP的Calico网络插件的机制,最后会讨论如何实现多网卡、多网口网络接口的技术。
第三部分是集群内部服务网络。Pod在集群中的生命周期是不可靠的,它随时可能会被重新创建,并且IP地址发生改变。如何在Pod之上构造一层抽象的服务网络,并且在多个Pod实例之间进行负载均衡?在这部分我会讲述k8s的内部服务,以及Kube-proxy及负载均衡的实现,还会对内部服务的发现机制DNS进行介绍。
第四部分是集群外部访问。出于安全原因,一般情况下k8s集群内部网络不会直接暴露给外部。所以我们有一些方案来将内部服务对外部进行暴露,以及它的高可用方案。在这里我会介绍Ingress的一些原理及其高可用方案,以及引入一些边缘节点来进行流量隔离。
第五部分我会涉及到网络安全策略的讨论。在默认的情况下,k8s的Pod之间是互通的,而网络安全策略提供了这种Pod之间以及Namespace之间的通信和层次的流量控制。安全策略使得流量在Pod之间是可以被管理的,这为大型的或者一些混合的集群提供了一种安全的方案。
这就是本课程的主体内容。接下来对概述部分进行详细介绍。
第一,我会总体地讲一下在k8s中网络的三大方面:节点网络、容器网络以及服务网络。
然后以我自己家庭网络为例子,介绍TCP/IP的网络模型,以及在我们的物理机之上的虚拟机以及虚拟机中的容器,它们之间的网络是如何进行连接的。就是以我本机的实际情况进行讨论。
最后会讲一些Linux的基础技术,像Namespace、虚拟网卡、虚拟网桥接技术,因为理解这些基础的知识,对于理解k8s的网络是非常重要的。因为k8s网络其实是在软件层面去实现这些不同的方面。
所以你只有理解了这些,你才能比较深入地理解k8s内部的网络是怎么样沟通的。老师假设这是一个有三个节点组成的一个k8s集群,那Master节点、Worker节点以及Ingress节点。
那么所谓的k8s网络的第一个部分,节点网络就是指这些节点之间的一个实际的物理网络。当然根据实际情况,这些节点网络之间可能是一组路由器交换机连接起来的一个物理网络,也可能在公有云数据中心上面,它实际上是通过SDN所建立起来的一个虚拟网络。但对于这个网络我们有一个要求,就是它在物理上是可达的。如果你物理上都不能把它连通的话,那么它是无法把这些节点加入到一个k8s集群中进行统一的管理。
然后这些物理网络,实际上所有的k8s真正的流量都会通过这个物理网络进行转发、承载。也就是说这里即使有很多的Pod,那Pod之间的网络不管是通过隧道的方式也好,或者通过路由的方式也好,它们最终其实走的都是实际的物理网络。很好理解是吧?
然后我们就看物理网络是谁来创造的?它其实不是k8s本身的一部分,就是说k8s在安装的过程中、在它的升级的过程中,它本身不会对这个节点网络进行创建或者更改。它是由我们在创建集群之前,我们的IT部门来进行规划、进行创建的。
那么节点网络它对于我们整个集群的管理有什么影响啊?也就是说在节点网络的选择或节点网络本身的能力,会决定我们CNI插件的选项。因为有些CNI插件,它必须在比如说它在二层可达,它必须在同样一个物理的二层网段上面。但是有些网络它可能只需要三层可达就可以,它可以通过一些隧道的方式来建立节点之间的一个连接。
所以在CNI插件选型的时候,我们要考虑到我们的集群是运行在什么样的一个实际的底层的节点网络环境之中。这一点是非常重要的。
那下一个部分就是关于容器网络。容器网络解决的是一个什么问题?它解决的是一个在Pod和Pod之间建立一个联通性的问题,以及如何在Pod之间建立这种联通性。
在这个例子中,我们可以看到我们有两个服务,一个是前端服务的实例一和实例二,还有后端的实例一和后端的实例二。它们分别在不同的节点上面调度的。
那么当然在同一个Pod,这是一个Pod,同一个Pod它就会获取的IP地址,然后一个Pod有多个容器,一个Pod有多个容器。那Pod同一个Pod的内部容器之间通讯,因为它们是在一个命名空间之中,所以在逻辑上它们是一个网络IP协议栈,所以它们能通过IP回环来进行通信的。所以这个好理解。
那另外一个就是说,同一个Worker节点、同一个节点之间Pod的通信,比如说这是另外一个IP2、IP2,
原文链接: https://dashen.tech/2024/12/15/K8S中的网络通信/
版权声明: 转载请注明出处.