再次升级!阿里云Kubernetes日志解决方案

摘要: 今天阿里云Kubernetes日志解决方案再次升级,为您带来以下改进: 1、极致部署体验:只需一条命令一个参数即可完成整个K8S集群的日志解决方案部署。 2、支持更多配置方式:除原生控制台、SDK配置方式外,支持通过CRD方式进行配置(kubectl、控制台、K8S openapi)。

背景

针对K8S日志采集存在的采集目标多、弹性伸缩难、运维成本大、侵入性高、采集性能低等问题,在18年2月份日志服务和容器服务团队一起发布了阿里云Kubernetes日志解决方案。1分钟内即可完成整个集群部署,实现该节点上宿主机日志、容器日志、容器stdout等所有数据源的一站式采集。并且后续集群动态伸缩无需对采集做任何二次部署。

今天阿里云Kubernetes日志解决方案再次升级,为您带来以下改进:

  • 极致部署体验:只需一条命令一个参数即可完成整个K8S集群的日志解决方案部署。
  • 支持更多配置方式:除原生控制台、SDK配置方式外,支持通过CRD方式进行配置(kubectl、控制台、K8S openapi)。
  • K8S无缝集成:采集配置支持yaml方式部署,兼容K8S各种集成方式。

日志服务介绍

阿里云的日志服务(log service)是针对日志类数据的一站式服务,2013年研发,有5年多线上运行经验,经历双十一、新春红包等考验。日志采集Agent Logtail运行在100W+机器上,为万级别应用提供服务。主要特点如下:

日志服务主要包括 实时采集与消费、数据投递、查询与实时分析 等功能,接下来我们介绍下如何利用日志服务进行Kubernetes日志采集。

Kubernetes日志采集方案介绍

方案简介

阿里云Kubernetes日志采集方案如上图所示:

  • K8S的每个worker 节点都会运行一个Logtail容器,该容器可采集宿主机以及该宿主机上其他容器的日志(包括标准输出和日志文件)。
  • Logtail以daemon set模式运行,保证每个节点都有一个Logtail容器在运行
  • 使用自定义标识机器组,支持集群动态缩/扩容
  • 所有的采集配置支持通过docker lable以及环境变量过滤指定容器
  • K8S内部会注册自定义资源(CRD,CustomResourceDefinition)AliyunLogConfig,并部署alibaba-log-controller
  • 支持用户通过CRD方式或日志服务控制台对采集配置进行管理

运行流程

以CRD配置方式为例,内部工作流程如下:

  1. 用户使用kubectl或其他工具应用aliyunlogconfigs CRD配置。
  2. alibaba-log-controller监听到配置更新。
  3. alibaba-log-controller根据CRD内容以及服务端状态,自动向日志服务提交logstore创建、配置创建以及应用机器组的请求。
  4. 以DaemonSet模式运行的Logtail会定期请求配置服务器,获取新的或已更新的配置并进行热加载。
  5. Logtail根据配置信息采集各个容器(POD)上的标准输出或日志文件。
  6. 最终Logtail将处理、聚合好的数据发送到日志服务。

部署方法

阿里云Kubernetes用户只需一条命令即可完成日志采集部署,命令中只需输入一个参数。

  1. 开通阿里云日志服务,日志服务开通链接
  2. 登录您的阿里云容器服务Kubernetes的Master节点,如何登录参考SSH访问集群
  3. 将下述命令中的${your_k8s_cluster_id}替换为您的Kubernetes集群id,执行此命令。
 wget http://logtail-release.oss-cn-hangzhou.aliyuncs.com/linux64/alicloud-log-k8s-install.sh -O alicloud-log-k8s-install.sh; chmod 744 ./alicloud-log-k8s-install.sh; sh ./alicloud-log-k8s-install.sh ${your_k8s_cluster_id}

配置方式

日志采集配置默认支持控制台配置方式,同时针对Kubernetes微服务开发模式,我们还提供CRD的配置方式,您可以直接使用kubectl对配置进行管理或集成到其他编排服务。两种配置方式特点如下:

  CRD方式 控制台方式
操作复杂度 一般
功能项 支持除控制台方式外的高级配置 一般
上手难度 一般
网络连接 连接Kubernetes集群 连接互联网
与组件/应用部署集成 支持 不支持
鉴权方式 Kubernetes鉴权 云账号鉴权

如果您刚开始使用日志服务,建议使用控制台的配置方式,此种方式所见即所得,非常易于上手。

若后续您需要将日志采集与服务/组件发布集成,建议使用CRD的配置方式。可以直接将采集配置和服务配置放到同一个yaml文件部署和管理。

方案优势

相比其他采集方案,日志服务Kubernetes采集方案具备以下优势:

核心技术介绍

在上一篇阿里云Kubernetes日志解决方案中我们对容器数据采集、自定义标识机器组等技术做了相关的介绍。本次主要为大家带来日志采集配置与K8S无缝集成的技术实现。

K8S无缝集成

问题背景

不同于其他开源日志采集Agent,日志服务Logtail从设计之初就已经考虑到配置管理的难题。因此Logtail从第一个版本发布就支持中心化的配置管理。支持在日志服务控制台或者SDK远程对所有采集配置进行统一管理,大大降低了日志采集的管理负担。

但在K8S集群环境下,业务应用/服务/组件的持续集成和自动发布已经成为常态,使用控制台或SDK操作采集配置的方式很难与各类CI、编排框架集成,导致业务应用发布后用户只能通过控制台手动配置的方式部署与之对应的日志采集配置。

因此日志服务专门为K8S进行了扩展,用以支持原始的配置管理。

实现方式

如上图所示,日志服务为K8S新增了一个CustomResourceDefinition扩展,名为AliyunLogConfig。同时开发了alibaba-log-controller用于监听AliyunLogConfig事件。

当用户创建/删除/修改AliyunLogConfig资源时,alibaba-log-controller会监听到资源变化,并对应的在日志服务上创建/删除/修改相应的采集配置。以此实现K8S内部AliyunLogConfig与日志服务中采集配置的关联关系。

alibaba-log-controller内部实现

alibaba-log-controller主要由6个模块组成,各个模块的功能以及依赖关系如上图所示:

  • EventListener:负责监听AliyunLogConfig的CRD资源。这个EventListener是广义上的listener,主要功能有
    • 初始化时会list所有的AliyunLogConfig资源
    • 注册AliyunLogConfig监听变化的事件
    • 定期再扫描全量的AliyunLogConfig资源防止事件出现遗漏或处理失效
    • 将事件打包,交由EventHandler处理
  • EventHandler:负责处理对应的Create/Update/Delete事件,作为Controller的核心模块,主要功能如下:
    • 首先检查ConfigMapManager中对应的checkpoint,如该事件已经被处理(版本号相同且状态为200),则直接跳过
    • 为防止历史事件干扰处理结果,从服务端拉取最新的资源状态,检查是否为同一版本,若版本不一致,使用服务端版本替换
    • 对事件进行一定的预处理,使之符合LogSDK的基本格式需求
    • 调用LogSDKWrapper,创建日志服务Logstore,Create/Update/Delete对应的配置
    • 根据上述处理结果,更新对应AliyunLogConfig资源的状态
  • ConfigMapManager:依赖于K8S的ConfigMap机制实现Controller的checkpoint管理,包括:
    • 维护checkpoint到ConfigMap的映射关系
    • 提供基础的checkpoint增删改查接口
  • LogSDKWrapper:基于阿里云LOG golang sdk的二次封装,功能包括:
    • 初始化创建日志服务资源,包括Project、MachineGroup、Operation Logstore等
    • 将CRD资源转换为对应的日志服务资源操作,为1对多关系
    • 包装SDK接口,自动处理网络异常、服务器异常、权限异常
    • 负责权限管理,包括自动获取role,更新sts token等
  • ScheduledSyner:后台的定期同步模块,防止进程/节点失效期间配置改动而遗漏事件,保证配置管理的最终一致性:
    • 定期刷新所有的checkpoint和AliyunLogConfig
    • 检查checkpoint和AliyunLogConfig资源的映射关系,如果checkpoint中出现不存在的配置,则删除对应的资源
  • Monitor:alibaba-log-controller除了将本地运行日志输出到stdout外,还会将日志直接采集到日志服务,便于远程排查问题。采集日志种类如下:
    • k8s api内部异常日志
    • alibaba-log-controller运行日志
    • alibaba-log-controller内部异常数据(自动聚合)

总结

阿里云日志服务本次带来的提升更进一步简化了K8S日志采集的上手门槛以及集成体验。让广大用户真正体验到一个字:爽,从此日志运维人员的生活质量大大提高。

目前Logtail除支持宿主机文件、容器文件、容器stdout采集外,还支持以下多种采集方式(这些方式k8s中均支持):

  1. syslog采集
  2. Mysql binlog采集
  3. JDBC采集
  4. http采集

原文链接

原文地址:http://blog.51cto.com/13679539/2121254

时间: 2024-09-27 05:22:09

再次升级!阿里云Kubernetes日志解决方案的相关文章

利用 log-pilot + elasticsearch + kibana 搭建 kubernetes 日志解决方案

开发者在面对 kubernetes 分布式集群下的日志需求时,常常会感到头疼,既有容器自身特性的原因,也有现有日志采集工具的桎梏,主要包括: 容器本身特性: 采集目标多:容器本身的特性导致采集目标多,需要采集容器内日志.容器 stdout.对于容器内部的文件日志采集,现在并没有一个很好的工具能够去动态发现采集.针对每种数据源都有对应的采集软件,但缺乏一站式的工具. 弹性伸缩难:kubernetes 是分布式的集群,服务.环境的弹性伸缩对于日志采集带来了很大的困难,无法像传统虚拟机环境下那样,事先

15分钟在阿里云Kubernetes服务上快速建立Jenkins X Platform并运用GitOps管理应用发布

本文主要介绍如何在阿里云容器服务Kubernetes上快速安装部署Jenkins X Platform并结合demo实践演示GitOps的操作流程. 注意:本文中使用的jx工具.cloud-environments等做过改造用以适配阿里云Kubernetes容器服务,并未在自建Kubernetes集群中做过验证. 先决条件:首先,需要在 阿里云容器服务控制台 创建一个Kubernetes集群,本次实践使用的环境信息如下:master1 192.168.0.119master2 192.168.0

重磅发布: 阿里云WAF日志实时分析上线 (含视频)

背景Web***形势 互联网界的安全一直都不断的面临着挑战,以DDoS/Web***为代表的网络威胁直接对网络安全产生严重的影响. 据近年来的调查报告显示,Web***的方式向两极化发展,慢速***.混合***尤其是CC***占比不断增大,这给检测防御造成更大的难度.在整个网络***中, 应用层***也在大幅度翻倍(参考Imperva 2017Q4的DDoS风险报告) 阿里云WAF 阿里云云盾Web应用防火墙(Web Application Firewall, 简称 WAF)基于云安全大数据能力

利用 Log-Pilot + Kafka + Elasticsearch + Kibana 搭建 kubernetes日志解决方案

利用 Log-Pilot + Kafka+Elasticsearch + Kibana 搭建 kubernetes日志解决方案 1.前提条件 已有kafka.elk.k8s集群,这3套集群搭建网上资料很多,这里不写,IP规划如下所示: kafka集群 10.6.11.22:9092 10.6.11.23:9092 10.6.11.24:9092 ELK集群 10.6.11.25:9200 10.6.11.26:9200 10.6.11.27:9200 k8s集群 10.6.11.28(maste

阿里云SLS日志服务

1.linux安装logtail.sh 使用安骑士命令通道下发安装Agent存在用户隐私方面风险,因此日志服务不再提供Logtail的自动安装功能,请参照本文手动安装Logtail 支持Linux(64位)和Windows(32位.64位)操作系统 wget http://logtail-release.oss-cn-hangzhou-internal.aliyuncs.com/linux64/logtail.sh chmod 755 logtail.sh 以日志服务北京Region,ECS经典

边缘节点服务ENS重磅升级 阿里云首次定义“边缘云计算”概念层层深入

随着5G.物联网时代的到来以及云计算应用的逐渐增加,传统集中式的云计算技术已经无法满足终端侧"大连接,低时延,大带宽"的需求.结合边缘计算的概念,云计算将必然发展到下一个技术阶段,也就是将云计算的能力拓展至距离终端更近的边缘侧,并通过云边端的统一管控实现云计算服务的下沉,提供端到端的云服务.如此,边缘云计算的概念也随之产生了.为了积极引导边缘云计算技术和应用发展,以及边缘云计算相关标准化的制定,阿里云和中国电子技术标准化研究院联合发布<边缘云计算技术与标准化白皮书>,在业界

升级阿里云服务器文案

1.由于业务发展,阿里云要求一部分北一区的老旧服务器,进行硬件升级 2.然而这一切需要以迁移数据和更换IP为代价 3.而且官方居然连一个正式的文档,都没有写,如何转移,以及转移之后,会出现哪些错误,注意事项,完全没有,感觉这不是我心目中高大上的阿里作风呀 下面我说一下转移之后的坑吧 1.转移数据时间不固定,并没有说明进度和时间,之前特意看了一个帖子,他说转移数据一共花了16分钟,所有我猜测二十分钟左右也应该可以了,然并卵转移数据我居然花费了差不多一个小时.期间煎熬,给客服打电话说,你数据量大,所

centos 7 yum 设置 阿里云 kubernetes 库

cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/ enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum

阿里云日志服务(ELK)

最早公司日志采用直接NGINX单机日志保存和备份日志文件,通过GOACCESS来分析. 随后架构更新为负载均衡+多台nginx服务器前端服务器模式后,这么搜集和保存日志就不行了,所以直接使用了ELK采集,保存和查看日志. 最近发现阿里云本身就能提供日志服务.所以改用阿里云的日志服务采集. 首先需要开通日志服务,然后创建一个project. 需要开始创建Logstore,这个类似于ElasticSearch里的一个域(可能不准确) 根据自己需求设置即可..500M一下免费,所以我日志只保存了90天