DockOne微信分享（七十二）：Kubernetes容器集群中的日志系统集成实践

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

Fluentd的介绍

Fluentd的架构

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

Fluentd在Kubernetes集群中的部署架构

在Kubenetes中的部署案例YAML

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

ElasticSearch

ElasticSearch的架构

ElasticSearch在Kubernetes中的部署架构

ElasticSearch的特点

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

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

ElasticSearch在Kubernetes集群中的部署

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

日志的备份和恢复

sudo bin/elasticsearch-plugin install repository-s3

PUT _snapshot/my-s3-repository-1
{
"type": "s3",
"settings": {
"bucket": "s3_repository_1",
"region": "us-west"
}
}   

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
}
}  

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"
}
}  

sudo bin/elasticsearch-plugin install repository-gcs

PUT _snapshot/my-gcs-repository-1
{
"type": "gcs",
"settings": {
"bucket": "my_bucket",
"service_account": "_default_"
}
}  

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!"
}
}  

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

Kibana

Kibana在Kubernetes中的部署

整体日志管理系统的架构

Q&A

A：跟收集容器的日志是类似的，事实上容器的日志也是从主机的日志目录收集过来的。

A：抱歉，我们比较关注的是云平台服务器端的日志，移动设备的日志没有研究过。如果是移动设备日志通过服务器的API上传到服务器了，那么就是一样的处理。一般我们的理解，移动设备的日志是通过应用自己的一些日志程序，定期压缩发送到服务器或者第三方的日志手机平台，然后在服务器端，当作普通的服务器应用日志来处理，只不过要打上移动设备和用户的相关Tag。

A：可以设置。但是要通过自己的脚本或者crontab任务来实现。ES目前主要提供的是通过REST API创建、删除备份和通过保留的备份恢复某个集群。

A：容器应用目录在容器内，Fluentd是收集不到的，除非你的输出目录也是外部挂载的的共享目录。如果是一个单纯Docker Engine管理的节点，可以通过--volumn-from访问另一个容器存储的数据，当然这也是在那个容器-v声明的volumn而不是任意目录；这种方式对Kubernetes集群没什么帮助。

A：我们现在用的方式是用时间做索引，然后脚本定时删除。

A：我们用过的主要是NFS和GlusterFS。最初实现的PV比较弱，PVC不能通过Label与PV匹配，只能通过size和访问类型匹配，无法准确选择PV存储。现在最新Kubernetes支持PVC的selector支持选择带有特定Label的PV了。

A：用相应的不同的Fluentd插件，类似的mount到相应的主机日志目录即可。现在容器的日志也是通过主机收集的。

A：对于打到日志文件中的日志，原则上建议日志目录是主机绑定上的或是共享目录。日志的自动发现和收集需要通过fluentd的插件，将指定的目录的文件过滤出来，例如标准输出日志肯定在主机的/var/lib/docker/containers/container-id/下。我们集成的Fluentd镜像，已经打包配置好了相应的的插件 https://github.com/fabric8io/f ... ilter，可以参考。

A：文件日志比标准输出慢是正常的，调优Fluentd的性能可能要根据Fluentd的说明逐渐积累经验先定位哪里慢，再试验加快方法，跟各种系统的性能调优是同样的思路。下面这个链接有些调优建议。 http://docs.fluentd.org/articl ... uning

A：我们在Kubernetes集群中，elasticsearch-master和elasticsearch-client都是以Relication Controller或Replication Set方式启动的，系统会自动保证服务的高可用。其他集群也是类似的机制，和一般Web应用的高可用是一样，要有机制保证重启服务，要有机制做服务发现和负载均衡，在K8s集群是靠Relication Controller和Kube-proxy。

A：这个是主机节点（可能是物理机或虚拟机），就是Kubernetes的Node，部署Docker的节点。推荐的官方方法，是通过Kubernetes的DaemonSet做部署。当然也可以自己在每个节点上维持自动的启动脚本，运行一些每个节点都要启动的Pod服务。

A：我们是用podmaster做至少3节点master高可用部署，api-server是多活的，controllermanager 和schedule是1活2备。平台升级现在是手动的，不会影响运行中的服务。但是现在平台升级需要工程师小心翼翼的手动操作，还不是自动化的。

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容器集群中的日志系统集成实践