在flux-cluster-template项目中监控k0s的etcd组件

监控Kubernetes集群中的etcd组件是确保集群稳定性的重要环节。在基于k0s的Kubernetes发行版中，etcd作为默认的键值存储组件，其监控配置需要特殊处理。

etcd监控的技术挑战

k0s部署的etcd服务存在两个主要监控难点：

1. 证书访问限制：etcd启用了双向TLS认证，需要提供CA证书、服务端证书和私钥才能访问metrics接口
2. 网络隔离：etcd默认只监听127.0.0.1回环地址，外部服务无法直接访问

解决方案实现

通过分析k0s的文件系统布局，发现etcd证书存储在固定路径：

• CA证书：/var/lib/k0s/pki/etcd/ca.crt
• 服务端证书：/var/lib/k0s/pki/etcd/server.crt
• 私钥文件：/var/lib/k0s/pki/etcd/server.key

证书提取与存储

使用k0s的hook机制，在集群配置阶段自动创建包含这些证书的Secret：

hooks:
  apply:
    after:
      - 创建observability命名空间
      - 将证书文件打包为Secret存储

ServiceMonitor配置调整

虽然Prometheus Operator原生支持从Secret读取TLS配置，但kube-prometheus-stack的默认ServiceMonitor模板未开放此功能。需要通过postRenderer进行动态修改：

postRenderers:
  - 使用kustomize打补丁
      patches:
        - 重写endpoints配置
          添加tlsConfig指向证书Secret

网络访问方案

针对etcd仅监听本地回环的问题，最终采用了更简洁的解决方案：通过k0s内置的kubelet暴露etcd指标。这种方式避免了复杂的网络穿透配置，直接利用现有的监控体系采集数据。

实施建议

对于使用k0s的集群管理员，建议：

1. 优先检查k0s版本是否支持通过kubelet暴露etcd指标
2. 如必须直接监控etcd，考虑使用sidecar模式将指标代理到Pod网络
3. 定期验证证书有效性，设置自动轮换机制

这种监控方案既保证了安全性，又简化了运维复杂度，是k0s环境下etcd监控的推荐实践。