K8S的日志采 没有我们想的这么简单
发布时间：2023-02-27 11:09:06 所属栏目：通讯 来源：
导读：相比传统的主机日志采集，在Kubernetes集群中，采集容器日志有一些差异，使用方式上也有所区别。为此,我们就列出了一些常规的设置和使用办法供大家参考。
1.从主机到容器
在传统的使用虚拟机/云主机/物理机的时
1.从主机到容器
在传统的使用虚拟机/云主机/物理机的时
|
相比传统的主机日志采集，在Kubernetes集群中，采集容器日志有一些差异，使用方式上也有所区别。为此,我们就列出了一些常规的设置和使用办法供大家参考。 1.从主机到容器 在传统的使用虚拟机/云主机/物理机的时代，业务进程部署在固定的节点上，业务日志直接输出到宿主机上，运维只需要手动或者使用自动化工具把日志采集Agent部署在节点上，加一下Agent的配置，就可以开始采集日志了。而在Kubernetes环境中，就没这么简单了： 「动态迁移」：在Kubernetes集群中经常存在Pod主动或者被动的迁移，频繁的销毁、创建，我们无法和传统的方式一样人为的给每个服务下发日志采集配置。 「日志存储方式多样性」：容器的日志存储方式有很多不同的类型，例如stdout、hostPath、emptyDir、pv等。 「Kubernetes元信息」：由于日志数据采集后会被集中存储，所以查询日志时，需要根据namespace、pod、container、node，甚至包括容器的环境变量、label等维度来检索、过滤，此时要求Agent感知并默认在日志里注入这些元信息。 2. 在Kubernetes下的日志形态 为了采集容器日志，现在的话我们先来看一下现在在市面上我们一般都有哪些比较好的解决方案。 2.1 采集的日志类型 首先，需要提及的是，在云原生的12要素里，推荐业务容器将日志输出到stdout中，而不是采用打印日志文件的方式。当然，实际情况是，我们很难这么做，原因大概有： 需要业务方修改日志配置，比较难以推广 「标准输出stdout」 「日志文件」 2.2 Agent部署方式 采集容器日志，Agent有两种部署方式： 「DaemonSet」：每个节点部署一个Agent 「Sidecar」：每个Pod增加一个Sidecar容器，运行日志Agent 两种部署方式的优劣都显而易见： 侵入性：Sidecar的方式，Agent需要注入到业务Pod中，不管是否有平台封装这一过程，还是采用Kubernetes webhook的方式默认注入，仍然改变了原本的部署方式 稳定性：日志采集在大部分的情况下，需要保障的是稳定性，最重要的是不能影响业务，如果采用Sidecar的方式，在Agent发生异常或者oom等情况下，很容易对业务容器造成影响。另外，Agent比较多的时候，在连接数等方面会对下游服务比如Kafka造成一定的隐患。 隔离性：DaemonSet情况下，节点所有的日志都共用同一个Agent，而Sidecar方式，只会采集同一个Pod内的业务日志，此时Sidecar的隔离性理论上会好一些 性能：Sidecar由于只会采集Pod里的日志，压力相对较小，极端情况下，达到Agent的性能瓶颈比DaemonSet方式概率也会小很多 所以，对于Agent采集标准输出日志来说，也就是采集节点上的这些日志文件。一种简单粗暴的采集方式是，使用DaemonSet部署日志Agent，挂载/var/log/pods目录，Agent的配置文件使用类似/var/log/pod.log去通配日志文件，采集节点上所有的容器标准输出。采集节点上所有的容器标准输出。这样一来，就可以实现对整个系统的监控，包括容器的启动、停止、运行状态等。 （编辑：驾考网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |