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的连通状态。
主要功能如下：
-
接口管理
扫描二维码关注公众号，回复： 16101474 查看本文章
将接口信息配置到内核，以便内核能够正确地处理来自该端点的通信。特别是，它确保主机用主机的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服务器生成的更新数量会随着节点数量的增加而增加。