运维教程-Kubernetes容器集群中的日志系统集成实践

跨零代码为大家提供高品质的解决方案,请大家多多来访,跨零不胜感激,在此谢过。

 

Kubernetes容器集群中的日志系统集成实践

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

Kubernetes容器集群中的日志系统集成实践

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/fabric8/fluentd-kubernetes/这个镜像和https://github.com/fabric8io/docker-fluentd-kubernetes这个Plugins。

Kubernetes容器集群中的日志系统集成实践

Fig01-Fluend架构

Kubernetes容器集群中的日志系统集成实践

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而设计的。

Kubernetes容器集群中的日志系统集成实践

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

在Kubenetes中的部署案例YAML

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

Kubernetes容器集群中的日志系统集成实践

Fig04-Fluentd在Kubernetes集群中的部署YAML

Fluentd pod的运行时状态:

Kubernetes容器集群中的日志系统集成实践

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集群的状态。

Kubernetes容器集群中的日志系统集成实践

Fig06-Elasticsearch的架构

ElasticSearch在Kubernetes中的部署架构

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

Kubernetes容器集群中的日志系统集成实践

Fig06-Elasticsearch的架构

ElasticSearch在Kubernetes中的部署架构

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

Kubernetes容器集群中的日志系统集成实践

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

ElasticSearch在Kubernetes集群中的部署

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

Kubernetes容器集群中的日志系统集成实践

Fig09-ElasticSearch在Kubernetes集群中的部署

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

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

Kubernetes容器集群中的日志系统集成实践

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这个环境变量作为资源使用。

Kubernetes容器集群中的日志系统集成实践

整体日志管理系统的架构

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

Kubernetes容器集群中的日志系统集成实践

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

Q&A

Q:请问Kubernetes宿主机的日志是如何收集的?

Q:如果把移动设备的整机日志输入系统,尤其是移动设备需要注意哪些问题?产生日志目前想到有两种方案:(1)使用APP转发给Fluentd(2)使用Syslog,个人感觉第二个更合适,或者还有其他更好的方案么?

Q:ElasticSearch是可以设置备份周期的时间吧?如果我想保留一个月的日志来进行查询?

Q:Fluentd可否设置收集容器应用指定目录日志(非标准输出目录),怎么设置?

Q:ElasticSearch日志的保留策略, 怎么设置呢,是调API删除还是ElasticSearch自带呢?

Q:数据节点PVC/PV 挂载的文件系统是那种呢?实际使用上遇到什么问题没有?

Q:请问Kubernetes宿主机的日志是如何收集的?

Q:日志包括容器的捕获的标准输出日志和应用打到日志文件中的日志。对于这两类场景,如何用Fluentd实现新启动容器的日志自动发现和收集?

Q:我们目前也使用了Fluentd收集容器日志,收集容器写到log文件中的日志比收集从标准输出的日志要慢,请问你们有什么调优的方法吗?

Q:请问如何处理集群自我恢复机制,比如elasticsearch-master、elasticsearch-client 挂了?

Q:请问,在Kubernetes集群中的每个节点上运行一个Fluentd的容器,这个节点是容器还是部署Docker的节点?

Q:请问,Kubernetes的master是单点的,你们是否有优化过,现在1.3了,你们平台升级是否是热部署?

Q:请问Fluentd和Flume除了开发语言不一样,有什么本质上的区别?以及ES日索引的分片数量建议是?

文/王昕

文章出处:Docker

从零到一,创造未来!跨零综合IT问题解决服务站,欢迎你的到来。运维教程 只为你绽放。

本文固定链接: http://kua0.com/2019/01/01/运维教程-kubernetes容器集群中的日志系统集成实践/

为您推荐

发表评论

电子邮件地址不会被公开。 必填项已用*标注