系列文章：云原生Kubernetes日志落地方案

前言
第一次听到Kubernetes的名字是在16年，那个时候Kubernetes还处于和Docker Swarm、Mesos方案的“三国鼎立时代”，Kubernetes由于一系列优势（可扩展、声明式接口、云友好）在这一竞争中崭露头角，最终获得统治地位。Kubernetes作为CNCF最核心的项目（没有之一），是Cloud Native（云原生）落地的底座，目前阿里已经全面基于Kubernetes在开展全站的云原生改造，在1-2年内，阿里巴巴100%的业务都将跑在公有云上。

CloudNative在CNCF的定义的核心是：在公有云、私有云、混合云等环境中，通过Containers、Service Meshes、 MicroServices、Immutable Infrastructure、Declarative APIs构建和运行可弹性扩展的且具有高容错性、易于管理、可观察、松耦合的应用系统。可观察性是应用系统必不可少的一个部分，云原生的设计理念中就有一条：面向诊断性设计（Diagnosability），包括集群级别的日志、Metric和Trace。


为何我们需要日志系统
通常一个线上问题的定位流程是：通过Metric发现问题，根据Trace定位到问题模块，根据模块具体的日志定位问题原因。在日志中包括了错误、关键变量、代码运行路径等信息，这些是问题排查的核心，因此日志永远是线上问题排查的必经路径。



在阿里的十多年中，日志系统伴随着计算形态的发展在不断演进，大致分为3个主要阶段：

在单机时代，几乎所有的应用都是单机部署，当服务压力增大时，只能切换更高规格的IBM小型机。日志作为应用系统的一部分，主要用作程序Debug，通常结合grep等Linux常见的文本命令进行分析。
随着单机系统成为制约阿里业务发展的瓶颈，为了真正的Scale out，飞天项目启动：2013年飞天5K项目正式上线。在这个阶段各个业务开始了分布式改造，服务之间的调用也从本地变为分布式，为了更好的管理、调试、分析分布式应用，我们开发了Trace（分布式链路追踪）系统、各式各样的监控系统，这些系统的统一特点是将所有的日志（包括Metric等）进行集中化的存储。
为了支持更快的开发、迭代效率，近年来我们开始了容器化改造，并开始了拥抱Kubernetes生态、业务全量上云、Serverless等工作。在这阶段，日志无论从规模、种类都呈现爆炸式的增长，对日志进行数字化、智能化分析的需求也越来越高，因此统一的日志平台应运而生。

可观察性的终极解读
在CNCF中，可观察性的主要作用是问题的诊断，上升到公司整体层面，可观察性（Observability）不仅仅包括DevOps领域，还包括业务、运营、BI、审计、安全等领域，可观察性的最终的目标是实现公司各个方面的数字化、智能化。



在阿里，几乎所有的业务角色都会涉及到各式各样的日志数据，为了支撑各类应用场景，我们开发了非常多的工具和功能：日志实时分析、链路追踪、监控、数据加工、流计算、离线计算、BI系统、审计系统等等。日志系统主要专注于数据的实时采集、清洗、智能分析与监控以及对接各类各样的流计算、离线系统。


Kubernetes日志系统建设难点



单纯日志系统的解决方案非常多，相对也比较成熟，这里就不再去赘述，我们此次只针对Kubernetes上的日志系统建设而论。Kubernetes上的日志方案相比我们之前基于物理机、虚拟机场景的日志方案有很大不同，例如：

日志的形式变的更加复杂，不仅有物理机/虚拟机上的日志，还有容器的标准输出、容器内的文件、容器事件、Kubernetes事件等等信息需要采集。
环境的动态性变强，在Kubernetes中，机器的宕机、下线、上线、Pod销毁、扩容/缩容等都是常态，这种情况下日志的存在是瞬时的（例如如果Pod销毁后该Pod日志就不可见了），所以日志数据必须实时采集到服务端。同时还需要保证日志的采集能够适应这种动态性极强的场景。
日志的种类变多，上图是一个典型的Kubernetes架构，一个请求从客户端需要经过CDN、Ingress、Service Mesh、Pod等多个组件，涉及多种基础设施，其中的日志种类增加了很多，例如K8s各种系统组件日志、审计日志、ServiceMesh日志、Ingress等。
业务架构变化，现在越来越多的公司开始在Kubernetes上落地微服务架构，在微服务体系中，服务的开发更加复杂，服务之间的依赖以及服务底层产品的依赖越来越多，这时的问题排查将更加复杂，如果关联各个维度的日志将是一个困难的问题。
日志方案集成困难，通常我们都会在Kubernetes上搭建一套CICD系统，这套CICD系统需要尽可能的自动化的完成业务的集成和部署，其中日志的采集、存储、清洗等也需要集成到这套系统中，并和K8s的声明式部署方式尽可能一致。而现有的日志系统通常都是较独立的系统，集成到CICD中代价极大。
日志规模问题，通常在系统初期的时候我们会选择自建开源的日志系统，这种方式在测试验证阶段或公司发展初期是没有什么问题的，但当业务逐渐增长，日志量增长到一定规模时，自建的开源系统很多时候都会遇到各种各样的问题，例如租户隔离、查询延迟、数据可靠性、系统可用性等。日志系统虽不是IT中最核心的路径，但一旦关键时刻出现这些问题都将是非常可怕的影响，例如大促的时候出现紧急问题，排查时多个工程师并发查询把日志系统打爆，导致故障恢复时间变长，大促收到影响。
本文作者：元乙

原文链接：https://yq.aliyun.com/articles/717779?utm_content=g_1000076969

本文为云栖社区原创内容，未经允许不得转载。