这里是在本科毕业ing的准研究生，未来实验室是做云边协同研究的。保研后联系了我导，我导让我先钻研钻研eBPF，可以用在云原生可观测领域。于是看到了开源项目kindling，并上手尝试了一番。由于这是第一次接触云原生概念、第一次接触可观测工具，在安装部署时遇到过一些问题。写下这篇踩坑集合希望对大家上手kindling有帮助~
问题一
第一次看installation的时候，第一句告诉我有些ebpf相关的内核配置要打开。我当时在网上找了很久没有找到修改内核配置的方法，大多数资料告诉我要下载一个新的内核源码另外编译。
Solution:后来知道了在部署配置执行脚本的时候就会自动帮我检测的。一般内核是默认打开的。假如没有找到CONFIG_BPF=y的选项，也许是版本较低，问题不大，先跑了安装脚本再说。
kindling支持对较低版本的内核采用预编译内核模块的方式。对linux版本的支持参看kindling的Requirements。
- 问题二
执行完脚本后查看，有个在node51上的kindling-agent pod 发生crashbackoff。FailedPostStartHook？容器刚创建立刻停止？
**排错步骤：
#先describe一下。
kubectl describe po kindling-agent-xxx
#然后执行命令看具体日志：
kubectl logs --tail=100 -f kindling-agent-xxxx -c kindling-probe -n kindling**
Solution:
step1：
那么要搞清楚kindling简单架构。
kindling-probe从内核中采集事件，并为事件补充进程、容器、网络等信息，最后按照预定义的事件格式通过Unix domain socket将事件发送到kindling-collector。
kindling-collector接收事件并对事件做业务处理，生成预期的指标和单次请求数据，最终将数据输出到外部存储中做持久化。
可以看出，collector是依赖probe的。问题不在于打出日志的kindling-collector，而在于没有打出日志的kindling-probe。probe没有起来，collector才会报错
在排查Pod为什么创建失败时，首先看 Pod 容器退出状态码是非常有用的，能快速的定位问题原因。
step2：
再来查看probe。Error: Precompiled module at /opt/.kindling/ is not found
原来是预编译的模块在 /opt/.kindling/目录下没有找到，导致probe起不来。需要到这个Node上，手动下载内核头文件并重新编译模块。编译完打成镜像，替换对应node上的镜像为自己的新版本。
参见FAQ的第一个问题http://www.kindling.space:332...
也许会找不到对应的rpm包，FAQ中提供了一些下载内核头文件的安装包。
1、ml是主流支持版本，lt是长期支持版本
尽量不要用ml版本。因为不同人编译的选择的选项不同，我们要无ml版本(虽然我最后没找到4.19的lt版本，还是用了ml成功了)
2、查看已安装的内核版本的命令：
uname -a ; rpm -qa kernel请添加图片描述
- 问题三
grafana插件部署。报错
Solution:发现是复制文本不全，出现缩进错误。现在的安装脚本已经把yaml文件的细节封装了，不会在这里遇到问题。不过这是常见错误，可以注意一下。
- 问题四
grafana插件部署，报下面的错
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 26s (x3 over 87s) default-scheduler 0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 pod has unbound immediate PersistentVolumeClaims.Solution:给master节点容忍能力，让它可以调度。https://blog.frognew.com/2018...
- 问题五
在部署garafana后，如何让本机浏览器上访问到集群的grafana主页面。
问题场景：有的阿里的集群对外开放的端口只有8080，且不提供loadbalancer功能。
Grafana service 默认是loadbalancer
尝试1：用niginx把流量代理到grafana。但grafana设置为不允许。
尝试2（解决）：修改了grafana的配置，使其端口变为8080，然后使用hostnetwork让它能直接访问
在本次解决中，借这个机会学习了k8s中各种ip 的概念，小白开始时很容易混淆，这是这次的一大知识点收获。附暴露端口的办法：
● loadbalancer
阿里云集群没有。可以自己搭建nginx 或者使用云服务商的负载均衡器来做处理。
尝试自己安装https://www.jianshu.com/p/263...
yaml没有部署成功，同时考虑到可能不能指定端口，打算暂放。
● ingress
● nodeport
通过 nodeIP:nodePORT来访问。
标志指定的范围内分配端口（默认值：30000-32767） 8080不在范围内，行不通
https://morningspace.github.i...
https://my.oschina.net/u/4309...
● extenal ip
暴露出来的是随机端口号吧，在这里不符合
https://morningspace.github.i...
● hostnetwork
这种方法，搜到的几个文档里没有说。在同事给的文章（强推给小白）里面有。最后通过这个方式解决了
https://alesnosek.com/blog/20...
到这里基本就能在grafana上看到kindling为你提供的监控服务啦。
下面是参与开发之后，第一次自己编译项目打镜像测试时遇到的问题。
- 问题六
在编译probe时，报如下错
ERROR: /root/.cache/bazel/_bazel_root/de75aa139bb85abf44b50886c94decde/external/openjdk-base-glibc/image/BUILD:4:17: GUNZIP external/openjdk-base-glibc/image/001.tar.gz.nogz failed: (Exit 1): zipper failed: error executing command bazel-out/host/bin/external/io_bazel_rules_docker/container/go/cmd/zipper/zipper_/zipper -src external/openjdk-base-glibc/image/001.tar.gz -dst ... (remaining 2 argument(s) skipped)
Use --sandbox_debug to see verbose messages from the sandbox
ERROR: I/O error while writing action log: write (No space left on device)
Target //src/probe:push_image failed to build
Use --verbose_failures to see the command lines of failed build steps.io error判断出磁盘空间满了
df -h查看，果然100%
用 du命令找到大文件删掉。
删除所有退出状态的容器。docker rm -v $(docker ps -aq -f status=exited)
删除之前开发时打的一系列collector镜像https://blog.csdn.net/qq_2168...
docker images | grep registry.cn-hangzhou.aliyuncs.com/sugary199/kindling-collector | awk '{print $3}' | xargs docker rmi
pune操作，没敢在机器上用。在自己电脑上试了试删了1G。https://blog.51cto.com/ywliyq...
- 问题七：
替换新的镜像之后，kindling-agent容器并没有重启？？
step1:先确认镜像的确变了。
我用了get ds -o yaml | grep collector
也可以手动：
kubectl describe pod kindling-agent-fnk5r -n kindling
手动改 kubectl edit ds kindling-agent -n kindling
用vi的方法搜，/image，找到之后手动更改
step2:继续describe+log排查
describe 判断是probe还是collector启动失败了。找到了是probe，然后打probe log查看具体错误。找到了最初的内核模块问题。
最终排查出问题： 就是第一次部署在集群上的时候，遇到的内核问题（问题二）。今天是服务器重启了，正好node51上的pod被阻塞住了所以其他的后面的pod没有重启。
想暂且不管他的话，就手动删掉其他的pod，他们自会重启。不过最终还是要面对的...
其他小问题：
minikube 还没有适配，直接在集群上安装。
第一次自己打镜像部署到集群上查看日志，记得先校对机器时间。
结语：新同学们在参与时不要害怕。之前没有接触过云原生，问题多是正常的。多多交流，kindling有微信交流群，在上手使用时有问题可以发到群里，会有大佬给你解答的~
