Calico 是一种容器之间互通的网络方案。支持广泛的平台,包括Kubernetes、OpenShift、Docker EE、OpenStack和bare metal服务。
它可以不使用隧道或 NAT 来实现转发,而是巧妙的把所有二三层流量转换成三层流量,并通过 host 上路由配置完成跨 Host 转发。
calico/node
calico/node容器被部署到每个节点(在Kubernetes上,以DaemonSet形式部署),并运行三个内部守护进程:
-
Felix:运行在每个节点上并提供endpoints的Calico守护进程。
-
BIRD:BGP守护进程,负责向其他节点分发路由信息。
-
confd:一个守护进程,它监视Calico数据存储的配置更改并更新BIRD的配置文件。
Felix
配置路由,ACL等信息确保Endpoint的连通状态。
主要功能如下:
-
接口管理
将接口信息配置到内核,以便内核能够正确地处理来自该端点的通信。特别是,它确保主机用主机的MAC响应来自每个工作负载的ARP请求,并为它管理的接口启用IP转发。它还监视接口,以确保在适当的时候应用配置。
-
路由配置
将主机端点的路由信息配置到Linux内核的FIB(Forwarding Information Base,转发信息库)中,确保到达该主机端点的数据包能够被相应地转发。
-
ACL配置
确保只有有效的流量可以在端点之间发送,并且端点不能绕过Calico安全措施。
-
状态报告
提供网络健康数据。特别是在配置其主机时报告错误和问题。该数据被写入数据存储,以便对网络的其他组件和操作人员可见。
BIRD
从Felix获取路由,并分发给网络上的BGP对等体,用于主机间路由。在运行Felix代理的每个节点上运行。
主要功能如下:
-
路由分发
当Felix在Linux内核FIB中插入路由时,BGP客户端会将路由分发到其他节点。这确保了部署时有效的流量路由。
-
BGP路由反射器配置
BGP路由反射器通常配置为大型部署,而不是标准的BGP客户端。BGP路由反射器作为连接BGP客户端的中心点。(标准的BGP协议要求每个BGP客户端都要在一个网状拓扑中相互连接,维护起来比较困难。)
为了实现冗余,可以无缝部署多个BGP路由反射器。BGP路由反射器只负责网络的控制,没有端点数据经过。当Calico BGP客户端将自己的FIB路由发布到路由反射器时,路由反射器会将这些路由发布到整个部署的其他节点。
confd
监控Calico数据存储的BGP配置和全局默认值的变化,如日志级别和IPAM信息等。
Confd根据对数据存储中数据的更新动态生成BIRD配置文件。当配置文件发生变化时,confd会触发BIRD加载新文件。
Dikastes
为Istio服务网格执行网络策略。在集群上运行,作为Istio Envoy的sidecar代理。
CNI 插件
为Kubernetes集群提供Calico网络。
Datastore plugin
通过减少每个节点对数据存储的影响来增加伸缩性。是一个Calico CNI插件。
-
Kubernetes API datastore (kdd)
优势:
管理简单,因为它不需要额外的数据存储。
使用Kubernetes RBAC控制对Calico资源的访问。
使用Kubernetes审计日志来生成对Calico资源更改的审计日志。 -
etcd
优势:
允许在非kubernetes平台上运行Calico。
Kubernetes和Calico资源之间的关注点分离,例如,允许独立扩展数据存储。
允许运行一个包含不止一个Kubernetes集群的Calico集群,例如,带有Calico主机保护的裸金属服务器与Kubernetes集群互通。
IPAM 插件
使用Calico的IP池资源来控制如何将IP地址分配给集群中的pods。它是大多数Calico安装使用的默认插件。
Typha
通过减少每个节点对数据存储的影响来增加伸缩性。作为守护进程在Felix的数据存储和实例之间运行。
Typha维护一个单独的数据存储连接,代表它的所有客户端,如Felix和confd。它缓存数据存储状态并重复数据删除事件,以便将它们分发给许多侦听器。因为一个Typha实例可以支持数百个Felix实例,所以它大大减少了数据存储上的负载。因为Typha可以过滤掉与Felix无关的更新,它也减少了Felix的CPU使用率。在高规模(100多个节点)Kubernetes集群中,这是至关重要的,因为API服务器生成的更新数量会随着节点数量的增加而增加。