如何专业化监控一个Kubernetes集群？

时间  2021-06-13 标签 前端 node linux 数据库 json api 网络 架构 并发 app
简介：本文会介绍 Kubernetes 可观测性系统的构建，以及基于阿里云云产品实现 Kubernetes 可观测系统构建的最佳实践。

做者：佳旭 阿里云容器服务技术专家前端

引言

Kubernetes 在生产环境应用的普及度愈来愈广、复杂度愈来愈高，随之而来的稳定性保障挑战也愈来愈大。node

如何构建全面深刻的可观测性架构和体系，是提高系统稳定性的关键之因素一。ACK将可观测性最佳实践进行沉淀，以阿里云产品功能的能力对用户透出，可观测性工具和服务成为基础设施，赋能并帮助用户使用产品功能，提高用户 Kubernetes 集群的稳定性保障和使用体验。linux

本文会介绍 Kubernetes 可观测性系统的构建，以及基于阿里云云产品实现 Kubernetes 可观测系统构建的最佳实践。数据库

Kubernetes 系统的可观测性架构

Kubernetes 系统对于可观测性方面的挑战包括：json

  • K8s 系统架构的复杂性。系统包括控制面和数据面，各自包含多个相互通讯的组件，控制面和数据间之间经过 kube-apiserver 进行桥接聚合。
  • 动态性。Pod、Service 等资源动态建立以及分配 IP，Pod 重建后也会分配新的资源和 IP，这就须要基于动态服务发现来获取监测对象。
  • 微服务架构。应用按照微服务架构分解成多个组件，每一个组件副本数能够根据弹性进行自动或者人工控制。

针对 Kubernetes 系统可观测性的挑战，尤为在集群规模快速增加的状况下，高效可靠的 Kubernetes 系统可观测性能力，是系统稳定性保障的基石。api

那么，如何提高建设生产环境下的 Kubernetes 系统可观测性能力呢？网络

Kubernetes 系统的可观测性方案包括指标、日志、链路追踪、K8s Event 事件、NPD 框架等方式。每种方式能够从不一样维度透视 Kubernetes 系统的状态和数据。在生产环境，咱们一般须要综合使用各类方式，有时候还要运用多种方式联动观测，造成完善立体的可观测性体系，提升对各类场景的覆盖度，进而提高 Kubernetes 系统的总体稳定性。下面会概述生产环境下对 K8s 系统的可观测性解决方案。架构

指标（Metrics）

Prometheus 是业界指标类数据采集方案的事实标准，是开源的系统监测和报警框架，灵感源自 Google 的 Borgmon 监测系统。2012 年，SoundCloud 的 Google 前员工创造了 Prometheus，并做为社区开源项目进行开发。2015 年，该项目正式发布。2016 年，Prometheus 加入 CNCF 云原生计算基金会。并发

Prometheus 具备如下特性：app

  • 多维的数据模型（基于时间序列的 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)。系统架构以及访问链路以下： image.png Custom Metrics 对应的 API 是 custom.metrics.k8s.io，主要的实现是 Prometheus。它提供的是资源监测和自定义监测，资源监测和上面的资源监测实际上是有覆盖关系的，而这个自定义监测指的是：好比应用上面想暴露一个相似像在线人数，或者说调用后面的这个数据库的 MySQL 的慢查询。这些其实都是能够在应用层作本身的定义的，而后并经过标准的 Prometheus 的 client，暴露出相应的 metrics，而后再被 Prometheus 进行采集。 而这类的接口一旦采集上来也是能够经过相似像 custom.metrics.k8s.io 这样一个接口的标准来进行数据消费的，也就是说如今若是以这种方式接入的 Prometheus，那你就能够经过 custom.metrics.k8s.io 这个接口来进行 HPA，进行数据消费。系统架构以及访问链路以下： image.png 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 采集。 image.png 总结下来： * 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 等 image.png 综上，本章节总结了常见的 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 包参数，就能够定制化部署。 image.png 阿里云 Prometheus监测，是 ARMS 产品子产品。应用实时监测服务 (Application Real-Time Monitoring Service, 简称 ARMS) 是一款应用性能管理产品，包含前端监测，应用监测和 Prometheus 监测三大子产品。 在 2021 年的 Gartner 的 APM 魔力象限评测中，阿里云应用实时监测服务（ARMS）做为阿里云 APM 的核心产品，联合云监测以及日志服务共同参与。Gartner 评价阿里云 APM： * 中国影响力最强：阿里云是中国最大的云服务提供商，阿里云用户可使用云上监测工具来知足其可观测性需求。 * 开源集成：阿里云很是重视将开源标准和产品（例如 Prometheus）集成到其平台中。 * 成本优点：与在阿里云上使用第三方 APM 产品相比，阿里云 APM 产品具备更高的成本效益。 下图概要对比了开源 Prometheus 和阿里云 Prometheus 的模块划分和数据链路。 image.png ACK 支持 CoreDNS、集群节点、集群概况等 K8s 可观测性能力；除此以外，ACK Pro 还支持托管的管控组件 Kube API Server、Kube Scheduler 和 Etcd 的可观测性能力，并持续迭代。用户能够经过在阿里云 Prometheus 中丰富的监测大盘，结合告警能力，快速发现 K8s 集群的系统问题以及潜在风险，及时采起相应措施以保障集群稳定性。监测大盘集成了 ACK 最佳实践的经验，能够帮助用户从多维度分析分析、定位问题。下面介绍如何基于最佳实践设计可观测性大盘，并列举使用监测大盘定位问题的具体案例，帮助理解如何使用可观测性能力。 首先来看 ACK Pro 的可观测性能力。监测大盘入口以下： image.png 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 访问的客户端来源分析，实现访问源的分析 下面概要介绍模块的实现。 ##### ### 关键指标 image.png 显示了核心的指标，包括 APIServer 总 QPS、读请求成功率、写请求成功率、Read Inflight Request、Mutating Inflight Request 以及单位时间丢弃请求数量 Dropped Requests Rate。 这些指标能够概要展现系统状态是否正常，例如若是 Dropped Requests Rate 不为 NA，说明 APIServer 由于处理请求的能力不能知足请求出现丢弃请求，须要当即定位处理。 ### Cluster-Level Summary image.png 包括读非 LIST 读请求 RT、LIST 读请求 RT、写请求 RT、读请求 Inflight Request、修改请求 Inflight Request 以及单位时间丢弃请求数量，该部分大盘的实现结合了 ACK 最佳实践经验。 对于响应时间的可观测性，能够直观的观察到不一样时间点以及区间内，针对不一样资源、不一样操做、不一样范围的响应时间。能够选择不一样的分位数，来筛选。有两个比较重要的考察点： 1. 曲线是否连续 2. RT 时间 先来解释曲线的连续性。经过曲线的连续性，能够很直观的看出请求是持续的请求，仍是单一的请求。 下图表示在采样周期内，APIServer 收到 PUT leases 的请求，每一个采样期内 P90 RT 是 45ms。 由于图中曲线是连续，说明该请求在所有采样周期都存在，因此是持续的请求。 image.png 下图表示在采样周期内，APIServer 收到 LIST daemonsets 的请求，有样值的采样周期内 P90 RT 是 45ms。 由于图中只有一次，说明该请求只是在一次采样周期存在。该场景来自于用户执行 kubectl get ds --all-namespaces 产生的请求记录。 image.png 再来解释曲线体现的 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: ` image.png 下面解释一下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 image.png 该部分能够直观显示请求 QPS 以及 RT 按照 Verb、API 资源进行分类的状况，以便进行聚合分析。还能够展现读、写请求的错误码分类，能够直观发现不一样时间点下请求返回的错误码类型。 ### Client Summary image.png 该部分能够直观显示请求的客户端以及操做和资源。 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 中方便的查看日志。 image.png image.png ## 事件（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 中的全部事件并提供存储、查询、分析、可视化、告警等能力。 image.png # ACK可观测性展望 ACK 以及相关云产品对 Kubernetes 集群已经实现了全面的观测能力，包括指标、日志、链路追踪、事件等。后面发展的方向包括： * 挖掘更多应用场景，将应用场景与可观测性关联，帮助用户更好的使用K8s。例如监测一段时间内 Pod 中容器的内存/CPU 等资源水位，利用历史数据分析用户的Kubernets 容器资源 requests/limits 是否合理，若是不合理给出推荐的容器资源 requests/limits；监测集群 APIServer RT 过大的请求，自动分析异常请求的缘由以及处理建议； * 联动多种可观测性技术方案，例如K8s事件和指标监测，提供更加丰富和更多维度的可观测性能力。 咱们相信 ACK 可观测性将来的发展方向会愈来愈广阔，给客户带来愈来愈出色的技术价值和社会价值！ > 本文内容由阿里云实名注册用户自发贡献，版权归原做者全部，阿里云开发者社区不拥有其著做权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将马上删除涉嫌侵权内容。
联系我们 沪ICP备13005482号-10