容器化RDS：借助火焰图定位Kubernetes性能问题

成都创新互联是一家专业提供东乡企业网站建设,专注与网站设计、成都网站设计、H5场景定制、小程序制作等业务。10年已为东乡众多企业、政府机构等服务。创新互联专业网站设计公司优惠进行中。

所有的编程人员都是乐观主义者，毕竟在可能出现问题的地方，一定都会遇到问题，在耗时 3600 秒后，95% 的 PVC 处于 Pending 状态，严格的说，在批量创建的场景，该功能不可用。

大量 PVC 处于 Pending 状态

| 定位问题组件

架构图

通过 kubelet logs 查看日志，可以在 external-provisioner 中发现可疑日志：

I0728 19:19:50.504069    1 request.go:480] Throttling request took 192.714335ms, request: POST:https://10.96.0.1:443/api/v1/namespaces/default/events
I0728 19:19:50.704033    1 request.go:480] Throttling request took 190.667675ms, request: POST:https://10.96.0.1:443/api/v1/namespaces/default/events

external-provisioner 访问 kube-apiserver 触发限流

external-provisioner 有重大嫌疑。

| 定位问题 code-path

函数的调用关系以及采样周期内 CPU 耗时百分比：

来自于 external-provisioner 调用的第三方模块 kubenetes-incubator/external-storage

| 解决问题

external-provisioner 日志中的 throttling 关键字消失

100 PVC 的时间缩短到60秒以内全部创建成功，无任何报错。

| 结语

对于终端用户而言，交互的界面越来越简单，但对于开发者而言，组件越来越多，编译一次的时间越来越久，加上无处不在的并发，导致定位问题的难度越来越大，尤其是性能问题。所以，对体系架构的理解能帮我们快速锁定问题组件，配合 Profile 工具和 Flame Graph 快速定位 code-path，再加上对业务逻辑的理解找到解决方案。

所有的编程人员都是乐观主义者，无论是什么样的程序，结果是勿庸置疑的："这次它肯定会运行。" 或者 "我刚刚找出了最后一个问题。"              ——人月神话

| 作者简介

熊中哲·沃趣科技联合创始人

曾就职于阿里巴巴和百度，超过10年关系型数据库工作经验，目前致力于将云原生技术引入到关系型数据库服务中。