前言
公司在经历2019-2020年的快速发展后，业务的高速成长给运维基建带来了巨大挑战，业务特性转变为大流量、高并发（千万级）。为保障业务稳定和安全，运维团队在架构上做了重大调整，从传统架构逐渐演化成混合云架构，同时实现业务异地容灾、容器化、跨机房调度等。公司从2020年开始规划容器，到现在已落地150个项目，过程中遇到包含日志、监控、网络、CI/CD等版块问题，本篇文章将重点围绕日志版块进行详细阐述。
一、背景
每家公司在成长的过程中或多或少都会存在一些历史遗留问题，如：
-
业务资源使用率偏低
-
公司每季度服务器资源投入成本巨大
-
业务突发资源扩缩容操作时间过长
-
当前Kvm虚拟化实现自动化整合难度大
二、选择K8S****的原因
容器化编排有K8S、Swarm、Mesos，近年K8S成为主流趋势，Swarm和Mesos已经逐渐小众化，因此我们选择了K8S作为编排。其拥有以下优点，如：
-
弹性伸缩具有应突发、省成本、自动化的业务价值
-
平台侧将各业务零散、闲置资源进行整合，形成一个大规模资源池，通过K8S弹性调度、库存管控技术在公司运营成本和业务体感中寻求较好的平衡
-
api接口丰富，易于融入自动化运维体系
三、挑战难题之日志篇
日志庞大，Pod适应于无状态的，而业务重日志是有状态的，如何保障数十T级别的日志安全稳定，运维团队面临着十分艰巨的挑战。
日志大体上划分为三类：
-
业务日志，数十T/日级别
-
归档日志，数十T/日级别
-
入数仓日志，数十T/日级别
四、日志调研
日志的采集方式分为被动采集和主动推送两种，在 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 推荐在超大型的集群中使用
详细的各种采集方式对比如下：
Item
原生方式
业务直写
DaemonSet方式
Sidecar方式
采集类型
STOUT/STDERR
业务日志
STOUT/STDERR+部分文件
文件
部署运维
低，原生支持
低，只需维护配置文件
一般，需要维护DaemonSet
较高，每个需要采集日志的Pod均需要部署sidecar
日志分类存储
无法实现
业务独立配置
一般，可通过映射等方式
每个Pod可单独配置，灵活性高
多租户隔离
弱
弱，日志直写会和业务逻辑竞争资源
一般，只能通过配置隔离
强，通过容器进行隔离，可单独分配资源
支持集群规模
本地存储无限制，若使用
syslog等则存在单点
无限制
取决于配置数
无限制
资源占用
低，docker原生
实际使用
低
高
engine
提供
整体最低，省去采集开销
高，每个Pod运行一个容器
低，每个节点运行一个容器
高，每个Pod运行一个容器
可定制性
低
高，可自由扩展
低
高，每个Pod单独配置
耦合度
高，与docker engine绑定，修改需要重启docker
一般
低，
agent可独立升级
一般，有些agent升级需要重启
适用场景
测试，POC场景
对性能要求极高的场景
日志分配明确，功能单一的场景
大型、混合型、PAAS型集群
五、解决方案
1.业务日志选型：
为尽量减少业务开发的改造成本，容器化需要尽快推广，并选择sidecar方式对业务日志进行采集，链路图如下：
整个架构的数据流承载每秒200万条数据，logstash集群自动按日期切割索引，再通过生命周期管理自动清理过期日志。
安装日志采集agent的yaml配置，采集包含容器namespace、pod ip、nodename等，区分不同容器集群和不同环境。
2.归档日志**&数仓日志**
归档日记和入数仓日志是我们的核心数据，不仅需要很强的性能要求，而且日志的稳定和安全也很重要，开源的组件无法满足需求，自研日志网关解决。
历史归档日志几十P甚至数百P时，在浩瀚的归档日志中查找到我们需要的一小段日志是一件很艰难的事，设计分布式集群日志网关，解决了诸多痛点：
-
日志网关从多个维度记录了归档日志的索引信息，归档日志规范化，极大得降低了运维和业务对归档日志的时效性
-
归档机存储自动均衡，解放了归档机存储存满时运维手动迁移数据时候的繁琐，减少人力成本
-
通过可视化平台融入自动化体系，对归档日志的查看和下载进行审计，安全性得到保障
六、总结
在K8S落地后，公司已上线的业务线资源平均使用率由历史的10%提高至40%，帮助公司极大降低了服务器资源成本。但团队在落地和推广的过程中仍然存在很多问题还没有解决，如：
-
容器内部无法看到分配的内存和cpu核数
-
容器的IOPS和IO Buffer的限制
-
通容器安全隔离防护
-
业务线成本资源和容器集群绑定
-
....
未来，运维团队将继续攻克K8S生产环境落地所面临的多重挑战及难题，后续将分别就“监控”、“网络”、“CI/CD”等话题持续分享， 敬请期待。
