1 k8s网络类型
2 Pod网络
2.1 同一pod内不同容器通信
Pod是Kubernetes中最小的可部署单元，它是一个或多个紧密关联的容器的组合，这些容器共享同一个网络命名空间和存储卷，因此Pod中的所有容器都共享相同的网络命名空间和IP地址——PodIP，所以在同一个Pod内的容器间通信可以通过localhost直接通信。
k8s创建Pod时永远都是首先创建Infra 容器，也可以被称为pause容器。这个容器为其他容器提供了一个共享的基础设施，包括网络和存储功能，其他业务容器共享pause容器的网络栈和Volume挂载卷。
pause 容器被创建后会初始化Network Namespace网络栈，之后其他容器就可以加入到pause 容器中共享Infra容器的网络了。而对于同一个 Pod 里面的所有用户容器来说，它们的进出流量，认为都是通过 pause 容器完成的。
pause 容器会创建并管理虚拟以太网（veth）接口。在容器启动之前，pause 容器会为每个容器创建一个虚拟以太网接口，一个保留在宿主机上（称为 vethxxx），另一个保留在容器网络命名空间内并重命名为 eth0，如下图所示。这两个虚拟接口的两端是连接在一起的，从一端进入的数据会从另一端出来。
2.2 同一节点不同pod间相互通信
同一节点不同POD之间的通信是通过将容器网络接口（CNI）与主机网络命名空间中的虚拟以太网（veth）接口相连来实现的。 每生成一个新的Pod，那么在Node上都会根据插件来生成一个新的虚拟网卡如vethxxxx或者calixxxx，这个网卡会对应到Pod里的eth0。
如图，veth接口则被保留在主机的网络命名空间中，并被连接到CNI插件（如Flannel或Calico等）创建的虚拟网桥（如cni0或flannel0等）上。一旦这些veth接口被正确地连接起来，它们就可以进行通信了。当一个POD发送数据包时，数据包会通过其veth接口被发送到主机网络命名空间中的veth接口，然后该veth接口会将数据包发送到虚拟网桥上。虚拟网桥又会将数据包路由到目标POD的veth接口，最终将数据包发送到目标POD。
如图所示的ip地址与网桥网段，同一节点的不同POD的IP地址通常属于同一网段，并通过CNI插件连接到同一个虚拟网桥（如cni0）上。虚拟网桥会管理其IP地址空间和分配，确保不同POD的IP地址不会冲突。
具体的IP地址和网段取决于所使用的CNI插件和网络方案。例如Flannel插件默认使用10.244.x.0/24的网段，其中x是随机分配给每个POD的。这意味着不同POD的IP地址将位于10.244.x.0/24的网段中，其中x是不同的值。
CNI介绍见：Kubernetes基础(十一)-CNI网络插件用法和对比_k8s网络组件对比-CSDN博客
2.3 不同节点pod相互通信
若不同节点pod想要相互通信，在cni0网桥外还有一层CNI插件配置的网络隧道，如上图新的虚拟网卡flannel0接收cni0网桥的数据，并通过维护路由表，对接收到的数据进行封包和转发（vxlan隧道）。
- cni0：网桥设备，每创建一个pod都会创建一对 veth pair。其中一段是pod中的eth0，另一端是cni0网桥中的端口。
- VTEP设备：、VXLAN Tunnel End Point(虚拟隧道端点)，在Flannel中 VNI的默认值是1，这也是为什么宿主机的VTEP设备都叫flannel.1的原因。VTEP设备之间通过二层数据帧进行通信，源VTEP设备收到原始IP包后，在上面加上一个目的MAC地址，封装成一个内部数据帧，发送给目的VTEP设备。
- flannel.1：vxlan网关设备，用户 vxlan 报文的解包和封包。不同的 pod 数据流量都从overlay设备以隧道的形式发送到对端。flannel.1不会发送arp请求去获取目标IP的mac地址，而是由Linuxkernel将一个"L3 Miss"事件请求发送到用户空间的flanneld程序，flanneld程序收到内核的请求事件后，从etcd中查找能够匹配该地址的子网flannel.1设备的mac地址，即目标pod所在host中flannel.1设备的mac地址。
- flanneld：在每个主机中运行flanneld作为agent，它会为所在主机从集群的网络地址空间中，获取一个小的网段subnet，本主机内所有容器的IP地址都将从中分配。同时Flanneld监听K8s集群数据库，为flannel.1设备提供封装数据时必要的mac，ip等网络数据信息。
- VXLAN：Virtual eXtensible Local Area Network，虚拟扩展局域网。采用L2 over L4（MAC-in-UDP）的报文封装模式，将二层报文用三层协议进行封装，实现二层网络在三层范围内进行扩展，同时满足数据中心大二层虚拟迁移和多租户的需求。flannel只使用了vxlan的部分功能，VNI被固定为1。
- 内部数据桢：并不能在宿主机的二层网络传输，Linux内核还需要把它进一步封装成为宿主机的一个普通的数据帧，承载着内部数据帧通过宿主机的eth0进行传输。
- 容器跨网络通信解决方案：如果集群的主机在同一个子网内，则跳过flannel.1隧道，而是直接通过路由eth0转发过去；若不在一个子网内，就通过隧道转发过去。
3 Service网络
3.1 ClusterIp
在Kubernetes中，Pod是非持久性的资源，可以按照需要创建和销毁。当使用Deployment来运行应用时，可以根据需要动态地创建或销毁Pod，实现水平扩缩容。
当引入Deployment，并为Pod设置多个副本时，那么某一个服务就会有多个pod及多个podIp，此时即使知道了这些Pod的IP，那访问起来也并不方便。此外，Pod的IP地址是动态分配的，可能发生变化，所以在实际通信中，直接使用Pod的IP地址进行通信会有一些问题。为了解决这个问题，Kubernetes引入了Service的概念。
所以，这里需要有一个统一入口，其它Pod通过这个统一入口去请求该服务（Nginx）对应的所有Pod。这时就有了Service这个资源对象，它主要作用就是用来提供统一入口，也就是说只需要一个IP就能访问所有的Pod，而这个入口IP就是ClusterIP，也就是Service的IP。
Pod IP 地址是实际存在于某个网卡(可以是虚拟设备)上的，但Cluster IP是一个完全虚拟的IP，没有网络设备与其对应。
- Cluster IP仅仅作用于Kubernetes Service这个对象，并由Kubernetes管理和分配P地址
- Cluster IP无法被ping，他没有一个“实体网络对象”来响应
- Cluster IP只能结合Service Port组成一个具体的通信端口，单独的Cluster IP不具备通信的基础，并且他们属于Kubernetes集群这样一个封闭的空间。
- 虚拟 ip 是固定的，这也是service可以解决pod动态ip的原因
K8s通过在引入一层Service抽象，还能解决以下问题：
- 服务发现：Service提供统一的ClusterIP来解决服务发现问题，Client只需通过ClusterIP就可以访问App的Pod集群，不需要关心集群中的具体Pod数量和PodIP，即使是PodIP发生变化也会被ClusterIP所屏蔽。注意，这里的ClusterIP实际是个虚拟IP，也称Virtual IP(VIP)。
- 负载均衡：Service抽象层具有负载均衡的能力，支持以不同策略去访问App集群中的不同Pod实例，以实现负载分摊和HA高可用。K8s中默认的负载均衡策略是RoundRobin，也可以定制其它复杂策略。