如何进行K8s日志采集最佳实践

发布时间:2021-12-16 10:44:46 作者:柒染
来源:亿速云 阅读:161

这篇文章将为大家详细讲解有关如何进行K8s日志采集最佳实践,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。

Kubernetes 日志采集难点

在 Kubernetes 中,日志采集相比传统虚拟机、物理机方式要复杂很多,最根本的原因是 Kubernetes 把底层异常屏蔽,提供更加细粒度的资源调度,向上提供稳定、动态的环境。因此日志采集面对的是更加丰富、动态的环境,需要考虑的点也更加的多。

例如:


Kubernetes传统方式
日志种类文件、stdout、宿主机文件、journal文件、journal
日志源业务容器、系统组件、宿主机业务、宿主机
采集方式Agent(Sidecar、DaemonSet)、直写(DockerEngine、业务)Agent、直写
单机应用数10-1001-10
应用动态性
节点动态性
采集部署方式手动、Yaml手动、自定义

采集方式:主动 or 被动

日志的采集方式分为被动采集和主动推送两种,在 K8s 中,被动采集一般分为 Sidecar 和 DaemonSet 两种方式,主动推送有 DockerEngine 推送和业务直写两种方式。

如何进行K8s日志采集最佳实践

总结下来:

详细的各种采集方式对比如下:


DockerEngine业务直写DaemonSet方式Sidecar方式
采集日志类型标准输出业务日志标准输出+部分文件文件
部署运维低,原生支持低,只需维护好配置文件即可一般,需维护DaemonSet较高,每个需要采集日志的POD都需要部署sidecar容器
日志分类存储无法实现业务独立配置一般,可通过容器/路径等映射每个POD可单独配置,灵活性高
多租户隔离弱,日志直写会和业务逻辑竞争资源一般,只能通过配置间隔离强,通过容器进行隔离,可单独分配资源
支持集群规模本地存储无限制,若使用syslog、fluentd会有单点限制无限制取决于配置数无限制
资源占用低,docker


engine提供整体最低,省去采集开销较低,每个节点运行一个容器较高,每个POD运行一个容器
查询便捷性低,只能grep原始日志高,可根据业务特点进行定制较高,可进行自定义的查询、统计高,可根据业务特点进行定制
可定制性高,可自由扩展高,每个POD单独配置
耦合度高,与DockerEngine强绑定,修改需要重启DockerEngine高,采集模块修改/升级需要重新发布业务低,Agent可独立升级一般,默认采集Agent升级对应Sidecar业务也会重启(有一些扩展包可以支持Sidecar热升级)
适用场景测试、POC等非生产场景对性能要求极高的场景日志分类明确、功能较单一的集群大型、混合型、PAAS型集群

日志输出:Stdout or 文件

和虚拟机/物理机不同,K8s 的容器提供标准输出和文件两种方式。在容器中,标准输出将日志直接输出到 stdout 或 stderr,而 DockerEngine 接管 stdout 和 stderr 文件描述符,将日志接收后按照 DockerEngine 配置的 LogDriver 规则进行处理;日志打印到文件的方式和虚拟机/物理机基本类似,只是日志可以使用不同的存储方式,例如默认存储、EmptyDir、HostVolume、NFS 等。

虽然使用 Stdout 打印日志是 Docker 官方推荐的方式,但大家需要注意:这个推荐是基于容器只作为简单应用的场景,实际的业务场景中我们还是建议大家尽可能使用文件的方式,主要的原因有以下几点:

因此我们建议线上应用使用文件的方式输出日志,Stdout 只在功能单一的应用或一些 K8s 系统/运维组件中使用。

CICD集成:Logging Operator

如何进行K8s日志采集最佳实践

Kubernetes 提供了标准化的业务部署方式,可以通过 yaml(K8s API)来声明路由规则、暴露服务、挂载存储、运行业务、定义缩扩容规则等,所以 Kubernetes 很容易和 CICD 系统集成。而日志采集也是运维监控过程中的重要部分,业务上线后的所有日志都要进行实时的收集。

原始的方式是在发布之后手动去部署日志采集的逻辑,这种方式需要手工干预,违背 CICD 自动化的宗旨;为了实现自动化,有人开始基于日志采集的 API/SDK 包装一个自动部署的服务,在发布后通过 CICD 的 webhook 触发调用,但这种方式的开发代价很高。

在 Kubernetes 中,日志最标准的集成方式是以一个新资源注册到 Kubernetes 系统中,以 Operator(CRD)的方式来进行管理和维护。在这种方式下,CICD 系统不需要额外的开发,只需在部署到 Kubernetes 系统时附加上日志相关的配置即可实现。

Kubernetes 日志采集方案

如何进行K8s日志采集最佳实践

早在 Kubernetes 出现之前,我们就开始为容器环境开发日志采集方案,随着 K8s 的逐渐稳定,我们开始将很多业务迁移到 K8s 平台上,因此也基于之前的基础专门开发了一套 K8s 上的日志采集方案。主要具备的功能有:

安装日志采集组件

目前这套采集方案已经对外开放,我们提供了一个 Helm 安装包,其中包括 Logtail 的 DaemonSet、AliyunlogConfig 的 CRD 声明以及 CRD Controller,安装之后就能直接使用 DaemonSet 采集以及 CRD 配置了。安装方式如下:

  1. 阿里云 Kubernetes 集群在开通的时候可以勾选安装,这样在集群创建的时候会自动安装上述组件。如果开通的时候没有安装,则可以 手动安装;

  2. 如果是自建的 Kubernetes,无论是在阿里云上自建还是在其他云或者是线下,也可以使用这样采集方案。

安装好上述组件之后,Logtail 和对应的 Controller 就会运行在集群中,但默认这些组件并不会采集任何日志,需要配置日志采集规则来采集指定 Pod 的各类日志。

采集规则配置:环境变量 or CRD

除了在日志服务控制台上手动配置之外,对于 Kubernetes 还额外支持两种配置方式:环境变量和 CRD。

这种方式部署简单,学习成本低,很容易上手;但能够支持的配置规则很少,很多高级配置(例如解析方式、过滤方式、黑白名单等)都不支持,而且这种声明的方式不支持修改/删除,每次修改其实都是创建 1 个新的采集配置,历史的采集配置需要手动清理,否则会造成资源浪费。

如何进行K8s日志采集最佳实践

例如下面的示例就是部署一个容器标准输出的采集,其中定义需要 Stdout 和 Stderr 都采集,并且排除环境变量中包含 COLLEXT_STDOUT_FLAG:false 的容器。

基于 CRD 的配置方式以 Kubernetes 标准扩展资源的方式进行管理,支持配置的增删改查完整语义,而且支持各种高级配置,是我们极其推荐的采集配置方式。

如何进行K8s日志采集最佳实践

采集规则推荐的配置方式

如何进行K8s日志采集最佳实践

实际应用场景中,一般都是使用 DaemonSet 或 DaemonSet 与 Sidecar 混用方式,DaemonSet 的优势是资源利用率高,但有一个问题是 DaemonSet 的所有 Logtail 都共享全局配置,而单一的 Logtail 有配置支撑的上限,因此无法支撑应用数比较多的集群。

上述是我们给出的推荐配置方式,核心的思想是:

实践 1 - 中小型集群

如何进行K8s日志采集最佳实践

绝大部分 Kubernetes 集群都属于中小型的,对于中小型没有明确的定义,一般应用数在 500 以内,节点规模 1000 以内,没有职能明确的 Kubernetes 平台运维。这种场景应用数不会特别多,DaemonSet 可以支撑所有的采集配置:

实践 2 - 大型集群

如何进行K8s日志采集最佳实践

对于一些用作 PaaS 平台的大型/超大型集群,一般业务在 1000 以上,节点规模也在 1000 以上,有专门的 Kubernetes 平台运维人员。这种场景下应用数没有限制,DaemonSet 无法支持,因此必须使用 Sidecar 方式,整体规划如下:

关于如何进行K8s日志采集最佳实践就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。

推荐阅读:
  1. K8S安全军规101:对CNCF最佳实践的扩充
  2. Logstash 日志采集工具

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

k8s

上一篇:flume1.7 新特性是什么

下一篇:Linux sftp命令的用法是怎样的

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》