这里是在本科毕业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 sandboxERROR: I/O error while writing action log: write (No space left on device)Target //src/probe:push_image failed to buildUse --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有微信交换群，在上手应用时有问题能够发到群里，会有大佬给你解答的~