Kubernetes 应用问题的通用排查思维
发布时间：2021-12-07 12:41:29 所属栏目：云计算 来源：互联网
导读：本片文章介绍下 Kubernetes 应用问题的通用排查思路，分享一个线上此类问题的排查案例，总结下背后的相关知识，以飨读者，大家共勉！ 1 技术趋势大背景 我们知道，大数据进一步发展的一个趋势，就是大数据和云计算进一步融合（包括在底层更加青睐存储计算分离
|
本片文章介绍下 Kubernetes 应用问题的通用排查思路，分享一个线上此类问题的排查案例，总结下背后的相关知识，以飨读者，大家共勉！ 1 技术趋势大背景 我们知道，大数据进一步发展的一个趋势，就是大数据和云计算进一步融合（包括在底层更加青睐存储计算分离的架构，在底层更加青睐对象存储），在部署架构上支持混合云和多云场景，拥抱云计算走向云原生化。 对应到底层具体技术堆栈上，体现在各个主流大数据平台和底层的大数据组件，纷纷开始支持以 Kubernetes 和 Docker 为代表的容器系列技术栈。 所以大数据从业者，需要不断扩展自己的技能包，掌握 Kubernetes 和 Docker 的基础知识和常见命令，才能在排查大数据相关问题时不至于捉襟见肘，因技能储备短缺，无从下手。 从技术视角看大数据行业的发展趋势 在此分享一个大数据平台中 docker 容器相关故障的排查案列，并介绍下此类问题的背后知识和排查思路，以飨读者，大家共勉！ 2 问题现象 星环大数据平台 TDH 中， zookeeper 服务无法正常启动。我们知道 TDH 中，各个服务其实是在 k8s 的管控下运行于 docker 容器中，通过 kubectl get pods -owide |grep -i zoo 可以发现，对应的 pod 的状态是CrashLoopBackOff，如下图所示: pod-CrashLoopBackOff 3 背后知识：什么是 CrashLoopBackOff? 某个 pod 处于 CrashloopBackOff， 意味着该 pod 中的容器被启动了，然后崩溃了，接下来又被自动启动了，但又崩溃了，如此周而复始，陷入了（starting, crashing, starting，crashing）的循坏. 注意：pod 中的容器之所以会被自动重启，其实是通过 PodSpec 中的 restartPolicy 指定的，该配置项默认是 Always，即失败后会自动重启： A PodSpec has a restartPolicy field with possible values Always, OnFailure, and Never which applies to all containers in a pod， the default value is Always; The restartPolicy only refers to restarts of the containers by the kubelet on the same node (so the restart count will reset if the pod is rescheduled in a different node). Failed containers that are restarted by the kubelet are restarted with an exponential back-off delay (10s, 20s, 40s …) capped at five minutes, and is reset after ten minutes of successful execution. 4 背后知识：为什么会发生 CrashLoopBackOff 错误？ pod 的 CrashLoopBackOff 错误还是挺常见的，该错误可能会因为多种原因被触发，几个主要的上层原因有： Kubernetes 集群部署有问题; 该 pod 或 pod 底层的 container 的某些参数被配置错了； 该 pod 内部的 container 中运行的应用程序，在多次重启运行时都一直处于失败状态； 5 背后知识：如何排查 pod 容器底层的应用程序的故障? 当 pod 容器底层的应用程序运行出现故障时，通用的排查思路，一般是： 步骤一：通过命令 kubectl describe pod xxx 获取 pod 详细信息 步骤二：通过命令 kubectl logs xxx 查看 pod 容器底层的应用程序的日志 步骤三：进一步获取并查看 pod 容器底层的应用程序的其它日志文件，深挖问题原因 有的小伙伴可能会有疑问，上述步骤二和步骤三都是查看 pod 容器底层的应用程序的日志，有什么区别呢？ 其实步骤二和步骤三在底层查看的是应用程序的不同的日志文件，其底层细节跟 kubernetes 的日志机制，以及该 pod 底层的应用程序将日志写向何处有关： kubectl logs 展示的是 pod 底层的 container 的标准输出 stdout 和标准错误 stderr 的日志； 应用程序写到其它文件的日志，kubectl logs 展示不了，需要获取日志文件路径，并自行查看； k8s 建议应用程序将日志写到 container 的标准输出 stdout 和标准错误 stderr； 容器内的应用程序可以将日志直接写到 container 的标准输出 stdout 和标准错误 stderr； 如果容器内的应用程序不能或不方便将日志直接写到 container 的标准输出 stdout 和标准错误 stderr，可以使用 sidecar 即边车模式，在应用程序的 container 所在的 pod 内部署另一个 sidecar container，该 sidecar container 负责读取应用程序的日志文件并输出到其标准输出 stdout 和标准错误 stderr 里； k8s 在底层会通过运行在各个节点的 kubelet 来收集节点中所有 container 的 stdout 和 stderr 日志，并写到一个 kubelet 管理的本地文件中； 用户执行 kubectl logs xx 命令时，该命令在底层会调用该 container 对应节点上的 kubelet 来检索其管理的本地日志文件，以获取日志; 用户使用 kubectl log xxx 来检索应用程序日志，省去了用户登录 k8s 集群中对应节点查看对应日志的繁琐操作，提供了很大遍历； ps. 我们这里讨论的是运行在 k8s 容器中的应用程序的日志，除了应用程序的日志，其实整个k8s 集群中还有很多系统组件的日志，如：docker，kubelet，kube-proxy，kube-apiserver，kube-scheduler，etcd等。 （编辑：随州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
