在 Kubernetes 中部署 Alertmanager

AlertManager 是一个开源警报系统，与 Prometheus 监控系统配合使用。本博客是 Prometheus Kubernetes 教程系列的一部分。在我们之前的文章中，我们研究了以下内容：

• 在 Kubernetes 上部署 Prometheus
• 部署 Kube State Metrics

在本指南中，我将介绍 Alertmanager 设置及其与 Prometheus 的集成。

注意：在本指南中，所有 Alert Manager Kubernetes 对象都将在名为 monitoring 的命名空间中创建。如果使用不同的命名空间，则可以在 YAML 文件中替换它。

核心要点摘要

• 本文目标是在 Kubernetes 中部署 Alertmanager，并让 Prometheus 通过 alertmanager.monitoring.svc:9093 把告警发送给它。
• 示例对象包括两个 ConfigMap、一个 Deployment 和一个 NodePort Service，均创建在 monitoring 命名空间。
• Alertmanager 的配置文件负责定义模板路径、路由规则、邮件接收器和 Slack webhook 接收器。
• 生产环境使用前，需要把示例中的 SMTP、邮件地址、Slack webhook、镜像版本和 Service 暴露方式替换成自己的配置。
• 部署完成后，可以通过 Kubernetes Service 内部地址与 Prometheus 集成，也可以通过 NodePort 访问 Alertmanager Web UI。

Kubernetes 上的 Alertmanager

Alert manager 有以下关键配置：

• 用于 Alertmanager 配置的 ConfigMap
• 用于 Alertmanager 警报模板的 ConfigMap
• Alertmanager 本身的 Deployment
• Alertmanager 的 Service，用于访问 Web UI

部署前检查

您应该已经启动并运行了一个 Prometheus。Prometheus 的 config.yaml 中应具有正确的 Alertmanager 地址，如下所示，以便将警报发送到警报管理器。

alerting:
   alertmanagers:
      - scheme: http
        static_configs:
        - targets:
          - "alertmanager.monitoring.svc:9093"

为了能够接收邮件告警，您需要在 Alertmanager 的 config.yaml 中配置合法的 SMTP 信息。您也可以根据自己的需求自定义邮件告警模板。我们在本指南中给出了通用模板。让我们开始吧。

部署前建议确认以下事项：

1. Kubernetes 集群中已经存在 monitoring 命名空间，或准备把 YAML 中的命名空间替换成自己的命名空间。
2. Prometheus 可以解析 alertmanager.monitoring.svc:9093 这个集群内服务地址。
3. 示例里的 SMTP、收件人、发件人和 Slack webhook 只是占位配置，不能直接用于生产通知。
4. 如果集群不允许使用 NodePort，后面的 Service 类型需要改成集群实际支持的暴露方式。

Alertmanager Kubernetes 清单

本教程中使用的所有 Kubernetes 清单都可以在此 Github 链接中找到。使用以下命令克隆 Github 仓库。

git clone https://github.com/bibinwilson/kubernetes-alert-manager.git

用于 Alertmanager 配置的 ConfigMap

Alert Manager 从 config.yaml 文件中读取其配置。它包含警报模板路径、电子邮件和其他警报接收配置的配置。

在此次部署演示中，我们使用电子邮件和 Slack webhook 接收器。您可以从此处查看所有受支持的警报接收器。

创建名为 AlertManagerConfigmap.yaml 的文件，并复制以下内容。

kind: ConfigMap
apiVersion: v1
metadata:
  name: alertmanager-config
  namespace: monitoring
data:
  config.yml: |-
    global:
    templates:
    - '/etc/alertmanager/*.tmpl'
    route:
      receiver: alert-emailer
      group_by: ['alertname', 'priority']
      group_wait: 10s
      repeat_interval: 30m
      routes:
        - receiver: slack_demo
        # Send severity=slack alerts to slack.
          match:
            severity: slack
          group_wait: 10s
          repeat_interval: 1m    
 
    receivers:
    - name: alert-emailer
      email_configs:
      - to: demo@devopscube.com
        send_resolved: false
        from: from-email@email.com
        smarthost: smtp.eample.com:25
        require_tls: false
    - name: slack_demo
      slack_configs:
      - api_url: https://hooks.slack.com/services/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sz4Qk
        channel: '#devopscube-demo'

让我们使用 kubectl 创建 ConfigMap。

kubectl create -f AlertManagerConfigmap.yaml

用于 Alertmanager 警报模板的 ConfigMap

我们需要为我们使用的所有接收器（电子邮件、Slack 等）提供警报模板。Alertmanager 将动态替换这些值，并根据模板向接收者发送警报。您可以根据需要自定义这些模板。

创建一个名为 AlertTemplateConfigMap.yaml 的文件，并从此文件链接 ==> 警报管理器模板 YAML 中复制内容。

使用 kubectl 创建 configmap。

kubectl create -f AlertTemplateConfigMap.yaml

创建 Deployment

在此 Deployment 中，我们将挂载我们创建的两个 ConfigMap。

使用以下内容创建名为 Deployment.yaml 的文件。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: alertmanager
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alertmanager
  template:
    metadata:
      name: alertmanager
      labels:
        app: alertmanager
    spec:
      containers:
      - name: alertmanager
        image: prom/alertmanager:latest
        args:
          - "--config.file=/etc/alertmanager/config.yml"
          - "--storage.path=/alertmanager"
        ports:
        - name: alertmanager
          containerPort: 9093
        resources:
            requests:
              cpu: 500m
              memory: 500M
            limits:
              cpu: 1
              memory: 1Gi
        volumeMounts:
        - name: config-volume
          mountPath: /etc/alertmanager
        - name: templates-volume
          mountPath: /etc/alertmanager-templates
        - name: alertmanager
          mountPath: /alertmanager
      volumes:
      - name: config-volume
        configMap:
          name: alertmanager-config
      - name: templates-volume
        configMap:
          name: alertmanager-templates
      - name: alertmanager
        emptyDir: {}

使用 kubectl 创建 Deployment。

kubectl create -f Deployment.yaml

创建 Alertmanager 的服务端点

我们需要使用 NodePort 或 Load Balancer 公开警报管理器，以便访问 Web UI。Prometheus 将使用内部服务端点与警报管理器进行通信。

创建包含以下内容的 Service.yaml 文件。

apiVersion: v1
kind: Service
metadata:
  name: alertmanager
  namespace: monitoring
  annotations:
      prometheus.io/scrape: 'true'
      prometheus.io/port:   '9093'
spec:
  selector: 
    app: alertmanager
  type: NodePort  
  ports:
    - port: 9093
      targetPort: 9093
      nodePort: 31000

使用 kubectl 创建服务。

kubectl create -f Service.yaml

现在，您将能够在节点端口 31000 上访问警报管理器。例如

http://35.114.150.153:31000

部署后验证

创建完 Deployment 和 Service 后，至少要验证三件事。

第一，确认 Pod 已经运行：

kubectl -n monitoring get pods -l app=alertmanager

第二，确认 Service 已经暴露 9093 端口：

kubectl -n monitoring get svc alertmanager

第三，确认 Prometheus 的 alerting.alertmanagers 地址与 Service 名称、命名空间和端口一致。如果 Prometheus 配置里仍然指向旧地址，Alertmanager 即使部署成功也收不到告警。

常见问题

Alertmanager 一定要用 NodePort 暴露吗？

不一定。本文为了演示 Web UI 访问使用了 NodePort。Prometheus 与 Alertmanager 在集群内通信时，通常使用 alertmanager.monitoring.svc:9093 这类内部 Service 地址即可。生产环境可以根据集群网络和安全策略选择 ClusterIP、Ingress、LoadBalancer 或其他暴露方式。

示例中的 SMTP 和 Slack 配置可以直接使用吗？

不能。示例里的邮箱地址、SMTP 地址和 Slack webhook 只用于说明配置结构。真正部署时，需要替换成自己的通知渠道，并确认网络、认证、TLS 和收件人策略符合实际环境。

为什么要把配置和模板拆成两个 ConfigMap？

配置文件负责路由、接收器、分组和通知策略，模板负责通知内容的展示格式。拆开之后，修改通知模板时不必混动主要路由配置，也方便团队分别维护告警策略和消息格式。

小结

在 Kubernetes 中部署 Alertmanager 的关键不是单纯启动一个容器，而是把 Prometheus 告警地址、Alertmanager 路由配置、通知模板和 Service 访问方式串起来。本文示例适合作为入门清单，真正用于生产环境前，应固定镜像版本、替换通知凭据，并按团队的告警分组、静默、抑制和升级策略继续完善配置。

• 英文原文：https://devopscube.com/alert-manager-kubernetes-guide/
• 中文译文：https://flashcat.cloud/blog/alert-manager-kubernetes-guide/
• 译者：巴辉特

本博客出自快猫星云的小伙伴们，快猫星云是一家专注在监控/可观测性领域的初创公司，其团队是开源项目 Open-Falcon、Nightingale 的创始团队。如果您想要采购监控/可观测性相关的产品方案，欢迎 联系我们做产品技术交流。