关于k8s集群容器日志收集的总结

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 容器日志存在形式 目前容器日志有两种输出形式: 1、 stdout,stderr标准输出 这种形式的日志输出我们可以直接使用docker logs查看日志,k8s集群中同样集群可以使用kubectl logs类似的形式查看日志。

容器日志存在形式

目前容器日志有两种输出形式:

1、 stdout,stderr标准输出

这种形式的日志输出我们可以直接使用docker logs查看日志,k8s集群中同样集 群可以使用kubectl logs类似的形式查看日志。

2、日志文件记录

这种日志输出我们无法从以上方法查看日志内容,只能tail日志文件查看。

在k8s官方文档中,对于以上两种形式的日志形式我们如果想收集并分析日志的话,官方推荐以下两种对策:
对于第一种文档中这样说:

When a cluster is created, the standard output and standard error output of each container can be ingested using a Fluentd agent running on each node into either Google Cloud Logging or into Elasticsearch and viewed with Kibana.

When a Kubernetes cluster is created with logging to Google Cloud Logging enabled, the system creates a pod called fluentd-cloud-logging on each node of the cluster to collect Docker container logs. These pods were shown at the start of this blog article in the response to the first get pods command.

就说说集群启动时会在每个机器启动一个Fluentd agent收集日志然后发送给
Elasticsearch。
实现方式是每个agent挂载目录/var/lib/docker/containers使用fluentd的tail插件扫描每个容器日志文件,直接发送给Elasticsearch。

对于第二种:

  1. A second container, using the gcr.io/google_containers/fluentd-sidecar-es:1.2 image to send the logs to Elasticsearch. We recommend attaching resource constraints of 100m CPU and 200Mi memory to this container, as in the example.
  2. A volume for the two containers to share. The emptyDir volume type is a good choice for this because we only want the volume to exist for the lifetime of the pod.
  3. Mount paths for the volume in each container. In your primary container, this should be the path that the applications log files are written to. In the secondary container, this can be just about anything, so we put it under /mnt/log to keep it out of the way of the rest of the filesystem.
  4. The FILES_TO_COLLECT environment variable in the sidecar container, telling it which files to collect logs from. These paths should always be in the mounted volume.

其实跟第一种类似,但是是把Fluentd agent起在业务同一个pod中共享volume然后实现对日志文件的收集发送给Elasticsearch

fluentd分析

2016121461970fluentd-architecture.png

对于fluentd官方对其的定义是:

统一日志层

Fluentd通过在后端系统之间提供统一的日志记录层来从后端系统中解耦数据源。
此层允许开发人员和数据分析人员在生成日志时使用多种类型的日志。
统一的日志记录层可以让您和您的组织更好地使用数据,并更快地在您的软件上进行迭代。
也就是说fluentd是一个面向多种数据来源以及面向多种数据出口的日志收集器。另外它附带了日志转发的功能。

fluentd特点

  1. 部署简单灵活
  2. 开源
  3. 经过验证的可靠性和性能
  4. 社区支持,插件较多
  5. 使用json格式事件格式
  6. 可拔插的架构设计
  7. 低资源要求
  8. 内置高可靠性

fluentd与Logstash

2016121448323logstash_fluentdcomparison.png

引用一张图对比这两个日志收集工具。具体它们两个项目的对比请参考:

Fluentd vs. Logstash: A Comparison of Log Collectors1

fluentd与zeroMQ

把这两个产品放在一起比较实属不怎么合适,因为它们属于不同的阵营,完成不同的功能需求。由于fluentd具有消息转发的功能,姑且将其与以zeroMQ为例的消息中间件的关系做个说明:
在大型系统架构中,有使用zeroMQ进行大量的日志转发工作。在fluentd中有两个项目完成日志的中转路由的任务:golang编写的:fluentd-forwarder 和c写的fluent-bit

那么是否意味着你需要做出选择呢?其实不然。
着眼fluentd的定义和zeroMQ的定义。其实它们是一种合作关系。如果你是大型的架构系统,日志量很庞大。我推荐你使用fluentd进行日志收集,将zeroMQ作为fluentd的出口。就是说fluentd完成统一收集,zeroMQ完成日志传输。如果你的系统并不庞大,你就无需zeroMQ来传输了。

因此你也无需关注这两个产品的性能比较。虽然它们都有高性能的定义。

zeroMQ的性能测试结果:zeroMQ 与JeroMQ性能对比1

容器日志收集总结

如上所描述的一样,无论你的业务容器日志呈现方式有什么不同,你都可以使用统一的日志收集器收集。以下简介三种情况下日志手机方式推荐:

  1. k8s集群
    这种方式上文中已经提到了官方的解决方案,你只需要安装此方案部署即可。
  2. docker swarm集群
    docker swarm目前暂时没有提供日志查看机制。但是docker cloud提供了与kubectrl logs类似的机制查看stdout的日志。目前还没有fluentd插件直接对服务进行日志收集,暂时考虑直接使用使用跟容器一样的机制收集。docker service create 支持--log-driver
  3. 自己部署的docker容器
    从docker1.8内置了fluentd log driver。以如下的形式启动容器,容器stdout/stderr日志将发往配置的fluentd。如果配置后,docker logs将无法使用。另外默认模式下如果你配置得地址没有正常服务,容器无法启动。你也可以使用fluentd-async-connect形式启动,docker daemon则能在后台尝试连接并缓存日志。
docker run --log-driver=fluentd --log-opt fluentd-address=myhost.local:24224

同样如果是日志文件,将文件暴露出来直接使用fluentd收集。

好雨云帮对kubernetes服务日志的统一处理方式

需求是什么?

云帮的公有云服务,平台上跑着有企业级应用和小型用户应用。我们怎么做到统一的日志收集和展示?又怎么做到面对企业级应用的日志输出和分析?
上面提到的方式不能完全解决我们的问题。

实践

首先目前kubernetes版本(v1.5.1)还不支持pod级别的日志log-driver设置,但是我们知道容器是可以设置log-driver的。这里1也有关于这个问题的讨论。我们为了实现在用户网络(即pod容器网络)下的可配置日志转发方式。我们暂时修改了kubernetes源码使其支持设置容器的log-driver。默认情况下我们使用自己实现的zeroMQ-driver直接将容器日志通过0MQ发到日志统一处理中心。在处理中心统一完成下一步处理。如果平台用户需要将日志向外输出或者直接对接平台内日志分析应用,我们的处理是在应用pod中启动日志收集插件容器(封装扩展的fluentd),根据用户的需要配置日志出口,实现应用级日志收集。这里你需要明确的是:容器日志首先是由docker-daemon收集到,再根据容器log-driver配置进行相应操作,也就是说如果你的宿主机网络与容器网络不通(k8s集群),日志从宿主机到pod中的收集容器只有两种方式:走外层网络,文件挂载。
我们采用文件挂载方式。

本文转自开源中国-关于k8s集群容器日志收集的总结

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
2月前
|
存储 监控 对象存储
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
针对本地存储和 PVC 这两种容器存储使用方式,我们对 ACK 的容器存储监控功能进行了全新升级。此次更新完善了对集群中不同存储类型的监控能力,不仅对之前已有的监控大盘进行了优化,还针对不同的云存储类型,上线了全新的监控大盘,确保用户能够更好地理解和管理容器业务应用的存储资源。
365 182
|
12天前
|
存储 监控 对象存储
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
|
14天前
|
存储 监控 对象存储
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
|
16天前
|
监控 Kubernetes Cloud Native
基于阿里云容器服务Kubernetes版(ACK)的微服务架构设计与实践
本文介绍了如何基于阿里云容器服务Kubernetes版(ACK)设计和实现微服务架构。首先概述了微服务架构的优势与挑战,如模块化、可扩展性及技术多样性。接着详细描述了ACK的核心功能,包括集群管理、应用管理、网络与安全、监控与日志等。在设计基于ACK的微服务架构时,需考虑服务拆分、通信、发现与负载均衡、配置管理、监控与日志以及CI/CD等方面。通过一个电商应用案例,展示了用户服务、商品服务、订单服务和支付服务的具体部署步骤。最后总结了ACK为微服务架构提供的强大支持,帮助应对各种挑战,构建高效可靠的云原生应用。
|
21天前
|
弹性计算 人工智能 资源调度
DeepSeek大解读系列公开课上新!阿里云专家主讲云上智能算力、Kubernetes容器服务、DeepSeek私有化部署
智猩猩「DeepSeek大解读」系列公开课第三期即将开讲,聚焦阿里云弹性计算助力大模型训练与部署。三位专家将分别讲解智能算力支撑、Kubernetes容器服务在AI场景的应用实践、以及DeepSeek一键部署和多渠道应用集成,分享云计算如何赋能大模型发展。欲观看直播,可关注【智猩猩GenAI视频号】预约。 (239字符)
|
2月前
|
存储 运维 Kubernetes
正式开源,Doris Operator 支持高效 Kubernetes 容器化部署方案
飞轮科技推出了 Doris 的 Kubernetes Operator 开源项目(简称:Doris Operator),并捐赠给 Apache 基金会。该工具集成了原生 Kubernetes 资源的复杂管理能力,并融合了 Doris 组件间的分布式协同、用户集群形态的按需定制等经验,为用户提供了一个更简洁、高效、易用的容器化部署方案。
正式开源,Doris Operator 支持高效 Kubernetes 容器化部署方案
|
14天前
|
监控 Cloud Native Java
基于阿里云容器服务(ACK)的微服务架构设计与实践
本文介绍如何利用阿里云容器服务Kubernetes版(ACK)构建高可用、可扩展的微服务架构。通过电商平台案例,展示基于Java(Spring Boot)、Docker、Nacos等技术的开发、容器化、部署流程,涵盖服务注册、API网关、监控日志及性能优化实践,帮助企业实现云原生转型。
|
2月前
|
存储 监控 对象存储
ACK容器监控存储全面更新:让您的应用运行更稳定、更透明
介绍升级之后的ACK容器监控体系,包括各大盘界面展示和概要介绍。
|
2月前
|
Kubernetes Linux 虚拟化
入门级容器技术解析:Docker和K8s的区别与关系
本文介绍了容器技术的发展历程及其重要组成部分Docker和Kubernetes。从传统物理机到虚拟机,再到容器化,每一步都旨在更高效地利用服务器资源并简化应用部署。容器技术通过隔离环境、减少依赖冲突和提高可移植性,解决了传统部署方式中的诸多问题。Docker作为容器化平台,专注于创建和管理容器;而Kubernetes则是一个强大的容器编排系统,用于自动化部署、扩展和管理容器化应用。两者相辅相成,共同推动了现代云原生应用的快速发展。
329 11
|
存储 Kubernetes API
在K8S集群中,如何正确选择工作节点资源大小? 2
在K8S集群中,如何正确选择工作节点资源大小?

相关产品

  • 容器服务Kubernetes版