Kubernetes 监控详解

标签: kubernetes 监控 | 发表时间:2020-11-14 14:49 | 作者:玻璃樽
出处:http://weekly.dockone.io

【编者的话】监控 Kubernetes 并不是件容易的事。本文介绍了监控 Kubernetes 的难点、用例以及有关工具,希望可以帮助大家进一步了解监控 Kubernetes。

如果想要监控 Kubernetes,包括基础架构平台和正在运行的工作负载,传统的监控工具和流程可能还不够用。就目前而言,监控 Kubernetes 并不是件容易的事。

为什么监控 Kubernetes 很难?

Kubernetes 已经席卷了整个容器生态系统,它充当着容器分布式部署的大脑,旨在使用跨主机集群分布的容器来管理面向服务的应用程序。Kubernetes 提供了用于应用程序部署、调度、更新、服务发现和扩展的机制,但是监控 Kubernetes 呢?

虽然 Kubernetes 可以极大地简化将应用程序在容器以及跨云的部署过程,但它会为日常任务、应用程序性能管理、服务可见性以及典型的“监控->警报->故障排除”工作流程增加了复杂性。

旧版监控工具从静态目标中收集指标,用于监控服务器和服务,这些工具过去工作良好,但现在无法正常工作。下面就是这些工具现在无法监控 Kubernetes 的原因:

Kubernetes 增加了基础架构的复杂性

为了简化应用程序部署,基础架构增加了新的复杂性层:动态配置的 IaaS、自动配置的配置管理工具以及编排平台(如 Kubernetes),它们都位于裸机或虚拟基础架构与支持应用程序的服务之间,因此在控制平面上监控 Kubernetes 安全也是工作的一部分。

微服务架构

除了增加基础架构的复杂性之外,微服务还被设计了新的应用程序,其中相互通信的组件数量也会按数量级增加。每个服务分布在多个实例中,并且容器可以根据需要在基础结构中移动。这就是监控 Kubernetes 编排状态对于了解 Kubernetes 执行工作至关重要的原因。我们要验证服务的所有实例都已启动并运行。

原生云爆炸的规模要求

我们需要监控系统,这样能为高水平的服务目标发出警报,另外我们也要保留粒度以根据需要检查各个组件。当采用云原生架构时,它们带来了变化也带走了越来越多的小组件。这就影响了 Kubernetes 监控方法和工具。

随着指标数量的激增,传统的监控系统已无法跟上。虽然过去我们能知道每个服务组件有多少个实例以及它们位于何处,但现在情况已不再如此。现在指标通常具有一定的基数,Kubernetes 会有一些多维级别,例如集群、节点、命名空间、Service 等。许多标签的代表属性来自于微服务的逻辑、应用程序版本、API 端点、特定资源或操作等。

另外,容器不会永远运行下去。据一份容器使用情况报告显示,22% 的容器寿命不超过 10 秒,54% 的容器寿命不到 5 分钟。这会造成很大的变动,容器 ID、Pod 名称之类的标签始终在变化,这也是我们在处理新标签时却再也看不到它们的原因。

现在,我们如果将度量标准的名称、标签与实际值、时间戳一起使用,在短时间内,就将拥有成千上万个数据点,即使是在小型 Kubernetes 集群中,也将生成数十万个时间序列,如果是中型基础架构,可能就是数百万个。这就是为什么 Kubernetes 监控工具需要准备好扩展成千上万个指标。

容器可见性不足

容器的生命周期是短暂的,它一旦死亡,内部的所有东西都将消失,我们无法使用 SSH 或查看日志。容器非常适合操作,我们可以打包、隔离应用程序,在任何地方以一致的方式部署它们,但是同时,它们同样会成为难以排除故障的黑盒。监控工具可以通过系统调用跟踪从而提供详尽的可见性,这样我们可以查看容器内发生的每个进程、文件或网络连接,从而更快地对问题进行故障排除。

考虑到这些因素,我们可以更好地理解为什么监控 Kubernetes 与监控服务器、VM 甚至是云实例有很大不同。

Kubernetes 监控的用例

Kubernetes 集群具有多个组件和层,在每个组件和层中,我们需要监控不同的故障点。以下是 Kubernetes 监控的一些典型用例:

监控 Kubernetes 集群和节点

通过监控集群,您可以全面了解整个平台的运行状况和容量。具体的用例如下:
  • 集群资源使用情况:集群基础架构充分利用了吗?还是产能过剩?
  • 项目和团队分摊资源:每个项目或团队的资源使用量是多少?
  • 节点可用性和运行状况:是否有足够的节点可用于复制我们的应用程序?我们会耗尽资源吗?


监控 Kubernetes deployment 和 Pod

查看诸如命名空间、deployment、副本集或 DaemonSet 之类的 Kubernetes constructs,我们可以了解应用程序是否已正确部署。例如:
* Pod 丢失(Missing)和失败:Pod 是否在我们的应用程序中运行?多少 Pod 快死亡了?
* 正在运行的实例与所需的实例:每个 Service 实际准备了多少个实例?我们需要多少个?
* 请求和限制的 Pod 资源使用情况:是否设置了 CPU 和内存的请求和限制?它们的实际作用是什么?

监控 Kubernetes 应用

归根结底,应用的监控才是最重要的。下面是应用监控的一部分:
  • 应用程序可用性:应用程序是否响应?
  • 应用程序运行状况和性能:我们有多少个请求?多少响应能力或延迟时间?我们有没有出错?


Kubernetes 监控工具

与大多数平台一样,Kubernetes 具有一组基本工具,可以监控平台,包括基于物理基础架构之上的 Kubernetes 构造。由于 Kubernetes 具有可扩展性,它会添加其他组件以获得 Kubernetes 可见性。让我们来看一下 Kubernetes 监控设置的部分:

cAdvisor 和 Heapster

cAdvisor 是一个开源容器资源使用收集器。它专为容器而构建,支持本地 Docker 容器。cAdisor 会自动发现给定节点中的所有容器,并收集CPU、内存、文件系统和网络使用情况统计信息,不过它仅会收集基本资源利用率。仅当容器具有 X%CPU 利用率时,cAdvisor 才能告诉我们应用程序的实际性能。cAdvisor 本身并不提供任何长期存储或分析功能。

在 Kubernetes 上,节点的 kubelet 可以安装 cAdvisor 来监控 Pod 容器资源。

为了进一步处理这些数据,我们需要一些东西来整合整个集群中的数据。最受欢迎的选择是 Heapster。就像任何应用程序一样,Heapster 在集群中作为 Pod 运行。Heapster Pod 从 kubelet 获取有用数据,而 kubelet 本身的数据则是从 cAdvisor 得到,然后 Heapster 按窗格将信息分组,其中也包括相关标签。

在 Kubernetes 中使用 Heapster 和 cAdvisor 进行监控。资料来源:blog.kubernetes.io

Heapster 是一个收集者,而不是采集者,它只是让我们收集整个集群中的 cAdvisor 数据。我们需要将这些数据推送到可配置的后端进行存储和可视化。我们可以添加可视化层(例如 Grafana)查看数据。

虽然 cAdvisor 仍然是通过 kubelet 的默认 Pod 监控组件,但 Heapster 已被弃用,现在 Kubernetes 通过 metric-server 使用指标。

Kubernetes Metric Server

从 Kubernetes v1.8 开始,来自 Kubernetes 和 cAdvisor 的资源使用情况指标可以通过 Kubernetes Metric Server API 获得,这与公开 Kubernetes API 的方式相同。

不过此服务也不允许我们随时间存储值,并且缺乏可视化或分析功能。Kubernetes Metric Server 可用于 Kubernetes 的高级编排,例如 Horizontal Pod Autoscaler 自动伸缩。

Kubernetes 仪表板(Dashboard)

Kubernetes 仪表板提供了一种简单的方式,让我们通过 Kubernetes 命名空间和工作量查看环境。它提供了一种一致的方式来可视化基本数据,包括基本的 CPU、内存数据。另外,我们还可以从仪表板进行管理并采取措施,不过这就涉及到了多租户集群上的安全问题,需要设置适当的 RBAC 特权。

Kubernetes kube-state-metrics

还有一个组件是 kube-state-metrics,这是一项附加服务,它与 Kubernetes metrics-server 一起运行,可轮询 Kubernetes API 并将 Kubernetes 构造的特征转换为指标。kube-state-metrics 可以解决以下问题:
  • 现在计划了多少个副本?目前有多少可用?
  • 有多少个 Pod 正在运行、已停止、已终止?
  • 此 Pod 已重启多少次?


我们现在对在 Kubernetes 环境中构建合理的监控有了一定了解,虽然仍然没有详细的应用程序监控(例如:我的数据库服务的响应时间是多少?),但至少可以看到基础主机、Kubernetes 节点以及 Kubernetes 状态的一些监控。

Kubernetes Liveness 和 Readiness 探针

Kubernetes 探针发挥了定期监控 Pod 的运行状况和可用性的重要作用。它可以让我们通过针对端点的请求和运行命令来任意定义“活动性”。以下是基于运行 cat 命令的 liveness 探针的简单示例:
apiVersion: v1  
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
image: gcr.io/google_containers/busybox
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5 

#source https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

用于 Kubernetes 监控的 Prometheus

Prometheus 是一个是开源的时间序列数据库,它和 Kubernetes 一样是 CNCF 项目。Prometheus 监控是围绕 Prometheus 服务器的整个监控堆栈,该服务器会收集并存储度量,另外还有用于仪表板的 Grafana。
Prometheus 入门非常容易,只要简单设置 Prometheus、Grafana 和很少的元素即可。Prometheus 是监控 Kubernetes 的一种不错方法,我们可以对自己的 Kubernetes 实施 DIY Prometheus 监控。

尽管一开始使用 Prometheus 监控 Kubernetes 真的很简单,但是以后 DevOps 团队会很快意识到 Prometheus 也有一些使用障碍,例如规模、RBAC 以及一些团队合规性问题。

总结

Kubernetes 监控的事实标准是由许多开源工具构建的,例如 cAdvisor、Kubernetes Metric Server、kube-state-metrics 和 Prometheus。总而言之,我们要考虑以适合的方式来监控我们的 Kubernetes。

原文链接: https://mp.weixin.qq.com/s/NimzBHGHCxjTamWyoOyC1A

相关 [kubernetes 监控] 推荐:

Kubernetes 监控详解

- - DockOne.io
【编者的话】监控 Kubernetes 并不是件容易的事. 本文介绍了监控 Kubernetes 的难点、用例以及有关工具,希望可以帮助大家进一步了解监控 Kubernetes. 如果想要监控 Kubernetes,包括基础架构平台和正在运行的工作负载,传统的监控工具和流程可能还不够用. 就目前而言,监控 Kubernetes 并不是件容易的事.

使用Prometheus、Thanos监控Kubernetes集群

- - DockOne.io
当你阅读这篇文章的时候,我相信你一定已经说服了你的经理,或者是公司CTO,选择容器和Kubernetes作为微服务治理平台,去转型升级你们公司的软件产品. 你非常非常的happy,一切都貌似按照计划进行,你创建了你的第一个Kubernetes集群(三大主流云服务提供商,微软云Azure,亚马逊云AWS和谷歌云GCP都提供了非常方便的方式部署Kubernetes平台),你开发了你的第一个容器化应用,然后把它部署到了你的Kubernetes集群上.

Kubernetes & Microservice

- - 午夜咖啡
这是前一段时间在一个微服务的 meetup 上的分享,整理成文章发布出来. 谈微服务之前,先澄清一下概念. 微服务这个词的准确定义很难,不同的人有不同的人的看法. 比如一个朋友是『微服务原教旨主义者』,坚持微服务一定是无状态的 http API 服务,其他的都是『邪魔歪道』,它和 SOA,RPC,分布式系统之间有明显的分界.

Kubernetes 完全教程

- - 午夜咖啡
经过一个阶段的准备,视频版本的 《Kubernetes 完全教程》出炉了. 课程一共分为七节,另外有一节 Docker 预备课,每节课大约一个多小时. 目标是让从没接触过 Kubernetes 的同学也能通过这个课程掌握 Kubernetes. 为什么要学习 Kubernetes. 在介绍课程之前,先说说为什么要学习 Kubernetes 以及什么人需要学习 Kubernetes.

喜大普奔:Spark on kubernetes

- - Zlatan Eevee
两个星期前(08/15/2017),spark社区提了一个新的SPIP(Spark Project Improvement Proposals): Spark on Kubernetes: Kubernetes as A Native Cluster Manager,即用k8s管理spark集群. 经过社区2个星期的投票,看上去很快要能合入了.

Kubernetes 日志收集方案

- - IT瘾-dev
Kubernetes 中的基本日志. Kubernetes 日志收集. 以 sidecar 容器收集日志. 用 sidecar 容器重新输出日志. 使用 sidecar 运行日志采集 agent. 前面的课程中和大家一起学习了 Kubernetes 集群中监控系统的搭建,除了对集群的监控报警之外,还有一项运维工作是非常重要的,那就是日志的收集.

Kubernetes 会不会“杀死” DevOps?

- - InfoQ推荐
DevOps 这个概念最早是在 2007 年提出的,那时云计算基础设施的概念也才刚刚提出没多久,而随着互联网的逐渐普及,应用软件的需求爆发式增长,软件开发的理念也逐渐从瀑布模型(waterfall)转向敏捷开发(agile). 传统的软件交付模式(应用开发人员专注于软件开发、IT 运维人员负责将软件部署到服务器运行),再也无法满足互联网软件快速迭代的需求.

轻量级Kubernetes k3s初探

- - InfoQ推荐
1 k3s简介–5 less than K8s. k3s [1] 是rancher®开源的一个Kubernetes发行版,从名字上就可以看出k3s相对k8s做了很多裁剪和优化,二进制程序不足50MB,占用资源更少,只需要512MB内存即可运行. 而之所以称为k3s是因为相对k8s裁剪了如下5个部分:.

kubernetes dashboard向外网提供服务

- - 学习日志
目前新版本的 kubernetes dashboard ( https://github.com/kubernetes/dashboard)安装了后,为了安全起见,默认情况下已经不向外提供服务,只能通过. http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/ 本机访问.

如何进行kubernetes问题的排障

- - Xinkun Blog
k8s的成熟度很高,伴随着整个项目的扩增,以及新功能和新流程的不断引入,也伴随这产生了一些问题. 虽然自动化测试可以排除掉大部分,但是一些复杂流程以及极端情况却很难做到bug的完全覆盖. 因此在实际的工作过程中,需要对运行的集群进行故障定位和解决. 当然,进行排障的前提是对于k8s的流程和概念进行掌握,对于源码有一定的掌握能力,才可以更好的进行.