kubernetes

Kubernetes监控介绍

Kubernetes改变了现代运营团队部署和扩展应用程序的方式。尽管Kubernetes使得在生产中使用容器变得更加简单,但这并不否定对健壮的监视系统的需求,该系统可以让您查询系统的状态。

Kubernetes监控是必不可少的,这样您就可以跟踪性能指标,审计对部署环境的更改,并检索有助于调试应用程序崩溃的日志。在没有监控解决方案的情况下,对Kubernetes进行故障排除是一件繁琐且容易出错的事情,这使得问题不断升级,因为它们经常被忽视。

我们将介绍监视Kubernetes集群的基础知识,并解释如何通过确定收集Kubernetes指标的关键机会来最大化工作负载的可见性。这将支持在系统生命周期中更早地检测错误。

监控Kubernetes的5个原因

需要监视生产应用程序,以便检测错误、优化资源使用并管理成本。Kubernetes也不例外:监控通常是有效集群和未充分利用且性能较差的集群之间的区别。

实时警报

1.实时警报和早期错误检测

主动监视Kubernetes集群可以帮助您在错误影响用户之前及早发现错误。日志文件、跟踪和性能指标提供了对集群中发生的事情的可见性,为您提供使用高峰和不断增加的错误率的预先警告。实时警报可以在问题开始时立即通知您,避免当用户第一个发现问题时可能导致的尴尬对话。这减少了恢复服务的时间,从而保护了您的品牌声誉。

工作负载管理

2.更好的工作负载管理和优化

全面监控有助于更好地管理工作负载和更优化地使用资源。监视您的Kubernetes集群可以发现有太多的资源争用,或者在您的节点上应用程序pod分布不均匀。简单的调度调整,如设置亲和性和反亲和性可以显著提高性能和可靠性,但是如果不深入了解实际的集群使用情况,就会错过这些机会。

故障排除

3.简单故障排除

监视可以在排除问题时提供帮助。从应用程序和Kubernetes组件中访问日志通常是发现复制步骤和发现根本原因的最佳方法。如果没有监控解决方案,您必须假设问题的可能来源,然后使用反复试验来测试修复程序。这增加了开发人员的工作量,特别是不熟悉系统的新手。能够尽早查明问题,可以最大限度地减少停机时间,并鼓励每个人都做出贡献。

成本的可见性

4.实时成本可见性

Kubernetes比尔的冲击是真实的。自动伸缩架构可以让您实时适应不断变化的需求,但这也会导致成本迅速上升。监控是必不可少的,这样您就可以查看的数量节点负载平衡器,持久的卷当前部署在您的云帐户中的。这些对象中的每一个通常都会从您的提供者那里产生单独的成本。

的见解

5.强大的见解

Kubernetes监控可以产生独特的见解,突出机会,以提高您的服务。除了简单的性能指标,监控还有助于揭示用户如何与应用程序交互,从而为未来的产品决策提供信息。来自组件的数据,例如入口控制器将显示调用次数最多的端点,以及流经基础设施的数据量。这些信息为寻找需要进一步扩展的功能提供了一个起点,无论是由于活跃用户还是由于低曝光率而导致的低使用率。

Kubernetes监控:关键组件

Kubernetes集群由许多不同的组件组成,这些组件协同工作以支持容器化的工作负载。您将在日常管理过程中遇到其中一些问题,但其他问题将在幕后协调操作。

Kubernetes的基本架构是将应用程序作为容器运行豆荚.豆荚分布在多个节点,表示集群中的物理机器。节点由控制飞机,包括API服务器用于与您的集群和多个集群进行交互控制器控制器观察集群中的变化,并采取行动以实现新的所需状态,例如在添加pod对象时启动容器。

Kubernetes集群的复杂性意味着总是需要一个多方面的监控方法。应该观察下图中的每一项,这样你就可以跟踪整个基础设施的性能:

Kubernetes中要监测的可观测性层图

接下来,我们将回顾其中的一些组件,以及如何从它们收集指标。

性能指标

性能监视允许您调查集群容量问题,并确定何时添加更多资源。收集到的指标将让您发现资源消耗趋势,使您能够在用户可以注意到的放缓之前保持领先。

节点资源利用率指标

节点资源利用率指标,例如CPU和内存消耗,可以通过几种机制获得。最常见的是运行代理,例如普罗米修斯节点出口商在每个节点上。度量代理定期抓取节点的当前度量并将数据发送到可观察性平台。

或者,当你有度量API安装在您的集群中,Kubernetes可以自己收集这些数据。使用Metrics API允许您在终端中使用kubectl最高命令.它提供了方便的资源监视,没有任何外部依赖。

从主要云提供商部署的Kubernetes集群通常也有自己的监控仪表板。您可以登录到您的云帐户来查看关键指标的基本图表,而无需自己设置任何东西。这提供了一个方便的快速启动选项,但不一定会显示您需要知道的所有内容。

定期监控这些基本硬件利用率指标非常重要,这样您就可以预测未来的使用情况,并在需求之前增加容量。通常高CPU和内存消耗会降低服务的性能空间。如果出现使用高峰,这可能会导致中断和不稳定。

对象容量和运行状况度量

kube-state-metrics(KSM)服务监听Kubernetes API服务器事件,并公开记录集群对象状态的Prometheus度量。一千多个不同的度量标准提供了各个容器、pod、部署和其他资源的状态、容量和健康状况。

您可以使用这种检测来深入查询集群中的对象。的Pod Metrics API例如,提供了关于每个吊舱的40多个独立数据点,包括吊舱的状态、自上次状态转换以来所经过的时间、已经发生的重新启动次数以及适用于它的资源限制。单个api可用用于所有其他Kubernetes内置对象类型。

监视这些指标可以提醒您集群和应用程序问题。具有高重启次数的pod可能表明集群中存在资源争用或应用程序中存在导致其崩溃的错误。KSM公开的指标是由Kubernetes控制平面收集的原始指标,允许您在没有准备的情况下处理和分析它们。

存储健康

Kube-state-metrics (KSM)可用于监控存储健康,太。它包括公开指标的api存储类持久的卷,持续数量索赔,例如卷的容量,它们当前是否可用,以及每个索赔请求的空间量。

检查存储运行状况的另一种方法是使用卷运行状况监视系统.这个alpha特性内置于Kubernetes中,并提供描述持久卷整体运行状况的指标。它包括一个专用控制器,可以监视异常的容量状况,这可能表明您的存储有问题。当访问卷的pod被调度到故障节点时,控制器还在卷上设置事件。这让您可以检查已声明一个卷的pod是否实际运行。

Kubelet指标

运行在Kubernetes节点上的Kubelet进程提供详细的指标可以用普罗米修斯来获取。可以通过/指标端口10255上的端点。

首先在集群中发现节点的IP地址:

$ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME minikube Ready control-plane,master 74d v1.23.3 192.168.49.2  Ubuntu 20.04.2 LTS 5.4.0-122-generic docker://20.10.12

该节点已获取IP地址192.168.49.2.现在您可以通过访问端口10255查询其度量数据:

curl http://192.168.49.2:10255/metrics # HELP apiserver_audit_event_total [ALPHA]生成并发送到审计后端的审计事件计数器。# TYPE apiserver_audit_event_total counter apiserver_audit_event_total 0 # HELP apiserver_audit_requests_rejected_total [ALPHA]由于审计日志后端错误而拒绝apiserver请求的计数器。# TYPE apiserver_audit_requests_rejected_total counter apiserver_audit_requests_rejected_total 0 # HELP apiserver_client_certificate_expiration_seconds [ALPHA]用于验证请求的证书的剩余生命周期分布。# TYPE apiserver_client_certificate_expiration_seconds_bucket{le="0"} 0 apiserver_client_certificate_expiration_seconds_bucket{le="1800"} 0 apiserver_client_certificate_expiration_seconds_bucket{le="3600"} 0…

Kubelet度量端点可用于查询集群内节点的性能。这些数据公开了与Kubelet与Kubernetes控制平面交互相关的统计数据,例如工作队列中的任务数量和完成API请求所需的时间。

Kubelet也提供了cAdvisor指标/标准/ cadvisor端点。cAdvisor (Container Advisor)是一个分析容器的资源使用情况和性能特征的工具。

curl http://192.168.49.2:10255/metrics/cadvisor # HELP cadvisor_version_info一个带有常量“1”值的度量,标记为内核版本、OS版本、docker版本、cadvisor版本和cadvisor修订。#式cadvisor_version_info计cadvisor_version_info {cadvisorRevision = " ", cadvisorVersion = " ", dockerVersion = " ", kernelVersion =“5.4.0-122-generic osVersion =“Ubuntu 20.04.2 LTS”}1 #帮助container_blkio_device_usage_total Blkio设备字节使用#类型container_blkio_device_usage_total计数器container_blkio_device_usage_total{容器= ",设备= / dev / nvme0n1, id = " / " = "形象,主要= " 259 ",小= " 0 " name = " ",名称空间= " ",操作=“异步”,pod = " "} 0 1660656772812container_blkio_device_usage_total{container="",device="/dev/nvme0n1",id="/",image="",major="259",minor="0",name="",namespace="",operation="Discard",pod=""} 0 1660656772812 container_blkio_device_usage_total{container="",device="/dev/nvme0n1",id="/",image="",major="259",minor="0",name="",namespace="",operation="Read",pod="} 778240 1660656772812…

这些指标有助于在容器级别上分析CPU、内存、磁盘和网络利用率。一旦使用上面讨论的集群级指标确定了一个繁忙的节点,就可以使用该节点的cAdvisor输出来查找使用过多资源并与其他对象争用的容器。高利用率可能是由于用户活动的增加,这表明您需要使用更多的pod来扩展您的服务,或者在容器中缺少优化,从而导致负载增加。

Kubernetes日志

除了性能指标和资源利用率,捕获和保留Kubernetes日志也很重要,以便将来可以参考它们。多个Kubernetes组件直接将事件和错误写入主机文件系统上的日志文件。这里有一些常见的路径检查。

在Kubernetes控制平面节点上,查看如下图:

  • /var/log/kube-apiserver.log此日志包含发生在Kubernetes API服务器内的事件。
  • /var/log/kube-scheduler.log调度决策的记录,当Kubernetes决定将pod放置到哪个节点时创建。
  • /var/log/kube-controller-manager.log来自Kubernetes控制器管理器的日志,该管理器负责运行集群中监视活动的所有内置控制器。

在各个工作节点上,查看以下内容:

  • /var/log/kubelet.logkubelet进程负责维护节点与Kubernetes控制平面服务器之间的通信。当您在排除节点不可用的原因时,这个日志文件应该是您的起点。
  • /var/log/kube-proxy.log这就是log从kube-proxy进程被存储。的kube-proxy进程负责将流量通过服务路由到节点上的pods。

您可以使用数据收集器访问这些日志文件,例如PromtailGrafana代理将新线直接流到您的监控平台。在节点上安装这些代理之一将自动收集日志。这让您可以在查看性能指标的同时查看日志,并且无需手动连接到节点以使用Unix工具来访问其日志而且尾巴

Promtail还适用于应用程序编写的容器级日志。Kubernetes根据进程写入标准输出和错误流的数据创建容器日志。您应该配置您的应用程序来支持这种机制,因为直接写入容器文件系统的日志将在重新启动时被销毁。这可能会使调查bug和崩溃变得更加困难,因为您将失去对日志错误消息和堆栈跟踪的访问。

使用代理收集容器日志并将其发送到监控平台,使其内容更易于访问。您将能够搜索和过滤日志行,而不是依赖于简单的时间顺序输出kubectl日志命令提供。大多数日志聚合解决方案,例如bob彩票中奖计划Grafana洛基,还支持长期日志存档,允许您在重新启动或更换容器后重新查看问题。

痕迹

跟踪是一种日志记录形式,它记录程序执行期间发生的事件的高度精确细节。虽然跟踪和日志记录之间的区别有时是模糊的,但原始跟踪可能是冗长的、嘈杂的,并且被设计为为开发人员提供最大的保真度。跟踪通常由导致事件的代码堆栈层序列组成。

相比之下,日志消息通常包含更多以人为中心的信息。他们记录了一个事件的发生,却没有解释是什么导致了它。日志消息可能是“处理付款失败”。相应的跟踪应该显示贯穿代码的步骤,从应用程序的入口点到尝试调用外部支付提供程序并在响应中得到错误。

跟踪中的单个操作被称为跨越.在上面的示例中,跟踪是整个操作,从用户发起支付到确定结果。在跟踪中,可能存在以下跨度:

  • 验证用户的输入,例如卡片详细信息和代金券代码。
  • 检索用户篮子中的内容。
  • 将数据发送到后端支付提供商。
  • 存储事务的结果。
  • 发送订单确认邮件。

跨度通常有自己的元数据与之关联,比如它们的直接父级、持续时间和执行的操作。这种区别使您可以深入到单个事件的特定部分,缩小对问题的搜索范围。

在调试用户报告的问题时,检查请求所采用的代码路径的能力是非常宝贵的。在开发过程中,并不是每个问题都能轻易重现;跟踪可以让您准确地看到在用户会话期间发生了什么,从而更有效地解决问题。如果没有跟踪,您必须要求用户确认在错误发生之前他们所采取的确切步骤。这并不总是可能的,也不一定会导致成功的繁殖。跟踪提供了您需要的所有数据,允许您直接进行补救。

Kubernetes也有内置跟踪功能。几个系统组件公开跟踪,以便更好地理解集群的内部操作和度量性能。集成的集群级跟踪在诊断影响所有应用程序的一般性问题时很有用,但是在精确分析代码执行时,应用程序级的用户部署跟踪更有效。

Kubernetes事件

Kubernetes维护集群中发生的所有事件的全面历史。您可以使用kubectl查看终端中的事件:

$ kubectl get events LAST SEEN TYPE REASON OBJECT MESSAGE 1m Normal创建的pod/demo-pod创建的容器demo-pod 1m Normal启动的pod/demo-pod启动的容器demo-pod

每个事件包括它所引用的对象的名称、发生的操作、对象的状态(如“正常”或“失败”)以及简要描述所发生事情的消息。这提供了集群中活动的全面历史记录,包括Kubernetes控制平面生成的事件,以及响应用户操作而生成的事件。

属性进行筛选,可以获得与特定对象关联的事件——field-selector国旗。属性的事件demo-pod通过匹配involvedObject.kind而且involvedObject.name事件对象字段:

$ kubectl get events \——field-selector involvedObject。kind=Pod \——field-selector involvedObject.name=demo-pod LAST SEEN TYPE REASON OBJECT MESSAGE 1m Normal创建的Pod /demo-pod创建的容器demo-pod 1m Normal启动的Pod /demo-pod启动的容器demo-pod

对象可以修改此示例以支持任何其他对象involvedObject.kind字段中包含您正在查找的对象类型的名称,例如部署ReplicaSet,或工作

事件对于理解导致特定问题的行为序列是非常宝贵的。实际上,连接到对象的每个操作都将显示在列表中,从成功创建容器到失败的作业、图像提取错误和低内存条件。

Kubernetes将事件视为瞬态记录,在事件发生后不久就会自动清理。在大多数情况下,事件会被删除仅仅一个小时后.你应该使用基于代理的数据收集器将事件传输到可观察性解决方案,如Grafana。这将允许您在事件发生后很长时间内检索、搜索和存档事件,从而在排除未来问题时提供另一个参考点。

容器化的应用程序度量

在监视集群运行状况的同时监视容器化工作负载非常重要。创建自己的应用内指标API导出Prometheus-compatible数据将允许您使用可观察性解决方案获取性能统计数据。

普罗米修斯已经官方客户端库适用于Go, Java/Scala, Python, Ruby和Rust。社区支持的选项也可用于大多数其他流行语言。这些库允许您使用应用程序实例上的HTTP端点定义和公开自定义应用程序指标。

例如,您可能希望跟踪执行特定业务功能所需的时间,例如处理登录或完成支付事务。Prometheus简化了这些持续时间的测量,并将它们作为您可以获取的指标公开,从而最大限度地减少了需要编写的代码量。

花时间测量工作负载可以让您在应用程序级别上分析性能,从而增强可观察性。最终,对用户最重要的是处理应用程序功能所需的时间,而不是绝对的CPU消耗或集群利用率。跟踪特定于业务的度量方法的趋势可以发现改善用户体验的机会,并让您在出现性能问题成为节点级或集群级问题之前发现它们。

结论

Kubernetes比传统的部署解决方案有更多的活动部件,并且需要一种新的监控和可观察性方法。bob彩票中奖计划除了基本的日志记录、应用程序运行状况和资源利用率指标外,还需要评估Kubernetes控制平面内各个组件的性能。

在本文中,我们研究了在创建一个全面的Kubernetes监控解决方案时必须考虑的组件。专注于上面列出的领域,将有助于了解集群的内部操作及其工作负载。您将能够及早发现新出现的问题,以及改进和增强集群使用的新机会。

开始在Grafana云中使用Kubernetes监控

无论您是推出新更改的应用程序开发人员、寻求更好方法排除基础设施故障的SRE,还是维护运行集群的裸金属服务器的DevOps管理员,Grafana Labs都可以提供帮助。bob电竞频道输入Kubernetes监控,为所有级别的Kubernetes使用提供完整的解决方案,可以开箱即用地访问Kubernetes基础设施的指标、日志和Kubernetes事件以及预构建的仪表板和警报。Kubernetes Monitoring可用于所有Grafana Cloud用户,包括那些在慷慨免费永远层bob体育手机二维码

准备好Kubernetes监控了吗?