从 Kubernetes 1.8 开始,资源使用指标(如容器 CPU 和内存使用率)通过 Metrics API 在 Kubernetes 中获取。 这些指标可以直接被用户访问(例如通过使用 kubectl top 命令),或由集群中的控制器使用(例如,Horizontal Pod Autoscale 可以使用这些指标作出决策)。
描述: 在《Ops实践 | 从零开始,在云原生环境下快速实现K8S集群可视化监控》文章中,针对 Kubernetes 集群资源监控部分,作者写得有些含糊不清,所以此文我将对K8S集群组件(kubelet、kube-proxy)以及使用kube-state-metric暴露资源(deployment、statefulset、service、pod)的监控指标整理介绍。
HPA(Horizontal Pod Autoscaler)的实现是一个控制循环,由controller manager的–horizontal-pod-autoscaler-sync-period参数指定周期(默认值为15秒)。每个周期内,controller manager根据每个HorizontalPodAutoscaler定义中指定的指标查询资源利用率。controller manager可以从resource metrics API(pod 资源指标)和custom metrics API(自定义指标)获取指标。
metrics-server 可实现 Kubernetes 的 Resource Metrics API(metrics.k8s.io),通过此 API 可以查询 Pod 与 Node 的部分监控指标,Pod 的监控指标用于 HPA、VPA 与** kubectl top pods** 命令,而 Node 指标目前只用于 kubectl top nodes 命令。容器服务 某些k8s发行版 自带 Resource Metrics API 的实现,指向 hpa-metrics-server,且目前提供 Pod 的监控指标。
Kubernetes 从 v1.8 开始,资源使用情况的监控可以通过 Metrics API 的形式获取,具体的组件为 Metrics Server,用来替换之前的 Heapster,Heapster从 v1.11 开始逐渐被废弃。
Horizontal Pod Autoscaler(HPA,Pod水平自动伸缩),根据平均 CPU 利用率、平均内存利用率或你指定的任何其他自定义指标自动调整 Deployment 、ReplicaSet 或 StatefulSet 或其他类似资源,实现部署的自动扩展和缩减,让部署的规模接近于实际服务的负载。HPA不适用于无法缩放的对象,例如DaemonSet。
经过前面k8s系列的文章,这一系列已经基本完成,现在就用几篇文章说一下日常的集群维护。
Prometheus是由SoundCloud公司开发的开源监控系统,是继Kubernetes之后CNCF第2个毕业的项目,在容器和微服务领域得到了广泛应用。Prometheus的主要特点如下:
kubernetes监控指标大体可以分为两类:核心监控指标和自定义指标,核心监控指标是kubernetes内置稳定可靠监控指标,早期由heapster完成,现由metric-server实现;自定义指标用于实现核心指标的扩展,能够提供更丰富的指标支持,如应用状态指标,自定义指标需要通过Aggregator和k8s api集成,当前主流通过promethues实现。
Prometheus 最初是 SoundCloud 构建的开源系统监控和报警工具,是一个独立的开源项目,于 2016 年加入了 CNCF 基金会,作为继 Kubernetes 之后的第二个托管项目。Prometheus 相比于其他传统监控工具主要有以下几个特点:
描述: 本章主要讲解和实践Prometheus在企业中的应用场景的复现,采用了docker-compose的资源清单进行快速构建prometheus_server、prometheus_pushgateway、prometheus_alertmanager、grafana等环境。
metrics-server 是一个采集集群中指标的组件,类似于 cadvisor,在 v1.8 版本中引入,官方将其作为 heapster 的替代者,metric-server 属于 core metrics(核心指标),提供 API metrics.k8s.io,仅可以查看 node、pod 当前 CPU/Memory/Storage 的资源使用情况,也支持通过 Metrics API 的形式获取,以此数据提供给 Dashboard、HPA、scheduler 等使用。
在前一篇文章中详细介绍了Kubernetes容器集群管理环境 - 完整部署(中篇),这里继续记录下Kubernetes集群插件等部署过程:
上一篇关于HPA的文章,我们了解到HPA的实现原理,通过对服务CPU的metrics的监控实现了Deployment的弹性伸缩,但是对于我们来说,HPA核心指标较为简单,不适合个性化业务弹性的需求。我们这边文章就来研究一下扩展自定义指标,丰富业务弹性能力。在开始之前,我们需要了解两个组件。分别是Metrics server和Prometheus adapter。
其中基础设施层监控指标的拉取肯定是来在Prometheus的node_exporter,因为我们要监控的服务器节点既包含Kubernetes节点又包含其他部署独立中间件的节点, 所以我们并没有将node_exporter以daemonset的形式部署到k8s上,而是使用ansible将node_exporter以二进制的形式部署到所有要监控的服务器上。 而负责从node_exporter拉取指标的Prometheus也是用ansible独立部署在Kubernetes集群外部的。Prometheus的配置文件prometheus.yml使用ansible的j2模板生成。
kube-apiserver 是 Kubernetes 最重要的核心组件之一,是所有服务访问的统一入口(所有请求的统一的入口),并提供认证、授权、访问控制、API 注册和发现等能力,同时也是是 Kubernetes Cluster 的前端接口,各种客户端工具(CLI 或 UI)以及 Kubernetes 其他组件可以通过它管理 Cluster 的各种资源。
Kubernetes 节点的监控:比如节点的 cpu、load、disk、memory 等指标 内部系统组件的状态:比如 kube-scheduler、kube-controller-manager、kubedns/coredns 等组件的详细运行状态 编排级的 metrics:比如 Deployment 的状态、资源请求、调度和 API 延迟等数据指标
Istio 为网格内所有的服务通信生成详细的遥测数据。这种遥测技术提供了服务行为的可观测性,使运维人员能够排查故障、维护和优化应用程序,而不会给开发人员带来其他额外的负担。通过 Istio,运维人员可以全面了解到受监控的服务如何与其他服务以及 Istio 组件进行交互。
常规的做法是给集群资源预留保障集群可用,通常20%左右。这种方式看似没什么问题,但放到Kubernetes中,就会发现如下2个问题。
从 v1.8 开始,资源使用情况的度量(如容器的 CPU 和内存使用)可以通过 Metrics API 获取。注意:
Prometheus Server 的数据抓取工作基于 Pull 模型,因而,它必须要事先知道各 target 的位置,然后才能从相应的 Exporter 或 Instrumentation 中抓取数据。
在前面的学习中我们使用用一个 kubectl scale 命令可以来实现 Pod 的扩缩容功能,但是这个毕竟是完全手动操作的,要应对线上的各种复杂情况,我们需要能够做到自动化去感知业务,来自动进行扩缩容。为此,Kubernetes 也为我们提供了这样的一个资源对象:HorizontalPodAutoscaling(Pod水平自动伸缩),简称 HPA,HPA 通过监控分析一些控制器控制的所有 Pod 的负载变化情况来确定是否需要调整 Pod 的副本数量,这是 HPA 最基本的原理:
源于一次线上 P0 故障,一个生产集群被误操作删除(不只是业务被删,是集群也被删了),集群规模较大,在集群恢复后 Pod 进行了重新、调度的过程,整个过程(从开始恢复集群到业务服务就绪)耗时略长,其中涉及到调度环节耗时的计算,由于当时监控服务也部署在集群中,导致故障时的调度器监控数据丢失,最后的最后,又回到了原点:故障驱动,自证清白。于是就有了 scheduler-stress-test 项目,就有了本篇关于此项目的介绍,希望可以帮助到有类似需求(调度器压测)的同志们。
版权声明:欢迎交流,菲宇运维! https://blog.csdn.net/bbwangj/article/details/82832883
Longhorn 在 REST 端点 http://LONGHORN_MANAGER_IP:PORT/metrics 上以 Prometheus 文本格式原生公开指标。有关所有可用指标的说明,请参阅 Longhorn's metrics。您可以使用 Prometheus, Graphite, Telegraf 等任何收集工具来抓取这些指标,然后通过 Grafana 等工具将收集到的数据可视化。
当你的应用部署到 Kubenetes 后,你很难看到容器内部发生了什么,一旦容器死掉,里面的数据可能就永远无法恢复,甚至无法查看日志以定位问题所在,何况一个应用可能存在很多个实例,用户的一个请求不指定被哪个容器处理了,这使得在 Kubernetes 中对应用进行故障排除较为复杂。在应用之外,由于 Kubernetes 作为基础设施,掌管这整个集群的生死,Kubernetes 的任何故障,必定影响到应用服务的运行,因此监控 Kubernetes 运行状况也至关重要。
jokey,腾讯云容器产品工程师,热衷于云原生领域。目前主要负责腾讯云TKE 的售中、售后的技术支持,根据客户需求输出合理技术方案与最佳实践。 概述 Kubernetes Pod 水平自动扩缩(Horizontal Pod Autoscaler,以下简称 HPA)可以基于 CPU 利用率、内存利用率和其他自定义的度量指标自动扩缩 Pod 的副本数量,以使得工作负载服务的整体度量水平与用户所设定的目标值匹配。本文将介绍和使用腾讯云容器服务 TKE 的 HPA 功能实现 Pod 自动水平扩缩容。 使用场景 H
作为Kubernetes的维护者,我们一直在寻找在保持兼容性的同时提高可用性的方法。在开发特性、分类bug和回答支持问题的过程中,我们积累了有助于Kubernetes用户了解的信息。在过去,信息的共享仅限于发布说明、公告电子邮件、文档和博客文章等外部方法。除非有人知道该信息并设法找到它,否则他们不会从中受益。
在服务器安装完 Ubuntu 20.04 之后,打开终端的 motd (message of the day) 中,会看到这段话:
在前文中我们已经安装配置了 ElasticSearch 的集群,本文我们将来使用 Metricbeat 对 Kubernetes 集群进行监控。Metricbeat 是一个服务器上的轻量级采集器,用于定期收集主机和服务的监控指标。这也是我们构建 Kubernetes 全栈监控的第一个部分。
prometheus是一个最初在SoundCloud上构建的开源系统监控和警报工具包 。 从2012年开始,许多公司和组织开始使用Prometheus,该项目拥有非常活跃的开发人员和用户社区。 目前它是一个独立的开源项目,并且不依赖与任何公司。 为了强调这一点,并澄清项目的治理结构,Prometheus在2016年加入Cloud Native Computing Foundation,作为kubernetes之后的第二个托管项目。
调研发现prometheus配合node_exporter、kube-state-metrics可以很方便地采集单个集群的监控指标。因此最初的构想是在每套k8s集群里部署prometheus,由它采集该集群的监控指标,再运用prometheus的联邦模式将多个prometheus中的监控数据聚合采集到一个中心prometheus里来,参考模型为Hierarchical federation。
目前监控k8s集群指标是SkyWalking v9版本新特性,配置的时候网上一篇文章没有,搞了很久,记录一下,经验之谈就是多番找GitHub中 Issues 和阅读官方文档。
监控系统的历史悠久,是一个很成熟的方向,而 Prometheus 作为新生代的开源监控系统,慢慢成为了云原生体系的事实标准,也证明了其设计很受欢迎。
Kubernetes Dashboard 是 Kubernetes 集群的基于 Web 的通用 UI。它允许用户管理在群集中运行的应用程序并对其进行故障排除,以及管理群集本身。
实际生产系统, 会遇到某个服务需要扩容的场景,也可能会遇到由于资源紧张或者工作负载降低而需要减少服务实例数量的场景。
业务容器化后,如何将其部署在 K8S 上?如果仅仅是将它跑起来,很简单,但如果是上生产,我们有许多地方是需要结合业务场景和部署环境进行方案选型和配置调优的。比如,如何设置容器的 Request 与 Limit、如何让部署的服务做到高可用、如何配置健康检查、如何进行弹性伸缩、如何更好的进行资源调度、如何选择持久化存储、如何对外暴露服务等。
1. 用于支持自动扩缩容的 CPU/memory HPA metrics:metrics-server;2. 通用的监控方案:使用第三方可以获取 Prometheus 格式监控指标的监控系统,如 Prometheus Operator;3. 事件传输:使用第三方工具来传输、归档 kubernetes events;
前面介绍了 Prometheus 标签 label、PromQL、AlertManager、Alertmanager 配置实现钉钉告警、Pushgateway、基于K8S服务发现、监控常见服务等相关的知识点,今天我将详细的为大家介绍 Prometheus 配置 Grafana 展示与报警 相关知识,希望大家能够从中收获多多!如有帮助,请点在看、转发朋友圈支持一波!!!
Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。 例如,Kubernetes 可以轻松管理系统的 Canary 部署。
Kubeadm 是一个工具,它提供了 kubeadm init 以及 kubeadm join 这两个命令作为快速创建 kubernetes 集群的最佳实践。 kubeadm 通过执行必要的操作来启动和运行一个最小可用的集群。kubeadm 只关心启动集群,而不关心其他工作,如部署前的节点准备工作、安装各种Kubernetes Dashboard、监控解决方案以及特定云提供商的插件,这些都不属于 kubeadm 关注范围。
问题出在这里:DiscoveryFailed:Discovery failed for some groups, 1 failing: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request
认证插件会连同用户名,和用户id返回组,组可以一次性给用户服务多个权限,不用单次赋予,
Prometheus把所有的数据按时序列进行存储, 所有采集上来的数据在都被打了时间戳并按时间先后顺序进行流化,这些数据属于相同的指标名以及一组标签维度(labeled dimensions)
Traefik 是一个开源的可以使服务发布变得轻松有趣的边缘路由器。它负责接收你系统的请求,然后使用合适的组件来对这些请求进行处理。
如何查看各节点的资源使用情况? 如何监控kubernetes集群资源?自kubernetes 1.8开始,资源使用指标(如容器 CPU 和内存使用率)通过 Metrics API 在 Kubernet
上一个章节中kubernetes系列教程(十九)使用metric-server让HPA弹性伸缩愉快运行介绍了在kubernetes中的监控架构,通过安装和使用metric-server提供kubernetes中的核心监控指标:提供node节点和pod容器CPU和内存的监控能力,核心监控指标提供的监控维度和指标相对有限,需要更好的扩展监控能力,需要使用自定义监控来实现,本文介绍prometheus提供更更加丰富的自定义监控能力。
本次系列使用的所需部署包版本都使用的目前最新的或最新稳定版,安装包地址请到公众号内回复【K8s实战】获取
cAdvisor已经内置在了 kubelet 组件之中,所以不需要单独去安装,cAdvisor的数据路径为/api/v1/nodes//proxy/metrics,同样这里使用 node 的服务发现模式,因为每一个节点下面都有 kubelet,自然都有cAdvisor采集到的数据指标,配置如下:
领取专属 10元无门槛券
手把手带您无忧上云