Kubernetes日志的6个最佳实践

本文转自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环境的安全性和高性能。