Kubernetes从零到精通（11-CNI网络插件）

 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插件包括：

Calico：提供网络策略、网络隔离等高级功能。

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，但仍然比封装隧道轻量。

原文地址：https://blog.csdn.net/fzw1030/article/details/142255959

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！