共计 2666 个字符，预计需要花费 7 分钟才能阅读完成。
本文转自 Rancher Labs
Kubernetes 可以帮助管理部署在 Pod 中的上百个容器的生命周期。它是高度分布式的并且各个部分是动态的。一个已经实现的 Kubernetes 环境通常涉及带有集群和节点的几个系统，这些系统托管着几百个容器，而这些容器不断地基于工作负载启动、毁灭。
当在 Kubernetes 中处理大量的容器化应用和工作负载时，主动进行监控和调试错误十分重要。在容器、节点或集群级别，这些错误都能在容器中看到。Kubernetes 的日志机制是一个十分重要的组件，可以用来管理和监控服务以及基础设施。在 Kubernetes 中，日志可以让你跟踪错误甚至可以调整托管应用程序的容器的性能。
配置 stdout（标准输出）和 stderr（标准错误）数据流
图片来源：kubernetes.io
第一步是理解日志是如何生成的。通过 Kubernetes，日志会被发送到两个数据流——stdout 和 stderr。这些数据流将写入 JSON 文件，并且此过程由 Kubernetes 内部处理。你可以配置将哪个日志发送到哪个数据流中。而一个最佳实践的建议是将所有应用程序日志都发送到 stdout 并且所有错误日志都发送到 stderr。
决定是否使用 Sidecar 模型
Kubernetes 建议使用 sidecar 容器来收集日志。在这一方法中，每个应用程序容器将有一个邻近的“streaming 容器”，该容器将会将所有日志流传输到 stdout 和 stderr。Sidecar 模型可以帮助避免在节点级别公开日志，并且它可以让你控制容器级别的日志。
然而，这一模型的问题是它能够适用于小容量的日志记录，如果面对大规模的日志记录，可能会造成大量资源被占用。因此，你需要为每个正在运行的应用程序容器单独运行一个日志容器。在 Kubernetes 文档中，将 sidecar 模型形容为“几乎没有很大的开销”。需要由你决定是否尝试这一模型并在选择它之前查看它所消耗的资源类型。
替代方法是使用日志代理，该代理在节点级别收集日志。这样可以减少开销，并确保安全地处理日志。Fluentd 已成为大规模聚合 Kubernetes 日志的最佳选择。它充当 Kubernetes 与你要使用 Kubernetes 日志的任意数量的端点之间的桥梁。你也可以选择像 Rancher 这样的 Kubernetes 管理平台，在应用商店已经集成了 Fluentd，无需从头开始安装配置。
确定 Fluentd 可以更好地汇总和路由日志数据后，下一步就是确定如何存储和分析日志数据。
选择日志分析工具：EFK 或专用日志记录
传统上，对于以本地服务器为中心的系统，应用程序日志存储在系统中的日志文件中。这些文件可以在定义的位置看到，也可以移动到中央服务器。但是对于 Kubernetes，所有日志都发送到磁盘上 /var/log 的 JSON 文件中。这种类型的日志聚合并不安全，因为节点中的 Pod 可以是临时的也可以是短暂的。删除 Pod 时，日志文件将丢失。如果你需要尝试对部分日志数据丢失进行故障排除时，这可能很难。
Kubernetes 官方推荐使用两个选项：将所有日志发送到 Elasticsearch，或使用你选择的第三方日志记录工具。同样，这里存在一个潜在的选择。采用 Elasticsearch 路线意味着你需要购买一个完整的堆栈，即 EFK 堆栈，包括 Elasticsearch、Fluentd 和 Kibana。每个工具都有其自己的作用。如上所述，Fluentd 可以聚合和路由日志。Elasticsearch 是分析原始日志数据并提供可读输出的强大平台。Kibana 是一种开源数据可视化工具，可以从你的日志数据创建漂亮的定制 dashboard。这是一个完全开源的堆栈，是使用 Kubernetes 进行日志记录的强大解决方案。
尽管如此，有些事情仍然需要牢记。Elasticsearch 除了由名为 Elastic 的组织构建和维护，还有庞大的开源社区开发人员为其做贡献。尽管经过大量的实践检验，它可以快速、强大地处理大规模数据查询，但在大规模操作时可能会出现一些问题。如果采用的是自我管理（Self-managed）的 Elasticsearch，那么需要有人了解如何构建大规模平台。
替代方案是使用基于云的日志分析工具来存储和分析 Kubernetes 日志。诸如 Sumo Logic 和 Splunk 等工具都是很好的例子。其中一些工具利用 Fluentd 来将日志路由到他们平台，而另一些可能有它们自己的自定义日志代理，该代理位于 Kubernetes 中的节点级别。这些工具的设置十分简单，并且使用这些工具可以花费最少的时间从零搭建一个可以查看日志的 dashboard。
使用 RBAC 控制对日志的访问
在 Kubernetes 中身份验证机制使用的是基于角色访问控制（RBAC）以验证一个用户的访问和系统权限。根据用户是否具有特权（authorization.k8s.io/decision）并向用户授予原因（authorization.k8s.io/reason），对在操作期间生成的审核日志进行注释。默认情况下，审核日志未激活。建议激活它以跟踪身份验证问题，并可以使用 kubectl 进行设置。
保持日志格式一致
Kubernetes 日志由 Kubernetes 架构中不同的部分生成。这些聚合的日志应该格式一致，以便诸如 Fluentd 或 FluentBit 的日志聚合工具更易于处理它们。例如，当配置 stdout 和 stderr 或使用 Fluentd 分配标签和元数据时，需要牢记这一点。这种结构化日志提供给 Elasticsearch 之后，可以减少日志分析期间的延迟。
在日志收集守护进程上设置资源限制
由于生成了大量日志，因此很难在集群级别上管理日志。DaemonSet 在 Kubernetes 中的使用方式与 Linux 类似。它在后台运行以执行特定任务。Fluentd 和 filebeat 是 Kubernetes 支持的用于日志收集的两个守护程序。我们必须为每个守护程序设置资源限制，以便根据可用的系统资源来优化日志文件的收集。
结 论
Kubernetes 包含多个层和组件，因此对其进行良好地监控和跟踪能够让我们在面对故障时从容不迫。Kubernetes 鼓励使用无缝集成的外部“Kubernetes 原生”工具进行日志记录，从而使管理员更轻松地获取日志。文章中提到的实践对于拥有一个健壮的日志记录体系结构很重要，该体系结构在任何情况下都可以正常工作。它们以优化的方式消耗计算资源，并保持 Kubernetes 环境的安全性和高性能。
