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

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 本文讲的是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容器集群中的日志系统集成实践


相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
4天前
|
存储 Kubernetes 开发者
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
39 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
|
2天前
|
Prometheus Kubernetes 监控
OpenAI故障复盘 - 阿里云容器服务与可观测产品如何保障大规模K8s集群稳定性
聚焦近日OpenAI的大规模K8s集群故障,介绍阿里云容器服务与可观测团队在大规模K8s场景下我们的建设与沉淀。以及分享对类似故障问题的应对方案:包括在K8s和Prometheus的高可用架构设计方面、事前事后的稳定性保障体系方面。
|
4天前
|
Kubernetes 网络协议 应用服务中间件
Kubernetes Ingress:灵活的集群外部网络访问的利器
《Kubernetes Ingress:集群外部访问的利器-打造灵活的集群网络》介绍了如何通过Ingress实现Kubernetes集群的外部访问。前提条件是已拥有Kubernetes集群并安装了kubectl工具。文章详细讲解了Ingress的基本组成(Ingress Controller和资源对象),选择合适的版本,以及具体的安装步骤,如下载配置文件、部署Nginx Ingress Controller等。此外,还提供了常见问题的解决方案,例如镜像下载失败的应对措施。最后,通过部署示例应用展示了Ingress的实际使用方法。
20 2
|
16天前
|
存储 Kubernetes 关系型数据库
阿里云ACK备份中心,K8s集群业务应用数据的一站式灾备方案
本文源自2024云栖大会苏雅诗的演讲,探讨了K8s集群业务为何需要灾备及其重要性。文中强调了集群与业务高可用配置对稳定性的重要性,并指出人为误操作等风险,建议实施周期性和特定情况下的灾备措施。针对容器化业务,提出了灾备的新特性与需求,包括工作负载为核心、云资源信息的备份,以及有状态应用的数据保护。介绍了ACK推出的备份中心解决方案,支持命名空间、标签、资源类型等维度的备份,并具备存储卷数据保护功能,能够满足GitOps流程企业的特定需求。此外,还详细描述了备份中心的使用流程、控制台展示、灾备难点及解决方案等内容,展示了备份中心如何有效应对K8s集群资源和存储卷数据的灾备挑战。
|
26天前
|
存储 Prometheus 监控
Docker容器内进行应用调试与故障排除的方法与技巧,包括使用日志、进入容器检查、利用监控工具及检查配置等,旨在帮助用户有效应对应用部署中的挑战,确保应用稳定运行
本文深入探讨了在Docker容器内进行应用调试与故障排除的方法与技巧,包括使用日志、进入容器检查、利用监控工具及检查配置等,旨在帮助用户有效应对应用部署中的挑战,确保应用稳定运行。
32 5
|
28天前
|
运维 Kubernetes Docker
深入理解容器化技术:Docker与Kubernetes的协同工作
深入理解容器化技术:Docker与Kubernetes的协同工作
50 1
|
28天前
|
Kubernetes Cloud Native 持续交付
容器化、Kubernetes与微服务架构的融合
容器化、Kubernetes与微服务架构的融合
47 1
|
1月前
|
Kubernetes Cloud Native API
深入理解Kubernetes——容器编排的王者之道
深入理解Kubernetes——容器编排的王者之道
44 1
|
1月前
|
Kubernetes 监控 Cloud Native
Kubernetes集群的高可用性与伸缩性实践
Kubernetes集群的高可用性与伸缩性实践
74 1
|
2月前
|
JSON Kubernetes 容灾
ACK One应用分发上线:高效管理多集群应用
ACK One应用分发上线,主要介绍了新能力的使用场景

相关产品

  • 容器服务Kubernetes版