总结自己的容器平台巡检手册,相关敏感信息以及删除
XX集群巡检指导手册
Ver1.0
目录
一. 前言 2
1 文档目的 2
2 适用范围 2
二. 集群信息 2
1 集群架构 2
2 巡检范围 4
3 登录信息 4
4 登录注意事项 5
三. 巡检指导 6
1 脚本路径 6
2 巡检步骤 6
1. 运行巡检脚本 6
2. 检查巡检结果 7
3. prometheus确认告警信息 9
4. Kubectl确认集群状态 14
5. 检查主机状态 15
6. 汇总反馈结果 16
四. 常见问题 17
1 prometheus没有暴露端口导致无法登录 17
2 prometheus中”监控系统心跳监测“的问题 17
3 Namespace资源利用率过高/容器cache内存使用率超过阈值/kubeAPIClient 请求错误率超过阈值 18
4 prometheus告警时间 18
五. 建议 19
前言
文档目的
该文档为实现以下目的:
- 为了指导一线运维工程师对XX数据中心XX容器云集群进行日常巡检
- 提供需要进行巡检的常用信息,必要步骤
- 提供在巡检过程中碰到的一般问题的解决办法
- 归纳总结在巡检过程中产生的问题
- 对巡检工作持续改进
适用范围
该文档适用XX数据中心。
集群信息
集群架构
容器平台部署架构
global集群:XX容器云的统一管控及全局服务层。一个管控层部署一套global。
业务集群:应用容器资源池集群。
集群中的节点说明:
集群 | 节点 | 说明 |
global | publisher | 为全局服务节点,不属于K8s集群。 主要安装harbor,为所有业务集群提供镜像仓库、鉴权认证等服务。 |
controller | 统一管控节点,属于K8s集群。 主要安装portal,用于管控所有集群。 | |
业务集群 | master | 管理节点,属于K8s集群。 主要负责承接global的业务请求、调度pod。 |
node | 业务节点,属于K8s集群。 主要运行pod。 | |
infra | 基础服务节点,属于K8s集群。 主要提供业务集群的监控和日志服务。 | |
repo | 二级镜像节点,不属于K8s集群。 主要安装harbor,为所在业务集群提供镜像仓库、鉴权认证等服务,分担publisher镜像业务。 |
巡检范围
涉及稻香湖集团域,南湖XX域,南湖集团域,南湖私有云范围部署的集群,包括人工智能、大数据、边缘计算。稻香湖XX域,信创云,南湖子公司域global层
登录信息
巡检工作主要是在global层的publihser节点进行,巡检脚本部署在该节点上。
publisher节点登录信息如下:
类别 | 集群 | 角色 | 主机名 | ip |
稻香湖集团域 | gbd0mg1 | publisher | d010mwpubap0001 | |
d010mwpubap0002 | ||||
d010mwpubap0003 | ||||
南湖XX域 | cwn1mg1 | publisher | n110mypubap1001 | |
n110mypubap1002 | ||||
n110mypubap1003 | ||||
南湖集团域 | gwn1mg1 | publisher | n110mgpubap0001 | |
n110mgpubap0002 | ||||
n110mgpubap0003 | ||||
南湖私有云 | pwn1mg1 | publisher | wn10mppubap1001 | |
wn10mppubap2001 | ||||
wn10mppubap3001 |
说明:登录任意一个publisher节点即可进行巡检,常用节点表中标黄显示
关于登录信息,详细请查阅云文档上的信息。
- Prometheus在集群的node节点,部署了prometheus容器,配合node_exporter和alertmanager,实现集群的状态监控、告警等功能。部署namespace为monitoring ,使用nodeport方式暴露,暴露端口30090,访问方式http://nodeip:30090,只能通过windows堡垒机从web访问。
- Grafana
在集群的node节点,部署了grafana容器,通过对接prometheus,使用自定义dashboard,实现集群的图形化性能监控。部署namespace为monitoring ,使用nodeport方式暴露,暴露端口30100,访问方式http://nodeip:30100,只能通过windows堡垒机从web访问。默认登录账号密码admin xxxxx, 。
- windows堡垒机windows堡垒机,可以登录任意集群,任意节点,在巡检过程中,主要作用是登录查看集群的告警状态,性能图表等信息。
信息如下:
地址 | 用户名 |
XXX | xxxx |
- Ansible
在master节点部署了ansible,实现批量自动化运维。/etc/ansible/hosts文件,定义了对应的所有主机,可以在master节点实现对node节点和其他节点进行批量管理。
登录注意事项
- 使用root登录主机的时候,输入TMOUT=3600,避免超时导致终端退出;
- 完成巡检后,需要尽快退出终端,退出SOM。
巡检指导
脚本路径
巡检工作,主要通过在publisher节点执行巡检脚本来执行。
巡检脚本路径:
/home/backupfile/tmp/healthecheck/healthcheck/start_health_check.sh
脚本输出结果路径:
/tmp/kaiyang_health_check.tmp_${日期}
如下所示:
每次执行后,输出结果都会被清理。
巡检步骤
整体巡检过程及步骤:
运行巡检脚本->检查巡检结果->prometheus确认告警信息->kubectl确认集群状态->检查主机状态->汇总反馈问题。
运行巡检脚本
切换到脚本路径,按照如下方式执行脚本
bash start_health_check.sh
执行过程如下:
说明:
- 只有start_health_check.sh才是主程序,路径下的其他脚本文件作为调用
- 脚本执行大致逻辑,通过ansible批量检查集群主机状态;调用prometheus监控页面,检测是否有告警信息;汇总输出
检查巡检结果
脚本执行完成后,用vim打开巡检结果文件
vim /tmp/kaiyang_health_check.tmp_${日期}
结果如下所示:
在巡检结果中,包含了以下信息:
(1)etcd备份检查结果
检查名称:etcd备份检查 | 检查报错:etcdbackupstatusis ERROR,please check |
操作权限:root | |
操作步骤:
|
(2)集群pod状态检查结果
检查名称:pod状态检查 | 检查报错:master节点unhealthy_pod_num is 2(>1,1显示标题行) master节点unhealthy_pod_num is 1;master节点 所在集群无异常状态容器,属于正常 |
操作权限:root | |
操作步骤: 1)登录对应master节点 2)执行kubectlget–all-namespace|grep –v “Running” 3)查看非正常pod报错原因,若是应用pod,联系应用处理 |
Pod是会消亡,或者重启的,虽然promethes会自动发现pod,自动监控,但是难免出现误报或者不准的情况,同时我们也需要登录到集群中查看相关信息,因此需要登录集群,使用kubectl工具检查。
例如,在巡检结果中,发现”10.241.32.11“出现有unhealthy的pod,此时登录相应异常节点上查看集群状态。
以下是kubectl常用检查命令:
kubectl get nodes
kubectl get service
kubectl get deploy
kubectl get pods
kubectl get pods --namespace=xxx
kubectl get pods --namespace=kube-system
kubectl get pods --all-namespaces -o wide
kubectl describe pod <pod-name>
kubectl describe deployment/<deployment-name>
kubectl describe replicaset/<replicaset-name>
kubectl logs <pod-name>
kubectl logs <pod-name> --previous
关于kubectl详细指使用,请自行查阅相关资料。
针对pod运行状态,使用如下指令快速检查
kubectl get -A | grep -v “Running”检查不处于Running状态的pod
(检查pod)
可以看到部分pod存在异常。
检查node状态:
Kubectl get node -o wide
(检查node状态)
可以看到有node节点处于notready状态,原因可能是服务器故障。
关于k8s的故障排查,请自行查阅相关资料
- 主机磁盘空间检查结果
- 检查的集群的主机和主机名
巡检结果需要仔细查看,尽量不要遗漏异常结果。
(3)开始prometheus alert检查
报错信息:master节点 所在集群prometheus alert异常,请手动检查
主要报错主要体现在:
a.监控系统心跳检测 | 查看该告警项目,显示正常,可以暂时无视 |
b.Daemonset下有未成功启动的容器 | 登录集群master节点检查 |
c.POD中有容器非ready状态 | 登录集群master节点检查 |
d.POD状态异常 | 登录集群master节点检查 |
e.容器CACHE内存使用率超过阈值 | 巡检过程中,出现以上告警,可以暂时无视。产生原因是需求方/容器云租户消耗过多集群资源导致,暂时不算做异常 |
f.容器CPU使用率高 | 巡检过程中,出现以上告警,可以暂时无视。产生原因是需求方/容器云租户消耗过多集群资源导致,暂时不算做异常 |
g.容器内存使用率高 | 巡检过程中,出现以上告警,可以暂时无视。产生原因是需求方/容器云租户消耗过多集群资源导致,暂时不算做异常 |
h.KubeAPIClient请求错误率超过阈值 | 巡检过程中,出现以上告警,可以暂时无视。产生原因是需求方/容器云租户消耗过多集群资源导致,暂时不算做异常 |
巡检结果只是汇总信息,具体的检查告警信息需要登录prometheus的alert进行查看。
例如,在检查结果中,发现”10.241.32.11”这台主机异常项目较多,需要登录prometheus确认告警信息,则按照如下进行:
登录windows堡垒机->浏览器输入”http://10.241.32.11:30090”->点击Alerts
(prometheus登录页面)
(prometheus的alert页面)
基本上prometheus上的告警信息与巡检结果输出应该是一致的。
说明:
- 在promethues alert页面上,绿色代表没有触发告警或者是告警恢复,红色代表有告警触发
- alert显示了各种告警项目,基本涵盖了集群监控的大部分指标阈值
- alert是依赖的prometheus的监控指标和设定的阈值表达式实现的
- alert告警流程是触发阈值->超出持续实现->分组|抑制|静默
- alert没有配置告警发送,没有对接行内的告警平台,所以prometheus alert的告警信息不会发送行内
- promethues的告警和指标一般都是事先定义好的,一般无需更改
- alert信息说明
(alert告警信息)
Alert :告警规则的名称
Expr: 基于PromQL表达式告警触发条件,用于计算是否有时间序列满足该条件。
For: 告警持续时间
Labels: 自定义标签,允许用户指定要附加到告警上的一组附加标签。
Stat:告警状态,有三种,分别是Inactive,Pending,Firing.
关于stat告警状态:
- Inactive: 非活动的,表示正在监控,但是还未有任何警报触发
- Pending: 表示这个警报必须被触发。由于告警可以被分组,压抑或者静默,所以等待验证,一旦所有的验证都通过,则将会被转到Firing状态。
- Firing: 将告警发送到alertmanager,它将按照配置将警报的发送给所有的接收者。一旦告警接触,则将状态转到Inactive,如此循环。
- 表达式查看在alert触发的告警中,定义了指标项目和监控表达式,在graph界面可以对指标进行查看,同时支持查看区间以及历史数据。
(graph界面查看监控数据)
(通过表达式查看图形数据)
在巡检过程中,不必详细查看每个指标的图形,建议是在出现性能问题或者排查故障的时候才进行。
关于prometheus表达式,和详细使用配置,请自行查阅相关资料。
- Targetsprometheus的监控指标,依靠targets。如果targets不工作,或者异常,会导致监控信息不准确,所以也需要关注下。
(图targets页面)
- grafana查看
可以登录grafana查看集群资源性能监控图表,方便故障排查和诊断。
(grafana资源监控)
(4)检查主机状态
巡检脚本主要会检查主机磁盘空间利用率,超过80%则会显示出来。
磁盘空间利用率需要重点关注,造成磁盘使用率高的原因基本上容器数据或者日志占满/var/lib/docker/ 目录导致,一般是node节点才会出现该问题。
发现集群主机磁盘空间利用率高后,登录到主机检查,如下所示:
df -h 查看硬盘空间
du -sh /var/lib/docker/ #查看docker目录使用的空间
在确认磁盘后,可以通过如下命令检查docker中pod的空间使用情况
docker system df #检查空间使用
docker ps -a --format “table {{.Size}}\t{{.Names}} #检查pod的空间情况
(pod空间占用情况)
通过查看pod空间占用情况,可以查出是那个容器在占用大量磁盘空间。
汇总反馈结果
完成检查后,将巡检结果记录,通知相关人员。
常见问题
在巡检过程中,会碰到一些困难和问题,需要记录总结。以下是部分问题和解决办法。
prometheus没有暴露端口导致无法登录
在新建集群中肯能会出现prometheus没有配置完全或者没有使用nodeport方式暴露,导致无法登录.
查看svc,确认是否配置nodeport
Kubectl get svc -A
如果没有配置,需要安排变更,配置services由ClusterIP改为NodePort 30090
prometheus中”监控系统心跳监测“的问题
查看该告警项目,显示正常。
此告警可以暂时无视,不算异常。
Namespace资源利用率过高/容器cache内存使用率超过阈值/kubeAPIClient 请求错误率超过阈值
巡检过程中,出现以上告警,可以暂时无视。产生原因是需求方/容器云租户消耗过多集群资源导致,暂时不算做异常。
prometheus告警时间
查看告警的时候,例如显示pod异常重启或者未正常启动,但是通过kubectl 检查未发现异常pod。同时发现告警时间发生在一个月或者一年之前,告警并未恢复,如下所示:
(告警发生时间是一年之前)
产生该问题的原因可能是:
- 告警已经消失了,pod已经正常,但是alert上告警没有恢复,一直处于一种hang的状态。
- 在巡检的过程中,确实存在pod重启,或者消亡,因此记录了告警,但是巡检完成后pod状态又处于正常
- 部分pod有初始化容器,在pod启动之后停止退出了,处于complete状态,同时部分job类型的pod在完成启动就退出,也会处于complete状态,alert算作pod异常;
出现这样的问题后,需要认证核实集群中pod的实际运行状态。关于告警hang住而没有恢复的情况,暂时无视。需要重点关注alert出现时间点在巡检时间段一周内告警项。
建议
巡检工作需要持续改进。针对没有检查到的地方需要增加检查项,误报的地方需要修改检查项逻辑,同时,争取自动化巡检,提高效率。基于以上几点,针对巡检工作有着如下建议:
- 完善巡检脚本功能
- 发现并修改巡检脚本逻辑错误
- 采用计划任务定时执行,将巡检结果自动集中保存
- 针对巡检结果,自动生成简单的巡检报表
- 优化prometheus告警,解决告警hang住没有恢复的问题,优化告警表达式,使得告警更加准确