小白安装云原生可观测性开源工具Kindling体验

本文转自一位准研究生博客,以下为正文。本人是一个刚接触云原生概念,第一次安装可观测工具的小白。安装过程总体还算顺利,但也遇到了不少问题,这里把安装过程中遇到的问题以及解决方案记录下来,希望对大家上手kindling有帮助~

问题一:

第一次看安装指南(:33215/project-3/doc-37/)的时候,第一句告诉我有些ebpf相关的内核配置要打开。我当时在网上找了很久没有找到修改内核配置的方法,大多数资料告诉我要下载一个新的内核源码另外编译。

解决方案:

经过研究发现在部署配置执行脚本的时候就会自动帮我检测的。一般内核是默认打开的。假如没有找到CONFIG_BPF=y的选项,也许是版本较低,问题不大,先跑了安装脚本再说。kindling支持对较低版本的内核采用预编译内核模块的方式。对linux版本的支持参看kindling的前置条件(:33215/project-3/doc-38/)。

问题二:

执行完脚本后查看,有个在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

解决方案: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的第一个问题::33215/project-3/doc-42/也许会找不到对应的rpm包,FAQ中提供了一些下载内核头文件的安装包。1、ml是主流支持版本,lt是长期支持版本尽量不要用ml版本。因为不同人编译的选择的选项不同,要无ml版本(虽然我最后没找到4.19的lt版本,还是用了ml成功了)2、查看已安装的内核版本的命令:uname -a ; rpm -qa kernel\* | sort

```

 

问题三:

部署grafana插件报错

解决方案:发现是复制文本不全,出现缩进错误。现在的安装脚本已经把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 didnt tolerate, 2 pod has unbound immediate PersistentVolumeClaims.

解决方案:

给master节点容忍能力,让它可以调度。可参见这篇blog: 

问题五:

在部署grafana后,如何让本机浏览器上访问到集群的grafana主页面。问题场景:有的阿里的集群对外开放的端口只有8080,且不提供loadbalancer功能。

Grafana service 默认是loadbalancer

解决方案:

尝试1:用niginx把流量代理到grafana。但grafana设置为不允许。尝试2(解决):修改了grafana的配置,使其端口变为8080,然后使用**hostnetwork**让它能直接访问 在本次解决中,借这个机会学习了k8s中各种ip 的概念,小白开始时很容易混淆,这是这次的一大知识点收获。附暴露端口的办法:● loadbalancer阿里云集群没有。可以自己搭建nginx 或者使用云服务商的负载均衡器来做处理。尝试自己安装:https://www.jianshu.com/p/263185800214yaml没有部署成功,同时考虑到可能不能指定端口,打算暂放。● ingress● nodeport通过 nodeIP:nodePORT来访问。标志指定的范围内分配端口(默认值:30000-32767) 8080不在范围内,行不通https://my.oschina.net/u/4309098/blog/3414421● extenal ip暴露出来的是随机端口号吧,在这里不符合● hostnetwork这种方法,搜到的几个文档里没有说。后来在一位前辈给的文章(强推给小白)里找到了方法。最后通过这个方式解决了https://alesnosek.com/blog/2017/02/14/accessing-kubernetes-pods-from-outside-of-the-cluster/

 

到这里基本就能在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_21682469/article/details/98736809docker images | grep registry.cn-hangzhou.aliyuncs.com/sugary199/kindling-collector | awk {print $3} | xargs docker rmipune操作,没敢在机器上用。在自己电脑上试了试删了1G。

问题七:

替换新的镜像之后,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有交流群,在上手使用时有问题可以发到群里,会有大佬给你解答的。