Kubernetes网络模型
Kubernetes的网络模型（Kubernetes Networking Model）旨在提供跨所有节点、Pod和服务的统一网络连接。它的核心理念是通过统一的网络通信规则，保证集群中的所有组件能够顺畅地相互通信。Kubernetes网络模型主要有以下几个关键点：
1.Pod-to-Pod通信
每个 Pod 都有一个独立的IP地址，即"IP per Pod" 模型。每个Pod中的所有容器共享同一个网络命名空间，因此可以通过localhost通信。
Pod 之间直接通信：无论Pod在同一Node或不同Node上，它们可以直接通过IP地址互相通信，不需要使用NAT或端口映射。
2.Pod-to-Service通信
如上节提到，Pod通过Service方式访问其他Pod。
3.Service-to-External通信
如Ingress/Gateway API+ Service的ClusterIP模式;Service的NodePort模式；Service的LoadBalancer模式等。
4.Node-to-Pod通信
在 Kubernetes集群中，节点上的应用可以直接与Pod通信，无需额外配置。Kube-proxy负责在节点级别管理这些网络规则，保证节点可以通过虚拟IP或端口访问服务。
5.网络策略（Network Policies）
Kubernetes通过网络策略（Network Policies）来控制Pod之间的通信权限。网络策略允许用户基于标签、命名空间等指定允许或禁止的网络流量(必须使用支持NetworkPolicy实施的网络插件CNI)。
6.网络插件CNI（ Container Network Interface）
Kubernetes本身并不定义如何实现网络，而是通过CNI插件扩展网络功能。这些插件提供Pod 的网络接口配置和跨节点的网络互联能力。常见的CNI插件包括：
Flannel：轻量级的 Overlay 网络方案。
Weave：提供简单的跨节点网络连接。
Pod-to-Pod场景
在 Kubernetes 中，Pod和Pod之间通信是非常常见的需求，主要是为了实现应用之间的互操作性。虽然可以使用Pod-to-Service来解决大部分通信问题，但Pod之间直接通信也是有其场景和必要性的。
状态紧密关联的Pod
某些场景下，多个Pod之间存在紧密的状态共享和低延迟的通信需求。例如：
数据库集群：在数据库集群中，主节点和从节点之间需要实时同步数据，直接Pod间通信比通过 Service更加高效。
高性能计算（HPC）和分布式计算：在某些需要低延迟的高性能计算场景下，多个Pod可能会进行频繁的点对点通信，例如分布式计算中的任务调度和数据交换。
有状态应用
有些应用需要每个Pod直接与另一个特定Pod通信，尤其是在有状态应用中，例如Kafka、Cassandra等分布式系统。这类系统中，各个Pod可能有各自的状态和存储分片，彼此之间的通信不总是通过Service进行。
批处理任务
在某些批处理任务中，多个Pod之间需要通过IP进行点对点通信以协调任务的执行。这类Pod通常是短期存在的，使用Service可能会增加额外的延迟和复杂度。
Kube-proxy和CNI的区别
kube-proxy组件（或者已经部署的其他替换组件）是Kubernetes自带的组件，使用linux的iptables、IPVS 等，实现Service的虚拟 IP（ClusterIP）和负载均衡功能。主要管理Service层面的网络规则，而不管理底层的网络路由、网络策略等。
CNI网络插件，使用linux的路由、虚拟网络技术等，主要实现Pod-to-Pod通信，以及网络安全策略等。以下介绍Flannel和Calico。
Flannel
Flannel简介
Flannel是一种简单易用的Kubernetes网络插件，专注于为Kubernetes提供容器网络解决方案。它的主要作用是为Kubernetes集群中的Pod提供跨主机的网络连接，允许不同节点上的Pod能够互相通信。Flannel是一种覆盖网络（overlay network）实现，底层依赖于封装（encapsulation）技术来跨越不同节点的网络边界。
Flannel组件
flanneld：Flannel的主要守护进程，负责分配子网并处理数据包的封装与解封装。它运行在每个节点上，并与etcd或Kubernetes API Server交互，维护整个集群的子网分配信息。
etcd/Kubernetes API Server：Flannel通过etcd或Kubernetes API Server来存储和共享每个节点的子网信息。集群中的所有节点通过etcd或Kubernetes API Server了解如何将流量路由到其他节点上的Pod。
Backend（后端）：Flannel支持多种网络后端，如VXLAN、host-gw、UDP等，决定了Flannel使用哪种方式封装和路由数据包。
Flannel的网络模式
Flannel提供了多种模式，用户可以根据集群的实际需求选择不同的网络模式：
VXLAN模式：默认的Flannel网络模式，适合大多数情况下的Kubernetes集群，使用封装技术实现跨主机通信。
Host-GW模式：直接通过主机路由表实现节点间通信，适合物理网络已经具备节点直接通信的场景，性能相对较高。
UDP模式：最早的实现方式，依赖于UDP封装，但由于性能较差，通常不建议使用。
AWS VPC模式：针对AWS环境的优化，允许Flannel与AWS的VPC网络集成。
Calico
Calico简介
Calico是一种广泛使用的Kubernetes网络插件，主要用于提供容器网络和网络安全策略。Calico的设计目标是提供高性能的、可扩展的网络连接，并且能够在Kubernetes集群中实施细粒度的安全策略（网络策略）。它可以在多个云环境和裸机上工作，既支持容器网络，也支持虚拟机和物理主机的网络。它通过直接路由实现Pod的网络通信，而不依赖像VXLAN或GRE这样复杂的隧道封装（overlay）技术。
Calico组件
Felix：Calico的核心组件，运行在每个节点上，负责配置和管理节点上的网络路由和防火墙规则。Felix会根据Kubernetes中定义的网络策略和Calico的配置来控制网络的流量。它负责维护主机的路由表、接口、IP地址和防火墙规则，以便正确地转发数据包和应用安全策略。
BIRD：Calico的BGP功能依赖于一个轻量级的BGP路由守护进程，通常使用BIRD。BIRD负责在集群节点之间分发路由信息，从而确保每个节点都知道如何将流量发送到其他节点的Pod。
etcd/Kubernetes API Server：Calico通过etcd或Kubernetes API Server来存储和共享网络状态信息。通过这些存储，Calico能够记录各个节点的Pod IP分配和网络策略配置。
Calico的网络模式
Calico可以通过以下两种模式实现跨节点的Pod通信：
BGP模式：Calico默认使用BGP路由协议来分发路由信息，每个节点会通过BGP将本节点的PodIP地址段发布给集群中的其他节点。通过BGP，所有节点之间形成了一个互通的网络，每个节点知道如何将流量路由到其他节点上的Pod。
网络命名空间的相关介绍在这里，最后有Calico BGP模式的底层模拟：Linux技术01-虚拟网络、网络命名空间
IP-in-IP模式：在某些情况下，底层网络无法直接路由Pod的IP地址（例如，两个节点的网络无法直接互通）。此时，Calico可以启用IP-in-IP模式，将Pod的IP包封装在主机的IP包中进行传输。这种模式类似于VXLAN，但仍然比封装隧道轻量。
