乐趣区

关于存储:如何专业化监控一个Kubernetes集群

简介:本文会介绍 Kubernetes 可观测性零碎的构建,以及基于阿里云云产品实现 Kubernetes 可观测零碎构建的最佳实际。

作者:佳旭 阿里云容器服务技术专家

引言

Kubernetes 在生产环境利用的遍及度越来越广、复杂度越来越高,随之而来的稳定性保障挑战也越来越大。

如何构建全面深刻的可观测性架构和体系,是晋升零碎稳定性的要害之因素一。ACK 将可观测性最佳实际进行积淀,以阿里云产品性能的能力对用户透出,可观测性工具和服务成为基础设施,赋能并帮忙用户应用产品性能,晋升用户 Kubernetes 集群的稳定性保障和应用体验。

本文会介绍 Kubernetes 可观测性零碎的构建,以及基于阿里云云产品实现 Kubernetes 可观测零碎构建的最佳实际。

Kubernetes 零碎的可观测性架构

Kubernetes 零碎对于可观测性方面的挑战包含:

  • K8s 零碎架构的复杂性。零碎包含管制面和数据面,各自蕴含多个互相通信的组件,管制面和数据间之间通过 kube-apiserver 进行桥接聚合。
  • 动态性。Pod、Service 等资源动态创建以及调配 IP,Pod 重建后也会调配新的资源和 IP,这就须要基于动静服务发现来获取监测对象。
  • 微服务架构。利用依照微服务架构分解成多个组件,每个组件正本数能够依据弹性进行主动或者人工控制。

针对 Kubernetes 零碎可观测性的挑战,尤其在集群规模快速增长的状况下,高效牢靠的 Kubernetes 零碎可观测性能力,是零碎稳定性保障的基石。

那么,如何晋升建设生产环境下的 Kubernetes 零碎可观测性能力呢?

Kubernetes 零碎的可观测性计划包含指标、日志、链路追踪、K8s Event 事件、NPD 框架等形式。每种形式能够从不同维度透视 Kubernetes 零碎的状态和数据。在生产环境,咱们通常须要综合应用各种形式,有时候还要使用多种形式联动观测,造成欠缺平面的可观测性体系,进步对各种场景的覆盖度,进而晋升 Kubernetes 零碎的整体稳定性。上面会概述生产环境下对 K8s 零碎的可观测性解决方案。

指标(Metrics)

Prometheus 是业界指标类数据采集计划的事实标准,是开源的零碎监测和报警框架,灵感源自 Google 的 Borgmon 监测零碎。2012 年,SoundCloud 的 Google 前员工发明了 Prometheus,并作为社区开源我的项目进行开发。2015 年,该我的项目正式公布。2016 年,Prometheus 退出 CNCF 云原生计算基金会。

Prometheus 具备以下个性:

  • 多维的数据模型(基于工夫序列的 Key、Value 键值对)
  • 灵便的查问和聚合语言 PromQL
  • 提供本地存储和分布式存储
  • 通过基于 HTTP 的 Pull 模型采集工夫序列数据
  • 可利用 Pushgateway(Prometheus 的可选中间件)实现 Push 模式
  • 可通过动静服务发现或动态配置发现指标机器
  • 反对多种图表和数据大盘

Prometheus 能够周期性采集组件裸露在 HTTP(s) 端点的 /metrics 上面的指标数据,并存储到 TSDB,实现基于 PromQL 的查问和聚合性能。

对于 Kubernetes 场景下的指标,能够从如下角度分类:

  1. 容器根底资源指标

采集源为 kubelet 内置的 cAdvisor,提供容器内存、CPU、网络、文件系统等相干的指标,指标样例包含:

容器以后内存应用字节数 container\_memory\_usage\_bytes;

容器网络接管字节数 container\_network\_receive\_bytes\_total;

容器网络发送字节数 container\_network\_transmit\_bytes\_total,等等。

  1. Kubernetes 节点资源指标

采集源为 node\_exporter,提供节点零碎和硬件相干的指标,指标样例包含:节点总内存 node\_memory\_MemTotal\_bytes,节点文件系统空间 node\_filesystem\_size\_bytes,节点网络接口 ID node\_network\_iface\_id,等等。基于该类指标,能够统计节点的 CPU/ 内存 / 磁盘使用率等节点级别指标。

  1. Kubernetes 资源指标

采集源为 kube-state-metrics,基于 Kubernetes API 对象生成指标,提供 K8s 集群资源指标,例如 Node、ConfigMap、Deployment、DaemonSet 等类型。以 Node 类型指标为例,包含节点 Ready 状态指标 kube\_node\_status\_condition、节点信息 kube\_node\_info 等等。

  1. Kubernetes 组件指标

Kubernetes 零碎组件指标。例如 kube-controller-manager, kube-apiserver,kube-scheduler, kubelet,kube-proxy、coredns 等。

Kubernetes 运维组件指标。可观测类包含 blackbox\_operator, 实现对用户自定义的探活规定定义;gpu\_exporter,实现对 GPU 资源的透出能力。

Kubernetes 业务利用指标。包含具体的业务 Pod 在 /metrics 门路透出的指标,以便内部进行查问和聚合。

除了上述指标,K8s 提供了通过 API 形式对外透出指标的监测接口标准,具体包含 Resource Metrics,Custom Metrics 和 External Metrics 三类。

<span> 监测接口标准 </span> <span>APIService 地址 </span> <span> 接口应用场景形容 </span>
<span>Resource Metrics</span> metrics.k8s.io<span class=”lake-fontsize-11″>http://metrics.k8s.io/</span> <span> 次要用于 Kubernetes 内置的生产链路,通常由 Metrcis-Server 提供。</span>
<span>Custom Metrics</span> custom.metrics.k8s.io<span class=”lake-fontsize-11″>http://custom.metrics.k8s.io/</span> <span> 次要的实现为 Prometheus,提供资源监测和自定义监测。</span>
<span>External Metrics</span> external.metrics.k8s.io<span class=”lake-fontsize-11″>http://external.metrics.k8s.io/</span> <span> 次要的实现为云厂商的 Provider,提供云资源的监测指标。</span>

Resource Metrics 类对应接口 metrics.k8s.io,次要的实现就是 metrics-server,它提供资源的监测,比拟常见的是节点级别、pod 级别、namespace 级别。这些指标能够通过 kubectl top 间接拜访获取,或者通过 K8s controller 获取,例如 HPA(Horizontal Pod Autoscaler)。零碎架构以及拜访链路如下:

Custom Metrics 对应的 API 是 custom.metrics.k8s.io,次要的实现是 Prometheus。它提供的是资源监测和自定义监测,资源监测和下面的资源监测其实是有笼罩关系的,而这个自定义监测指的是:比方利用下面想裸露一个相似像在线人数,或者说调用前面的这个数据库的 MySQL 的慢查问。这些其实都是能够在应用层做本人的定义的,而后并通过规范的 Prometheus 的 client,暴露出相应的 metrics,而后再被 Prometheus 进行采集。

而这类的接口一旦采集上来也是能够通过相似像 custom.metrics.k8s.io 这样一个接口的规范来进行数据生产的,也就是说当初如果以这种形式接入的 Prometheus,那你就能够通过 custom.metrics.k8s.io 这个接口来进行 HPA,进行数据生产。零碎架构以及拜访链路如下:

External Metrics。因为咱们晓得 K8s 当初曾经成为了云原生接口的一个实现规范。很多时候在云上打交道的是云服务,比如说在一个利用外面用到了后面的是音讯队列,前面的是 RBS 数据库。那有时在进行数据生产的时候,同时须要去生产一些云产品的监测指标,相似像音讯队列中音讯的数目,或者是接入层 SLB 的 connection 数目,SLB 下层的 200 个申请数目等等,这些监测指标。

那怎么去生产呢?也是在 K8s 外面实现了一个规范,就是 external.metrics.k8s.io。次要的实现厂商就是各个云厂商的 provider,通过这个 provider 能够通过云资源的监测指标。在阿里云下面也实现了阿里巴巴 cloud metrics adapter 用来提供这个规范的 external.metrics.k8s.io 的一个实现。

## 日志(Logging)

概要来说包含:

* 主机内核的日志。主机内核日志能够帮助开发者诊断例如:网络栈异样,驱动异样,文件系统异样,影响节点(内核)稳固的异样。

* Runtime 日志。最常见的运行时是 Docker,能够通过 Docker 的日志排查例如删除 Pod Hang 等问题。

* K8s 组件日志。APIServer 日志能够用来审计,Scheduler 日志能够诊断调度,etcd 日志能够查看存储状态,Ingress 日志能够剖析接入层流量。

* 利用日志。能够通过利用日志剖析查看业务层的状态,诊断异样。

日志的采集形式分为被动采集和被动推送两种,在 K8s 中,被动采集个别分为 Sidecar 和 DaemonSet 两种形式,被动推送有 DockerEngine 推送和业务直写两种形式。

* DockerEngine 自身具备 LogDriver 性能,可通过配置不同的 LogDriver 将容器的 stdout 通过 DockerEngine 写入到远端存储,以此达到日志采集的目标。这种形式的可定制化、灵活性、资源隔离性都很低,个别不倡议在生产环境中应用;
* 业务直写是在利用中集成日志采集的 SDK,通过 SDK 间接将日志发送到服务端。这种形式省去了落盘采集的逻辑,也不须要额定部署 Agent,对于零碎的资源耗费最低,但因为业务和日志 SDK 强绑定,整体灵活性很低,个别只有日志量极大的场景中应用;
* DaemonSet 形式在每个 node 节点上只运行一个日志 agent,采集这个节点上所有的日志。DaemonSet 绝对资源占用要小很多,但扩展性、租户隔离性受限,比拟实用于性能繁多或业务不是很多的集群;
* Sidecar 形式为每个 POD 独自部署日志 agent,这个 agent 只负责一个业务利用的日志采集。Sidecar 绝对资源占用较多,但灵活性以及多租户隔离性较强,倡议大型的 K8s 集群或作为 PaaS 平台为多个业务方服务的集群应用该形式。

挂载宿主机采集、规范输入输出采集、Sidecar 采集。

总结下来:

* DockerEngine 直写个别不举荐;
* 业务直写举荐在日志量极大的场景中应用;
* DaemonSet 个别在中小型集群中应用;
* Sidecar 举荐在超大型的集群中应用。

####

## 事件(Event)

事件监测是实用于 Kubernetes 场景的一种监测形式。事件蕴含了产生的工夫、组件、等级(Normal、Warning)、类型、详细信息,通过事件咱们可能晓得利用的部署、调度、运行、进行等整个生命周期,也能通过事件去理解零碎中正在产生的一些异样。

K8s 中的一个设计理念,就是基于状态机的一个状态转换。从失常的状态转换成另一个失常的状态的时候,会产生一个 Normal 的事件,而从一个失常状态转换成一个异样状态的时候,会产生一个 Warning 的事件。通常状况下,Warning 的事件是咱们比较关心的。事件监测就是把 Normal 的事件或者是 Warning 事件汇聚到数据中心,而后通过数据中心的剖析以及报警,把相应的一些异样通过像钉钉、短信、邮件等形式进行裸露,实现与其余监测的补充与欠缺。

Kubernetes 中的事件是存储在 etcd 中,默认状况下只保留 1 个小时,无奈实现较长周期范畴的剖析。将事件进行长期存储以及定制化开发后,能够实现更加丰盛多样的剖析与告警:

* 对系统中的异样事件做实时告警,例如 Failed、Evicted、FailedMount、FailedScheduling 等。
* 通常问题排查可能要去查找历史数据,因而须要去查问更长时间范畴的事件(几天甚至几个月)。
* 事件反对归类统计,例如可能计算事件产生的趋势以及与上一时间段(昨天 / 上周 / 公布前)比照,以便基于统计指标进行判断和决策。
* 反对不同的人员依照各种维度去做过滤、筛选。
* 反对自定义的订阅这些事件去做自定义的监测,以便和公司外部的部署运维平台集成。

## NPD(Node Problem Detector)框架

Kubernetes 集群及其运行容器的稳定性,强依赖于节点的稳定性。Kubernetes 中的相干组件只关注容器治理相干的问题,对于硬件、操作系统、容器运行时、依赖零碎(网络、存储等)并不会提供更多的检测能力。NPD(Node Problem Detector)针对节点的稳定性提供了诊断查看框架,在默认查看策略的根底上,能够灵便扩大查看策略,能够将节点的异样转换为 Node 的事件,推送到 APIServer 中,由同一的 APIServer 进行事件治理。

NPD 反对多种异样查看,例如:

* 根底服务问题:NTP 服务未启动
* 硬件问题:CPU、内存、磁盘、网卡损坏
* Kernel 问题:Kernel hang,文件系统损坏
* 容器运行时问题:Docker hang,Docker 无奈启动
* 资源问题:OOM 等

综上,本章节总结了常见的 Kubernetes 可观测性计划。在生产环境,咱们通常须要综合应用各种计划,造成平面多维度、互相补充的可观测性体系;可观测性计划部署后,须要基于上述计划的输入后果疾速诊断异样和谬误,无效升高误报率,并有能力保留、回查以及剖析历史数据;进一步延长,数据能够提供给机器学习以及 AI 框架,实现弹性预测、异样诊断剖析、智能运维 AIOps 等高级利用场景。

这须要可观测性最佳实际作为根底,包含如何设计、插件化部署、配置、降级上述各种可观测性计划架构,如何基于输入后果疾速精确诊断剖析跟因等等。阿里云容器服务 ACK 以及相干云产品(监测服务 ARMS、日志服务 SLS 等),将云厂商的最佳实际通过产品化能力实现、赋能用户,提供了欠缺全面的解决方案,能够让用户疾速部署、配置、降级、把握阿里云的可观测性计划,显著晋升了企业上云和云原生化的效率和稳定性、升高技术门槛和综合老本。

上面将以 ACK 最新的产品状态 ACK Pro 为例,联合相干云产品,介绍 ACK 的可观测性解决方案和最佳实际。

# ACK 可观测性能力

## 指标(Metrics)可观测性计划

对于指标类可观测性,ACK 能够反对开源 Prometheus 监测和阿里云 Prometheus 监测(阿里云 Prometheus 监测是 ARMS 产品子产品)两种可观测性计划。

开源 Prometheus 监测,以 helm 包模式提供、适配阿里云环境、集成了钉钉告警、存储等性能;部署入口在控制台的利用目录中 ack-prometheus-operator,用户配置后能够在 ACK 控制台一键部署。用户只须要在阿里云 ACK 控制台配置 helm 包参数,就能够定制化部署。

阿里云 Prometheus 监测,是 ARMS 产品子产品。利用实时监测服务 (Application Real-Time Monitoring Service, 简称 ARMS) 是一款利用性能治理产品,蕴含前端监测,利用监测和 Prometheus 监测三大子产品。

在 2021 年的 Gartner 的 APM 魔力象限评测中,阿里云利用实时监测服务(ARMS)作为阿里云 APM 的外围产品,联结云监测以及日志服务独特参加。Gartner 评估阿里云 APM:

* 中国影响力最强:阿里云是中国最大的云服务提供商,阿里云用户能够应用云上监测工具来满足其可观测性需求。

* 开源集成:阿里云非常重视将开源规范和产品(例如 Prometheus)集成到其平台中。

* 老本劣势:与在阿里云上应用第三方 APM 产品相比,阿里云 APM 产品具备更高的老本效益。

下图概要比照了开源 Prometheus 和阿里云 Prometheus 的模块划分和数据链路。

ACK 反对 CoreDNS、集群节点、集群详情等 K8s 可观测性能力;除此之外,ACK Pro 还反对托管的管控组件 Kube API Server、Kube Scheduler 和 Etcd 的可观测性能力,并继续迭代。用户能够通过在阿里云 Prometheus 中丰盛的监测大盘,联合告警能力,疾速发现 K8s 集群的零碎问题以及潜在危险,及时采取相应措施以保障集群稳定性。监测大盘集成了 ACK 最佳实际的教训,能够帮忙用户从多维度剖析剖析、定位问题。上面介绍如何基于最佳实际设计可观测性大盘,并列举应用监测大盘定位问题的具体案例,帮忙了解如何应用可观测性能力。

首先来看 ACK Pro 的可观测性能力。监测大盘入口如下:

APIServer 是 K8s 外围组件之一,是 K8s 组件进行交互的枢纽,ACK Pro APIServer 的监测大盘设计思考到用户能够抉择须要监测的 APIServer Pod 来剖析繁多指标、聚合指标以及申请起源等,同时能够下钻到某一种或者多种 API 资源联动观测 APIServer 的指标,这样的劣势是既能够全局观测全副 APIServer Pod 的全局视图,又能够下钻观测到具体 APIServer Pod 以及具体 API 资源的监测,监测全副和部分观测能力,对于定位问题十分无效。所以依据 ACK 的最佳实际,实现上蕴含了如下 5 个模块:

* 提供 APIServer Pod、API 资源(Pods,Nodes,ConfigMaps 等)、分位数(0.99,0.9,0.5)、统计工夫距离的筛选框,用户通过管制筛选框,能够联动管制监测大盘实现联动
* 凸显要害指标以便识别系统要害状态
* 展现 APIServer RT、QPS 等单项指标的监测大盘,实现繁多维度指标的观测
* 展现 APIServer RT、QPS 等聚合指标的监测大盘,实现多维度指标的观测
* 展现对 APIServer 拜访的客户端起源剖析,实现拜访源的剖析

上面概要介绍模块的实现。

#####

### 要害指标

显示了外围的指标,包含 APIServer 总 QPS、读申请成功率、写申请成功率、Read Inflight Request、Mutating Inflight Request 以及单位工夫抛弃申请数量 Dropped Requests Rate。

这些指标能够概要展现零碎状态是否失常,例如如果 Dropped Requests Rate 不为 NA,阐明 APIServer 因为解决申请的能力不能满足申请呈现抛弃申请,须要立刻定位解决。

### Cluster-Level Summary

包含读非 LIST 读申请 RT、LIST 读申请 RT、写申请 RT、读申请 Inflight Request、批改申请 Inflight Request 以及单位工夫抛弃申请数量,该局部大盘的实现联合了 ACK 最佳实践经验。

对于响应工夫的可观测性,能够直观的察看到不同工夫点以及区间内,针对不同资源、不同操作、不同范畴的响应工夫。能够抉择不同的分位数,来筛选。有两个比拟重要的考察点:

1. 曲线是否间断
2. RT 工夫

先来解释曲线的连续性。通过曲线的连续性,能够很直观的看出申请是继续的申请,还是繁多的申请。

下图示意在采样周期内,APIServer 收到 PUT leases 的申请,每个采样期内 P90 RT 是 45ms。

因为图中曲线是间断,阐明该申请在全副采样周期都存在,所以是继续的申请。

下图示意在采样周期内,APIServer 收到 LIST daemonsets 的申请,有样值的采样周期内 P90 RT 是 45ms。

因为图中只有一次,阐明该申请只是在一次采样周期存在。该场景来自于用户执行 kubectl get ds –all-namespaces 产生的申请记录。

再来解释曲线体现的 RT。

用户执行命令创立 1MB 的 configmap,申请连贯到公网 SLBkubectl create configmap cm1MB –from-file=cm1MB=./configmap.file

APIServer 记录的日志中,该次申请 POST configmaps RT 为 9.740961791s,该值能够落入 apiserver\_request\_duration\_seconds\_bucket 的 (8, 9] 区间,所以会在 apiserver\_request\_duration\_seconds\_bucket 的 le=9 对应的 bucket 中减少一个样点,可观测性展现中依照 90 分位数,计算失去 9.9s 并图形化展现。这就是日志中记录的申请实在 RT 与可观测性展现中的展现 RT 的关联关系。

所以监测大盘既能够与日志可观测性能联结应用,又能够直观概要的以全局视图展现日志中的信息,最佳实际倡议联合监测大盘和日志可观测性做综合剖析。

`
I0215 23:32:19.226433 1 trace.go:116] Trace[1528486772]: “Create” url:/api/v1/namespaces/default/configmaps,user-agent:kubectl/v1.18.8 (linux/amd64) kubernetes/d2f5a0f,client:39.x.x.10,request_id:a1724f0b-39f1-40da-b36c-e447933ef37e (started: 2021-02-15 23:32:09.485986411 +0800 CST m=+114176.845042584) (total time: 9.740403082s):
Trace[1528486772]: [9.647465583s] [9.647465583s] About to convert to expected version
Trace[1528486772]: [9.660554709s] [13.089126ms] Conversion done
Trace[1528486772]: [9.660561026s] [6.317µs] About to store object in database
Trace[1528486772]: [9.687076754s] [26.515728ms] Object stored in database
Trace[1528486772]: [9.740403082s] [53.326328ms] END
I0215 23:32:19.226568 1 httplog.go:102] requestID=a1724f0b-39f1-40da-b36c-e447933ef37e verb=POST URI=/api/v1/namespaces/default/configmaps latency=9.740961791s resp=201 UserAgent=kubectl/v1.18.8 (linux/amd64) kubernetes/d2f5a0f srcIP=”10.x.x.10:59256″ ContentType=application/json:
`

上面解释一下 RT 与申请的具体内容以及集群规模有间接的关联。

在上述创立 configmap 的例子中,同样是创立 1MB 的 configmap,公网链路受网路带宽和时延影响,达到了 9s;而在内网链路的测试中,只须要 145ms,网络因素的影响是显著的。

所以 RT 与申请操作的资源对象、字节尺寸、网络等有关联关系,网络越慢,字节尺寸越大,RT 越大。

对于大规模 K8s 集群,全量 LIST(例如 pods,nodes 等资源)的数据量有时候会很大,导致传输数据量减少,也会导致 RT 减少。所以对于 RT 指标,没有相对的衰弱阈值,肯定须要联合具体的申请操作、集群规模、网络带宽来综合评定,如果不影响业务就能够承受。

对于小规模 K8s 集群,均匀 RT 45ms 到 100ms 是能够承受的;对于节点规模上 100 的集群,均匀 RT 100ms 到 200ms 是能够承受的。

然而如果 RT 继续达到秒级,甚至 RT 达到 60s 导致申请超时,少数状况下呈现了异样,须要进一步定位解决是否合乎预期。

这两个指标通过 APIServer /metrics 对外透出,能够执行如下命令查看 inflight requests,是掂量 APIServer 解决并发申请能力的指标。如果申请并发申请过多达到 APIServer 参数 max-requests-inflight 和 max-mutating-requests-inflight 指定的阈值,就会触发 APIServer 限流。通常这是异常情况,须要疾速定位并解决。

### QPS & Latency

该局部能够直观显示申请 QPS 以及 RT 依照 Verb、API 资源进行分类的状况,以便进行聚合剖析。还能够展现读、写申请的错误码分类,能够直观发现不同工夫点下申请返回的错误码类型。

### Client Summary

该局部能够直观显示申请的客户端以及操作和资源。

QPS By Client 能够按客户端维度,统计不同客户端的 QPS 值。

QPS By Verb + Resource + Client 能够按客户端、Verb、Resource 维度,统计单位工夫(1s)内的申请散布状况。

基于 ARMS Prometheus,除了 APIServer 大盘,ACK Pro 还提供了 Etcd 和 Kube Scheduler 的监测大盘;ACK 和 ACK Pro 还提供了 CoreDNS、K8s 集群、K8s 节点、Ingress 等大盘,这里不再一一介绍,用户能够查看 ARMS 的大盘。这些大盘联合了 ACK 和 ARMS 的在生产环境的最佳实际,能够帮忙用户以最短门路观测零碎、发现问题本源、进步运维效率。

## 日志(Logging)可观测性计划

SLS  阿里云日志服务是阿里云规范的日志计划,对接各种类型的日志存储。

对于托管侧组件的日志,ACK 反对托管集群管制立体组件(kube-apiserver/kube-controller-manager/kube-scheduler)日志透出,将日志从 ACK 管制层采集到到用户 SLS 日志服务的 Log Project 中。

对于用户侧日志,用户能够应用阿里云的 logtail、log-pilot 技术计划将须要的容器、零碎、节点日志收集到 SLS 的 logstore,随后就能够在 SLS 中不便的查看日志。

## 事件(Event)可观测性计划 + NPD 可观测性计划

Kubernetes 的架构设计基于状态机,不同的状态之间进行转换则会生成相应的事件,失常的状态之间转换会生成 Normal 等级的事件,失常状态与异样状态之间的转换会生成 Warning 等级的事件。

ACK 提供开箱即用的容器场景事件监测计划,通过 ACK 保护的 NPD(node-problem-detector)以及蕴含在 NPD 中的 kube-eventer 提供容器事件监测能力。

* NPD(node-problem-detector)是 Kubernetes 节点诊断的工具,能够将节点的异样,例如 Docker Engine Hang、Linux Kernel Hang、网络出网异样、文件描述符异样转换为 Node 的事件,联合 kube-eventer 能够实现节点事件告警的闭环。
* kube-eventer 是 ACK 保护的开源 Kubernetes 事件离线工具,能够将集群的事件离线到钉钉、SLS、EventBridge 等零碎,并提供不同等级的过滤条件,实现事件的实时采集、定向告警、异步归档。

NPD 依据配置与第三方插件检测节点的问题或故障,生成相应的集群事件。而 Kubernetes 集群本身也会因为集群状态的切换产生各种事件。例如 Pod 驱赶,镜像拉取失败等异常情况。日志服务 SLS(Log Service)的 Kubernetes 事件核心实时汇聚 Kubernetes 中的所有事件并提供存储、查问、剖析、可视化、告警等能力。

# ACK 可观测性瞻望

ACK 以及相干云产品对 Kubernetes 集群曾经实现了全面的观测能力,包含指标、日志、链路追踪、事件等。前面倒退的方向包含:

* 开掘更多利用场景,将利用场景与可观测性关联,帮忙用户更好的应用 K8s。例如监测一段时间内 Pod 中容器的内存 /CPU 等资源水位,利用历史数据分析用户的 Kubernets 容器资源 requests/limits 是否正当,如果不合理给出举荐的容器资源 requests/limits;监测集群 APIServer RT 过大的申请,主动剖析异样申请的起因以及解决倡议;
* 联动多种可观测性技术计划,例如 K8s 事件和指标监测,提供更加丰盛和更多维度的可观测性能力。

咱们置信 ACK 可观测性将来的倒退方向会越来越广大,给客户带来越来越杰出的技术价值和社会价值!

> 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

退出移动版