共计 4042 个字符，预计需要花费 11 分钟才能阅读完成。
这里是在本科毕业 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 有微信交换群，在上手应用时有问题能够发到群里，会有大佬给你解答的~
