kubernetes 周边生态

监控

• 以 Prometheus 项目为核心的一套统一的方案
  • Prometheus 项目工作的核心，是使用 Pull 的方式去搜集被监控对象的 Metrics 数据（监控指标数据），然后再把这些数据保存在一个 TSDB （时间序列数据库，比如 OpenTSDB、InfluxDB 等）当中，以便后续可以按照时间进行检索
  • Pull模式
    • 特点
      • 被监控方提供一个server，并负责维护
      • 监控方控制采集频率
    • 优点
      • 监控指标由用户自己维护，使得标准化很简单
      • 监控系统对metric采集的统一和稳定有了可靠的保证，对于数据量大的情况下很重要
    • 缺点
      • 采用轮询拉取方式，数据延迟较高
      • 容易造成一些信息的丢失和不准确
  • 监控指标
    • 宿主机数据，包括负载，磁盘等
    • k8s组件数据，包括Controller 的工作队列的长度、请求的 QPS 和延迟数据等
      • 是检查 k8s本身工作情况的主要依据

日志采集

• 容器默认采用的是日志驱动为 json-file 模式，采集效率极低还占用大量 IO 读写效能，基本无法适应生产环境需要
• 在我们生产实践推荐中，偏向于采用系统提供的日志系统 systemd-journal 来接收日志采集，然后通过 fluentd 采集代理进程，把相应的日志按照业务规则分类汇聚，发送到 Elasticsearch 这样的中央日志管理系统
• 由于业务日志量的规模扩大，日志采集的流量速率会让中央日志系统处理负载过高，导致业务日志处理不过来。所以通常采用流式消息队列服务 Kafka 作为日志存储的异步缓冲，可以极大的缓解日志流量，并高效的解决日志采集的汇聚难题

三种日志方案

• 方案一： Node 上部署 logging agent，将日志文件转发到后端存储里保存起来
  • 一个节点只需要部署一个 agent，并且不会对应用和 Pod 有任何侵入性
  • 不足在于，它要求应用输出的日志，都必须是直接输出到容器的 stdout 和 stderr 里
    
• 方案二： 当容器的日志只能输出到某些文件里的时候，我们可以通过一个 sidecar 容器把这些日志文件重新输出到 sidecar 的 stdout 和 stderr 上
  • 这样就能够继续使用第一种方案了
  • 由于 sidecar 跟主容器之间是共享 Volume 的，所以这里的 sidecar 方案的额外性能损耗并不高，也就是多占用一点 CPU 和内存
  • 但是宿主机上实际上会存在两份相同的日志文件，这对磁盘是很大的浪费
    
• 方案三： 通过一个 sidecar 容器，直接把应用的日志文件发送到远程存储里面去
  • 相当于把方案一里的 logging agent，放在了应用 Pod 里
  • 部署简单，并且对宿主机非常友好
  • 但是这个 sidecar 容器很可能会消耗较多的资源，甚至拖垮应用容器
  • 并且由于日志没有输出到 stdout 上，通过 kubectl logs 是看不到任何日志输出的

• 无论是哪种方案，你都必须要及时将这些日志文件从宿主机上清理掉，或者给日志目录专门挂载一些容量巨大的远程盘。否则，一旦主磁盘分区被打满，整个系统就可能会陷入奔溃状态