3.8　日志概述

到目前为止，我们已经对Kubernetes和指标进行了很多探讨，但为了全面了解环境，你还需要收集并集中管理来自Kubernetes和集群中应用的日志。

关于日志，“把一切都记录下来”听起来理所当然，但这会导致两个问题：

• 干扰太多导致难以快速定位问题。
• 大量的日志会耗费大量的资源，带来高昂的成本。

日志究竟应该记录什么？这个问题并没有明确的答案，因为用于调试的日志已经成为不可避免的麻烦。随着时间的推移，你会更了解你的环境并且知道哪些干扰可以从日志系统中排除。而且，为了应对不断增长的日志存储，你还需要引入日志的保留和归档策略。从终端用户的经验来说，保留30到45天的历史日志是比较合适的，这样既能排查那些时间跨度较长的问题，也减少了日志存储所需要的资源。如果由于合规的原因需要保留更长时间的日志，你应该考虑使用更低成本的资源来对它们进行归档。

在Kubernetes集群中，很多组件都会记录日志。以下列举了需要收集日志的组件：

• 节点日志
• Kubernetes控制平面日志

• API Server
• Controller Manager
• Scheduler

• Kubernetes 审计日志
• 应用容器日志

通过节点日志，可以收集发生在节点关键服务上的事件。比如，你可能想要收集节点上Docker守护程序的日志，毕竟健康的Docker守护程序对在节点上运行的容器至关重要。收集这些日志有助于诊断Docker守护程序可能遇到的问题，日志中会给出该守护程序潜在问题的相关信息。同样，你还需要收集节点上其他关键服务的日志。

Kubernetes控制平面由若干个组件组成，你需要从这些组件中收集日志，以便更深入地了解其中潜藏的问题。控制平面是一个健康集群的核心，你需要将存储在主机 /var/log/kube-APIserver.log 、 /var/log/kube-scheduler.log 以及 /var/log/kube-controller-manager.log 上的日志聚合在一起。Controller Manager的职责是创建用户定义的对象。例如，用户创建了一个LoadBalancer类型的服务，但它一直处于挂起状态，Kubernetes事件可能无法为该问题提供详细的诊断信息。但是如果你将相关的日志全部收集到一个集中式的日志系统中，就可以获得该问题的更多详细信息，从而更快速地定位问题。

可以将Kubernetes审计日志应用于安全监控，因为它能让你洞悉谁在系统中执行了哪些操作。这些日志可能充满干扰，所以你需要针对不同环境进行适当的调整。很多情况下，日志系统的数据量会在其初始化阶段迅猛增长，请确保遵循Kubernetes文档中关于审计日志监控的指引。

应用容器日志让你能够深入了解应用程序实际产生的日志。有多种方式可以将这些日志转发到集中式存储库。第一种（也是推荐的方式）是将所有应用程序日志发送到标准输出（大多数情况下是控制台），因为这可以统一应用日志的记录方式，而且后台监控程序可以直接从Docker守护程序中采集到这些日志。另一种方式是采用边车（sidecar）模式，即在应用容器所在的Pod中运行另一个容器，专门用来转发日志。当需要将应用日志记录到文件系统时，你可能需要使用这种模式。