作者 | 元乙 阿里雲儲存服務技術專家
第一篇：《6 個 k8s 日誌系統建設中的典型問題，你遇到過幾個？》
第二篇：《一文看懂 k8s 日誌系統設計和實踐》
第三篇：《9 個技巧，解決 k8s 中的日誌輸出問題》
在 kubernetes 中，日誌採集相比傳統虛擬機器、物理機方式要複雜很多，最根本的原因是 kubernetes 把底層異常遮蔽，提供更加細粒度的資源排程，向上提供穩定、動態的環境。因此日誌採集面對的是更加豐富、動態的環境，需要考慮的點也更加的多。
例如：
日誌的採集方式分為被動採集和主動推送兩種，在 k8s 中，被動採集一般分為 sidecar 和 daemonset 兩種方式，主動推送有 dockerengine 推送和業務直寫兩種方式。
總結下來：
詳細的各種採集方式對比如下：
和虛擬機器/物理機不同，k8s 的容器提供標準輸出和檔案兩種方式。在容器中，標準輸出將日誌直接輸出到 stdout 或 stderr，而 dockerengine 接管 stdout 和 stderr 檔案描述符，將日誌接收後按照 dockerengine 配置的 logdriver 規則進行處理；日誌列印到檔案的方式和虛擬機器/物理機基本類似，只是日誌可以使用不同的儲存方式，例如預設儲存、emptydir、hostvolume、nfs 等。
雖然使用 stdout 列印日誌是 docker 官方推薦的方式，但大家需要注意：這個推薦是基於容器只作為簡單應用的場景，實際的業務場景中我們還是建議大家盡可能使用檔案的方式，主要的原因有以下幾點：
因此我們建議線上應用使用檔案的方式輸出日誌，stdout 只在功能單一的應用或一些 k8s 系統/運維元件中使用。
kubernetes 提供了標準化的業務部署方式，可以通過 yaml(k8s api)來宣告路由規則、暴露服務、掛載儲存、執行業務、定義縮擴容規則等，所以 kubernetes 很容易和 cicd 系統整合。而日誌採集也是運維監控過程中的重要部分，業務上線後的所有日誌都要進行實時的收集。
原始的方式是在發布之後手動去部署日誌採集的邏輯，這種方式需要手工干預，違背 cicd 自動化的宗旨；為了實現自動化，有人開始基於日誌採集的 api/sdk 包裝乙個自動部署的服務，在發布後通過 cicd 的 webhook 觸發呼叫，但這種方式的開發代價很高。
在 kubernetes 中，日誌最標準的整合方式是以乙個新資源註冊到 kubernetes 系統中，以 operator(crd)的方式來進行管理和維護。在這種方式下，cicd 系統不需要額外的開發，只需在部署到 kubernetes 系統時附加上日誌相關的配置即可實現。
早在 kubernetes 出現之前，我們就開始為容器環境開發日誌採集方案，隨著 k8s 的逐漸穩定，我們開始將很多業務遷移到 k8s 平台上，因此也基於之前的基礎專門開發了一套 k8s 上的日誌採集方案。主要具備的功能有：
目前這套採集方案已經對外開放，我們提供了乙個 helm 安裝包，其中包括 logtail 的 daemonset、aliyunlogconfig 的 crd 宣告以及 crd controller，安裝之後就能直接使用 daemonset 採集以及 crd 配置了。安裝方式如下：
阿里雲 kubernetes 集群在開通的時候可以勾選安裝，這樣在集群建立的時候會自動安裝上述元件。如果開通的時候沒有安裝，則可以手動安裝；
如果是自建的 kubernetes，無論是在阿里雲上自建還是在其他雲或者是線下，也可以使用這樣採集方案，具體安裝方式參考自建 kubernetes 安裝。
安裝好上述元件之後，logtail 和對應的 controller 就會執行在集群中，但預設這些元件並不會採集任何日誌，需要配置日誌採集規則來採集指定 pod 的各類日誌。
除了在日誌服務控制台上手動配置之外，對於 kubernetes 還額外支援兩種配置方式：環境變數和 crd。
這種方式部署簡單，學習成本低，很容易上手；但能夠支援的配置規則很少，很多高階配置(例如解析方式、過濾方式、黑白名單等)都不支援，而且這種宣告的方式不支援修改/刪除，每次修改其實都是建立 1 個新的採集配置，歷史的採集配置需要手動清理，否則會造成資源浪費。
例如下面的示例就是部署乙個容器標準輸出的採集，其中定義需要 stdout 和 stderr 都採集，並且排除環境變數中包含 collext_stdout_flag：false 的容器。
基於 crd 的配置方式以 kubernetes 標準擴充套件資源的方式進行管理，支援配置的增刪改查完整語義，而且支援各種高階配置，是我們極其推薦的採集配置方式。
實際應用場景中，一般都是使用 daemonset 或 daemonset 與 sidecar 混用方式，daemonset 的優勢是資源利用率高，但有乙個問題是 daemonset 的所有 logtail 都共享全域性配置，而單一的 logtail 有配置支撐的上限，因此無法支撐應用數比較多的集群。
絕大部分 kubernetes 集群都屬於中小型的，對於中小型沒有明確的定義，一般應用數在 500 以內，節點規模 1000 以內，沒有職能明確的 kubernetes 平台運維。這種場景應用數不會特別多，daemonset 可以支撐所有的採集配置：
對於一些用作 paas 平台的大型/超大型集群，一般業務在 1000 以上，節點規模也在 1000 以上，有專門的 kubernetes 平台運維人員。這種場景下應用數沒有限制，daemonset 無法支援，因此必須使用 sidecar 方式，整體規劃如下：
雲原生應用平台邀 kubernetes/容器/ serverless/應用交付技術領域專家(p7-p8)加盟。
簡歷投遞：xining.zj at alibaba-inc.com。
「阿里巴巴雲原生關注微服務、serverless、容器、service mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。」
k8s集群日誌
硬體環境 三颱虛擬機器，10.10.20.203 部署docker etcd flannel kube apiserver kube controller manager kube scheduler elsticsearch kibana 10.10.20.206 部署docker flannel...
K8S之EFK日誌收集
1.1 部署es 2 共6個檔案 root k8s master01 efk ls es service.yaml es statefulset.yaml fluentd es configmap.yaml fluentd es ds.yaml kibana deployment.yaml kiba...
EFK完成k8s應用日誌收集
方案選擇 kubernetes官方提供了efk的日誌收集解決方案，但是這種方案並不適合所有的業務場景，它本身就有一些侷限性，例如 所有日誌都必須是out前台輸出，真實業務場景中無法保證所有日誌都在前台輸出 只能有乙個日誌輸出檔案，而真實業務場景中往往有多個日誌輸出檔案 fluentd並不是常用的日誌...