极客星球|数据智能公司K8S生产环境落地之日志篇 k8s数据分析数据结构和算法

文章图片

前言公司在经历2019-2020年的快速发展后，业务的高速成长给运维基建带来了巨大挑战，业务特性转变为大流量、高并发（千万级）。为保障业务稳定和安全，运维团队在架构上做了重大调整，从传统架构逐渐演化成混合云架构，同时实现业务异地容灾、容器化、跨机房调度等。公司从2020年开始规划容器，到现在已落地150个项目，过程中遇到包含日志、监控、网络、CI/CD等版块问题，本篇文章将重点围绕日志版块进行详细阐述。
一、背景
每家公司在成长的过程中或多或少都会存在一些历史遗留问题，如：

业务资源使用率偏低
公司每季度服务器资源投入成本巨大
业务突发资源扩缩容操作时间过长
当前Kvm虚拟化实现自动化整合难度大

二、选择K8S的原因
容器化编排有K8S、Swarm、Mesos，近年K8S成为主流趋势，Swarm和Mesos已经逐渐小众化，因此我们选择了K8S作为编排。其拥有以下优点，如：

弹性伸缩具有应突发、省成本、自动化的业务价值
平台侧将各业务零散、闲置资源进行整合，形成一个大规模资源池，通过K8S弹性调度、库存管控技术在公司运营成本和业务体感中寻求较好的平衡
api接口丰富，易于融入自动化运维体系

三、挑战难题之日志篇
日志庞大，Pod适应于无状态的，而业务重日志是有状态的，如何保障数十T级别的日志安全稳定，运维团队面临着十分艰巨的挑战。
日志大体上划分为三类：

业务日志，数十T/日级别
归档日志，数十T/日级别
入数仓日志，数十T/日级别

四、日志调研
【极客星球|数据智能公司K8S生产环境落地之日志篇】日志的采集方式分为被动采集和主动推送两种，在 K8S 中，被动采集一般分为 Sidecar 和 DaemonSet 两种方式，主动推送分为 DockerEngine 推送和业务直写两种方式：

DockerEngine本身具有 LogDriver 功能，可通过配置不同的 LogDriver 将容器的 stdout 通过 DockerEngine 写入到远端存储，以此达到日志采集的目的。这种方式的可定制化、灵活性、资源隔离性都很低，一般不建议在生产环境中使用

DaemonSet方式在每个 node 节点上只运行一个日志 agent，采集这个节点上所有的日志。DaemonSet 相对资源占用要小很多，但扩展性、租户隔离性受限，比较适用于功能单一或业务不是很多的集群

业务直写是在应用中集成日志采集的 SDK，通过 SDK 直接将日志发送到服务端。这种方式省去了落盘采集的逻辑，也不需要额外部署 Agent，对于系统的资源消耗最低，但由于业务和日志 SDK强绑定，整体灵活性很低，一般只有日志量极大的场景中使用

Sidecar方式为每个POD单独部署日志 agent，这个 agent 只负责一个业务应用的日志采集。Sidecar 相对资源占用较多，但灵活性以及多租户隔离性较强，建议大型的 K8S 集群或作为 PaaS 平台为多个业务方服务的集群使用该方式

文章图片

文章图片

总结下来：

DockerEngine 直写一般不推荐
业务直写推荐在日志量极大的场景中使用
DaemonSet 一般在中小型集群中使用
Sidecar 推荐在超大型的集群中使用

详细的各种采集方式对比如下：

文章图片

五、解决方案
1.业务日志选型：为尽量减少业务开发的改造成本，容器化需要尽快推广，并选择sidecar方式对业务日志进行采集，链路图如下：

文章图片

整个架构的数据流承载每秒200万条数据，logstash集群自动按日期切割索引，再通过生命周期管理自动清理过期日志。

文章图片

文章图片

安装日志采集agent的yaml配置，采集包含容器namespace、pod ip、nodename等，区分不同容器集群和不同环境。

文章图片

文章图片

2.归档日志&数仓日志归档日记和入数仓日志是我们的核心数据，不仅需要很强的性能要求，而且日志的稳定和安全也很重要，开源的组件无法满足需求，自研日志网关解决。

文章图片

历史归档日志几十P甚至数百P时，在浩瀚的归档日志中查找到我们需要的一小段日志是一件很艰难的事，设计分布式集群日志网关，解决了诸多痛点：
日志网关从多个维度记录了归档日志的索引信息，归档日志规范化，极大得降低了运维和业务对归档日志的时效性
归档机存储自动均衡，解放了归档机存储存满时运维手动迁移数据时候的繁琐，减少人力成本
通过可视化平台融入自动化体系，对归档日志的查看和下载进行审计，安全性得到保障
六、总结
在K8S落地后，公司已上线的业务线资源平均使用率由历史的10%提高至40%，帮助公司极大降低了服务器资源成本。但团队在落地和推广的过程中仍然存在很多问题还没有解决，如：