Kubernetes日志


Kubernetes以惊人的速度成为了DevOps领域的明星。 它负责管理大量的容器,以及对应的容器组(pod),节点组(cluster)的配置,更新等等。它使得你能够将注意力放到你最关心的应用的核心-- 代码和数据--上来 。因为具有这些优点,Kubernetes已经成为当今容器编排工具的王者。

Kubernetes让管理大规模的容器变得容易,但是它也有很陡峭的学习曲线。为了解决Kubernetes的管理问题市面上有很多的产品和服务推出: Platform9, Kismatic, OpenShift, CoreOS Tectonic (已经被Redhat收购)等等。

无论你采用何种方式管理Kubernetes集群,一个基础的需求是: 当出现问题的时候,要有有效的日志分析功能。传统的应用使用日志数据来排错,排查性能问题,系统问题,bug,服务器攻击等。面对像Kubernetes这样的基础架构,整个集群上面运行着指数级增长的虚拟系统(容器),日志必须要做集中处理和打标签才能有效分析。

免责声明

这篇文章是我们在构建Kubernetes来支持LogDNA的过程中所有洞见和想法的总结。给我们的客户带来优质的体验非常重要,但同时我们也将自己的大部分服务也迁移到了Kubernetes上。我们专注于构建一个完美的日志平台来处理你所有系统的日志收集,解析,索引,标记/标签,搜索,分新,报警和存储。

Kubernetes日志数据的重要

日志对于Kubernetes管理而言非常重要。Kubernetes是一个高度动态的平台,变化无时无刻不在发生。当容器启动停止,IP地址变化,负载变化的事件发生时,Kubernetes也都要作出变化来确保服务被正确的扩展,性能没有被影响。当出现问题或者性能下降的时候,你不可避免的需要依靠日志来提供细节信息。在Kubernetes的世界里面,容器在不停的被启动或者终止,完全可能有这样一种情况:当出现问题,你要查看产生错误日志的那个容器来调查的时候,那个容器已经被终止了。回溯的唯一方法就是确保日志可用,你可以通过日志来描绘过去发生了什么。除了性能和排错需要之外,产业合规也会需要日志数据来确保你符合HIPAA 或者 PCI DSS的要求。当有严重的数据泄露发生时,你将需要及时回溯来识别攻击源以及它在你所有系统里面的经过路径。对于这些使用场景,日志数据是必不可少的。

访问和分析Kubernetes日志数据库有许多方式,从简单到高级。我们来由浅入深,逐一说明。

在Pod中处理日志

Kubernetes中容器是最底层的元素,但是Pod级别的日志是查看日志的最基本形式。KC命令可以用来获取每个pod的日志数据。这些日志存在pod里面,当pod消亡时,日志就没有了。当你只有少量的pod的时候,这些就足够了。 你可以快速查看pod的健康状况,而不需要搭建一套大的日志集群。

在Node中处理日志

每一个节点(node)的日志收集存储在一个JSON文件中。这个文件会变得非常大,所以你需要使用logrotate的功能将日志数据切分到多个文件里面,一天执行一次或者当数据增长到某个固定大小后执行。节点级别的日志比pod级别的日志更有持续性。即使一个Pod被重启了,它之前的日志也会保留在节点上。但是如果一个pod被从一个节点上驱逐了,那么它的日志数据也会被删除。

node级和pod级的日志在Kubernetes中是非常重要的概念,但它们本身不是一个实际的解决方案。它们是你构建一个实际的集群级别日志系统解决方案的基石。

处理整个集群的日志

Kubernetes没有给整个cluster提供一个缺省的日志方案,这一块留给用户和第三方工具来做。一种方式是基于node级别的日志来做。这种方式下,你在每个node上安装一个agent然后合并它们的输出。

缺省方案是Stackdriver,它使用一个Fluentd agent将日志输出到一个文件里面。你也可以将日志发送到google云上,然后你可以通过Google Cloud的CLI来查询日志数据。但是这并不是分析日志数据的最强大的工具,尤其当你没有使用过GCP的时候会很痛苦。 这触使我们继续讨论当下其他可能的解决方案。

使用Elasticsearch来DIY日志方案

Cluster级别日志的一种流行解决方案是通过一个Fluentd agent从node上收集日志,然后将它们发送到一个外部的Elasticsearch集群中。使用Elasticsearch来存储和处理这些日志数据,然后通过Kibana这样的工具来做可视化。

The ELK stack (Elasticsearch, Logstash, Kibana)或者我们现在说的 EFK (Elasticsearch, Fluentd, Kibana)是当今最流行的开源日志系统解决方案,它们的组件也构成了许多其他新的解决方案的基础。ELK提供了强大的日志处理能力,比Stackdriver / Google Cloud更多的扩展性。构建你自己的ELK刚开始的时候并不复杂,配置每个input源的Logstash or Fluentd可能就稍微复杂一点,日志量起来以后扩展ELK会更麻烦一些,最后你会发现你要付出比当初预想的多得多的时间和精力。

使用一个Sidecar容器来收集日志

收集日志的另一个流行方式是通过在pod里面部署一个sidecar容器来部署pod里面的日志。每个sidecar容器包括一个收集和传输日志的代理程序。大多数的sidecar实现是非常轻量级的但是也需要消耗每个pod里面的资源。对于大型的应用来说,这意味着你需要修改每一个pod配置。规模一大就会非常繁琐,并不是一个好的实践。

使用DaemonSet来收集日志

我们发现最有效的日志收集方式是简单地部署一个DaemonSet当作收集器。把资源部署到node这一级而不是pod这一级,功能与sidecar方式实现的完全一样,而不需要给每个pod部署额外的进程或者容器。 部署DaemonSet也内在支持了通过一组简单的kubectl命令做跨整个集群的自动化部署。配完就不用管了。

丰富上下文的日志元数据


Kubernetes日志元数据的截图

我们把日志收集到一个集中式的可检索的数据仓库里了,但是如果你不知道自己要搜索的内容,那些重要的功能概念和日志也没什么用。Kubernetes日志功能中的最美好的方面是它作为一个独立的编排系统带来的框架和组织。Kubernetes存储的日志带有丰富上下文信息,方便一个日志系统自动地为每一条日志数据打上丰富的元数据标签。日志上附着的节点,pod,容器,甚至标签信息可以日那个你方便的做日志分析和聚合。一个好的日志解决方案可以利用这些优势,做一些有趣的应用。比如直接将commit hash作为标签打到特定的容器上,然后通过标签来过滤和检索日志。

结语

Kubernetes是当今领先的容器编排平台, 而要运行一个生产级别的Kubernetes集群需要对系统相当的熟悉度和强大的日志做支撑。尤其到应用日志管理和日志分析这一层Kubernetes带来了更大的复杂度。Kubernetes虽然提供了对pod,node,cluster的基本日志收集功能,但是对一个生产级别的集群来说你需要一个统一的日志系统。利用Kubernetes本身提供的优势来设计构建一个解决方案肯定比传统的跟踪服务器和应用的方式更加优雅和更有扩展性。

搭建自己的ELK或者EFK栈是管理和访问Kubernetes日志的一种通用方式,但随着需要部署和维护的工具数量的增加,它本身也会变得相当复杂。理想状态下,你需要你的日志工具简单让你可以专注于日志数据和Kubernetes集群本身。

一个深度定制化的Kubernetes日志解决方案应该自动识别所有的元数据(包括Kubernetes集群的pod, node, container, namespace等)。它应该提供的功能有:实时Kubernetes集群分析,强大的自然语言检索,过滤,解析,快捷方式和报警等。

原文链接 https://hackernoon.com/nodes-a ... ec50d

0 个评论

要回复文章请先登录注册