云原生概念
随着虚拟化技术的成熟和分布式框架的普及,在容器技术、可持续交付、编排系统等开源社区的推动下,以及微服务等开发理念的带动下,应用上云已经是不可逆转的趋势。云原生是一种构建和运行应用程序的方法,是一套技术体系和方法论。云原生(CloudNative)是一个组合词,Cloud+Native。Cloud表示应用程序位于云中,而不是传统的数据中心;Native表示应用程序从设计之初即考虑到云的环境,原生为云而设计,在云上以最佳姿势运行,充分利用和发挥云平台的弹性+分布式优势。Pivotal官网对云原生最新概括为4个要点:DevOps + 持续交付 + 微服务 + 容器化。
云原生核心–kubernetes
Kubernetes提供的编排和管理功能,轻松完成大规模容器部署,借助k8s的编排功能,用户可以构建跨多个容器的应用服务,实现跨集群调度,扩展容器,以及长期持续管理这些容器的健康状况等,并整合网络,存储,安全性,监控及其他服务,提供全面的容器基础架构。Kubernetes在设计之初就充分考虑了针对容器的服务发现与负载均衡机制,提供了Service资源,并通过kube-proxy配合cloud provider来适应不同的应用场景。
云桌面订购系统上云
系统日志可以帮助我们了解集群内部的运行情况,日志对于我们调试问题和监视集群情况也是非常有用的默认情况下容器会把这些日志输出到宿主机上的一个 JSON 文件之中,同样我们也可以通过 docker logs 或者 kubectl logs 来查看到对应的日志信息。但是,如果容器崩溃了、Pod被驱逐了或者节点挂掉了,存量的日志将无法查看。所以,日志应该独立于节点、Pod 或容器的生命周期,即完全独立于 Kubernetes集群,需要自己提供单独的日志后端存储、分析和查询工具。
采集方案介绍
Kubernetes 集群本身不提供日志收集的解决方案,一般来说主要有3种方案来做日志收集:
方案一:在每个节点上运行一个agent来收集日志
使用 DaemonSet 控制器在每个节点上运行一个日志收集的 agent是最常见的方法,因为它只需要在每个节点上运行一个代理程序,并不需要对节点上运行的应用程序进行更改,对应用程序没有任何侵入性,在中小型集群中推荐优先使用。
方案二:在每个Pod中包含一个sidecar来收集日志
Sidecar方式为每个POD单独部署日志agent,这个agent只负责一个业务应用的日志采集。Sidecar相对资源占用较多(cpu,内存等),但灵活性以及多租户隔离性较强。在超大型集群中,由于对日志需求的多样性,推荐优先使用。
方案三:直接在应用程序中将日志信息推送到采集后端
业务直写是在应用中集成日志采集的SDK,通过SDK直接将日志发送到服务端。这种方式省去了落盘采集的逻辑,也不需要额外部署Agent,对于系统的资源消耗最低,但由于业务和日志SDK强绑定,整体灵活性很低,一般只有日志量极大的场景中使用。
参考上述三种日志采集方案,作为一个小型的K8S集群,结合云桌面本身对日志采集的需求,因此采用方案一作为最终的采集方案。
日志系统选型(主流ELK vs 新贵Loki)
1.ELK介绍
ELK是三个开源软件的缩写,分别表示:Elasticsearch , Logstash, Kibana , 它们都是开源软件。新增了一个FileBeat,它是一个轻量级的日志收集处理工具(Agent),Filebeat占用资源少,适合于在各个服务器上搜集日志后传输给Logstash。
Elasticsearch是个开源分布式搜索引擎,提供搜集、分析、存储数据三大功能。它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,restful风格接口,多数据源,自动搜索负载等。
Logstash 主要是用来日志的搜集、分析、过滤日志的工具,支持大量的数据获取方式。一般工作方式为c/s架构,client端安装在需要收集日志的主机上,server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。
Kibana 也是一个开源和免费的工具,Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面,可以帮助汇总、分析和搜索重要数据日志。
Filebeat隶属于Beats,它是一个轻量级的日志收集处理工具(Agent)。
如上图所示,各角色功能如下:
- 多个Filebeat在各个业务端进行日志采集,然后上传至Logstash
- 多个Logstash节点并行(负载均衡),对日志记录进行过滤处理,然后上传至Elasticsearch集群
- 多个Elasticsearch构成集群服务,提供日志的索引和存储能力
- Kibana负责对Elasticsearch中的日志数据进行检索、分析
2.Loki介绍
Loki是一个水平可扩展,高可用性,多租户的日志聚合系统。它的设计非常经济高效且易于操作,因为它不会为日志内容编制索引,而是为每个日志流编制一组标签,专门为 Prometheus 和 Kubernetes 用户做了相关优化。该项目受 Prometheus 启发,官方的介绍就是: Like Prometheus,But For Logs.,类似于 Prometheus 的日志系统。
与其他日志聚合系统相比, Loki具有下面的一些特性:
- 不对日志进行全文索引。通过存储压缩非结构化日志和仅索引元数据,Loki 操作起来会更简单,更省成本。
- 通过使用与 Prometheus 相同的标签记录流对日志进行索引和分组,这使得日志的扩展和操作效率更高,能对接alertmanager;
- 特别适合储存 Kubernetes Pod 日志; 诸如 Pod 标签之类的元数据会被自动删除和编入索引;
- 受 Grafana 原生支持,避免kibana和grafana来回切换;
云桌面订购系统的上云改造
云桌面在上云改造过程中,充分吸收了云原生的理念,先后实现了微服务、容器化的改造,并于近期接入k8s并在ops自动发布平台实现的自动化部署。 单体应用 > 微服务 > DevOps > 容器化 > k8s接入 > 自动发布平台。
在接入了k8s之后,出现了系统日志难以统一管控的问题,当需要查看日志定位问题时,操作变得相当繁琐。基于云桌面现有对日志采集的需求,通过ELK与Loki的优缺点对比,最终,选择了轻量级、易操作的Loki作为云桌面的日志采集系统。