笔记23--使用kubernetes-event-exporter采集集群events日志

Kubernetes Events 收集与检索工具

转载自博客：https://zhuanlan.zhihu.com/p/516240617?utm_id=0

Kubernetes 可用于导出指标、日志和事件以实现可观察性。事件是了解服务中正在发生的事情的丰富信息来源，并且可以使用多种工具来充分利用它们。

以下是我将要解释的内容的概述：

• 事件机制
• Kubernetes API 中的事件结构
• 需要关注的事件类型
• 检索事件的可用解决方案

在本文的最后，会链接到 YouTube 和 Github 上的相关教程，这样你就可以直接学习如何收集和检索 Kubernetes 事件。

Kubernetes 事件简介

Kubernetes 会生成许多与我们的工作负载部署、调度等相关的事件。这是一个非常丰富的信息来源，可以帮助我们了解集群中正在发生的事情，即回答诸如“为什么这个特定的 pod 被杀死或重新启动？”之类的问题。

有两种方法可以查看 K8s 中的事件：

• kubectl describe pod
• kubectl get events

当应用程序出现问题时，您首先应该查看的是它的事件和它的基础设施操作。将事件保留更长的时间也很有用，因为它们可以用于事后分析或了解故障是否是由早期事件引起的。

Kubernetes 中有多种类型的事件，因为每个 Kubernetes 对象都会经历几种状态，直到达到所需的状态。

主节点和工作节点有几个核心组件，它们允许 K8s 在我们的“服务器”上编排工作负载。调度器在节点上调度 Pod，controller manager 检测状态变化以在 Pod 消失的情况下重建 Pod，而 etcd 将存储各种 K8s 资源的状态（但仅限于最后一小时）。

所有的这些核心组件都能够根据事件编排我们的工作负载。这意味着事件对于理解特定情况很重要。

让我们看一个简单的例子：

部署 pod 时，调度程序会尝试识别正确的节点来启动 pod。同时，pod 将处于pending 状态。一旦调度程序确定了正确的节点，pod 将处于creating 状态。

要启动这个 pod，我们首先需要拉取容器的镜像。实际上，节点会从外部 docker 注册表中拉取镜像。调度程序还更倾向在已经拥有镜像的节点上调度 pod。

拉取镜像后，Pod 将处于running 状态。

如果由于某种原因，pod 消失了，controller manager 将重新创建该 pod。

但是如果 Pod 已经多次重启并出现相同的错误，Pod 将进入状态CrashLoopBackOff。

如果 Pod 卡在 pending 状态，则可能意味着节点上没有可用资源，或者无法找到正确的节点。

Pod 通常有存活探针或就绪探针来帮助 K8s 确定您的 pod 的状态或健康状况，即 /health 或 /ready。Kubelet 会调用这些探针。

您还可以使用特定的镜像定义一个 init 容器，以便 K8s 先执行完成该 init 容器，然后运行其他容器。

如果您在部署文件中提供了错误的镜像，或者 docker 注册表存在连接问题，则节点无法拉取镜像，因此 Pod 将永远不会达到 running 状态。如果执行 describe 会看到ImagePullBackOff事件

Kubernetes API 中的事件

所有事件都可以在 Kubernetes API（也可以使用 kubectl）的帮助下检索。通常，我们经常使用“ kubectl describe”来收集状态、原因等。

与 API 交互时，您将收集：

• message
• reason
• type
• 事件中涉及的对象
• 事件发生次数
• 事件的来源

这正是使用kubectl get events看到的。

Kubernetes 事件有哪些类型？

• 信息事件：Pods 调度，镜像拉取，节点健康，deployment 更新，replica set 被调用，容器被杀死
• 警告：Pod 有错误，PV 尚未绑定
• 错误：节点已关闭，找不到 PV，无法在云提供商中创建负载均衡器等。

您可以使用 REST API、API 客户端或 event recorder 直接发布您自己的事件。

最重要的 Kubernetes 事件

Kubernetes 有非常广泛的事件，这里有一些需要重点考虑的事件：

• CrashLoopBackOff，当 Pod 启动、崩溃、再次启动、然后再次崩溃时发生
• ImagePullBackOff，当节点无法拉取镜像时发生
• 驱逐事件，当节点确定需要驱逐或终止 pod 以释放一些资源（CPU、内存等）时，可能会发生这种情况。发生这种情况时，K8s 应该在另一个节点上重新调度 pod。
• FailedMount / FailedAttachVolume，当 pod 需要持久卷或存储时，如果存储不可访问，此事件会阻止它们启动。
• FailedSchedulingEvents，当调度程序无法找到运行您的 pod 的节点时。
• NodeNotReady，当节点由于潜在问题而无法运行 pod 时。
• Rebooted
• HostPort 冲突

 

转载自博客：https://blog.csdn.net/u011127242/article/details/127391025

1 介绍
kubernetes-event-exporter 是一个用于采集k8s事件的工具，它允许我们将经常遗漏的 Kubernetes 事件导出到第三方平台或者数据库，以便用于可观察性或警报目的。
event-exporter 可以将k8s事件存储到 Opsgenie、Webhooks、kafka、es等十几种平台|数据库，本文基于该工具介绍两种最常见的采集方式，方法一将事件日志采集到 kafka，方法二将事件日志直接采集到 es集群。

2 部署测试
2.1 写入kafka
部署脚本：

apiVersion: v1
kind: Namespace
metadata:
  name: lens-metrics
---
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: lens-metrics
  name: event-exporter
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: event-exporter
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
  - kind: ServiceAccount
    namespace: lens-metrics
    name: event-exporter
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: event-exporter-cfg
  namespace: lens-metrics
data:
  config.yaml: |该工具允许将经常遗漏的Kubernetes事件导出到各种输出，以便用于可观察性或警报目的。你不会相信你错过了什么。
    logLevel: error
    logFormat: json
    route:
      routes:
      - match:
        - receiver: "kafka"
    receivers:
      - name: "kafka"
        kafka:
          clientId: "kubernetes"
          topic: "k8s-event-log"
          brokers:
          - "192.168.2.11:9092"
          compressionCodec: "gzip"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: event-exporter
  namespace: lens-metrics
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: event-exporter
        version: v1
    spec:
      serviceAccountName: event-exporter
      containers:
      - name: event-exporter
        image: opsgenie/kubernetes-event-exporter:0.9
        imagePullPolicy: IfNotPresent
        args:
        - -conf=/data/config.yaml
        volumeMounts:
        - mountPath: /data
          name: cfg
      volumes:
        - name: cfg
          configMap:
            name: event-exporter-cfg
  selector:
    matchLabels:
      app: event-exporter
      version: v1

采集数据：
服务部署后，很快就采集到kafka，如下所示：

 

offset 4077的具体数据如下所示：

{
    "metadata": {
        "name": "calico-node-4p4jb.171cf6be0f3d946d",
        "namespace": "kube-system",
        "uid": "53d89898-44f3-471b-a3fc-9362567ac846",
        "resourceVersion": "4225520",
        "creationTimestamp": "2022-10-11T08:34:18Z",
        "managedFields": [
            {
                "manager": "kubelet",
                "operation": "Update",
                "apiVersion": "v1",
                "time": "2022-10-11T08:34:18Z"
            }
        ]
    },
    "reason": "Unhealthy",
    "message": "Readiness probe failed: 2022-10-11 08:34:18.377 [INFO][503] confd/health.go 180: Number of node(s) with BGP peering established = 0\ncalico/node is not ready: BIRD is not ready: BGP not established with 192.168.2.12\n",
    "source": {
        "component": "kubelet",
        "host": "kmaster"
    },
    "firstTimestamp": "2022-10-11T08:34:18Z",
    "lastTimestamp": "2022-10-11T08:34:18Z",
    "count": 1,
    "type": "Warning",
    "eventTime": null,
    "reportingComponent": "",
    "reportingInstance": "",
    "involvedObject": {
        "kind": "Pod",
        "namespace": "kube-system",
        "name": "calico-node-4p4jb",
        "uid": "069010fe-ca85-4ede-a4c5-033f02975433",
        "apiVersion": "v1",
        "resourceVersion": "4223433",
        "fieldPath": "spec.containers{calico-node}",
        "labels": {
            "controller-revision-hash": "84f97c77db",
            "k8s-app": "calico-node",
            "pod-template-generation": "2"
        }
    }
}