摘要: DaemonSet和Sidecar模式各有优缺点,目前没有哪种方式可以适用于所有场景。因此我们阿里云日志服务同时支持了DaemonSet以及Sidecar两种方式,并对每种方式进行了一些额外的改进,更加适用于K8S下的动态场景。

Kubernetes(K8S)作为CNCF(cloud native computing foundation)的一个核心项目,背靠Google和Redhat的强大社区,近两年发展十分迅速,在成为容器编排领域中领导者的同时,也正在朝着PAAS底座标配的方向发展。

日志采集方式
日志作为任一系统不可或缺的部分,在K8S的官方文档中也介绍了多种的日志采集形式,总结起来主要有下述3种:原生方式、DaemonSet方式和Sidecar方式。

原生方式:使用 kubectl logs 直接在查看本地保留的日志,或者通过docker engine的 log driver 把日志重定向到文件、syslog、fluentd等系统中。
DaemonSet方式:在K8S的每个node上部署日志agent,由agent采集所有容器的日志到服务端。
Sidecar方式:一个POD中运行一个sidecar的日志agent容器,用于采集该POD主容器产生的日志。

 

采集方式对比
每种采集方式都有一定的优劣势,这里我们进行简单的对比:

 

 

从上述表格中可以看出:

原生方式相对功能太弱,一般不建议在生产系统中使用,否则问题调查、数据统计等工作很难完成;
DaemonSet方式在每个节点只允许一个日志agent,相对资源占用要小很多,但扩展性、租户隔离性受限,比较适用于功能单一或业务不是很多的集群;
Sidecar方式为每个POD单独部署日志agent,相对资源占用较多,但灵活性以及多租户隔离性较强,建议大型的K8S集群或作为PAAS平台为多个业务方服务的集群使用该方式。
日志服务K8S采集方式
DaemonSet和Sidecar模式各有优缺点,目前没有哪种方式可以适用于所有场景。因此我们阿里云日志服务同时支持了DaemonSet以及Sidecar两种方式,并对每种方式进行了一些额外的改进,更加适用于K8S下的动态场景。

这两种模式均基于Logtail实现,日志服务客户端Logtail目前已有百万级部署,每天采集上万应用、数PB的数据,历经多次双11、双12考验。相关技术分享可以参见文章:多租户隔离技术+双十一实战效果,Polling + Inotify 组合下的日志保序采集方案。

DaemonSet采集方式
DaemonSet方式下Logtail做了非常多的适配工作,包括:

一条命令一个参数即可实现部署,资源自动初始化
支持CRD方式配置,支持K8S控制台、kubectl、kube api等,与K8S发布、部署无缝集成
K8S RBAC鉴权,日志服务STS鉴权管理

 

详细的介绍文章可以参考:
再次升级!阿里云Kubernetes日志解决方案
LC3视角:Kubernetes下日志采集、存储与处理技术实践

Sidecar采集方式
sidecar方式的配置以及使用相对在虚拟机/物理机上采集数据区别不大,从Logtail容器视角来看:Logtail工作在一个“虚拟机”上,需要采集这个机器上某个/某些日志文件。

 

 

但在容器场景下还需解决两个问题:

配置:使用编排的方式配置agent容器
动态性:需适应POD的IP地址和hostname的变化
目前Logtail的容器支持通过环境变量配置相关参数,并支持自定义标识的机器组进行工作,可以完美解决上述两个问题。
Sidecar配置示例
Sidecar模式下日志组件安装、配置方式如下:

步骤一: 部署Logtail容器

在部署POD时将日志路径挂载到本地,并将对应的volume也挂载到Logtail容器。
Logtail容器需配置 ALIYUN_LOGTAIL_USER_ID 、 ALIYUN_LOGTAIL_CONFIG 、 ALIYUN_LOGTAIL_USER_DEFINED_ID ,参数含义以及值的选取参见:标准Docker日志采集。
tips:

Logtail容器建议配置健康检查,在运行环境、内核等出现异常时可自动恢复。
示例中使用的Logtail镜像访问的是阿里云hangzhou公网镜像仓库,您可根据需求替换成本Region的镜像,并使用内网方式。

apiVersion: batch/v1
kind: Job
metadata:
name: nginx-log-sidecar-demo
namespace: kube-system
spec:
template:
metadata:
name: nginx-log-sidecar-demo
spec:
# volumes配置
volumes:
– name: nginx-log
emptyDir: {}
containers:
# 主容器配置
– name: nginx-log-demo
image: registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest
command: [“/bin/mock_log”]
args: [“–log-type=nginx”, “–stdout=false”, “–stderr=true”, “–path=/var/log/nginx/access.log”, “–total-count=1000000000”, “–logs-per-sec=100”]
volumeMounts:
– name: nginx-log
mountPath: /var/log/ngin
# Logtail的Sidecar容器配置
– name: logtail
image: registry.cn-hangzhou.aliyuncs.com/log-service/logtail:latest
env:
# aliuid
– name: “ALIYUN_LOGTAIL_USER_ID”
value: “165421******3050”
# 自定义标识机器组配置
– name: “ALIYUN_LOGTAIL_USER_DEFINED_ID”
value: “nginx-log-sidecar”
# 启动配置(用于选择Logtail所在Region)
– name: “ALIYUN_LOGTAIL_CONFIG”
value: “/etc/ilogtail/conf/cn-hangzhou/ilogtail_config.json”
# 和主容器共享volume
volumeMounts:
– name: nginx-log
mountPath: /var/log/nginx
# 健康检查
livenessProbe:
exec:
command:
– /etc/init.d/ilogtaild
– status
initialDelaySeconds: 30
periodSeconds: 30

步骤二: 配置机器组

如下图所示,在日志服务控制台创建一个Logtail的机器组,机器组选择自定义标识,可以动态适应POD ip地址的改变。具体操作步骤如下:

开通日志服务并创建Project、Logstore,详细步骤请参考准备流程。
在日志服务控制台的机器组列表页面单击创建机器组。
选择用户自定义标识,将您上一步配置的 ALIYUN_LOGTAIL_USER_DEFINED_ID填入用户自定义标识内容框中。

 

步骤三:配置采集方式

机器组创建完成后,即可配置对应文件的采集配置,目前支持极简、Nginx访问日志、分隔符日志、JSON日志、正则日志等格式,具体可参考:文本日志配置方式。本示例中配置如下:

 

 

步骤四:查询日志

 

采集配置完成并应用到机器组后,1分钟内日志即可采集上来,进入对应logstore的查询页面即可查询到采集上来的日志。

 

日志进阶
阿里云日志服务针对日志提供了完整的解决方案,日志采集只是其中的第一步,以下相关功能是日志进阶的必备良药:

日志上下文查询:https://help.aliyun.com/document_detail/48148.html
快速查询:https://help.aliyun.com/document_detail/88985.html
实时分析:https://help.aliyun.com/document_detail/53608.html
快速分析:https://help.aliyun.com/document_detail/66275.html
基于日志设置告警:https://help.aliyun.com/document_detail/48162.html
配置大盘:https://help.aliyun.com/document_detail/69313.html
更多日志进阶内容可以参考:日志服务学习路径。
————————————————
版权声明:本文为CSDN博主「牛牛Blog」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/yujia_666/article/details/115705807

原文地址:http://www.cnblogs.com/gaoyanbing/p/16900525.html

1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长! 2. 分享目的仅供大家学习和交流,请务用于商业用途! 3. 如果你也有好源码或者教程,可以到用户中心发布,分享有积分奖励和额外收入! 4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解! 5. 如有链接无法下载、失效或广告,请联系管理员处理! 6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需! 7. 如遇到加密压缩包,默认解压密码为"gltf",如遇到无法解压的请联系管理员! 8. 因为资源和程序源码均为可复制品,所以不支持任何理由的退款兑现,请斟酌后支付下载 声明:如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性