遇到的问题总览：
-
calico-node 运行一直显示 running 0/1，可能有以下几个原因：
- etcd 性能原因
- deployment 存活探针问题
- calico自身bird组件问题
-
calico 报错：error getting ClusterInformation: connection is unauthorized: Unauthorized
前置
calico版本号： v3.19.0
集群规模： 100 node以下，所以使用BGP: node-to-node 模式进行路由同步。
calico-node 运行时 running 0/1
etcd性能
calico存储组件使用的是ETCD。默认安装情况下，存储操作都通过kube-apiserver访问etcd。所以etcd的性能（与k8s共用）也会影响calico的正常运行。 查看calico数据，etcd的相关命令：
etcdctl --cacert=/etc/ssl/etcd/ssl/ca.pem --cert=/etc/ssl/etcd/ssl/node-node1.pem --key=/etc/ssl/etcd/ssl/node-node1-key.pem --endpoints=https://127.0.0.1:2379 get /registry/crd.projectcalico.org/ --prefix --keys-only
可以看出，第三方组件通过kube-apiserver存储信息，可以使用etcdctl /registry/<三方组件CRD> ， 如/registry/crd.projectcalico.org
etcd的官方推荐是使用SSD盘，在内部测试环境还是机械硬盘，所以通过以下几个手段进行etcd的性能优化：
# 启动设置环境变量
ETCD_ELECTION_TIMEOUT=5000 # 选举超时
ETCD_HEARTBEAT_INTERVAL=250 # 心跳周期
#ionice - 获取或设置程序的IO调度与优先级，通过设置命令或进程的IO调度优先级，加快IO效率
ionice -c2 -n0 -p 'pgrep etcd'
etcd --snapshot-count
etcd --auto-compaction
# 压缩完之后执行。
etcd defrag
参考：cloud-atlas.readthedocs.io/zh-cn/lates…
deployment探针
在3.19 官方提供的manifests中，livenessProbe（存活探针）中的timeoutSeconds只有1，在系统环境不太给力的情况下，会导致calico-node经常重启，可以设置为60。
livenessProbe:
exec:
command:
- /bin/calico-node
- -felix-live
- -bird-live
periodSeconds: 10
initialDelaySeconds: 10
failureThreshold: 6
timeoutSeconds: 60
readinessProbe:
exec:
command:
- /bin/calico-node
- -felix-ready
- -bird-ready
periodSeconds: 10
timeoutSeconds: 60
bird性能问题
在calico成功运行一段时间后，发现calico-node偶现running 0/1的情况，并且日志以及pod容器事件没有看见明显的日志错误。 在此情况下，程序间的RPC调用出现超时的情况，排查思路如下：
现象
kubectl get pod -n kube-system |grep calico：
发现calico组件一直都是running状态， 并没有崩溃，并且日志中没有发现任何的Error日志；
从calico官方说明： 
当I/O loop cycle时间过长时，看门狗会打印日志， 
在bird/sysdep/unix/io.c 下，io_loop函数进行。
kubectl describe pod -n kube-system从calico-node的pod情况来看：
image.png
top查看当前资源使用情况， 可以发现calico的bird进程CPU使用率达到100%；并一直处于高位不下；
image.png
可以看到，bird使用if_find_by_index的时候，cpu占用非常高，这两个函数的定义为： 
一个为根据索引查看找网卡，一个根据名称查看网卡。 怀疑点：每台机器的pod数过多，导致网卡以及iptables设置过多。
image.png
(链接地址：github.com/projectcali…，当前作为BUG 合入calico 3.27.0中，在内部使用了两个月未出现这个问题。) 在项目场景中，存在大量的定时任务，大部分定时任务一分钟启动一次，必然会触发当前BUG。
当前解决方式
短期规避：
经验项：
calico 鉴权问题
现象，在k8s运行过程中，创建pod时报错：
error getting ClusterInformation: connection is unauthorized: Unauthorized
相关issue： github.com/projectcali… 当前的解决方式，因为运行了2年只发现了这一起，所以直接将calico-node进行重启解决。
小结
在使用第三方组件的过程中，出现问题需要有明确的排查思路，一般的路径是：
以上。
