系列文章：雲原生Kubernetes日誌落地方案

在Logging這塊作了幾年，最近1年來愈來愈多的同窗來諮詢如何爲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個主要階段：

1. 在單機時代，幾乎全部的應用都是單機部署，當服務壓力增大時，只能切換更高規格的IBM小型機。日誌做爲應用系統的一部分，主要用做程序Debug，一般結合grep等Linux常見的文本命令進行分析。
2. 隨着單機系統成爲制約阿里業務發展的瓶頸，爲了真正的Scale out，飛天項目啓動：2013年飛天5K項目正式上線。在這個階段各個業務開始了分佈式改造，服務之間的調用也從本地變爲分佈式，爲了更好的管理、調試、分析分佈式應用，咱們開發了Trace（分佈式鏈路追蹤）系統、各式各樣的監控系統，這些系統的統一特色是將全部的日誌（包括Metric等）進行集中化的存儲。
3. 爲了支持更快的開發、迭代效率，近年來咱們開始了容器化改造，並開始了擁抱Kubernetes生態、業務全量上雲、Serverless等工做。在這階段，日誌不管從規模、種類都呈現爆炸式的增加，對日誌進行數字化、智能化分析的需求也愈來愈高，所以統一的日誌平臺應運而生。

可觀察性的終極解讀

在CNCF中，可觀察性的主要做用是問題的診斷，上升到公司總體層面，可觀察性（Observability）不只僅包括DevOps領域，還包括業務、運營、BI、審計、安全等領域，可觀察性的最終的目標是實現公司各個方面的數字化、智能化。

在阿里，幾乎全部的業務角色都會涉及到各式各樣的日誌數據，爲了支撐各種應用場景，咱們開發了很是多的工具和功能：日誌實時分析、鏈路追蹤、監控、數據加工、流計算、離線計算、BI系統、審計系統等等。日誌系統主要專一於數據的實時採集、清洗、智能分析與監控以及對接各種各樣的流計算、離線系統。

Kubernetes日誌系統建設難點

單純日誌系統的解決方案很是多，相對也比較成熟，這裏就再也不去贅述，咱們這次只針對Kubernetes上的日誌系統建設而論。Kubernetes上的日誌方案相比咱們以前基於物理機、虛擬機場景的日誌方案有很大不一樣，例如：

1. 日誌的形式變的更加複雜，不只有物理機/虛擬機上的日誌，還有容器的標準輸出、容器內的文件、容器事件、Kubernetes事件等等信息須要採集。
2. 環境的動態性變強，在Kubernetes中，機器的宕機、下線、上線、Pod銷燬、擴容/縮容等都是常態，這種狀況下日誌的存在是瞬時的（例如若是Pod銷燬後該Pod日誌就不可見了），因此日誌數據必須實時採集到服務端。同時還須要保證日誌的採集可以適應這種動態性極強的場景。
3. 日誌的種類變多，上圖是一個典型的Kubernetes架構，一個請求從客戶端須要通過CDN、Ingress、Service Mesh、Pod等多個組件，涉及多種基礎設施，其中的日誌種類增長了不少，例如K8s各類系統組件日誌、審計日誌、ServiceMesh日誌、Ingress等。
4. 業務架構變化，如今愈來愈多的公司開始在Kubernetes上落地微服務架構，在微服務體系中，服務的開發更加複雜，服務之間的依賴以及服務底層產品的依賴愈來愈多，這時的問題排查將更加複雜，若是關聯各個維度的日誌將是一個困難的問題。
5. 日誌方案集成困難，一般咱們都會在Kubernetes上搭建一套CICD系統，這套CICD系統須要儘量的自動化的完成業務的集成和部署，其中日誌的採集、存儲、清洗等也須要集成到這套系統中，並和K8s的聲明式部署方式儘量一致。而現有的日誌系統一般都是較獨立的系統，集成到CICD中代價極大。
6. 日誌規模問題，一般在系統初期的時候咱們會選擇自建開源的日誌系統，這種方式在測試驗證階段或公司發展初期是沒有什麼問題的，但當業務逐漸增加，日誌量增加到必定規模時，自建的開源系統不少時候都會遇到各類各樣的問題，例如租戶隔離、查詢延遲、數據可靠性、系統可用性等。日誌系統雖不是IT中最核心的路徑，但一旦關鍵時刻出現這些問題都將是很是可怕的影響，例如大促的時候出現緊急問題，排查時多個工程師併發查詢把日誌系統打爆，致使故障恢復時間變長，大促收到影響。

總結

相信在搞K8s日誌系統建設的同窗看到上面的難點分析都會深有感觸，後面咱們會從落地角度出發，詳細介紹在阿里咱們如何去搭建K8s的日誌系統，敬請關注。

---

本文做者：元乙

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。