Kubernetes ——Calico网络插件

这篇具有很好参考价值的文章主要介绍了Kubernetes ——Calico网络插件。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Calico网络插件

  Calico 是一个开源网络和网络安全解决方案,适用于容器、虚拟机和基于本地主机的工作负载。Calico 支持广泛的平台,包括 Kubernetes、OpenShift、Mirantis Kubernetes Engine (MKE)、OpenStack 和裸机服务。(官网翻译:https://projectcalico.docs.tigera.io/about/about-calico)

  无论您选择使用 Calico 的 eBPF 数据平面还是 Linux 的标准网络管道,Calico 都能提供超快的性能和真正的云原生可扩展性。Calico 为开发人员和集群运营商提供一致的体验和一组功能,无论是在公共云或本地、单个节点上还是跨数千个节点的集群上运行。(官网翻译:https://projectcalico.docs.tigera.io/about/about-calico)

  Calico本身是一个三层的虚拟网络方案,它将每个节点都当作路由器(router),将每个节点的容器都当作是“节点路由器”的一个终端并为其分配一个IP地址,各节点路由器通过BGP(Border Gateway Protocol)学习生成路由规则,从而将不同节点上的容器连接起来。因此,Calico方案其实是一个纯三层的解决方案,通过每个节点协议栈的三层(网络层)确保容器之间的连通性,这摆脱了flannel host-gw类型的所有节点必须位于同一二层网络的限制,从而极大地扩展了网络规模和网络边界。

一、Calico工作特性

  Calico 利用 Linux 内核在每一个计算节点上实现了一个高效的 vRouter(虚拟路由器)进行报文转发,而每个 vRouter(虚拟路由器) 都通过 BGP 负责把自身所属的节点上运行的 Pod 资源的 IP 地址信息基于节点的 agent 程序(Felix)直接由 vRouter 生成路由规则向整个 Calico 网络内进行传播。小规模部署可以直接互联,大规模建议使用 BPP 路由反射器(router reflector)来完成。Felix 也支持在每个节点上按需生成 ACL(Access Control List)从而实现安全策略,如隔离不同的租户或项目的网络通信。vRouter 利用 BGP 通告本节点上现有的地址分配信息,每个 vRouter 均接入 BGP 路由反射器以实现控制平面扩展。

  Calico承载的各Pod资源直接通过vRouter经由基础网络进行互联,它非叠加、无隧道、不使用VRF表,也不依赖于NAT,因此每个工作负载都可以直接配置使用公网IP接入互联网,当然,也可以按需使用网络策略控制它的网络连通性。

1.1)经过 IP 路由直连

  Calico 中,Pod 收发的 IP 报文由所在节点的 Linux 内核路由表负责转发,并通过 iptables 规则实现其安全功能。

  某 Pod 对象发送报文时,Calico 应确保节点总是作为下一跳 MAC 地址返回,不管工作负载本身可能配置什么路由,而发往某 Pod 对象的报文,其最后一个 IP 跃点就是 Pod 所在的节点。也就是说,报文的最后一程即由节点发网目标 Pod 对象,如下图所示:

k8s安装calico,linux,DPDK,c++,网络,kubernetes,linux,c/c++,虚拟机

  需为某 Pod 对象提供连接时,系统上的专用插件(如 Kubernetes 的 CNI)负责将需求通知给 Calico Agent。收到消息后,Calico Agent 会为每个工作负载添加直接路径信息到工作负载的 TAP 设备(如 veth)。而运行于当前节点的 BGP 客户端监控到此类消息后会调用路由 reflector 向工作于其他节点的 BGP 客户端进行通告。

1.2)简单、高效、易扩展

  Calico未使用额外的报文封装和解封装,从而简化了网络拓扑,这也是Calico高性能、易扩展的关键因素。毕竟,小的报文减少了报文分片的可能性,而且较少的封装和解封装操作也降低了对CPU的占用。此外,较少的封装也易于实现报文分析,易于进行故障排查。

  创建、移动或删除Pod对象时,相关路由信息的通告速度也是影响其扩展性的一个重要因素。Calico出色的扩展性缘于与互联网架构设计原则别无二致的方式,它们都使用了BGP作为控制平面。BGP以高效管理百万级的路由设备而闻名于世,Calico自然可以游刃有余地适配大型IDC网络规模。另外,由于Calico各工作负载使用基IP直接进行互联,因此它还支持多个跨地域的IDC之间进行协同。

1.3)较好的安全性

  原则上,Calico 网络允许 IDC 中的任何工作负载与其他任意目标进行通信,但管理员或用户却未必期望如此,在多租户 IDC 中隔离租户挽留过几乎是必需之需。于是,Calico 操纵节点上的 iptables 规则以管控工作负载的互联许可。此种 iptables 规则操纵功能是节点间的警戒哨,负责阻挡任何非许可流量,并防止通过工作负载危及自身。

    • 严格的域间流量分隔: 运行于某个租户虚拟网络内的应用应严禁访问其他租户的应用,这种流量分隔是由久经考验的 Linux 内核中的 ACL 子系统予以实现的。
    • 精细的策略规则: 实现了租户间隔离的网络方案大多并没有额外实现细粒度的安全策略,而 Calico 通过使用 Linux 内建的 ACL 扩展来支持一众安全规则,任何可由 ACL 支持的功能均能通过 Calico 实现。
    • 简洁而不简单: Calico 直接使用个 IP 网络,无须任何地址转换或隧道承载的机制实现了一个简洁的 "WYSIWYG"(what you see is what you get)网络模型,它可以清晰地标识出每个报文从哪儿来,到哪儿去。于是,管理员可因此而清晰地理解流量的来去。

二、Calico 系统架构

  概括来说,Calico 主要由 Felix、Orchestrator Plugin、etcd、BIRD 和 BGP Router Reflector 等组件组成,其组件架构如下图所示:

k8s安装calico,linux,DPDK,c++,网络,kubernetes,linux,c/c++,虚拟机
    • Felix: Calico Agen,运行于每个节点。主要负责网络接口管理和监听、路由、ARP 管理、ACL管理和同步、状态上报等。
    • Orchestrator Plugin: 编排系统(如 k8s、openstack等)以将 Calico 整合进系统中的插件,例如 k8s 的 CNI。
    • etcd:持久存储 Calico 数据的存储管理系统。分布式键值存储,主要负责网络元数据一致性,确保 Calico 网络状态的准确性,可以与 Kubernetes 共用。
    • BIRD:用于分发路由信息的 BGP 客户端。Calico 可以为每一台节点部署一个 BGP Client,使用 BIRD 实现,BIRD 是一个单独的持续发展项目,实现了众多动态路由协议比如 BGP、OSPF、RIP 等。在 Calico 的角色是监听 节点上由 Felix 注入的路由信息 ,然后通过 BGP 协议广播告诉剩余节点,从而实现网络互通。
    • BGP Route Reflector:BGP 路由反射器,可选组件,用于较大规模的网络场景。在大型网络规模中,如果仅仅使用 BGP client 形成 mesh 全网互联的方案就会导致规模限制,因为所有节点之间俩俩互联,需要 N^2 个连接,为了解决这个规模问题,可以采用 BGP 的 Router Reflector 的方法,使所有 BGP Client 仅与特定 RR 节点互联并做路由同步,从而大大减少连接数。

2.1)Felix

  Felix 运行于各节点的用于支持端点(VM或Container)构建的守护进程,它负责生成路由和ACL,以及其他任何由节点用到的信息,从而为各端点构建连接机制。Felix在各编排系统中主要负责以下任务:

    1. 首先是接口管理(Interface Management)功能,负责为接口生成必要的信息并送往内核,以确保内核能够正确处理各端点的流量,尤其是要确保各节点能够响应目标MAC为当前节点上各工作负载的MAC地址的ARP请求,以及为其管理的接口打开转发功能。另外,它还要监控各接口的变动以确保规则能够得到正确的应用。
    2. 其次是路由规划(Route Programming)功能,其负责为当前节点运行的各端点在内核FIB(Forwarding Information Base)中生成路由信息,以保证到达当前节点的报文可正确转发给端点。
    3. 再次是ACL规划(ACL Programming)功能,负责在Linux内核中生成ACL,用于实现仅放行端点间的合法流量,并确保流量不能绕过Calico的安全措施。
    4. 最后是状态报告(State Reporting)功能,负责提供网络健康状态的相关数据,尤其是报告由其管理的节点上的错误和问题。这些报告数据会存储于etcd,供其他组件或网络管理员使用。

2.2)容器系统插件

  编排系统插件(Orchestrator Plugin)依赖于编排系统自身的实现,故此并不存在一个固定的插件以代表此组件。编排系统插件的主要功能是将Calico整合进系统中,并让管理员和用户能够使用Calico的网络功能。它主要负责完成API的转换和反馈输出。

  编排系统通常有其自身的网络管理API,网络插件需要负责将对这些API的调用转为Calico的数据模型并存储于Calico的存储系统中。如果有必要,网络插件还要将Calico系统的信息反馈给编排系统,如Felix的存活状态,网络发生错误时设定相应的端点为故障等。

2.3)etcd 存储系统

  Calico 使用 etcd 完成组件间的通信,并以之作为一个持久数据存储系统。根据编排系统的不同,etcd 所扮演角色的重要性也因之而异,但它贯穿了整个 Calico 部署全程,并被分为两类主机:

      • 核心集群
      • 代理(proxy)

  在每个运行着 Felix 或编排系统插件的主机上都应该运行一个 etcd 代理以降低 etcd 集群和集群边缘节点的压力。此模式中,每个运行着插件的节点都会运行着 etcd 集群的一个成员节点。

  etcd 是一个分布式、强一致、具有容错功能的存储系统,这一点有助于将Calico网络实现为一个状态确切的系统:要么正常,要么发生故障。另外,分布式存储易于通过扩展应对访问压力的提升,而避免成为系统瓶颈。另外,etcd也是Calico各组件的通信总线,可用于确保让非etcd组件在键空间(keyspace)中监控某些特定的键,以确保它们能够看到所做的任何更改,从而使它们能够及时地响应这些更改。

2.4)BGP客户端(BIRD)

  Calico 要求在每个运行着 Felix 的节点上同时还要运行一个 BGP 客户端,负责将 Felix 生成的路由信息载入内核并通告到整个IDC。在 Calico 语境中,此组件是通用的 BIRD,因此任何 BGP 客户端(如GoBGP等)都可以从内核中提取路由并对其分发对于它们来说都适合的角色。

  BGP 客户端的核心功能就是路由分发,在 Felix 插入路由信息至内核 FIB 中时,BGP 客户端会捕获这些信息并将其分发至其他节点,从而确保了流量的高效路由。

2.5)BGP路由反射器(BIRD)

  在大规模的部署场景中,简易版的BGP客户端易于成为性能瓶颈,因为它要求每个BGP客户端都必须连接至其同一网络中的其他所有BGP客户端以传递路由信息,一个有着N个节点的部署环境中,其存在网络连接的数量为N的二次方,随着N值的逐渐增大,其连接复杂度会急剧上升。因而在较大规模的部署场景中,Calico应该选择部署一个BGP路由反射器,它是由BGP客户端连接的中心点,BGP的点到点通信也就因此转化为与中心点的单路通信模型。出于冗余之需,生产实践中应该部署多个BGP路由反射器。对于Calico来说,BGP客户端程序除了作为客户端使用之外,还可以配置成路由反射器。

 三、Calico 部署要点

  安装 Calico 需要事先有运行中的 Kubernetes 1.1 及以上版本的集群,如果要用到网络策略,则 Kubernetes 版本需要 1.3.0 及以上才可以。另外,还需要一个可由 Kubernetes 集群各节点访问到的 etcd 集群。虽然可以让 Calico 和 Kubernetes 共同使用一个 etcd 集群,然而有些场景中推荐为 etcd 使用集群,如需要获得较好的性能时:

  与 Kubernetes 集群进行整合时,Calico 需要提供三个组件,具体如文章来源地址https://www.toymoban.com/news/detail-727422.html

到了这里,关于Kubernetes ——Calico网络插件的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • kubernetes集群(k8s)之安装部署Calico 网络

    目录 安装部署Calico 网络 (一)环境准备 (二)部署docker环境 (三)部署kubernetes集群 (四)部署Calico网络插件 IP地址 主机名 组件 192.168.100.131 k8s-master kubeadm、kubelet、kubectl、docker-ce 192.168.100.132 k8s-node01 kubeadm、kubelet、kubectl、docker-ce 192.168.100.133 k8s-node02 kubeadm、kubelet、kube

    2024年02月12日
    浏览(48)
  • k8s-kubernetes--网络策略、flannel网络插件和calico网络插件

    抽象的接口层,将 容器网络配置方案与容器平台方案解耦 CNI(Container Network Interface)就是这样的一个接口层,它定义了一套接口标准,提供了规范文档以及一些标准实现。采用CNI规范来设置容器网络的容器平台不需要关注网络的设置的细节,只需要按CNI规范来调用CNI接口即

    2024年02月07日
    浏览(35)
  • k8s部署Calico网络插件出现Init:ImagePullBackOff

    配置环境: CentOS 7.9 docker-ce-19.03.15 kubeadm-1.22.17-0 kubelet-1.22.17-0 kubectl-1.22.17-0 配置过程略。。。 在部署单Master时,想要其他的node节点加入到集群中来,然后就显示其中一个node节点的准备状态是NotReady  此时这里我们用到的网络插件:Calico kubectl apply -f  https://gitee.com/leedon21/k

    2024年02月16日
    浏览(40)
  • ·[K8S:使用calico网络插件]:解决集群节点NotReady问题

    执行: wget --no-check-certificate https://projectcalico.docs.tigera.io/archive/v3.25/manifests/calico.yaml 1.2.1:查看本机ip 网卡相关信息: 1.2.2:修改calico.yaml网卡interface相关信息 1.3.1:异常日志抛出: 1.3.2:场景一:执行K8S admin config配置文件替换相关操作: 1.3.2:场景二:执行K8S admin config配置文

    2024年02月14日
    浏览(58)
  • 【云原生-K8s】kubeadm搭建安装k8s集群v1.25版本完整教程【docker、网络插件calico、中间层cri-docker】

    从 k8s 1.24开始,dockershim已经从kubelet中移除,但因为历史问题docker却不支持kubernetes主推的CRI(容器运行时接口)标准,所以docker不能再作为k8s的容器运行时了,即从k8s v1.24开始不再使用docker了 但是如果想继续使用docker的话,可以在kubelet和docker之间加上一个中间层cri-docker。

    2024年02月03日
    浏览(41)
  • 【大数据】kubernetes(k8s)calico跨节点网络不通的问题及排错过程

    进入节点 k8s-node27 的pod,ping k8s-node28 节点上的pod的ip都不通,k8s-node28 节点ping k8s-node27 也不通,但是k8s-node27,k8s-node28 之间他们各自节点上的pod的ip之间是可以相互ping通。 排查过程: 这种情况让我们想起了当时设置路由转发时候的配置,主机上有多个网卡,而k8s的calico网络

    2024年02月11日
    浏览(53)
  • k8s calico 网络异常处理

    故障 worker3故障重启后,该节点的 pod 访问不了其它节点服务 2023-06-26T07:44:41.041Z        ERROR   setup   unable to start manager {\\\"error\\\": \\\"Get \\\"https://10.244.64.1:443/api?timeout=32s\\\": dial tcp 10.244.64.1:443: i/o timeout\\\"} 发现网络组件也是有报错重启,对比其它节点的iptables,少了好多。     该节点

    2024年02月11日
    浏览(47)
  • 【云原生、k8s】Calico网络策略

    第四阶段 时  间:2023年8月17日 参加人:全班人员 内  容: Calico网络策略 目录 一、前提配置 二、Calico网络策略基础 1、创建服务 2、启用网络隔离 3、测试网络隔离 4、允许通过网络策略进行访问 三、Calico网络策略进阶 1、创建服务 2、拒绝所有入口流量 3、允许进入Nginx的流

    2024年02月12日
    浏览(41)
  • k8s 之网络组件-Calico(十九)

    下载资源 :安装 kubernetes 网络组件-Calico 一, 简介         Calico是Kubernetes生态系统中另一种流行的网络选择。虽然Flannel被公认为是最简单的选择,但Calico以其性能、灵活性而闻名。Calico的功能更为全面,不仅提供主机和pod之间的网络连接,还涉及网络安全和管理。Cali

    2024年02月11日
    浏览(37)
  • k8s Calico网络和flannel网络对比

    Calico 和 Flannel 是 Kubernetes(K8s) 中常用的两种网络插件,它们都有各自的优点和适用场景。以下是 Calico 网络与 Flannel 网络的一些主要对比点: Calico 1. 技术基础 :Calico 依赖于 BGP(Border Gateway Protocol)路由协议来实现节点间通信,可以支持大规模的集群。 2. 性能 :由于使用

    2024年04月27日
    浏览(56)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包