使用 kubernetes-event-exporter 监控 Amazon EKS 事件

Kubernetes Events 记录了集群中发生的各种事件，包括资源创建、更新、删除、调度失败等。通过监控和分析这些事件，可以快速帮助我们定位和诊断集群中发生的问题，如 Pod 无法调度、节点资源不足、容器启动失败等。这对于及时发现和解决问题至关重要。Kubernetes Events 还记录了用户操作、API 调用等信息，可以用于审计和合规性检查。通过监控这些事件，结合 Amazon Cloudtrail，我们可以及时了解谁在什么时间对集群进行了什么操作，确保符合安全策略和合规要求。

Amazon EKS 默认保存 60 分钟以内的事件，并且这个配置是不可更改的（该 feature request 依然处于 open 状态），在很多情况下，我们需要分析长于 60 分钟跨度的 Kubernetes 事件，来更好地分析集群的状态。因此我们需要一个方案来对事件进行持久化，比如，保存在 Amazon Opensearch。

本文将介绍通过 Opsgenie Kubernetes Event Exporter 来监控和收集 Amazon EKS 集群的事件。

前置条件

1. 一套 Amazon EKS 集群，版本在 1.23 或以上
2. 一套 Amazon Opensearch 集群，开启 fine-grain control，并配置主用户名及密码，用以登录 Opensearch dashboard 和接入集群注入 Amazon EKS events 数据
3. Amazon SNS 主题 – 订阅可以是邮件，Amazon lambda 或者通过 Amazon Lambda 推送到 webhook（比如我们拥有自建的监控告警系统，我们希望在这个系统中收到特定的 Amazon EKS 事件）

本文的基本架构图示例如下：

Amazon EKS

本文使用 EC2 节点组部署 Kubernetes event exporter。因为我们同时会将事件发送到 Amazon Opensearch 和 SNS，发送到 Amazon Opensearch 的时候使用终端节点加用户名和密码的方式，因此我们还需为节点组配置一个具有 SNS 读写的权限。

Kubernetes event exporter 部署 manifest

Kubernetes event exporter 的部署 manifest 包含几个部分：ClusterRole，ClusterRoleBinding，ServiceAccount，Configmap 及 exporter 本身的 Deployment。

其中 ServiceAccount，ClusterRole 和 ClusterRoleBinding 根据 Kubernetes RBAC 的规则来赋予 exporter 对集群资源的对应权限；而 Configmap 用于我们配置对应的事件接收器（receivers），我们可以同时配置多个接收器，接收器包括 Amazon Eventbridge，Amazon Opensearch（包括 ElasticSearch），Amazon SNS，Amazon Kinesis 和 webhook 等等，具体的配置信息见文末参考链接的 exporter github 首页 readme。

以下是 Configmap 的配置详情，剩余部分我们在此省略，具体详情同样可以参考 exporter github 链接。

apiVersion: v1
kind: ConfigMap
metadata:
  name: kubernetes-event-exporter-cfg
  namespace: monitoring
data:
  config.yaml: |
    logLevel: debug
    logFormat: json
    route:
      routes:
        - match:
            - receiver: "sns"
            - receiver: "dump"
    receivers:
      - name: "dump"
        opensearch:
          hosts:
          - https://vpc-qwert-opensearch-cluster-xxxxxxx.ap-southeast-1.es.amazonaws.com:443
          index: kube-events
          indexFormat: "kubernetes-events"
          username: admin
          password: xxxxxxxx
          useEventID: false
          tls:
            insecureSkipVerify: true
      - name: "sns"
        sns:
          topicARN: "arn:aws:sns:ap-southeast-1:xxxxxxx:EC2_CPU_Utilizatiuon"
          region: "ap-southeast-1"
          layout: # Optional

Amazon Opensearch

我们为 Amazon Opensearch（本文使用OpenSearch 2.11），并配置主用户和密码，用以配置以上 Configmap 中的 Opensearch receiver 的用户名和密码，并开启 Fine-grained access control。

在创建好 Opensearch 集群之后，我们要事先准备好一个 index，并为其配置 alias，本文使用 kube-events 作为 index，kubernetes-events 作为 alias：

Amazon SNS，Lambda 和 Chime webhook

如图所示，我们使用 Lambda 作为其订阅者，并在 Lambda 中配置 Chime 的 webhook：

本文将把完整的 event 全部通过 webhook 发送给 Chime 的 chat room，如需了解如何为 Chime chatroom 创建 webhook，请参考文末链接。

部署测试

我们把 exporter 部署在 monitoring 这个命名空间，部署完成之后，我们可以看到对应的 pod 及其 deployment：

进一步获取 exporter 的容器日志，检查它输送 events 的情况：

检查 Lambda 的执行情况和对应的 Chime room 接受的事件信息：

我们可以看到，当我们移除一个 fargate pod 到 EKS deployment 为 deployment 补齐 pod 之间的 event 全部通过 SNS 并发送到了 Chime。

我们再检查 Opensearch 对应的 index 情况：

同样地，对应的 EKS 事件信息将被输送到 Opensearch 作保存，并未后续的分析工作做好准备。

总结

监控 Kubernetes Events 对于维护集群的稳定性、安全性和高效运行至关重要。它可以帮助我们及时发现和解决问题，确保合规性，实现自动化运维，并优化集群性能。因此，在生产环境中部署 Kubernetes 时，监控 Events 是一个必不可少的环节。我们可以通过即时消息的方式，将事件通知到我们，也可以将事件输送到类似 Opensearch 的服务做保存和后续的分析。

参考链接

• Kuberneters event exporter：https://github.com/resmoio/kubernetes-event-exporter
• Amazon Chime webhook：https://docs.aws.amazon.com/zh_cn/chime/latest/ag/webhooks.html
• Kubernetes event TTL feature request：https://github.com/aws/containers-roadmap/issues/785
• Blog for gathering EKS events：https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/

本篇作者