【云计算】K8S DaemonSet 每一个node上都运行一个pod

时间 2019-12-05

标签云计算 k8s daemonset 每一个 node 上都运行一个 pod 繁體版

原文原文链接

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

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

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

评估容器云平台日志系统的标准：git

易扩展：可以支撑集群规模的增加github
开销低：尽可能占用较少的系统资源docker
入侵小：尽可能不须要改动应用容器和云平台系统数据库
大集中：将全部分布在各个主机节点上的日志集中在一块儿分析和查询swift
易部署：方便自动化部署到分布式集群中api
易定制：方便处理不一样日志格式，方便对接不一样的存储方式缓存
实效性：日志在产生以后须要能在短期内便可以进行查看分析服务器
社区活跃：方便将来的维护和更新，方便功能扩展

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。

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中，三类节点都是一个包含同一个镜像Pod
elasticsearch-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日志管理系统的架构

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/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日索引的分片数量建议是？

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比较好。

参考资料：

Kubernetes容器集群中的日志系统集成实践：http://oicwx.com/detail/1124477

轻松了解Kubernetes部署功能：http://www.tuicool.com/articles/qyaIBz