遇到的问题总览：

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的相关命令：

ruby 复制代码

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的性能优化：

选举时长优化

ini 复制代码

# 启动设置环境变量
ETCD_ELECTION_TIMEOUT=5000   # 选举超时
ETCD_HEARTBEAT_INTERVAL=250  # 心跳周期

减少磁盘IO 延迟

arduino 复制代码

#ionice - 获取或设置程序的IO调度与优先级，通过设置命令或进程的IO调度优先级，加快IO效率
ionice -c2 -n0 -p 'pgrep etcd'

保持合理的日志文件大小

css 复制代码

etcd --snapshot-count

自动压缩历史版本

arduino 复制代码

etcd --auto-compaction

定期清除碎片化

bash 复制代码

# 压缩完之后执行。
etcd defrag

参考：cloud-atlas.readthedocs.io/zh-cn/lates...

deployment探针

在3.19 官方提供的manifests中，livenessProbe（存活探针）中的timeoutSeconds只有1，在系统环境不太给力的情况下，会导致calico-node经常重启，可以设置为60。

bash 复制代码

          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调用出现超时的情况，排查思路如下：

现象

k8s pod无法访问集群内其他服务，grpc出现Unavailable 错误； --> 表明cni组成出现问题；
kubernetes组件层面，通过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

查看到了可疑情况，使用Perf进行堆栈的使用率才看：

可以看到，bird使用if_find_by_index的时候，cpu占用非常高，这两个函数的定义为：一个为根据索引查看找网卡，一个根据名称查看网卡。怀疑点：每台机器的pod数过多，导致网卡以及iptables设置过多。

查看对应主机的路由策略，以及网卡信息：

image.png

将问题怀疑点，去github上，进行issue查看，找到相关问题的分析，与我们场景相似：

(链接地址：github.com/projectcali...，当前作为BUG 合入calico 3.27.0中，在内部使用了两个月未出现这个问题。) 在项目场景中，存在大量的定时任务，大部分定时任务一分钟启动一次，必然会触发当前BUG。

当前解决方式

短期规避：

运维监听主机bird,bird6进程，超过85% cpu占用率时进行kill操作；

经验项：

业务层使用定时任务框架进行调度，而不使用Cronjob。

calico 鉴权问题

现象，在k8s运行过程中，创建pod时报错：

vbnet 复制代码

error getting ClusterInformation: connection is unauthorized: Unauthorized

相关issue： github.com/projectcali... 当前的解决方式，因为运行了2年只发现了这一起，所以直接将calico-node进行重启解决。

小结

在使用第三方组件的过程中，出现问题需要有明确的排查思路，一般的路径是：

引入时，需要对组件的原理进行较深的理解。
排查过程中，如果一般错误通过linux 10个排查小工具进行；cpu采样可以通过perf，以及Ebpf手段进行。
如果问题比较棘手，接下来就是去github上查找相关issue以及看源码。

以上。

记calico使用的‘陷阱’

前置

calico-node 运行时 running 0/1

etcd性能

deployment探针

bird性能问题

现象

当前解决方式

calico 鉴权问题

小结