「这是我参与11月更文挑战的第13天，活动详情查看：2021最后一次更文挑战」。
架构图
以下架构图来源于官方文档
下图为我们自已搭建的集群架构图
分析
从官方架构图中，显示了calico官方提供了一些可选组件，像Typha组件已经安装，但没有配置生效，Dikastes组件服务于Istio网格Envoy的没有启用，大型网络BGP路由反射器也没有配置。
calico-kube-controllers组件安装在kubernetes集群，主要基于集群状态监视kubernetes API要施行的动作,该组件包括策略，命令空间，账号服务，pod，节点等相关控制器
kubectl get pods -A | grep calico-kube-controllers
calico datastore是一个数据存储插件，它可以和kubenetes共用集群etcd，或单独再使用一套etcd服务，目前我们的架构是和kubernetes共用
其主要是为了calico网络组件之间的通信提供数据存储，在共用etcd之后，可以使用k8s rbac控制calico资源的访问，可以使用k8s审计日志生成calico资源更改的审计日志
如果单独立再部署一套的优势是，k8s和calico资源隔离，以及calico可以包含多个单集，对于中小型架构或不需要复杂架构的来说，共用是最好的选择
Felix 运行在每个节点的agent之一，主要负责路由和acl,主机pod连接等任务。
felix监听datastore的变化，管理着主机上的网络接口，处理来自pod的流量请求和转发
felix不定期上传状态报告到网络健康数据到存储datastore,将calico的相关出站入站等规则写入到iptables中，其中关于pod路由部分写入到linux 内核fib中,这些fib信息后续有客户端处理(bird)
ps aux | grep felix | grep -v grep
可以在每个calico节点上看到felix的守护进程
BIRD是一个客户端，也是运行在每个节点的agent之一，它在ipip模式下是个普通的bgp客户端，负载从felix获取路由信息然后分发给网络上的bgp对等点
当Felix将路由写入到linux 内核的fib时，bgp客户端将它们分配给其它节点
只有启用BGP模式，使用Typha组件，bird才路由反射器功能，BGP的路由反射器是BGP客户端的中心，具体变化在路由中只有一条中心路由，取代其它相互建立的多条路由
ps aux | grep bird | grep -v grep
可以在每个calico节点上看到bird的守护进程
confd是个状成管理工个，也是运行在每个节点的agent之一,它主机监视calico数据存储，以查看bgp配置和全局默认值(as号，日志级别，ipam信息)的变更
ps aux | grep confd | grep -v grep
CNI是实现kubenetes网络模型的一组工具，主要为kubenetes提供calico网络，它安装在kubenetes的每个节点，将充当网络协调器，提供工具命令和配置
在kubelet watch来自kubernetes api server的变更，调用calico 提供的配置和工具来配置容器的网络和规则
#网络配置
ll /etc/cni/net.d/
#工具命令
ll /opt/cni/bin/ | grep cali
小结
除了calico-kube-controllers部署在k8s中，在各节点上其实还部署了不少守护进程
除了felix,confd,bird。还有分配tunnel IP的，监控token和IP的一些进程，这些都是calici内部的自动运维工具，定时维护着组件的状态
