Kubernetes日志的6个优秀实践

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。