Kubernetes日志的6个最佳实践

标签：被占用   帮助   没有   利用   模型   sid   arch   数据查询   ide   

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

Kubernetes日志的6个最佳实践

标签：被占用   帮助   没有   利用   模型   sid   arch   数据查询   ide   

原文地址：https://www.cnblogs.com/lonelyxmas/p/13072270.html