Kubernetes（K8S）作為CNCF（cloud native computing foundation）的一個核心項目，背靠Google和Redhat的強大社群，近兩年發展十分迅速，在成為容器編排領域中上司者的同時，也正在朝着PAAS底座标配的方向發展。
日志采集方式
日志作為任一系統不可或缺的部分，在K8S的官方文檔中也介紹了多種的
日志采集形式，總結起來主要有下述3種：原生方式、DaemonSet方式和Sidecar方式。
- 原生方式：使用
kubectl logs
log driver
- DaemonSet方式：在K8S的每個node上部署日志agent，由agent采集所有容器的日志到服務端。
- Sidecar方式：一個POD中運作一個sidecar的日志agent容器，用于采集該POD主容器産生的日志。
采集方式對比
每種采集方式都有一定的優劣勢，這裡我們進行簡單的對比：
| 原生方式 | DaemonSet方式 | Sidecar方式 | |
| 采集日志類型 | 标準輸出 | 标準輸出+部分檔案 | 檔案 |
| 部署運維 | 低，原生支援 | 一般，需維護DaemonSet | 較高，每個需要采集日志的POD都需要部署sidecar容器 |
| 日志分類存儲 | 無法實作 | 一般，可通過容器/路徑等映射 | 每個POD可單獨配置，靈活性高 |
| 多租戶隔離 | 弱 | 一般，隻能通過配置間隔離 | 強，通過容器進行隔離，可單獨配置設定資源 |
| 支援叢集規模 | 本地存儲無限制，若使用syslog、fluentd會有單點限制 | 中小型規模，業務數最多支援百級别 | 無限制 |
| 資源占用 | 低，docker engine提供 | 較低，每個節點運作一個容器 | 較高，每個POD運作一個容器 |
| 查詢便捷性 | 低 | 較高，可進行自定義的查詢、統計 | 高，可根據業務特點進行定制 |
| 可定制性 | 高，每個POD單獨配置 | ||
| 适用場景 | 測試、POC等非生産場景 | 功能單一型的叢集 | 大型、混合型、PAAS型叢集 |
從上述表格中可以看出：
- 原生方式相對功能太弱，一般不建議在生産系統中使用，否則問題調查、資料統計等工作很難完成；
- DaemonSet方式在每個節點隻允許一個日志agent，相對資源占用要小很多，但擴充性、租戶隔離性受限，比較适用于功能單一或業務不是很多的叢集；
- Sidecar方式為每個POD單獨部署日志agent，相對資源占用較多，但靈活性以及多租戶隔離性較強，建議大型的K8S叢集或作為PAAS平台為多個業務方服務的叢集使用該方式。
日志服務K8S采集方式
DaemonSet和Sidecar模式各有優缺點，目前沒有哪種方式可以适用于所有場景。是以我們阿裡雲日志服務同時支援了DaemonSet以及Sidecar兩種方式，并對每種方式進行了一些額外的改進，更加适用于K8S下的動态場景。
這兩種模式均基于Logtail實作，日志服務用戶端Logtail目前已有百萬級部署，每天采集上萬應用、數PB的資料，曆經多次雙11、雙12考驗。相關技術分享可以參見文章：
多租戶隔離技術+雙十一實戰效果，
Polling + Inotify 組合下的日志保序采集方案。
DaemonSet采集方式
DaemonSet方式下Logtail做了非常多的适配工作，包括：
- 一條指令一個參數即可實作部署，資源自動初始化
- 支援CRD方式配置，支援K8S控制台、kubectl、kube api等，與K8S釋出、部署無縫內建
- K8S RBAC鑒權，日志服務STS鑒權管理
詳細的介紹文章可以參考：
再次更新！阿裡雲Kubernetes日志解決方案 LC3視角：Kubernetes下日志采集、存儲與處理技術實踐Sidecar采集方式
sidecar方式的配置以及使用相對在虛拟機/實體機上采集資料差別不大，從Logtail容器視角來看：Logtail工作在一個“虛拟機”上，需要采集這個機器上某個/某些日志檔案。
但在容器場景下還需解決兩個問題：
- 配置：使用編排的方式配置agent容器
-
動态性：需适應POD的IP位址和hostname的變化
目前Logtail的容器支援通過環境變量配置相關參數，并支援自定義辨別的機器組進行工作，可以完美解決上述兩個問題。
Sidecar配置示例
Sidecar模式下日志元件安裝、配置方式如下：
步驟一： 部署Logtail容器
- 在部署POD時将日志路徑挂載到本地，并将對應的volume也挂載到Logtail容器。
- Logtail容器需配置
ALIYUN_LOGTAIL_USER_ID
ALIYUN_LOGTAIL_CONFIG
ALIYUN_LOGTAIL_USER_DEFINED_ID
tips：
- Logtail容器建議配置健康檢查，在運作環境、核心等出現異常時可自動恢複。
- 示例中使用的Logtail鏡像通路的是阿裡雲hangzhou公網鏡像倉庫，您可根據需求替換成本Region的鏡像，并使用内網方式。
apiVersion: batch/v1
kind: Job
metadata:
name: nginx-log-sidecar-demo
namespace: kube-system
spec:
template:
metadata:
name: nginx-log-sidecar-demo
spec:
# volumes配置
volumes:
- name: nginx-log
emptyDir: {}
containers:
# 主容器配置
- name: nginx-log-demo
image: registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest
command: ["/bin/mock_log"]
args: ["--log-type=nginx", "--stdout=false", "--stderr=true", "--path=/var/log/nginx/access.log", "--total-count=1000000000", "--logs-per-sec=100"]
volumeMounts:
- name: nginx-log
mountPath: /var/log/ngin
# Logtail的Sidecar容器配置
- name: logtail
image: registry.cn-hangzhou.aliyuncs.com/log-service/logtail:latest
env:
# aliuid
- name: "ALIYUN_LOGTAIL_USER_ID"
value: "165421******3050"
# 自定義辨別機器組配置
- name: "ALIYUN_LOGTAIL_USER_DEFINED_ID"
value: "nginx-log-sidecar"
# 啟動配置（用于選擇Logtail所在Region）
- name: "ALIYUN_LOGTAIL_CONFIG"
value: "/etc/ilogtail/conf/cn-hangzhou/ilogtail_config.json"
# 和主容器共享volume
volumeMounts:
- name: nginx-log
mountPath: /var/log/nginx
# 健康檢查
livenessProbe:
exec:
command:
- /etc/init.d/ilogtaild
- status
initialDelaySeconds: 30
periodSeconds: 30 步驟二： 配置機器組
如下圖所示，在日志服務控制台建立一個Logtail的機器組，機器組選擇自定義辨別，可以動态适應POD ip位址的改變。具體操作步驟如下：
- 開通日志服務并建立Project、Logstore，詳細步驟請參考 準備流程
- 在日志服務控制台的機器組清單頁面單擊 建立機器組
- 選擇使用者自定義辨別，将您上一步配置的
ALIYUN_LOGTAIL_USER_DEFINED_ID
步驟三：配置采集方式
機器組建立完成後，即可配置對應檔案的采集配置，目前支援極簡、Nginx通路日志、分隔符日志、JSON日志、正則日志等格式，具體可參考：
文本日志配置方式。本示例中配置如下：
步驟四：查詢日志
采集配置完成并應用到機器組後，1分鐘内日志即可采集上來，進入對應logstore的查詢頁面即可查詢到采集上來的日志。
日志進階
阿裡雲日志服務針對日志提供了完整的解決方案，日志采集隻是其中的第一步，以下相關功能是日志進階的必備良藥：
- 日志上下文查詢： https://help.aliyun.com/document_detail/48148.html
- 快速查詢： https://help.aliyun.com/document_detail/88985.html
- 實時分析： https://help.aliyun.com/document_detail/53608.html
- 快速分析： https://help.aliyun.com/document_detail/66275.html
- 基于日志設定告警： https://help.aliyun.com/document_detail/48162.html
- 配置大盤： https://help.aliyun.com/document_detail/69313.html 更多日志進階内容可以參考： 日志服務學習路徑