网站空间 购买,免费网站建设浩森宇特,十大高端全屋定制,网站建设工作简介Kubernetes容器集群中的日志系统集成实践 Kubernetes是原生的容器编排管理系统#xff0c;对于负载均衡、服务发现、高可用、滚动升级、自动伸缩等容器云平台的功能要求有原生支持。今天我分享一下我们在Kubernetes集群中日志管理的实践方案。在这个方案中#xff0c;除了Doc…Kubernetes容器集群中的日志系统集成实践 Kubernetes是原生的容器编排管理系统对于负载均衡、服务发现、高可用、滚动升级、自动伸缩等容器云平台的功能要求有原生支持。今天我分享一下我们在Kubernetes集群中日志管理的实践方案。在这个方案中除了Docker和Kubernetes主要还涉及的技术包括Fluentd、Elasticsearch、Kibana和Swift。 Fig00-Kubernetes日志系统中涉及的技术 评估容器云平台日志系统的标准 易扩展能够支撑集群规模的增长 开销低尽量占用较少的系统资源 入侵小尽量不需要改动应用容器和云平台系统 大集中将所有分布在各个主机节点上的日志集中在一起分析和查询 易部署方便自动化部署到分布式集群中 易定制方便处理不同日志格式方便对接不同的存储方式 实效性日志在产生之后需要能在短时间内即可以进行查看分析 社区活跃方便未来的维护和更新方便功能扩展 Fluentd的介绍 Fluentd是一个实时日志收集系统它把JSON作为日志的中间处理格式通过灵活的插件机制可以支持丰富多样的日志输入应用、输出应用、以及多种日志解析、缓存、过滤和格式化输出机制。 Fluentd的架构 Fluentd将JSON作为数据处理的中间格式通过插件式的架构可扩展地支持不同种应用或系统作为日志源和日志输出端。假设有M种输入源Wordpress、MySQL、Tomcat……N种输出端MySQL、MongoDB、ElasticSearch……那么处理日志的代码模块由MxN减少为MN。我们在Kubernetes集群中收集日志主要用到https://hub.docker.com/r/fabric8/fluentd-kubernetes/这个镜像和https://github.com/fabric8io/docker-fluentd-kubernetes这个Plugins。 Fig01-Fluend架构 Fig02-Fluentd功能 Fluentd的特点 将JSON作为统一的中间层日志格式做日志处理 基于Ruby的日志收集工具较基于JRuby的Logstash的Footprint小 兼容的输入源输出端基本和Logstash相当 性能相关的部分为C代码速度较快 支持插件扩展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而设计的。 Fig03-Fluentd在Kubernetes集群中的部署架构 在Kubenetes中的部署案例YAML 在Kubernetes集群中部署Fluentd时可以采用类似下面的YAML文件将使用Docker镜像Fluentd-Elasticsearch的Pod部署到每一个Kubernetes节点上。 Fig04-Fluentd在Kubernetes集群中的部署YAML Fluentd pod的运行时状态 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集群的状态。 Fig06-Elasticsearch的架构 ElasticSearch在Kubernetes中的部署架构 我们在Kubernetes中三类节点都是一个包含同一个镜像Podelasticsearch-cloud-kubernetes区别只是启动时的环境role不一样。查询和索引节点需要提供对外的Web服务需要发布为一个Kubernetes Service。数据节点需要绑定一个持久化存储我们用Kubernetes PV创建出存储卷数据节点上面通过Kubernetes PVC绑定到相应的数据卷。PV的实际存储可以是NFS、GlusterFS等共享存储。 Fig07-ElasticSearch在Kubernetes中的部署架构 ElasticSearch的特点 搜索引擎基于Apache Lucene的全文搜索引擎作为开源搜索引擎应用案例开始比solr更流行 文档数据库可以作为文档数据库使用存储文档大数据日志大数据 实时数据分析查询系统支持大数据量的实时分析查询 完全分布式可随着节点数水平扩展存储量和查询速度 高可用可以自动检测破坏的分片自动重新平衡各个节点上存储的分片数据可备份冷数据到对象存储 支持插件扩展可自定义插件支持不同的备份目标 ElasticSearch与传统关系数据库的类比 ElasticSearch与传统数据的概念有许多类似之处下面是ElasticSearch与传统关系型数据库的对比。 Fig08-ElasticSearch与传统数据库的对比 ElasticSearch在Kubernetes集群中的部署 在Kubernetes集群中部署ElasticSearch我们会部署类似图中的3种节点es-data类是用来存放索引数据的es-master类是用来提供索引写服务的es-client是用来提供索引查询服务的。 Fig09-ElasticSearch在Kubernetes集群中的部署 ElasticSearch数据在Kubernetes集群中的持久化存储 在部署es-data节点的时候他们的数据卷我们是以共享存储卷挂载的这里采用PVC/PV的模式挂载一个NFS的PV提供数据卷如下图所示。 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这个环境变量作为资源使用。 Fig11-在Kubernetes集群中部署Kibana 整体日志管理系统的架构 在Kubernetes集群中的每个节点上运行一个Fluentd的容器收集容器的日志发送给到ElasticSearch集群中。ElasticSearch集群会保存一周的日志作为热数据以供实时分析和查询用户可以通过Kibana查看任意Node、Namespace、Service、Pod和容器的数据。对于超过一周的日志数据ElasticSearch会自动备份到Swift对象存储的相应Bucket中。 Fig12-整体Kubernetes日志管理系统的架构 QA Q请问Kubernetes宿主机的日志是如何收集的 A跟收集容器的日志是类似的事实上容器的日志也是从主机的日志目录收集过来的。 Q如果把移动设备的整机日志输入系统尤其是移动设备需要注意哪些问题产生日志目前想到有两种方案1使用APP转发给Fluentd2使用Syslog个人感觉第二个更合适或者还有其他更好的方案么 A抱歉我们比较关注的是云平台服务器端的日志移动设备的日志没有研究过。如果是移动设备日志通过服务器的API上传到服务器了那么就是一样的处理。一般我们的理解移动设备的日志是通过应用自己的一些日志程序定期压缩发送到服务器或者第三方的日志手机平台然后在服务器端当作普通的服务器应用日志来处理只不过要打上移动设备和用户的相关Tag。 QElasticSearch是可以设置备份周期的时间吧如果我想保留一个月的日志来进行查询 A可以设置。但是要通过自己的脚本或者crontab任务来实现。ES目前主要提供的是通过REST API创建、删除备份和通过保留的备份恢复某个集群。 QFluentd可否设置收集容器应用指定目录日志非标准输出目录怎么设置 A容器应用目录在容器内Fluentd是收集不到的除非你的输出目录也是外部挂载的的共享目录。如果是一个单纯Docker Engine管理的节点可以通过–volumn-from访问另一个容器存储的数据当然这也是在那个容器-v声明的volumn而不是任意目录这种方式对Kubernetes集群没什么帮助。 QElasticSearch日志的保留策略 怎么设置呢是调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/fluent-plugin-kubernetes_metadata_filter可以参考。 Q我们目前也使用了Fluentd收集容器日志收集容器写到log文件中的日志比收集从标准输出的日志要慢请问你们有什么调优的方法吗 A文件日志比标准输出慢是正常的调优Fluentd的性能可能要根据Fluentd的说明逐渐积累经验先定位哪里慢再试验加快方法跟各种系统的性能调优是同样的思路。下面这个链接有些调优建议。http://docs.fluentd.org/articles/performance-tuning 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日索引的分片数量建议是 AFluentd和Flume的设计理念是类似的一个用CRuby一个用JRuby与Fluentd和Logstash的情况类似Fluentd的镜像会小一些运行时内存消耗会小一些而Flume的镜像因为要打包JDK差不多要几百兆。在围绕容器的Linux环境中Java的跨平台性本身带来不了特别大优势反而Fluentd镜像小的优势更加明显。另外一个对我们的系统实践意义比较大就是fluentd跟Kubernetes集群的方案做的简单明了。ES默认的shards数是5一般的集群情况要根据使用情况测一下对于不同的index这个shards数可以是不一样的。Shards的个数尽量不设1吧设1的话将来想要增加分片时移动的数据量太大了。在没有很充分的生产测试经验之前设置2到5比较好。 参考资料 Kubernetes容器集群中的日志系统集成实践http://oicwx.com/detail/1124477 轻松了解Kubernetes部署功能http://www.tuicool.com/articles/qyaIBz 转载于:https://www.cnblogs.com/junneyang/p/5920078.html
