作者简介：

郭川磊

百度基础架构部研发工程师

负责云原生产品的研发

本文基于百度云原生团队『云原生基础知识概述及实践』系列视频课程——『Kubernetes入门—Kubernetes实现应用高可用』梳理.

视频课程可点击：https://cloud.baidu.com/video-center/video.html?id=610进行学习。

导读：

本节课是Kubernetes入门课程的最后一课。

可关注百度开发者中心公众号，回复k8s获取全部课件pdf电子版。

本节课主要分为以下四个板块：

1. 容器日志采集与管理

Kubernetes日志处理方案

2. 容器监控指标的采集与管理

以Prometheus为核心的统一监控方案

3. Demo

演示云原生环境日志采集与指标监控

4. 总结

总结日志采集与指标监控要点

01 容器日志搜集与管理

日志采集场景

日志采集场景主要分为以下四种：

**集群核心组件日志：**审计需要Kube-apiserver日志，诊断调度需要kube-scheduler日志，接入层流量分析需要Ingress日志。
**主机内核日志：**内核日志可以用于帮助开发及运维同学诊断影响节点稳定的异常，如：文件系统异常，网络栈异常，设备驱动异常等。
应用运行时日志：Docker是最常见的容器运行时，可以利用Docker和Kubelet日志排查Pod创建和启动失败等问题。
业务应用日志：通过分析业务的运行日志分析和观察业务状态，诊断异常。

日志采集目标

Kubernetes对容器日志的期望处理方式为：集群级日志处理（cluster-level-logging）即：与容器、Pod、节点生命周期完全无关。

对于一个容器，当应用将日志输出到stdout和stderr后，docker默认将这些日志输出到宿主机上一个JSON文件中。

日志采集方式

Kubernetes本身并不会对用户进行任何的日志搜集工作。为了实现集群级日志处理，需要在集群前，提前对日志采集管理进行方案规划。Kubernetes本身推荐3种日志方案。

日志采集方式1：使用节点级日志代理

核心是logging-agent （fluentd，etc ）；
Logging-agent以DaemonSet方式运行在节点上；
挂载宿主机上的容器日志目录；
转发日志至后端存储（ElasticSearch, etc）;

优点：对应用和Pod完全无侵入，一个节点仅需部署一个agent。
缺点：要求应用日志直接输出至容器的stdout和stderr。

日志采集方式2：使用sidecar容器和日志代理
容器全部或部分日志输出到文件
一个或多个sidecar容器将应用程序日志传送到自己的stdout和stderr。

优点：能够继续使用日志采集方式1。
缺点：成倍增加磁盘占用，造成浪费。（应用和sidecar容器写入两份相同日志文件）

日志采集方式3：使用具有日志代理功能的sidecar容器
相当于将logging-agent直接集成进Pod。
应用和输出日志至stdout&stderr或文件。
Logging-agent的输入源为应用日志文件。

优点：部署简单，对宿主机友好。
缺点：1.Sidecar容器可能消耗较多资源，甚至拖挂应用容器。
2. 无法使用kubectl logs命令查看容器日志。

总结：
实现集群级日志采集的三种方式：

• 使用节点级日志代理。
• 使用sidecar容器和日志代理。
• 使用具有日志代理功能的sidecar容器。

建议：使用方案1，将应用日志输出到stdout&stderr，通过宿主机上直接部署logging-agent的方式集中处理日志。

• 管理简单。
• 可以使用kubectl logs命令查看日志。
• 宿主机本身可能已有rstlogd等成熟日志收集组件可使用。

选型推荐

02 容器监控指标的采集与管理

监控场景

从监控类型划分，可分为以下几个场景:

资源监控：
CPU，内存，网络等资源类指标，常以数值，百分比为单位进行统计，是最常见的资源监控方式。

性能监控：
应用的内部监控。通常是Hock机制在虚拟机层，字节码执行层隐式回调，或者在应用层显式注入，获取更深层次的监控指标，常用来应用诊断与调优。
比如Jvm通过Hock机制,拿到类似Jvm里面的垃圾回收的次数，各种内存带的分布以及网络连接数的一些指标。通过这样的方式来进行应用的诊断与调优。

安全监控：
针对安全进行一系列监控策略，例如越权管理，安全漏洞扫描等。

事件监控：
Kubernetes中特有的监控方式，贴合Kubernetes设计理念，作为常规监控方案的补充。为什么说事件监控贴合Kubernetes设计理念呢？这是因为Kubernetes其中一个设计理念就是基于状态机的状态转换。从正常状态转换成另一个状态的时候，会发生一个Normal级别的事件(也就是正常的事件)而从一个正常状态转换成异常状态时，平台会触发一个Warning级别（也就是警告级别的事件）通常，Warning级别的事件是我们关心的事件。

而事件监控就可以把Normal级别的事件或Warning级别的事件离线存储到数据中心，然后通过数据中心的分析与报警，将相应的异常通过短信，邮件的方式暴露，弥补常规监控的弊端。

Prometheus的起源及现状

Prometheus与Kubernetes一样，来自于Borg体系。原型叫做BorgMon，是与Borg同时诞生的内部监控系统。而Prometheus项目发起的元婴也与Kubernetes类似，希望通过对用户更友好的方式，将Google内部系统的设计理念传递给开发者和用户。
Kubernetes监控体系曾经非常繁杂，但今天已经演变成了以Prometheus为核心的一套统一的方案。

Prometheus的架构与工作方式

Prometheus指标来源：

• 宿主机的监控数据：需要借助Node Exporter向外暴露;Exporter代替被监控对象来向Prometheus暴露可以被抓取的指标信息。 Kubernetes组件如APIServer,
• kubelet等的/metrics AP:除CPU，内存外，还包括各个组件的核心监控指标。
• Kubernetes核心的监控数据：包括Pod、Node、容器、Service等主要核心概念的metrics，其中容器相关的指标来源于kubectl内置的cAdvisor服务。

Prometheus特点：

1. 简洁强大的接入标准。只要实现Promethus Client接口，就可以直接实现数据的采集。
2. 多种数据采集方式。包括：在线，离线，push, pull 联邦的方式进行数据采集。
3. 和Kubernetes完全兼容。
4. 丰富的插件机制和生态。
5. Prometheus Operator助力。使Prometheus的运维实现自动化。

讲师第三节，演示了Kubernetes环境下日志采集与指标监控的一个Demo。感兴趣的同学可以点击视频观看。https://cloud.baidu.com/video-center/video.html?id=610

以上就是本期课程的所有内容，也是Kubernetes系列课程的最后一课。感谢大家的关注与支持，感谢百度云原生团队对课程的策划与支持。可点击下方链接回顾课程

Kubernetes入门——深入浅出讲Docker

Kubernetes入门——Kubernetes工作原理及使用

Kubernetes入门——Kubernetes应用部署

Kubernetes入门——Kubernetes实现应用的高可用