Kubernetes组件问题排查思路 – 十点运维吧-Linux|Kubernetes|Docker|Prometheus|Python|Golang|云原生|SRE

标签： | 发表时间：2021-08-23 18:36 | 作者：
出处：https://www.coolops.cn

Kubernetes的基础组件就像一栋房子的地基，它们的重要性不言而喻。作为Kubernetes集群的维护者，经常会遇到组件的问题，那平时是怎么去定位解决的呢？

这里简要分析一下我的排查思路。

  • 通过集群的状态，找到故障的节点或者组件
  • 分析组件的日志
  • 使用pprof分析组件的具体性能

确定范围

Kubernetes的基础组件不多，而且部署也非常简单，所以在定义范围的时候还是很容易的，比如我们在使用 kubectl get nodes的时候，如果某个节点的状态是 NotReady，我们脑海中是不是会出现两种可能？
（1）节点的kubelet组件有问题
（2）节点的网络组件有问题

这样一来，大体方向已经确定了，然后就是做排除法了。

这里为何说是排除法？因为在解决问题的途中，我们通常会采用 先假设再验证的方式进行，先把所以可能的因素列出来，然后一个一个的去验证去排除，直到解决问题。

分析日志

日志分析是故障排查最直接的方式，大部分问题都能从日志里体现出来，Kubernetes的组件日志查看方式通常有两种：

  • 通过systemd启动的服务，使用 journalctl -l -u xxxx
  • 使用静态pod启动的服务，使用 kubectl logs -n kube-system $PODNAME --tail 100

当然，很多时候不仅仅是分析它本身的问题，我们还会关注周边的问题，比如基础设施的CPU、内存、IO等情况，这样进行综合考虑来找出问题。

性能分析

为什么把性能分析放到最后呢？

对于大部分人来说，并不擅长，也不喜欢分析组件的性能。第一是时间比较长，第二是要对各个性能指标有一定的了解，第三是学习成本比较大。

众所周知，Kubernetes的版本迭代比较快，基本一年会发2-3个版本，如此快的迭代速度，不排除一些版本中存在BUG，存在一些性能问题。所以在实在没招的情况下，可以尝试对其组件的性能进行分析。

Kubernetes是使用Golang开发，而Golang的pprof是性能分析的利器，提供交互式界面和UI图形化，比较直观，可以很方便的找出问题。除此之外，还可以使用go-torch将profile数据生成火焰图，这样会更直观。

Kubernetes的组件都可以使用 pprof进行性能分析，界面在 host:port/debug/pprof/。

pprof的常用方式

使用交互式命令
  1. 查看堆栈调用信息
              1
 
              go tool pprof http://localhost:8001/debug/pprof/heap
  1. 查看 30 秒内的 CPU 信息
              1
 
              go tool pprof http://localhost:8001/debug/pprof/profile?seconds=30
  1. 查看 goroutine 阻塞
    go tool pprof http://localhost:8001/debug/pprof/block
  1. 收集 5 秒内的执行路径
    go tool pprof http://localhost:8001/debug/pprof/trace?seconds=5
  1. 争用互斥持有者的堆栈跟踪
    go tool pprof http://localhost:8001/debug/pprof/mutex
通过UI界面

UI分析工具使用起来相对比较麻烦，我们需要先导出文件，然后再使用 go tool工具起服务进行分析。

比如我们导出kube-scheduler的堆栈信息。

    curl -sK -v http://localhost:10251/debug/pprof/heap > heap.out

然后使用go tool工具起一个服务，如下：

    go tool pprof -http=0.0.0.0:8989 heap.out

然后就可以在浏览器上看到具体的堆栈信息图了。
image.png
注意，这里需要在服务端安装 graphviz组件，各种操作系统的安装方式见[3]。

UI界面主要的菜单以及其功能简要介绍如下：

  • VIEW：查看模式
    • Top：从高到底排序查看
    • Graph：默认的模式，以关系图形式查看
    • Flame Graph：以火焰图形式查看
    • Peek：排序查看，展示的信息更多
    • Source：排序查看，带源码标注
    • Disassemble：现实所有总量
  • SAMPLE：为VIEW提供查看模式
    • alloc_objects：已分配的对象总量（不管是否已释放
    • alloc_space：已分配的内存总量（不管是否已释放）
    • inuse_objects： 已分配但尚未释放的对象数量
    • inuse_sapce：已分配但尚未释放的内存数量
  • REFINE：提供筛选能力

上面简单介绍了pprof的基本使用方法，下面就Kubernetes的各个组件进行简单的分析，这里只就CPU信息进
行获取以及展示。

注意：由于版本原因，有的版本默认开启了pprof，有的版本则没有，如果没有开启的，需要自行去开启，参数基本都是 profiling: true，具体的信息可以到官网进行查看[4]。

分析kube-apiserver

（1）使用kubectl proxy启动一个代理

              1
 
              kubectl proxy

（2）另起一个终端，获取CPU信息

              1
 
              curl -sK -v  http://localhost:8001/debug/pprof/profile >apiserver-cpu.out

（3）使用go tool工具启动服务

              1
 
              go tool pprof -http=0.0.0.0:8989 apiserver-cpu.out

（4）在浏览器上进行查看
image.png

分析kube-scheduler

（1）获取CPU的信息

              1
 
              curl -sK -v  http://localhost:10251/debug/pprof/profile >scheduler-cpu.out

（2）使用go tool工具启动服务

              1
 
              go tool pprof -http=0.0.0.0:8989 scheduler-cpu.out

（3）在浏览器进行查看
image.png

分析kube-controller-manager

（1）获取CPU的信息

              1
 
              curl -sK -v  http://localhost:10252/debug/pprof/profile >controller-cpu.out

（2）使用go tool工具启动服务

              1
 
              go tool pprof -http=0.0.0.0:8989 controller-cpu.out

（3）在浏览器进行查看
image.png

分析kubelet

（1）使用kubectl proxy启动一个代理

              1
 
              kubectl proxy

（2）另起一个终端，获取CPU信息

              1
 
              curl -sK -v  http://127.0.0.1:8001/api/v1/nodes/k8s-node04-138/proxy/debug/pprof/profile >kubelet-cpu.out

（3）使用go tool工具启动服务

              1
 
              go tool pprof -http=0.0.0.0:8989 kubelet-cpu.out

（4）在浏览器上进行查看
image.png

能够抓到具体的性能数据才是第一步，后续的具体分析才会帮助我们找到问题。

文档

相关 [kubernetes 问题 运维] 推荐：

Kubernetes组件问题排查思路 – 十点运维吧-Linux|Kubernetes|Docker|Prometheus|Python|Golang|云原生|SRE

- -
Kubernetes的基础组件就像一栋房子的地基，它们的重要性不言而喻. 作为Kubernetes集群的维护者，经常会遇到组件的问题，那平时是怎么去定位解决的呢. 这里简要分析一下我的排查思路. 通过集群的状态，找到故障的节点或者组件. 使用pprof分析组件的具体性能. Kubernetes的基础组件不多，而且部署也非常简单，所以在定义范围的时候还是很容易的，比如我们在使用.

如何进行kubernetes问题的排障

- - Xinkun Blog
k8s的成熟度很高，伴随着整个项目的扩增，以及新功能和新流程的不断引入，也伴随这产生了一些问题. 虽然自动化测试可以排除掉大部分，但是一些复杂流程以及极端情况却很难做到bug的完全覆盖. 因此在实际的工作过程中，需要对运行的集群进行故障定位和解决. 当然，进行排障的前提是对于k8s的流程和概念进行掌握，对于源码有一定的掌握能力，才可以更好的进行.

如何进行Kubernetes问题的排障

- - DockOne.io
Kubernetes的成熟度很高，伴随着整个项目的扩增，以及新功能和新流程的不断引入，也伴随着产生了一些问题. 虽然自动化测试可以排除掉大部分，但是一些复杂流程以及极端情况却很难做到bug的完全覆盖. 因此在实际的工作过程中，需要对运行的集群进行故障定位和解决. 当然，进行排障的前提是对于Kubernetes的流程和概念进行掌握，对于源码有一定的掌握能力，才可以更好的进行.

Kubernetes学习笔记之kube-proxy service实现原理 – 运维派

- -
我们生产k8s对外暴露服务有多种方式，其中一种使用. external-ips clusterip service ClusterIP Service方式对外暴露服务，kube-proxy使用iptables mode. 这样external ips可以指定固定几台worker节点的IP地址(worker节点服务已经被驱逐，作为流量转发节点不作为计算节点)，并作为lvs vip下的rs来负载均衡.

Kubernetes的负载均衡问题(Nginx Ingress) - ericnie - 博客园

- -
Kubernetes关于服务的暴露主要是通过NodePort方式，通过绑定minion主机的某个端口,然后进行pod的请求转发和负载均衡，但这种方式下缺陷是. Service可能有很多个，如果每个都绑定一个node主机端口的话，主机需要开放外围一堆的端口进行服务调用，管理混乱. 无法应用很多公司要求的防火墙规则.

调试Kubernetes集群中的网络停顿问题

- - DockOne.io
我们曾经在这里中聊起过Kubernetes ( Kubernetes at GitHub : https://github.blog/2017-08-16. ithub/)，在过去几年，Kubernetes在Github已经成为标准的部署模式. 目前在Github，我们在Kubernetes上运行着海量的面向内部团队以及面向C端的服务.

kubernetes核心组件kube-proxy - 运维笔记 - 散尽浮华 - 博客园

- -
一.  kube-proxy 和 service . kube-proxy是Kubernetes的核心组件，部署在每个Node节点上，它是实现Kubernetes Service的通信与负载均衡机制的重要组件; kube-proxy负责为Pod创建代理服务，从apiserver获取所有server信息，并根据server信息创建代理服务，实现server到Pod的请求路由和转发，从而实现K8s层级的虚拟转发网络.

Kubernetes & Microservice

- - 午夜咖啡
这是前一段时间在一个微服务的 meetup 上的分享，整理成文章发布出来. 谈微服务之前，先澄清一下概念. 微服务这个词的准确定义很难，不同的人有不同的人的看法. 比如一个朋友是『微服务原教旨主义者』，坚持微服务一定是无状态的 http API 服务，其他的都是『邪魔歪道』，它和 SOA，RPC，分布式系统之间有明显的分界.

Kubernetes学习(Kubernetes踩坑记)

- - Z.S.K.'s Records
记录在使用Kubernetes中遇到的各种问题及解决方案, 好记性不如烂笔头. prometheus提示 /metrics/resource/v1alpha1 404. 原因: 这是因为[/metrics/resource/v1alpha1]是在v1.14中才新增的特性，而当前kubelet版本为1.13.

在阿里巴巴，我们如何先于用户发现和定位 Kubernetes 集群问题？

- - IT瘾-dev
 作者：彭南光(光南). 本文整理自阿里云高级研发工程师彭南光(光南) 在 KubeCon China 2021 大会的演讲实录，分享了阿里巴巴是如何通过自研通用链路探测+定向巡检工具 KubeProbe 应对大规模集群的稳定性挑战的. 关于阿里云云原生团队在本次 KubeCon 上分享的全部内容沉淀于电子书《云原生与云未来的新可能》当中，可点击文末“阅读原文”下载.