DockOne微信分享(七十二):Kubernetes容器集群中的日志系统集成实践

简介: 本文讲的是DockOne微信分享(七十二):Kubernetes容器集群中的日志系统集成实践【编者的话】本次课程将分享如何利用Fluentd、ElasticSearch、Kibana在Kubernetes集群中构建一个高可用高可扩展的日志系统,来收集、处理、分析和展示Kubernetes集群中的容器日志。
本文讲的是DockOne微信分享(七十二):Kubernetes容器集群中的日志系统集成实践【编者的话】本次课程将分享如何利用Fluentd、ElasticSearch、Kibana在Kubernetes集群中构建一个高可用高可扩展的日志系统,来收集、处理、分析和展示Kubernetes集群中的容器日志。

Kubernetes是原生的容器编排管理系统,对于负载均衡、服务发现、高可用、滚动升级、自动伸缩等容器云平台的功能要求有原生支持。今天我分享一下我们在Kubernetes集群中日志管理的实践方案。在这个方案中,除了Docker和Kubernetes,主要还涉及的技术包括:Fluentd、Elasticsearch、Kibana和Swift。
图片_1.png

Fig00-Kubernetes日志系统中涉及的技术

评估容器云平台日志系统的标准:
  1. 易扩展:能够支撑集群规模的增长
  2. 开销低:尽量占用较少的系统资源
  3. 入侵小:尽量不需要改动应用容器和云平台系统
  4. 大集中:将所有分布在各个主机节点上的日志集中在一起分析和查询
  5. 易部署:方便自动化部署到分布式集群中
  6. 易定制:方便处理不同日志格式,方便对接不同的存储方式
  7. 实效性:日志在产生之后需要能在短时间内即可以进行查看分析
  8. 社区活跃:方便未来的维护和更新,方便功能扩展

Fluentd的介绍

Fluentd是一个实时日志收集系统,它把JSON作为日志的中间处理格式,通过灵活的插件机制,可以支持丰富多样的日志输入应用、输出应用、以及多种日志解析、缓存、过滤和格式化输出机制。

Fluentd的架构

Fluentd将JSON作为数据处理的中间格式,通过插件式的架构可扩展地支持不同种应用或系统作为日志源和日志输出端。假设有M种输入源Wordpress、MySQL、Tomcat……;N种输出端MySQL、MongoDB、ElasticSearch……那么处理日志的代码模块由MxN减少为M+N。我们在Kubernetes集群中收集日志主要用到 https://hub.docker.com/r/fabri ... etes/  这个镜像和 https://github.com/fabric8io/d ... netes  这个Plugins。
02.png

Fig01-Fluend架构

03.png

Fig02-Fluentd功能

Fluentd的特点:
  1. 将JSON作为统一的中间层日志格式做日志处理
  2. 基于Ruby的日志收集工具:较基于JRuby的Logstash的Footprint小
  3. 兼容的输入源输出端基本和Logstash相当
  4. 性能相关的部分为C代码:速度较快
  5. 支持插件扩展:Input、Parser、Filter、Output、Formatter and Buffer

Fluentd在Kubernetes集群中的部署架构

每个Node节点上都要有Fluentd-Elasticsearch这个Pod,有两种方式支持:1. 放在/etc/kubernetes/manifest下,用脚本自动启动;2. 用DaemonSet启动。这两种模式都是为了保证在每一个Kubernetes集群节点上都有一个Fluentd的驻留Pod运行来收集日志。Kubernetes中DaemonSet这个API对象就是为了驻留Pod而设计的。
04.png

Fig03-Fluentd在Kubernetes集群中的部署架构

在Kubenetes中的部署案例YAML

在Kubernetes集群中部署Fluentd时,可以采用类似下面的YAML文件,将使用Docker镜像Fluentd-Elasticsearch的Pod部署到每一个Kubernetes节点上。
05.png

Fig04-Fluentd在Kubernetes集群中的部署YAML
Fluentd pod的运行时状态:
06.png

Fig05-Fluentd在Kubernetes集群中的运行状态

选用Fluentd的理由:
  • 开销低:核心代码为C,插件代码为Ruby,不需要打包JDK
  • 入侵小:用Pod部署,不干扰应用容器和主机服务
  • 易部署:使用容器镜像作为单容器Pod部署
  • 易定制:很方便增加和更改适合自己应用的插件

ElasticSearch

Elasticsearch是一个实时的分布式搜索和分析引擎。它可以用于文档存储,全文搜索,结构化搜索以及实时分析,与常见的互联网应用最典型的应用场景是日志分析查询和全文搜索。

ElasticSearch的架构

在ElasticSearch中有三类节点:第一类是Data Node,用来存储数据,ElasticSearch中对于一份数据可以有多个副本,以提供数据高可用能力;第二类是Client Node,或者叫查询节点,提供对查询的负载均衡;第三类是Master Eligible node,或者叫索引节点,这些节点可以被选举为Master Node,而Master Node会控制整个ElasticSearch集群的状态。
07.png

Fig06-Elasticsearch的架构

ElasticSearch在Kubernetes中的部署架构

我们在Kubernetes中,三类节点都是一个包含同一个镜像Pod
elasticsearch-cloud-kubernetes,区别只是启动时的环境role不一样。查询和索引节点需要提供对外的Web服务,需要发布为一个Kubernetes Service。数据节点需要绑定一个持久化存储,我们用Kubernetes PV创建出存储卷,数据节点上面通过Kubernetes PVC绑定到相应的数据卷。PV的实际存储可以是NFS、GlusterFS等共享存储。
08.png

Fig07-ElasticSearch在Kubernetes中的部署架构

ElasticSearch的特点

  • 搜索引擎:基于Apache Lucene的全文搜索引擎,作为开源搜索引擎应用案例开始比solr更流行
  • 文档数据库:可以作为文档数据库使用,存储文档大数据,日志大数据
  • 实时数据分析查询系统:支持大数据量的实时分析查询
  • 完全分布式:可随着节点数水平扩展存储量和查询速度
  • 高可用:可以自动检测破坏的分片,自动重新平衡各个节点上存储的分片数据,可备份冷数据到对象存储
  • 支持插件扩展:可自定义插件支持不同的备份目标

ElasticSearch与传统关系数据库的类比

ElasticSearch与传统数据的概念有许多类似之处,下面是ElasticSearch与传统关系型数据库的对比。
09.png

Fig08-ElasticSearch与传统数据库的对比

ElasticSearch在Kubernetes集群中的部署

在Kubernetes集群中部署ElasticSearch,我们会部署类似图中的3种节点:es-data类是用来存放索引数据的;es-master类是用来提供索引写服务的;es-client是用来提供索引查询服务的。
10.png

Fig09-ElasticSearch在Kubernetes集群中的部署

ElasticSearch数据在Kubernetes集群中的持久化存储

在部署es-data节点的时候,他们的数据卷我们是以共享存储卷挂载的,这里采用PVC/PV的模式挂载一个NFS的PV提供数据卷,如下图所示。
11.png

Fig10-ElasticSearch数据在Kubernetes集群中的持久化存储

日志的备份和恢复

ElasticSearch允许对于单个索引或整个集群做备份和恢复。备份恢复所支持的目标存储仓库类型包括:

S3仓库:将AWS S3作为备份仓库

安装命令:
sudo bin/elasticsearch-plugin install repository-s3

创建仓库示例:
PUT _snapshot/my-s3-repository-1
{
"type": "s3",
"settings": {
"bucket": "s3_repository_1",
"region": "us-west"
}
}   

Azure仓库:将Azure作为备份仓库

安装命令:
sudo bin/elasticsearch-plugin install repository-azure

创建仓库示例:
PUT _snapshot/my-azure-repository-1
{
"type": "azure",
"settings": {
    "container": "backup-container",
    "base_path": "backups",
    "chunk_size": "32m",
    "compress": true
}
}  

HDFS仓库:将HDFS作为备份仓库

安装命令:
sudo bin/elasticsearch-plugin install repository-hdfs

创建仓库示例:
PUT _snapshot/my-hdfs-repository-1
{
"type": "hdfs",
"settings": {
"uri": "hdfs://namenode:8020/",
"path": "elasticsearch/respositories/my_hdfs_repository",
"conf.dfs.client.read.shortcircuit": "true"
}
}  

GCS仓库:将Google Cloud Storage作为备份仓库

安装命令:
sudo bin/elasticsearch-plugin install repository-gcs

创建仓库示例:
PUT _snapshot/my-gcs-repository-1
{
"type": "gcs",
"settings": {
"bucket": "my_bucket",
"service_account": "_default_"
}
}  

作为私有云部署的环境,多数基于OpenStack的IaaS层,可以采用OpenStack的对象存储Swift作为备份。

Swift仓库:将OpenStack Swift作为备份仓库

安装命令:
sudo bin/elasticsearch-plugin install org.wikimedia.elasticsearch.swift/swift-repository-plugin/2.1.1
创建仓库示例:
PUT _snapshot/my-gcs-repository-1
{
"type": "swift",
"settings": {
    "swift_url": "http://localhost:8080/auth/v1.0/",
    "swift_container": "my-container",
    "swift_username": "myuser",
    "swift_password": "mypass!"
}
}  

选用ElasticSearch的理由:
  • 易扩展:可以随着增加节点水平扩展存储容量和索引能力
  • 大集中:将所有Pod和容器的数据集中在一起方便查询和分析
  • 易部署:使用容器镜像作为单容器Pod部署
  • 易定制:很方便增加和更改适合自己应用的插件
  • 实效性:日志在产生之后需要能在短时间内即可以进行查看分析
  • 社区活跃:ElasticSearch社区越来越活跃,大有赶超Solr之势

Kibana

Kibana在Kubernetes中的部署

Kibana跟ElasticSearch的集成相对来说比较直观,利用 https://hub.docker.com/r/fabric8/kibana4/ 镜像,设置好ELASTICSEARCH_URL参数就可以,Kibana是一个部署在Kubernetes集群中的Web前端服务,而它引用ELASTICSEARCH_URL这个环境变量作为资源使用。
12.png

Fig11-在Kubernetes集群中部署Kibana

整体日志管理系统的架构

在Kubernetes集群中的每个节点上运行一个Fluentd的容器,收集容器的日志发送给到ElasticSearch集群中。ElasticSearch集群会保存一周的日志作为热数据以供实时分析和查询,用户可以通过Kibana查看任意Node、Namespace、Service、Pod和容器的数据。对于超过一周的日志数据,ElasticSearch会自动备份到Swift对象存储的相应Bucket中。
13.png

Fig12-整体Kubernetes日志管理系统的架构

Q&A

Q:请问Kubernetes宿主机的日志是如何收集的?
A:跟收集容器的日志是类似的,事实上容器的日志也是从主机的日志目录收集过来的。
Q:如果把移动设备的整机日志输入系统,尤其是移动设备需要注意哪些问题?产生日志目前想到有两种方案:(1)使用APP转发给Fluentd(2)使用Syslog,个人感觉第二个更合适,或者还有其他更好的方案么?
A:抱歉,我们比较关注的是云平台服务器端的日志,移动设备的日志没有研究过。如果是移动设备日志通过服务器的API上传到服务器了,那么就是一样的处理。一般我们的理解,移动设备的日志是通过应用自己的一些日志程序,定期压缩发送到服务器或者第三方的日志手机平台,然后在服务器端,当作普通的服务器应用日志来处理,只不过要打上移动设备和用户的相关Tag。
Q:ElasticSearch是可以设置备份周期的时间吧?如果我想保留一个月的日志来进行查询?
A:可以设置。但是要通过自己的脚本或者crontab任务来实现。ES目前主要提供的是通过REST API创建、删除备份和通过保留的备份恢复某个集群。
Q:Fluentd可否设置收集容器应用指定目录日志(非标准输出目录),怎么设置?
A:容器应用目录在容器内,Fluentd是收集不到的,除非你的输出目录也是外部挂载的的共享目录。如果是一个单纯Docker Engine管理的节点,可以通过--volumn-from访问另一个容器存储的数据,当然这也是在那个容器-v声明的volumn而不是任意目录;这种方式对Kubernetes集群没什么帮助。
Q:ElasticSearch日志的保留策略, 怎么设置呢,是调API删除还是ElasticSearch自带呢?
A:我们现在用的方式是用时间做索引,然后脚本定时删除。
Q:数据节点PVC/PV 挂载的文件系统是那种呢?实际使用上遇到什么问题没有?
A:我们用过的主要是NFS和GlusterFS。最初实现的PV比较弱,PVC不能通过Label与PV匹配,只能通过size和访问类型匹配,无法准确选择PV存储。现在最新Kubernetes支持PVC的selector支持选择带有特定Label的PV了。
Q:请问Kubernetes宿主机的日志是如何收集的?
A:用相应的不同的Fluentd插件,类似的mount到相应的主机日志目录即可。现在容器的日志也是通过主机收集的。
Q:日志包括容器的捕获的标准输出日志和应用打到日志文件中的日志。对于这两类场景,如何用Fluentd实现新启动容器的日志自动发现和收集?
A:对于打到日志文件中的日志,原则上建议日志目录是主机绑定上的或是共享目录。日志的自动发现和收集需要通过fluentd的插件,将指定的目录的文件过滤出来,例如标准输出日志肯定在主机的/var/lib/docker/containers/container-id/下。我们集成的Fluentd镜像,已经打包配置好了相应的的插件 https://github.com/fabric8io/f ... ilter,可以参考。
Q:我们目前也使用了Fluentd收集容器日志,收集容器写到log文件中的日志比收集从标准输出的日志要慢,请问你们有什么调优的方法吗?
A:文件日志比标准输出慢是正常的,调优Fluentd的性能可能要根据Fluentd的说明逐渐积累经验先定位哪里慢,再试验加快方法,跟各种系统的性能调优是同样的思路。下面这个链接有些调优建议。 http://docs.fluentd.org/articl ... uning
Q:请问如何处理集群自我恢复机制,比如elasticsearch-master、elasticsearch-client 挂了?
A:我们在Kubernetes集群中,elasticsearch-master和elasticsearch-client都是以Relication Controller或Replication Set方式启动的,系统会自动保证服务的高可用。其他集群也是类似的机制,和一般Web应用的高可用是一样,要有机制保证重启服务,要有机制做服务发现和负载均衡,在K8s集群是靠Relication Controller和Kube-proxy。
Q:请问,在Kubernetes集群中的每个节点上运行一个Fluentd的容器,这个节点是容器还是部署Docker的节点?
A:这个是主机节点(可能是物理机或虚拟机),就是Kubernetes的Node,部署Docker的节点。推荐的官方方法,是通过Kubernetes的DaemonSet做部署。当然也可以自己在每个节点上维持自动的启动脚本,运行一些每个节点都要启动的Pod服务。
Q:请问,Kubernetes的master是单点的,你们是否有优化过,现在1.3了,你们平台升级是否是热部署?
A:我们是用podmaster做至少3节点master高可用部署,api-server是多活的,controllermanager 和schedule是1活2备。平台升级现在是手动的,不会影响运行中的服务。但是现在平台升级需要工程师小心翼翼的手动操作,还不是自动化的。
Q:请问Fluentd和Flume除了开发语言不一样,有什么本质上的区别?以及ES日索引的分片数量建议是?
A:Fluentd和Flume的设计理念是类似的,一个用CRuby,一个用JRuby,与Fluentd和Logstash的情况类似,Fluentd的镜像会小一些,运行时内存消耗会小一些,而Flume的镜像因为要打包JDK差不多要几百兆。在围绕容器的Linux环境中,Java的跨平台性本身带来不了特别大优势,反而Fluentd镜像小的优势更加明显。另外一个对我们的系统实践意义比较大,就是fluentd跟Kubernetes集群的方案做的简单明了。ES默认的shards数是5,一般的集群情况要根据使用情况测一下,对于不同的index,这个shards数可以是不一样的。Shards的个数尽量不设1吧,设1的话,将来想要增加分片时,移动的数据量太大了。在没有很充分的生产测试经验之前,设置2到5比较好。

以上内容根据2016年7月28日晚微信群分享内容整理。分享人王昕,清华大学通信硕士,ISC2认证信息系统安全专家(CISSP),资深架构师和软件开发专家。曾任VMware、IBM高级研发经理,BEA、Lucent高级工程师,从事十余年企业中间件、PaaS平台和SDN等产品的研发工作,有十多项美国和中国的在审专利发明。现为轻元首席架构师。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

原文发布时间为:2016-08-02

本文作者:王昕

本文来自云栖社区合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。

原文标题:DockOne微信分享(七十二):Kubernetes容器集群中的日志系统集成实践


相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
9月前
|
SQL 人工智能 监控
SLS Copilot 实践:基于 SLS 灵活构建 LLM 应用的数据基础设施
本文将分享我们在构建 SLS SQL Copilot 过程中的工程实践,展示如何基于阿里云 SLS 打造一套完整的 LLM 应用数据基础设施。
2929 107
|
存储 运维 开发工具
警惕日志采集失败的 6 大经典雷区:从本地管理反模式到 LoongCollector 标准实践
本文探讨了日志管理中的常见反模式及其潜在问题,强调科学的日志管理策略对系统可观测性的重要性。文中分析了6种反模式:copy truncate轮转导致的日志丢失或重复、NAS/OSS存储引发的采集不一致、多进程写入造成的日志混乱、创建文件空洞释放空间的风险、频繁覆盖写带来的数据完整性问题,以及使用vim编辑日志文件导致的重复采集。针对这些问题,文章提供了最佳实践建议,如使用create模式轮转日志、本地磁盘存储、单线程追加写入等方法,以降低日志采集风险,提升系统可靠性。最后总结指出,遵循这些实践可显著提高故障排查效率和系统性能。
2241 23
|
11月前
|
Cloud Native 中间件 调度
云原生信息提取系统:容器化流程与CI/CD集成实践
本文介绍如何通过工程化手段解决数据提取任务中的稳定性与部署难题。结合 Scrapy、Docker、代理中间件与 CI/CD 工具,构建可自动运行、持续迭代的云原生信息提取系统,实现结构化数据采集与标准化交付。
1205 1
云原生信息提取系统:容器化流程与CI/CD集成实践
|
Ubuntu 关系型数据库 MySQL
容器技术实践:在Ubuntu上使用Docker安装MySQL的步骤。
通过以上的操作,你已经步入了Docker和MySQL的世界,享受了容器技术给你带来的便利。这个旅程中你可能会遇到各种挑战,但是只要你沿着我们划定的路线行进,你就一定可以达到目的地。这就是Ubuntu、Docker和MySQL的灵魂所在,它们为你开辟了一条通往新探索的道路,带你亲身感受到了技术的力量。欢迎在Ubuntu的广阔大海中探索,用Docker技术引领你的航行,随时准备感受新技术带来的震撼和乐趣。
544 16
|
SQL 存储 自然语言处理
让跨 project 联查更轻松,SLS StoreView 查询和分析实践
让跨 project 联查更轻松,SLS StoreView 查询和分析实践
317 1
|
存储 监控 安全
网络安全视角:从地域到账号的阿里云日志审计实践
网络安全视角:从地域到账号的阿里云日志审计实践
428 0
|
监控 Cloud Native Java
基于阿里云容器服务(ACK)的微服务架构设计与实践
本文介绍如何利用阿里云容器服务Kubernetes版(ACK)构建高可用、可扩展的微服务架构。通过电商平台案例,展示基于Java(Spring Boot)、Docker、Nacos等技术的开发、容器化、部署流程,涵盖服务注册、API网关、监控日志及性能优化实践,帮助企业实现云原生转型。
|
监控 安全 Apache
什么是Apache日志?为什么Apache日志分析很重要?
Apache是全球广泛使用的Web服务器软件,支持超过30%的活跃网站。它通过接收和处理HTTP请求,与后端服务器通信,返回响应并记录日志,确保网页请求的快速准确处理。Apache日志分为访问日志和错误日志,对提升用户体验、保障安全及优化性能至关重要。EventLog Analyzer等工具可有效管理和分析这些日志,增强Web服务的安全性和可靠性。
607 9
|
监控 容灾 算法
阿里云 SLS 多云日志接入最佳实践:链路、成本与高可用性优化
本文探讨了如何高效、经济且可靠地将海外应用与基础设施日志统一采集至阿里云日志服务(SLS),解决全球化业务扩展中的关键挑战。重点介绍了高性能日志采集Agent(iLogtail/LoongCollector)在海外场景的应用,推荐使用LoongCollector以获得更优的稳定性和网络容错能力。同时分析了多种网络接入方案,包括公网直连、全球加速优化、阿里云内网及专线/CEN/VPN接入等,并提供了成本优化策略和多目标发送配置指导,帮助企业构建稳定、低成本、高可用的全球日志系统。
1247 55

相关产品

  • 容器服务Kubernetes版