云原生|kubernetes|kubernetes集群巡检脚本

简介: 云原生|kubernetes|kubernetes集群巡检脚本

前言:

生产环境下的kubernetes集群安装部署仅仅是前期的一点点工作,主要的工作其实是集中在集群正式运行后的维护,管理工作。

而kubernetes集群的巡视检查工作是一个比较重要的工作,可以通过定时,定期的巡检能够提前发现kubernetes集群的一些潜在问题,从而在发生大的影响运行的问题前发现问题并解决问题。

那么,通常的做法是安装部署监控软件,例如,prometheus,grafana,zabbix这些,但,毫无疑问的,这些监控系统或多或少的会对kubernetes集群有所侵入,并且监控系统也是需要维护的,这些无形中增加了我们的维护工作量。

OK,那么使用shell脚本来对集群做一个最为简单的监控,无疑是一个可行的方案。

对于kubernetes集群来说,我们关注的点应该是以下几点:

1,

kubernetes集群的关键服务,例如,kubelet,kube-scheduel,这些服务是否正常

2,

kubernetes集群的整体资源使用率,例如,所有节点的内存,CPU,这样的关键资源使用了多少,剩余多少

如果某个节点的内存使用率过高,会提示我们是哪个节点,并生成清单文件,按照清单来进行详细的分析,从而保证集群的稳定。

3,

pod的分布,例如,A节点有哪些pod在运行,这些pod运行是否正常

4,

pod的重启次数,该指标是一个关键的指标,在实际的生产中,很多pod可能实时观察的时候是running状态的,但其实这些pod在不停的反复部署,例如,因为某个存活探针的状态不稳定,某些pod需要的内存不足(pod有指定资源配额策略),造成了oom,等等各种原因都会造成pod反复重启(pod重启也就是等于pod重新部署)

因此,我们需要抓取所有pod的重启次数,并提供一个清单,后续手动的按照清单文件内所列的pod,挨个查询重启原因,以此来保证pod的健康,进而保证kubernetes集群的稳定。

基于这些需求,编写了以下的kubernetes巡检脚本

一,

巡检脚本的内容

#!/bin/bash
#!author zsk
#k8s集群日常巡检
if [ -d /opt/xunjian/$(date +'%Y-%m-%d') ];
then
echo "巡检目录已创建,今日巡检内容都存放到此目录/opt/xunjian/下"
else
mkdir -p /opt/xunjian/$(date +'%Y-%m-%d')
echo "/opt/xunjian/ 这个目录刚创建好"
fi
unhealthy=$(kubectl get cs | awk 'NR == 1 {next}{if($2 != "Healthy") print $1}' | wc -l)                                #组件状态异常数
kubeletError=$(systemctl status kubelet.service | grep ^"$(date | awk '{print$2,$3}')" | grep -i error | wc -l)         #kubelet日志报错数
errorPod=$(kubectl get po -A | grep -v NAMESPACE| awk '{if($4 != "Running") print}' | wc -l )                #非runing状态pod数
restartPod=`kubectl get po -A |awk '{if($4>0)print$1,$4}'|grep -v NAME`
#查看controller-manager、scheduler、etcd状态
server_stat=/opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-server.txt
>$server_stat
echo -e "----------Controller-manager、Scheduler、Etcd-0检测中--------------------------------------"
if (( ${unhealthy} >=1 ));then
  echo -e "\033[31m$(kubectl get cs | awk 'NR == 1 {next}{if($2 != "Healthy") print $1}') Unhealthy\033[0m" >$server_stat
else
  echo -e "controller-manager、scheduler、etcd-0无异常">$server_stat
fi
#查看kubelet状态
echo -e "\n \n----------       Kubelet状态检测中       ----------"
if (( ${kubeletError} >=1 ));then
  echo -e "\033[31mkubelet错误日志:\033[0m" ; systemctl status kubelet.service | grep ^"$(date | awk '{print$2,$3}')" |awk '{for (i=10;i<=NF;i++)printf("%s ", $i);print ""}' | grep -i error | sort -n | uniq >> node.txt 2>&1
else
  echo -e "\033[32mkubelet无日志报错\033[0m"
fi
#查看Pods状态
echo -e "\n \n----------      Pods运行状态检测中       ----------"
>/opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-pod.txt
if [ ${errorPod} -gt 1 ];then
  echo -e "异常的pod信息将写入下面的文件内"
  echo -e "\033[31mErrorPod:\033[0m"  && kubectl get po -A | grep -v NAMESPACE | awk '{if($4 != "Running") print}' > /opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-pod.txt
else
  echo -e "所有pod运行状态都是running" > /opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-pod.txt
fi
if [ -n "$restartPod" ];
then
echo -e "以下是有重启的pod,请根据此清单排查pod的重启原因 \n">>/opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-pod.txt
echo -e "$restartPod" >>/opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-pod.txt
else
echo "所有pod没有重启的情况">>/opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-pod.txt
fi
#查看Node资源使用率
check_node(){
echo -e "\n \n----------    Nodes资源使用状态检测中    ----------"
>/opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-memory.txt
>/opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-node.txt
memWarn=0
for i in $(kubectl get nodes | awk 'NR == 1 {next}{print $1}');do
  memRq=$(kubectl describe node $i | grep memory | grep % | awk '{print $3}' | sed "s/[^0-9]//g")       #memory_request
  memLim=$(kubectl describe node $i | grep memory | grep % | awk '{print $5}' | sed "s/[^0-9]//g")      #memory_limit
  cpuUsed=$(kubectl top nodes $i | awk 'NR == 1 {next}{print $3}'| sed "s/[^0-9]//g")                   #cpu使用率
  memUsed=$(kubectl top nodes $i | awk 'NR == 1 {next}{print $5}'| sed "s/[^0-9]//g")                   #内存使用率
  if (( $cpuUsed > 0)) || (( $memUsed > 0 ));then
    let memWarn+=1
    echo -e "$i\tCPU使用率:$cpuUsed%\t内存使用率:$memUsed" >> /opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-node.txt
  fi
  if [ $memUsed -gt  95 ];then
    let memWarn+=1
    echo "|||+++++++++++++++++++++++++++++++++++++++++++|||" >> /opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-memory.txt
    echo -e "$i\t内存使用率超出预期,请检查内存占用率过高的原因!!!"  >> /opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-memory.txt
    echo "|||++++++++++++++++++++++++++++++++++++++++++|||" >> /opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-memory.txt
    echo -e "\n \n \n" >> /opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-memory.txt
    else
    echo -e "$i  该节点的内存在正常范围内" >> /opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-memory.txt
  fi
done
#if (( $memWarn ==0 ));then
#  echo -e "无节点CPU、内存使用异常" >> /opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-memory.txt
#fi
}
check_node
##获取node的详情,记录每个节点内的运行了哪些pod,以及pod的资源使用情况
>/opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-describenode.txt
for e in $(kubectl get node |grep -v NAME|awk '{print $1}')
 do
   kubectl describe node $e >> /opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-describenode.txt 2>&1
   echo -e "\n \n" >>/opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-describenode.txt
   echo "||++++++++++++++++++++++++++++++++++++++这是分隔这是分隔这是分隔这是分隔+++++++++++++||" >>/opt/xunjian/$(date +'%Y-%m-%d')/$(date +'%Y-%m-%d')-describenode.txt
 done
jilu_tar(){
cd /opt/xunjian
tar cvjf  /opt/xunjian.tar.gz /opt/xunjian
echo "打包成功"
}
jilu_tar

二,

巡检脚本的使用的前置条件

1,

需要kubernetes集群内部署有metric-server 插件即可,因为脚本内很多关键数据是通过此插件来查询的

metric-server的部署见我的博客:

云原生|kubernetes|centos7下离线化部署kubesphere-3.3.2---基于kubernetes-1.22.16(从网络插件开始记录)_kubesphere离线部署_晚风_END的博客-

2,

kubernetes集群是以kubeadm方式部署的,etcd集群是内部堆叠形式部署的,因为脚本内的服务检查是通过kubectl get cs命令来检查的

三,

脚本说明

该脚本将会生成5个文件,文件存放路径是/opt/xunjian/当前日期  日期格式为2023-07-12

describe文件保存了所有节点的详细信息

memory文件保存了所有节点内存使用率,如果超出脚本内设定的95,将会提示

node文件保存了当前的节点的资源使用情况,第一列是节点IP,第二列是cpu使用率,第三列是内存使用率

pod文件保存了有过重启的pod的名称和重启次数,如果pod都正常,打印无异常pod

server文件保存了集群的主要服务是否正常,如有异常,将会提示。

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
人工智能 算法 调度
阿里云ACK托管集群Pro版共享GPU调度操作指南
本文介绍在阿里云ACK托管集群Pro版中,如何通过共享GPU调度实现显存与算力的精细化分配,涵盖前提条件、使用限制、节点池配置及任务部署全流程,提升GPU资源利用率,适用于AI训练与推理场景。
999 1
|
弹性计算 监控 调度
ACK One 注册集群云端节点池升级:IDC 集群一键接入云端 GPU 算力,接入效率提升 80%
ACK One注册集群节点池实现“一键接入”,免去手动编写脚本与GPU驱动安装,支持自动扩缩容与多场景调度,大幅提升K8s集群管理效率。
676 89
|
资源调度 Kubernetes 调度
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
ACK One 的多集群应用分发,可以最小成本地结合您已有的单集群 CD 系统,无需对原先应用资源 YAML 进行修改,即可快速构建成多集群的 CD 系统,并同时获得强大的多集群资源调度和分发的能力。
1316 9
|
资源调度 Kubernetes 调度
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
本文介绍如何利用阿里云的分布式云容器平台ACK One的多集群应用分发功能,结合云效CD能力,快速将单集群CD系统升级为多集群CD系统。通过增加分发策略(PropagationPolicy)和差异化策略(OverridePolicy),并修改单集群kubeconfig为舰队kubeconfig,可实现无损改造。该方案具备多地域多集群智能资源调度、重调度及故障迁移等能力,帮助用户提升业务效率与可靠性。
|
Cloud Native 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
|
存储 Kubernetes 监控
K8s集群实战:使用kubeadm和kuboard部署Kubernetes集群
总之,使用kubeadm和kuboard部署K8s集群就像回归童年一样,简单又有趣。不要忘记,技术是为人服务的,用K8s集群操控云端资源,我们不过是想在复杂的世界找寻简单。尽管部署过程可能遇到困难,但朝着简化复杂的目标,我们就能找到意义和乐趣。希望你也能利用这些工具,找到你的乐趣,满足你的需求。
1453 33
|
Cloud Native 关系型数据库 分布式数据库
客户说|知乎基于阿里云PolarDB,实现最大数据库集群云原生升级
近日,知乎最大的风控业务数据库集群,基于阿里云瑶池数据库完成了云原生技术架构的升级。此次升级不仅显著提升了系统的高可用性和性能上限,还大幅降低了底层资源成本。
|
存储 Cloud Native 数据处理
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式
本文整理自阿里云资深技术专家、Apache Flink PMC 成员梅源在 Flink Forward Asia 新加坡 2025上的分享,深入解析 Flink 状态管理系统的发展历程,从核心设计到 Flink 2.0 存算分离架构,并展望未来基于流批一体的通用增量计算方向。
868 0
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式
|
运维 监控 Cloud Native
从本土到全球,云原生架构护航灵犀互娱游戏出海
本文内容整理自「 2025 中企出海大会·游戏与互娱出海分论坛」,灵犀互娱基础架构负责人朱晓靖的演讲内容,从技术层面分享云原生架构护航灵犀互娱游戏出海经验。
1122 15
|
运维 监控 Cloud Native
从本土到全球,云原生架构护航灵犀互娱游戏出海
内容整理自「 2025 中企出海大会·游戏与互娱出海分论坛」,灵犀互娱基础架构负责人朱晓靖的演讲内容,从技术层面分享云原生架构护航灵犀互娱游戏出海经验。

推荐镜像

更多