当前位置: 首页 > article >正文

【k8s】Calico网络

Calico网络结构

Calico网络模型主要工作组件:

  1. Felix:运行在每一台 Host 的 agent 进程,主要负责网络接口管理和监听、路由、ARP 管理、ACL 管理和同步、状态上报等。
  2. etcd:分布式键值存储,主要负责网络元数据一致性,确保Calico网络状态的准确性,可以与kubernetes共用;
  3. BGP Client(BIRD):Calico 为每一台 Host 部署一个 BGP Client,使用 BIRD 实现,BIRD 是一个单独的持续发展的项目,实现了众多动态路由协议比如 BGP、OSPF、RIP 等。在 Calico 的角色是监听 Host 上由 Felix 注入的路由信息,然后通过 BGP 协议广播告诉剩余 Host 节点,从而实现网络互通。
  4. BGP Route Reflector:在大型网络规模中,如果仅仅使用 BGP client 形成 mesh 全网互联的方案就会导致规模限制,因为所有节点之间俩俩互联,需要 N^2 个连接,为了解决这个规模问题,可以采用 BGP 的 Router Reflector 的方法,使所有 BGP Client 仅与特定 RR 节点互联并做路由同步,从而大大减少连接数。

Felix

      Felix会监听ECTD中心的存储,从它获取事件,比如说用户在这台机器上加了一个IP,或者是创建了一个容器等。用户创建pod后,Felix负责将其网卡、IP、MAC都设置好,然后在内核的路由表里面写一条,注明这个IP应该到这张网卡。同样如果用户制定了隔离策略,Felix同样会将该策略创建到ACL中,以实现隔离。

BIRD

      BIRD是一个标准的路由程序,它会从内核里面获取哪一些IP的路由发生了变化,然后通过标准BGP的路由协议扩散到整个其他的宿主机上,让外界都知道这个IP在这里,你们路由的时候得到这里来。

架构特点

      由于Calico是一种纯三层的实现,因此可以避免与二层方案相关的数据包封装的操作,中间没有任何的NAT,没有任何的overlay,所以它的转发效率可能是所有方案中最高的,因为它的包直接走原生TCP/IP的协议栈,它的隔离也因为这个栈而变得好做。因为TCP/IP的协议栈提供了一整套的防火墙的规则,所以它可以通过IPTABLES的规则达到比较复杂的隔离逻辑。

Node上的Pod通信

 1、每个Node的Pod的IP分配都是基于每个node上的pod-cidr配置的,相同node上的pod分别的ip都是 同一个网段的,不同node的pod网段不一样。比如: node1上分配的pod-cidr网段是: 172.20.192.x,node2上分配的pod-cidr网段是: 172.20.193.x,那么在node1分配的pod的ip的都是172.20.192.xx 172.20.192.cc 。然后通过pod-cidr的网段就可以知道当一个pod需要和其他pod通信时是否在同一个node中,如果是在同一一个node上,那么网段肯定是一致的,那么就直接通过calixxx01 ------> 本机路由表--->calixxx02 来实现通信,如果不是同一个网段的就直接通过ipip隧道,把数据在封装成对方pod所在的node节点的ip.

准备知识点

    veth pair

   veth pair(虚拟以太网设备对)是 Linux 内核提供的一种网络接口类型,它允许创建一对相互连接的虚拟网络接口。这两个接口之间形成一个双向通道,任何发送到其中一个接口的数据包都会从另一个接口接收。这在容器化环境中特别有用,因为它可以用来建立宿主机与容器之间的网络通信,以及容器之间的网络通信。

veth pair 的工作原理
  1. 创建:当你在系统中创建一个 veth pair 时,实际上是在内核网络栈中同时创建了两个接口。这两个接口总是成对存在,并且它们之间形成了一个点对点的连接。

  2. 命名空间分离:在 Kubernetes 或 Docker 等容器化平台中,通常会将这对接口中的一个放置在宿主机的根命名空间中,而另一个则移动到容器的独立网络命名空间中。这样做的目的是让容器拥有自己的网络栈,从而实现网络隔离。

  3. 桥接或直接路由:宿主机上的那一端可以被添加到一个 Linux 桥接设备上(如 Docker 默认行为),或者通过路由规则直接与其他网络接口相连。对于 Calico 这样的 CNI 插件,它倾向于使用 BGP 来动态配置路由,而不是依赖于传统的桥接方式。

  4. 数据传输:当容器内的应用程序尝试发送数据包时,这些数据包会被发送到容器命名空间中的那个 veth 接口;然后,数据包会出现在宿主机命名空间中的配对 veth 接口上,再根据路由表决定下一步去哪里。反之亦然,来自外部网络的数据包也会通过同样的路径到达容器。

  5. 网络策略和安全:由于每个 Pod 都有自己的 veth 对,网络插件(例如 Calico)可以在这些接口上应用细粒度的安全策略,限制哪些流量可以进出容器,从而增强了集群的安全性。

      在 Kubernetes 中,每当一个新的 Pod 被创建时,CNI 插件(比如 Calico)就会负责设置这个 Pod 所需的所有网络资源,包括创建并配置相应的 veth pair。具体来说:

  • 一个 veth 接口被放在宿主机的网络命名空间中,并连接到 Calico 的路由机制。
  • 另一个 veth 接口被移到新创建的 Pod 的网络命名空间中,成为 Pod 的默认网卡(eth0)。

      这种设计不仅实现了容器间的高效通信,还确保了良好的网络隔离性和安全性,使得 Kubernetes 能够支持复杂的微服务架构和多租户环境。

 有个问题是:Node怎么知道其他Node的pod-cidr的网段呢?

  这个就需要通过每个节点上运行的bird+felix协作来完成,每一个节点加入时,calico组件会为本机分配一个pod-cidr的pod的网段,然后通过bird协议来告诉集群中的其他节点。然后其他节点得到消息之后,就修改路由表信息。


http://www.kler.cn/a/458654.html

相关文章:

  • Linux中sh脚本发邮件配置
  • arcgis server ip修改后服务异常解决方案
  • 阿里云clb是什么
  • 路由器单臂路由配置
  • Java - 日志体系_Apache Commons Logging(JCL)日志接口库_适配Log4j2 及 源码分析
  • uniapp实现为微信小程序扫一扫的功能
  • python|利用ffmpeg按顺序合并指定目录内的ts文件
  • 5G CPE接口扩展之轻量型多口千兆路由器小板选型
  • 【Jetson Nano】40Pin学习 GPIO
  • 青少年编程与数学 02-005 移动Web编程基础 05课题、rem布局与媒体查询
  • akamai3.0 wizzair 网站 分析
  • IEA国际能源署数据库
  • windows C#-显式实现两个接口的成员
  • pytorch张量的fill_方法介绍
  • hhdb客户端介绍(64)
  • 【MySQL】触发器
  • leetcode 面试经典 150 题:矩阵置零
  • 【openGauss】正则表达式次数符号“{}“在ORACLE和openGauss中的差异
  • mac如何查看使用git克隆下来的文件.git 文件【收藏版】
  • 单元测试/系统测试/集成测试知识总结