Circonus最近对Kubernetes运营商进行的一项调查中,收集哪些健康状况指标是运营商面临的最大挑战之一。考虑到Kubernetes每天可以生成数百万个指标,这不足为奇。
在本文中,我们将分享哪些健康指标对于Kubernetes运营商最关键。
一、资源和利用率指标
资源和利用率指标来自内置的metrics API,由Kubelets本身提供。大多数时候,我们仅将CPU使用情况用作健康状况的指标,但是监视内存使用情况和网络流量也很重要。
指标
|
名称
|
描述
|
CPU使用率
|
usageNanoCores
|
节点或Pod每秒使用的CPU核数。
|
CPU容量
|
capacity_cpu
|
节点上可用的CPU内核数量(不适用于Pod)。
|
内存使用情况
|
used{resource:memory,units:bytes}
|
节点或Pod使用的内存量(以字节为单位)。
|
内存容量
|
capacity_memory{units:bytes}
|
节点可用的内存容量(不适用于Pod),以字节为单位。
|
网络流量
|
rx{resource:network,units:bytes} tx{resource:network,units:bytes}
|
节点(或Pod)看到的总网络流量(已接收(传入)流量和已传输(传出)流量),以字节为单位。
|
CPU使用率是重要的健康状况指标,这是最容易理解的:你应该跟踪节点正在使用多少CPU。原因有两个。首先,你不希望耗尽应用程序的处理资源,如果你的应用程序受到CPU的限制,则需要增加CPU分配或向集群添加更多节点。其次,你不希望CPU闲置在那里。
二、状态指标
kube-state-metrics是一个组件,可提供有关集群对象(node,pod,DaemonSet,namespaces等)状态的数据。
指标
|
名称
|
描述
|
节点状态
|
kube_node_status_condition {status:true,condition:OutOfDisk| MemoryPressure|PIDPressure| DiskPressure|NetworkUnavailable}
|
当status为true时,指示该节点当前正在经历该条件。
|
循环崩溃(Crash Loops)
|
kube_pod_container_status_waiting_reason {reason:CrashLoopBackOff}
|
指示pod中的容器是否正在发生循环崩溃。
|
任务状态(失败)
|
kube_job_status_failed
|
指示任务是否失败。
|
持久卷状态(失败)
|
kube_persistentvolume_status _phase {phase:Failed}
|
指示持久卷是否失败。
|
Pod状态(Pending)
|
kube_pod_status_phase{phase:Pending}
|
指示Pod是否处于挂起状态。
|
Deployment
|
kube_deployment_metadata _generation
|
代表Deployment的序列号。
|
Deployment
|
kube_deployment_status_observed_generation
|
代表控制器观察到的当前Deployment生成的序列号。
|
DaemonSet期望的节点数
|
kube_daemonset_status_ desired_number_scheduled
|
DaemonSet期望的节点数。
|
DaemonSet当前的节点数
|
kube_daemonset_status_ current_number_scheduled
|
DaemonSet运行中的节点数。
|
期望的StatefulSet副本
|
kube_statefulset_status_replicas
|
每个StatefulSet期望的副本数。
|
准备就绪的StatefulSet副本
|
kube_statefulset_status_replicas _ready
|
每个StatefulSet准备好的副本数。
|
使用这些度量标准,你应该对以下指标监视并发出警报:崩溃循环,磁盘压力,内存压力,PID压力,网络不可用,任务失败,持久卷失败,Pod挂起,Deployment故障,DaemonSets未准备好和StatefulSets未准备好。
三、控制平面指标
Kubernetes控制平面包含Kubernetes的“系统组件”,可以帮助进行集群管理。在Google或Amazon提供的托管环境中,控制平面由云提供商管理,你通常不必担心监视这些指标。但是,如果你管理自己的集群,则需要了解如何监视控制平面。
指标
|
名称
|
描述
|
etcd领导者
|
etcd_server_has_leader
|
指示该成员是否知道其领导者是谁。
|
etcd领导者变动
|
etcd_server_leader_changes_ seen_total
|
etcd集群中领导者变更总数。
|
API延迟数
|
apiserver_request_latencies_count
|
API请求总数;用于计算每个请求的平均延迟。
|
API延迟总和
|
apiserver_request_latencies_sum
|
所有API请求持续时间的总和;用于计算每个请求的平均延迟。
|
队列等待时间
|
workqueue_queue_duration_ seconds
|
每个控制器管理器中的工作队列等待所花费的总时间。
|
队列持续时间
|
workqueue_work_duration_ seconds
|
每个控制器管理器中的工作队列处理操作所花费的总时间。
|
调度失败Pod的总尝试次数
|
scheduler_schedule_attempts _total {result:unschedulable}
|
调度程序尝试在节点上调度失败了Pod的总尝试次数。
|
Pod调度延迟
|
scheduler_e2e_scheduling_ delay_microseconds(<v1.14) 或 scheduler_e2e_scheduling_ duration_seconds
|
将Pod调度到节点上所花费的总时间。
|
控制平面健康状况
你应该监视控制平面上的以下健康状况:
etcd领导者
etcd集群应始终有一个领导者(在更改领导者的过程中除外,这种情况很少见)。你应该密切注意所有etcd_server_has_leader指标,因为如果很多集群成员没有领导者,那么集群性能将会下降。另外,如果你在etcd_server_leader_changes_seen_total中看到大量的领导者变更,则可能表明etcd集群存在连接性或资源问题。
API请求延迟
如果将apiserver_request_latencies_count划分为apiserver_request_latencies_sum,则将获得API服务器每个请求的平均延迟。跟踪随时间不断变化的平均请求延迟可以让你知道服务器何时不堪重负。
工作队列延迟
工作队列是由controller manager管理的队列,用于处理集群中的所有自动化流程。监视workqueue_queue_duration_seconds的增加,将使你知道队列延迟何时增加。如果发生这种情况,你可能需要深入研究controller manager日志以查看发生了什么。
调度程序问题
调度程序有两个方面值得关注。首先,你应该监视scheduler_schedule_attempts_total {result:unschedulable},因为无法调度的Pod的增加可能意味着你的集群存在资源问题。其次,你应该使用上面指示的延迟指标之一来监视调度程序延迟。Pod调度延迟的增加可能会导致其他问题,也可能表明集群中存在资源问题。
除了从Kubernetes集群中收集数值指标外,从集群中收集和跟踪事件也很有用。集群事件可以帮助你监视Pod生命周期并观察重大Pod故障,并且监视从集群流出的事件的速率可以是一个很好的预警指标。如果事件发生率突然显着变化,则可能表明发生了问题。
应用程序指标
与我们上面检查的指标和事件不同,应用程序指标不是从Kubernetes本身发出的,而是从集群运行的工作负载发出的。从应用程序的角度来看,这种监控可以是你认为重要的任何事情:错误响应,请求延迟,处理时间等。
关于如何收集应用程序度量标准,有两种方式。第一个是,应该将指标数据从应用程序“推送”到收集端点。这意味着必须将像StatsD这样的客户端与每个应用程序捆绑在一起,以提供一种将指标标准数据推出该应用程序的机制。该技术需要更多的管理开销,以确保正确地检测集群中运行的每个应用程序,因此它在集群管理器中不受欢迎。
第二种是,指标收集原理(正在被越来越广泛地采用),指标应由收集代理从应用程序中“拉取”。这使应用程序更易于编写,因为它们所要做的只是适当地发布了它们的指标标准,但是应用程序不必担心这些度量标准是如何被提取或删除的。这是OpenMetrics的工作方式,也是Kubernetes集群指标收集的方式。当此技术与收集代理的服务发现相结合时,它将创建一种功能强大的方法,用于从集群应用程序中收集你需要的任何类型的指标。
Kubernetes每天可以生成数百万个新指标。这会带来两个大挑战。首先,许多常规的监视系统无法正确监视Kubernetes集群的大量指标。其次,数据”庞杂”使你难以跟上并知道哪些指标最重要。
你的Kubernetes监视解决方案必须具有处理所有这些数据的能力,并能够自动分析,图形化和警告要注意的最关键指标。这样,你就知道自己已经收集了期望的一切,过滤掉了不必要的数据,并自动缩小了相关数据的范围。因此,你可以节省大量时间,并确保一切都能正常进行。
译者:王延飞
参考链接:
https://www.kubernetes.org.cn/8752.html
精彩文章推荐
k8s+SpringCloud全栈技术:在k8s平台部署亿级高并发的SpringCloud项目
安装kubernetes集群-灵活安装k8s各个版本高可用集群
Prometheus+Grafana+Alertmanager搭建全方位的监控告警系统-超详细文档
linux架构师成长路线图:如何从月薪3千涨到月薪3万
基于Jenkins共享库实践之自定义通知器
Spring Cloud基础面试题大集合
Docker+k8s+DevOps企业级架构师成长路线图
Kubernetes将弃用Docker,不必恐慌
手把手教你使用 Jenkins 配合 Github hook 持续集成
5个维度对 Kubernetes 集群优化
开源API网关Kong基本介绍和安装验证
一文搞懂全链路监控:方案概述与比较 | 干货
分布式存储不得不知的etcd,到底好在哪?
为了大家更快速的学习知识,掌握技术,随时沟通交流问题,特组建了技术交流群,大家在群里可以分享自己的技术栈,抛出日常问题,群里会有很多大佬及时解答的,这样我们就会结识很多志同道合的人,长按或者扫描下图二维码可加我微信,备注运维或者k8s或者devops即可进群,让我们共同的努力,向着美好的未来出发吧~~~,
想要
免费获取
linux、
k8s、DevOps
、Openstack、Openshift、运维、开发、测试、架构师、Python、Go、面试文档、容器、岗位内推等资料也可进群获取
哈~~
微信:
luckylucky421302
《
kubernetes/k8s+SpringCloud全栈技术:基于世界500强的企业实战课程
》
微信公众号
点击阅读原文即可了解更多信息
Circonus最近对Kubernetes运营商进行的一项调查中,收集哪些健康状况指标是运营商面临的最大挑战之一。考虑到Kubernetes每天可以生成数百万个指标,这不足为奇。在本文中,...
registry.cn-beijing.aliyuncs.com/mydlq/sleuth-service-customer:0.0.1
registry.cn-beijing.aliyuncs.com/mydlq/sleuth-service-provider:0.0.1
镜像能提供下么。
这边docker pull拉不下来
k8s部署Zipkin搭配Kafka+ElasticSearch实现链路追踪
baofeifei121088:
registry.cn-beijing.aliyuncs.com/mydlq/sleuth-service-customer:0.0.1
registry.cn-beijing.aliyuncs.com/mydlq/sleuth-service-provider:0.0.1
镜像能提供下么。
这边docker pull拉不下来
kubernetes HPA-超详细中文官方文档
k8s之DNS服务器搭建
「已注销」: