前言
随着k8s集群在集团的大规模应用，k8s集群在集团大大小小几十个，有的分布在IDC机房，有的使用云上资源。了解过k8s的老师应该知道k8s发现问题主要使用事件进行发现,但是统一收集事件就变得困难重重。针对这种现状集群的统一管理和稳定性建设变得极为棘手，IaaS团队着手研发了一套事件中心。事件中心除传统Kubernetes事件外，还采集主机硬件错误、内核错误、docker错误等。从事件中心上线后收集80+线上线下集群问题，定位硬件问题数十起，每日发现应用问题数百起。
除了事件收集外，分析事件问题也是建立稳定性保障机制的桥梁。通过分析事件能快速定位相关问题，并定向解决部分问题，可通过组件实现自愈修复。
目前事件中心作为底层服务，支持任何k8s集群自由接入，不依赖任何容器Paas服务。如果您需要一套定位问题、发现问题、分析问题、自愈修复问题的方案解决系统,欢迎您接入容器IaaS服务。
1 事件中心架构设计
在设计初期，IaaS团队对事件中心对定位主要方向： 发现问题 、收集问题、 主动告警 、 问题分析 、 问题自愈。在这个方向的前提下建立一个可观测性的系统，随着这个初心IaaS系统-事件中心就诞生了,可以一起来看一下事件中心架构图，如图1-1所示。
::: hljs-center
:::
- 控制面： 用户管理控制容器IaaS相关信息。例如"事件总览"，如图1-2所示。
::: hljs-center
:::
事件总览模块可以根据不同的指标快速定位到硬件以及应用相关问题,就拿“节点内存报警”而言，就发现过多起内存条故障，如图1-3所示。事件总览模块点击详细后可以直接定位到集群和具体内容。
::: hljs-center
:::
除事件模块以外，Kubernetes事件分析模块可以分析各集群间事件问题占比，根据分析可以针对故障占比进行整改。
- 数据面： 数据面主要提供给控制面的api支持，以及与容器基础组件交互。
- eventMesh组件： 由IaaS团队研发基础组件，核心功能主要为跨集群、跨IDC、跨云服务收集事件，并且路由分发通知告警。
- npd组件： node-problem-detector组件，kubernetes官方组件。npd组件目前基础社区组件，IaaS团队进行二次开发，支持自定义指标采集以及自愈功能自主扩展。
- 数仓： 目前数仓使用AnalyticDB。由于每天集群的事件产生量级其实挺大的，目前是在组件层面过滤掉一些，如果在未过滤状态下单集群可能在数十万左右，甚至有些在百万左右,光线上就纳管80+集群。上数仓也是在数据分析上助力。
2 核心组件介绍
2.1 npd组件
在k8s集群上通常只是管制集群本身以容器稳定运行，但是这些未定型都是强依赖Node节点的稳定性。在Node节点的管理是k8s比较弱的，从k8s的设计来说，这些事都归属于Iaas。不过虽则k8s的发展，它变成来一个操作系统，管理的事情也越来越多。所以Node也纳入k8s的管理里，并延伸了npd（Node Problem Detector）组件。
::: hljs-center
:::
NPD组件是以DaemonSet方式部署，NPD组件支持多种monitor来检测不同的错误类型，然后把这些错误信息通过Event和NodeCondition将问题报告给APIServer。
- NodeCondition：导致节点无法处理于Pod生命周期的的永久性问题应报告为NodeCondition。
- Event：对pod影响有限的临时问题应作为event报告。
2.1.1 问题检测类型
::: hljs-center
:::
NPD采集资源主要有极大部分分别为: network、ABRT、docker、health、kernel、systemd这几个部分，如图2-2所示。
::: hljs-center
:::
然而每个部分都对应在NPD组件的config配置中的json，如图2-3所示。对应的custom-plugin-monitor.json可以进行扩展自定义指标,实现一些满足自身情况的逻辑。
2.1.2 支持的选项
| 配置 | 描述 |
|---|---|
| –version | 显示当前版本。 |
| –hostname-override | 用于node-problem-detector的自定义节点名称，用于更新condition并发出event。node-problem-detector首先从hostname-override获取节点名称，然后从NODE_NAME环境变量获取节点名称，最后从os.Hostname返回。 |
| –config.system-log-monitor | 系统日志监控器配置文件的路径列表，以逗号分隔，例如 config/kernel-monitor.json。node-problem-detector将为每个配置启动一个单独的日志监视器。您可以使用不同的日志监视器来监视不同的系统日志。 |
| –config.system-stats-monitor | 对于系统状态监控器 ，系统状态监视配置文件的路径列表，以逗号分隔，例如 config / system-stats-monitor.json。node-problem-detector将为每个配置启动一个单独的系统状态监视器。您可以使用不同的系统状态监视器来监视与问题相关的不同系统状态。 |
| –config.custom-plugin-monitor | 对于自定义插件监视器，自定义插件监视器配置文件的路径列表，以逗号分隔，例如 config/custom-plugin-monitor.json。node-problem-detector将为每个配置启动一个单独的自定义插件监视器。您可以使用不同的自定义插件监视器来监视不同的节点问题。 |
| –enable-k8s-exporter | 启用向Kubernetes API服务器报告的功能，默认为true。 |
| –apiserver-override | 一个URI参数，用于自定义node-problem-detector连接apiserver的地址。如果–enable-k8s-exporter为false，则忽略此内容。格式与Heapster的源标志相同。例如，要在没有身份验证的情况下运行，请使用以下配置：http://APISERVER_IP:APISERVER_PORT?inClusterConfig=false |
| –address | 绑定node-problem-detector服务器的地址。 |
| –port | 绑定node-problem-detector服务器的端口。使用0禁用。 |
| –prometheus-address | 绑定Prometheus抓取端点的地址，默认为127.0.0.1。 |
| –prometheus-port | 绑定Prometheus抓取端点的端口，默认为20257。使用0禁用。 |
| –exporter.stackdriver | Stackdriver exporter程序配置文件的路径，例如 config/exporter/stackdriver-exporter.json，默认为空字符串。设置为空字符串以禁用。 |
2.1.3 节点自愈
采集节点的健康状态是为了能够在业务Pod不可用之前提前发现节点异常，从而运维或开发人员可以对Docker、Kubelet或节点进行修复。在NPD中，为了减轻运维人员的负担，提供了根据采集到的节点状态从而进行不同自愈动作的能力。集群管理员可以根据节点不同的状态配置相应的自愈能力，如重启Docker、重启Kubelet或重启ASK节点等。同时为了防止集群中的节点雪崩，在执行自愈动作之前做了严格的限流，防止节点大规模重启。自愈流程如图2-4所示。
::: hljs-center
:::
NPD组件可以自定义自愈配置，例如接收到磁盘指标和事件进行对docker image的回收。以及触发硬件问题，执行调度策略调走对应应用等等。
2.2 eventMesh组件
::: hljs-center
:::
eventMesh组件是Iaas团队自研开发的组件，针对现有集群特性做的一套事件采集、告警分发组件,如图2-5所示。
2.2.1 集群监听与事件收集
eventMesh组件对集群的监听，主要采取集群管理集群模式，通过集群secret收集监听Cluster信息进行管理维护。eventMesh监听Cluster Informer对应集群Add、Update、Delete事件进行对集群的管理与更新，及摘除。然而每个Cluster会在对Event Informer进行Add、Update、Delete事件监听,如图2-6 所示。
::: hljs-center
:::
为了在收集过程中过滤大量无用的事件信息，并且让过滤机制更高效，在eventMesh组件中实现了一套布隆过滤器，这样通过字节数组更过滤事件信息更高效。
2.2.2 路由告警与通知
路由告警与通知都是依赖于yaml文件发起路由告警,通过控制面板操作创建通知后，eventMesh组件会监听创建事件并对yaml文件进行变更。yaml变更后，eventMesh会重新reload告警相关配置。
::: hljs-center
:::
创建事件通知会分为三个维度，分别为：集群维度、节点维度、项目维度。如图2-7所示。集群维度与节点维度提供给集群以及业务对应的SRE，节点维度与项目则提供给Paas平台、项目维度主要提供给使用的业务,这样可以做到定向分发路由告警通知。
778
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
