0
点赞
收藏
分享

微信扫一扫

云计算-容器平台巡检

gy2006_sw 03-09 22:01 阅读 2

总结自己的容器平台巡检手册,相关敏感信息以及删除

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


前言

文档目的

该文档为实现以下目的:


  1. 为了指导一线运维工程师对XX数据中心XX容器云集群进行日常巡检
  2. 提供需要进行巡检的常用信息,必要步骤
  3. 提供在巡检过程中碰到的一般问题的解决办法
  4. 归纳总结在巡检过程中产生的问题
  5. 对巡检工作持续改进


适用范围

该文档适用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节点和其他节点进行批量管理。

登录注意事项

  1. 使用root登录主机的时候,输入TMOUT=3600,避免超时导致终端退出;
  2. 完成巡检后,需要尽快退出终端,退出SOM。



巡检指导

脚本路径

巡检工作,主要通过在publisher节点执行巡检脚本来执行。

巡检脚本路径:

/home/backupfile/tmp/healthecheck/healthcheck/start_health_check.sh

脚本输出结果路径:

/tmp/kaiyang_health_check.tmp_${日期}

如下所示:

云计算-容器平台巡检_容器云_02


每次执行后,输出结果都会被清理。

巡检步骤

整体巡检过程及步骤:

运行巡检脚本->检查巡检结果->prometheus确认告警信息->kubectl确认集群状态->检查主机状态->汇总反馈问题。


运行巡检脚本

切换到脚本路径,按照如下方式执行脚本

bash start_health_check.sh

执行过程如下:

云计算-容器平台巡检_容器云_03



说明:

  1. 只有start_health_check.sh才是主程序,路径下的其他脚本文件作为调用
  2. 脚本执行大致逻辑,通过ansible批量检查集群主机状态;调用prometheus监控页面,检测是否有告警信息;汇总输出

检查巡检结果

脚本执行完成后,用vim打开巡检结果文件

vim /tmp/kaiyang_health_check.tmp_${日期}

结果如下所示:

云计算-容器平台巡检_容器云_04



云计算-容器平台巡检_堡垒机_05


在巡检结果中,包含了以下信息:

(1)etcd备份检查结果

检查名称:etcd备份检查

检查报错:etcdbackupstatusis ERROR,please check

操作权限:root

操作步骤:

  1. vim /tmp/kaiyang_health_check.tmp_${日期}报错集群名称 etcdbackupfilenumtoday is 0
  2. 登录publisher节点,ls –la /alcorharboretcdbackup/ 是否有集群备份文件,若没有,则后期变更实施备份
(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

云计算-容器平台巡检_docker_06


(检查pod)

可以看到部分pod存在异常。

检查node状态:

Kubectl get node -o wide

云计算-容器平台巡检_堡垒机_07


(检查node状态)

可以看到有node节点处于notready状态,原因可能是服务器故障。

关于k8s的故障排查,请自行查阅相关资料


  1. 主机磁盘空间检查结果
  2. 检查的集群的主机和主机名

巡检结果需要仔细查看,尽量不要遗漏异常结果。

(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

云计算-容器平台巡检_docker_08


(prometheus登录页面)


云计算-容器平台巡检_堡垒机_09


(prometheus的alert页面)

基本上prometheus上的告警信息与巡检结果输出应该是一致的。

说明:

  1. 在promethues alert页面上,绿色代表没有触发告警或者是告警恢复,红色代表有告警触发
  2. alert显示了各种告警项目,基本涵盖了集群监控的大部分指标阈值
  3. alert是依赖的prometheus的监控指标和设定的阈值表达式实现的
  4. alert告警流程是触发阈值->超出持续实现->分组|抑制|静默
  5. alert没有配置告警发送,没有对接行内的告警平台,所以prometheus alert的告警信息不会发送行内
  6. promethues的告警和指标一般都是事先定义好的,一般无需更改


  • alert信息说明

云计算-容器平台巡检_容器云_10


(alert告警信息)

Alert :告警规则的名称

Expr: 基于PromQL表达式告警触发条件,用于计算是否有时间序列满足该条件。

For: 告警持续时间

Labels: 自定义标签,允许用户指定要附加到告警上的一组附加标签。

Stat:告警状态,有三种,分别是Inactive,Pending,Firing.

关于stat告警状态:

  1. Inactive: 非活动的,表示正在监控,但是还未有任何警报触发
  2. Pending: 表示这个警报必须被触发。由于告警可以被分组,压抑或者静默,所以等待验证,一旦所有的验证都通过,则将会被转到Firing状态。
  3. Firing: 将告警发送到alertmanager,它将按照配置将警报的发送给所有的接收者。一旦告警接触,则将状态转到Inactive,如此循环。


  • 表达式查看在alert触发的告警中,定义了指标项目和监控表达式,在graph界面可以对指标进行查看,同时支持查看区间以及历史数据。

(graph界面查看监控数据)

云计算-容器平台巡检_docker_11


(通过表达式查看图形数据)

在巡检过程中,不必详细查看每个指标的图形,建议是在出现性能问题或者排查故障的时候才进行。

关于prometheus表达式,和详细使用配置,请自行查阅相关资料。

  • Targetsprometheus的监控指标,依靠targets。如果targets不工作,或者异常,会导致监控信息不准确,所以也需要关注下。

(图targets页面)

  • grafana查看

可以登录grafana查看集群资源性能监控图表,方便故障排查和诊断。


云计算-容器平台巡检_容器云_12


(grafana资源监控)



(4)检查主机状态

巡检脚本主要会检查主机磁盘空间利用率,超过80%则会显示出来。

云计算-容器平台巡检_堡垒机_13



磁盘空间利用率需要重点关注,造成磁盘使用率高的原因基本上容器数据或者日志占满/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的空间情况


云计算-容器平台巡检_堡垒机_14


(pod空间占用情况)

通过查看pod空间占用情况,可以查出是那个容器在占用大量磁盘空间。


汇总反馈结果

完成检查后,将巡检结果记录,通知相关人员。


常见问题

在巡检过程中,会碰到一些困难和问题,需要记录总结。以下是部分问题和解决办法。

prometheus没有暴露端口导致无法登录

在新建集群中肯能会出现prometheus没有配置完全或者没有使用nodeport方式暴露,导致无法登录.

查看svc,确认是否配置nodeport

Kubectl get svc -A

云计算-容器平台巡检_docker_15



如果没有配置,需要安排变更,配置services由ClusterIP改为NodePort 30090


prometheus中”监控系统心跳监测“的问题

查看该告警项目,显示正常。


云计算-容器平台巡检_docker_16



此告警可以暂时无视,不算异常。


Namespace资源利用率过高/容器cache内存使用率超过阈值/kubeAPIClient 请求错误率超过阈值

巡检过程中,出现以上告警,可以暂时无视。产生原因是需求方/容器云租户消耗过多集群资源导致,暂时不算做异常。


prometheus告警时间

查看告警的时候,例如显示pod异常重启或者未正常启动,但是通过kubectl 检查未发现异常pod。同时发现告警时间发生在一个月或者一年之前,告警并未恢复,如下所示:


云计算-容器平台巡检_容器云_17


(告警发生时间是一年之前)

产生该问题的原因可能是:

  1. 告警已经消失了,pod已经正常,但是alert上告警没有恢复,一直处于一种hang的状态。
  2. 在巡检的过程中,确实存在pod重启,或者消亡,因此记录了告警,但是巡检完成后pod状态又处于正常
  3. 部分pod有初始化容器,在pod启动之后停止退出了,处于complete状态,同时部分job类型的pod在完成启动就退出,也会处于complete状态,alert算作pod异常;


出现这样的问题后,需要认证核实集群中pod的实际运行状态。关于告警hang住而没有恢复的情况,暂时无视。需要重点关注alert出现时间点在巡检时间段一周内告警项。


建议

巡检工作需要持续改进。针对没有检查到的地方需要增加检查项,误报的地方需要修改检查项逻辑,同时,争取自动化巡检,提高效率。基于以上几点,针对巡检工作有着如下建议:

  1. 完善巡检脚本功能
  2. 发现并修改巡检脚本逻辑错误
  3. 采用计划任务定时执行,将巡检结果自动集中保存
  4. 针对巡检结果,自动生成简单的巡检报表
  5. 优化prometheus告警,解决告警hang住没有恢复的问题,优化告警表达式,使得告警更加准确
举报

相关推荐

0 条评论