kube-prometheus-stack中Alertmanager网络策略配置实践

在Kubernetes环境中部署监控系统时，网络策略(NetworkPolicy)是保障组件间安全通信的重要机制。本文将以kube-prometheus-stack为例，深入分析Alertmanager组件在网络策略启用时出现的502错误问题及其解决方案。

问题背景

当在kube-prometheus-stack中启用网络策略后，Alertmanager的入口流量会被默认拒绝，导致访问Alertmanager Web界面时出现502错误。这是因为Kubernetes的网络策略默认采用"拒绝所有"的安全模型，需要显式配置允许的流量规则。

技术原理

Alertmanager作为Prometheus生态中的告警管理组件，需要处理以下类型的网络流量：

1. 来自Prometheus的告警推送
2. 来自Web界面的管理访问
3. 与其他Alertmanager实例的集群通信（高可用模式下）

网络策略需要针对这些流量模式进行精细控制，既要保证安全性，又要确保功能正常。

解决方案

方案一：内置网络策略配置

kube-prometheus-stack可以通过Chart参数为Alertmanager配置内置网络策略：

alertmanager:
  networkPolicy:
    enabled: true
    ingress:
      - from:
          - podSelector:
              matchLabels:
                app: prometheus
                component: server
        ports:
          - port: 9093
            protocol: TCP
      - from:
          - namespaceSelector: {}
            podSelector:
              matchLabels:
                app.kubernetes.io/name: alertmanager
        ports:
          - port: 9094
            protocol: TCP

这个配置实现了：

1. 允许Prometheus Server向Alertmanager的9093端口推送告警
2. 允许其他Alertmanager实例通过9094端口进行集群通信

方案二：自定义额外部署

对于需要更复杂网络策略的场景，可以使用extraDeploy机制：

extraDeploy:
  - apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: custom-alertmanager-policy
    spec:
      podSelector:
        matchLabels:
          app: alertmanager
      policyTypes:
        - Ingress
      ingress:
        - from:
            - ipBlock:
                cidr: 10.0.0.0/8
          ports:
            - port: 9093

最佳实践建议

1. 最小权限原则：只开放必要的端口和来源
2. 命名空间隔离：在多租户环境中使用namespaceSelector限制访问
3. 端口规范：
   • 9093: HTTP API和Web界面
   • 9094: 集群通信端口
4. 监控验证：部署后检查网络连通性和告警流程

进阶配置

对于生产环境，建议考虑以下增强配置：

1. Egress策略：限制Alertmanager的出站连接
2. 标签匹配：使用更精细的标签选择器
3. 协议限制：明确指定TCP/UDP协议
4. IP范围限制：在企业内网环境中限制访问源IP

总结

通过合理配置网络策略，可以在不牺牲安全性的前提下确保Alertmanager的正常工作。kube-prometheus-stack提供了灵活的配置选项，既支持开箱即用的简单配置，也允许通过extraDeploy机制实现复杂的网络策略需求。在实际部署时，应根据具体环境需求调整策略，并做好测试验证工作。

对于刚接触Kubernetes网络策略的用户，建议从小范围测试开始，逐步完善策略规则，最终形成适合生产环境的网络安全配置。