酷应用

技术分享｜K8s 在北纬39° 的最佳实践之路（下）

百家作者：QingCloud 2020-01-13 11:26:49

继我们上次分享过 KubeSphere 的可观察性、在日志、监控、告警等方面的一些实践经验（没看过的同学戳这里补课：技术分享｜K8s 在北纬39° 的最佳实践之路），今天为大家介绍告警、审计方面的内容以及未来规划。

Prometheus 在 2.0 重写了时序数据引擎，这个引擎的能力达到每秒钟采集百万级的样本，一共可以存数百万的时间序列。因为有这样的能力，单节点的 Prometheus 就可以满足很多用户的需求。Prometheus 的效率非常高，加上设计得非常好，专门收集时序监控数据，所以单节点也能承担很高的负载。

举几个例子，我们测试过单节点的 Prometheus，监控 200 个节点 8000 个 POD、17000 个 POD 一点问题都没有。

除了用一个中央的 Prometheus，收集下面各个集群中 Prometheus 的监控数据。其实还有另一个用法，就是可以把每个集群里 Prometheus 里的监控数据通过 remote write 写到 remote storage，其实现在 Prometheus 的 remote storage 也是百花齐放的。

在今年的 PromCon 上有一个主题叫 Remote Storage War，集中讨论了各种各样这方面的产品，比如 Thanos, Cortex, M3DB 等，这些产品均提供 PromQL 接口支持，并能够保存更久的监控数据，可扩展、高可用。这是一点题外话。

今天讲的主题是 “X + 告警”，为什么是 “X + 告警”？大家一提到告警就说这是跟监控有关的。其实告警除了监控外还有很多告警源的，我们来看具体有哪些。

X + 告警

幻灯片188.png

首先是我们 KubeSphere 2.0 自研的一个告警系统，当时我们做这个的时候，Alertmanager 的文档不是特别全，我们自己研发了一个告警系统，定期去 Prometheus 读监控指标，我们定义一些 Rules，比如指标检测周期、连续多少个周期才算告警这样一套规则。我们自己开发了一套告警系统，它已经很强大了，我们做过一些压力测试，并进行一些 Prometheus 的调优以配合告警系统，所以已经很强大。

但是还有一些用户一直在问，为什么你们不集成 Alertmanager？该来的总会来的，我们会在 KS3.0 全面集成社区的告警方案 Alertmanager，好处是它有一套通用的告警管理范式或者模式。

幻灯片189.png

分组监控

分组是什么意思？把相似的告警分到一个组里，如果这个组里告警，它不会立刻发送通知，它会等一段时间比如 30 秒，等等有没有属于这个组的其他的告警过来，它一块发送。如果这个组里已经发送过一次通知，下次这个组里再有通知的话，隔多长时间发送。

日志抑制

什么是抑制？如果有一个高等级的告警发生了，低等级的告警就没必要发送。比如这个 Node 已经挂了，Depolyment 的告警就没必要发送了。它也是解决了一个告警泛滥的问题。

日志静默

比如有告警在不停发送，我已经知道了，我不希望老是被告警烦，那可以把这个告警静默一段时间。

这些告警的范式是比较通用的。这样的告警方式可以应用在除了监控之外的很多其他的告警源。保守的说 Alertmanager 现在 99% 以上的应用场景是在监控领域的。其实它的用法可以更多样一些，具体我们可以看一下。

幻灯片190.png

比如事件，比如你部署一个工作负载出了问题，大家常用的 Debug 手段是看日志，如果日志没有这个信息，你就会用 Describe POD 或者 Get event，看这个到底出了什么问题。Event 包含了很多有价值的信息，可以帮助你定位问题。比如最常见的是 BackOff，一般配置写错或者程序有 Bug，container 会不停的重启，就会有很多 BackOff 的 Event 产生。

试想如果你有一个基于 Event 的告警系统，不用你去看 Event 到底是什么，如果它的告警你感兴趣，它会立即推送给你。对于你的运维是非常友好的，Event 非常适合于告警，因为它有实时性，包含非常有价值的信息。

审计

审计包括刚刚讲的 Event，都是日志。审计相当于 K8S API Server 的日志，那么审计日志具体是什么样的？比如它可以包含几部分：这个请求到底是 Create 还是 Delete，什么时候请求的？是谁发起请求？这个请求的 Requset 到底包含哪些东西。这是审计基本包含的信息。

幻灯片191.png

审计日志的级别可以分几种，只接收 Metadata 级别的信息，或者在 Requset 阶段记录一个审计信息，或者记录更详细的 request 和 response 内容都记录下来。可以设各种等级，根据需求调整。具体到 K8S 来讲，它有两种配置审计的方式：静态和动态。

静态审计

需要你在启用 API Server 的时候，指定一个审计的 Policy 配置文件。这个配置文件可以写非常复杂的规则，你对哪些资源的审计信息感兴趣，审计什么等级，都可以配置。静态审计不好的地方是你每次改了配置文件，必须重启 API Server，这对很多用户来说是不可接受的。集群运行得好好的，你把 API Server 重启了，是不可接受的。

动态审计

社区提出了一种动态的 Audit 配置方式。只要在 API Server 启动时指定一些指令，再想调整它的等级，只要更改 Audit CRD 即可，它会动态监测到，调整审计的输出。动态的审计是新功能，规则没有那么复杂，相对来说简单一些。它不需要重启 API Server 的功能还是很重要的，以后会越来越好。

具体到审计是怎么用的？它有两种功能：被动审计和主动审计。

幻灯片192.png

就是把审计开着，不管它发生什么 API 调用，都会接收并存储。等到有问题发生时，再根据存储的审计信息判断这到底是什么原因引起的，这是被动审计的用法。比如有的行业像银行、保险，有规定必须保留多长时间审计的信息，不管发不发生问题都要保存这么长时间，所以它是被动审计。

审计更有价值的一个地方，它是实时的，适用于告警，比如可以主动识别一些不合规或者可疑的行为。

举几个例子，比如如果有匿名用户或者未授权用户做了某些操作，产生告警的话对管理员来说非常有价值。另一个例子，Password 或者 Access Token 这样的敏感信息在 K8s 里一般是保存在 Secret 里。如果用户把这些敏感信息保存到了 configmap，被检测到后发一个告警。这对于安全性来讲是非常有价值的。

再比如说，如果你对于 Cluster-admin 的 role 创建一个 ClusterRoleBinding，也会产生一个告警。这对安全性来讲是非常有用的。

回到主题，X + 告警到底是什么？

幻灯片193.png

告警不仅可以用于监控数据，审计、事件或者其他组件的告警，都可以发到 Alertmanager，由 Alertmanager 管理告警、发送频率并发送通知。X + 告警的意义就在这里，不仅仅用于监控，还可以用于很多其他的告警源。

我们也积极参与开源的上游项目，我们是 kube-prometheus 的 maintainer, 也是 Prometheus Operator、Grafana 的 Contributor。这几个项目也是我们的对手 OpenShift 的研发人员积极参与的，这体现了开源生态的包容性和开放性。我们作为对手，也会积极共建一些开源项目。

幻灯片194.png