生產中Kubernetes的日志記錄是怎么實現的
譯文【51CTO.com快譯】人們需要了解生產Kubernetes集群的可擴展日志記錄模式，以用于自己的集群級日志記錄。
傳統上，在單體架構中，日志直接存儲在裸機或虛擬機上，并且從來沒有離開過服務器磁盤，運營團隊將會根據需要檢查每個磁盤的日志。
這適用于內部部署的服務器，而云中的日志是短暫的。隨著越來越多的企業在容器上運行他們的服務，并使用Kubernetes編排部署，日志不必再存儲在服務器上，因此實施日志管理策略至關重要。
日志是調試和監控應用程序的有效方法，它們需要存儲在單獨的后端，以便在Pod或節點故障時進行查詢和分析。這些獨立的后端包括Elasticsearch、谷歌云平臺的Stackdriver和AWS的Cloudwatch等系統。
將集群的日志存儲在存儲后端中稱為集群級日志記錄。本文將討論企業如何在自己的Kubernetes集群中實現這種方法。
日志架構
在Kubernetes集群中有兩個主要的日志源：應用程序和系統組件。
應用程序作為Kubernetes集群中的容器運行，容器運行時負責獲取應用程序的日志，而Docker將這些日志重定向到stdout( 標準輸出流)和 stderr( 標準輸入流)。在Kubernetes集群中，這兩個流都被寫入集群節點上的JSON文件。
可以使用以下命令隨時獲取這些容器日志：
- kubectl logs podname
日志的另一個來源是系統組件。一些系統組件(即kube-scheduler和kube-proxy)作為容器運行，并遵循與應用程序相同的日志記錄原則。
其他系統組件(kubelet和容器運行時本身)作為原生服務運行。如果機器上的systemd可用，組件會在journald中寫入日志，否則它們會在/var/log目錄中寫入.log文件。
現在已經了解了應用程序和集群的哪些組件生成日志以及它們的存儲位置，接下來看看將這些日志卸載到不同存儲系統的一些常見模式。
日志記錄模式
收集日志的兩個最突出的模式是DaemonSet模式和Sidecar模式。
(1)DaemonSet模式
在DaemonSet模式中，日志代理通過Kubernetes中的DaemonSet資源部署為Pod。部署DaemonSet可確保集群中的每個節點都有一個運行日志代理的Pod。這個日志代理被配置為從/var/logs目錄讀取日志并將它們發送到存儲后端。
(2)Sidecar模式
而在Sidecar模式中，一個專用容器與同一個Pod中的每個應用程序容器一起運行。Sidecar模式可以有兩種類型：Streaming Sidecar或日志代理Sidecar (Logging Agent Sidecar)。
當運行將日志寫入文件而不是stdout/stderr流的應用程序，或以非標準格式寫入日志的應用程序時，將使用流Streaming Sidecar。在這種情況下，可以使用Streaming Sidecar容器將文件中的日志發布到其自己的stdout/stderr流，然后Kubernetes本身可以獲取stdout/stderr流。
Streaming Sidecar還可以通過將日志消息轉換為標準日志格式來為日志結構帶來奇偶校驗。
另一種方法是日志代理Sidecar，Sidecar本身將日志發送到存儲后端。每個Pod都包含一個日志代理，例如Fluentd或Filebeat，它從應用程序容器中捕獲日志并將它們直接發送到存儲后端。
DaemonSet和Sidecar的優缺點
現在已經討論了DaemonSet和Sidecar方法，以下了解每種方法的優缺點。
(1)DaemonSet(節點級)
優點：
- 節點級日志更容易實現，因為它與現有的基于文件的日志相關，并且由于每個節點運行的容器較少，因此比Sidecar方法占用的資源更少。
- 日志可通過kubectl命令用于調試，因為日志文件可用于返回日志文件內容的kubelet。
缺點：
- 支持寫入日志文件而不是流的不同日志結構或應用程序的靈活性較低。需要修改應用程序日志結構以實現奇偶校驗，或者處理存儲后端中的差異。
- 由于它們作為JSON文件存儲在節點磁盤上，因此日志不能永久保存。需要有一個日志輪換機制來回收舊日志。如果使用的是容器運行時接口，kubelet會負責輪換日志，不需要實施明確的解決方案。
(2)Sidecar
優點：
- 可以靈活地為每個應用程序容器定制Sidecar。例如，應用程序可能無法寫入stdout/stderr，或者它可能具有某些不同的日志記錄格式。在這些情況下，Sidecar容器可以為系統帶來奇偶校驗。
- 如果沒有使用流式傳輸的日志代理Sidecar，則不需要輪換日志，因為節點磁盤上沒有存儲任何日志。
缺點：
- 與節點級別的Pod相比，為每個應用程序容器運行一個Sidecar非常耗費資源。
- 為每個部署添加一個Sidecar會增加額外的復雜性。
- 如果將Streaming Sidecar用于將其日志寫入文件的應用程序，將使用兩倍的存儲空間來存儲相同的日志，因為將會復制條目。
- 如果沒有使用流式傳輸的日志代理Sidecar，將無法通過kubectl訪問日志。這是因為kubelet不再有權訪問JSON日志。
- 使用日志代理Sidecar，還需要一個節點級代理，否則將無法收集系統組件日志。
將理論付諸實踐
現在已經了解了登錄Kubernetes集群的可能模式，可以付諸實踐，部署生成日志的虛擬容器，并創建Kubernetes資源來實現上面討論的日志記錄模式。
在這個例子中，將使用Fluentd作為日志代理，將安裝Elasticsearch用于日志記錄后端和Kibana用于可視化目的。將使用Helm圖表將Elasticsearch和Kibana安裝到同一個集群中。但是需要注意的是，存儲后端不應位于同一個集群上，這樣做僅用于演示目的。由于Fluentd的可插拔架構，它支持各種不同的接收器。這就是Elasticsearch后端可以被任何云原生解決方案替換的原因，包括Stackdriver或Cloudwatch。
(1)安裝Elasticsearch和Kibana
將使用找到的官方Helm圖表部署Elasticsearch和Kibana(Elasticsearch、Kibana)。要通過Helm安裝，在路徑上需要一個Helm二進制文件，但Helm的安裝不在本文討論范圍之內。
讓我們從添加helm repos開始。
Properties files
1 helm repo add elastic https://helm.elastic.co
接下來，將把Elasticsearch和Kibana圖表安裝到集群中。
Properties files
1 helm install elasticsearch elastic/elasticsearch
2 helm install kibana elastic/kibana
這將在集群中安裝最新版本的Elasticsearch和Kibana，然后可以將其用作日志的存儲后端。
在圖表中使用了默認值，但是在生產中安裝它時，可以根據需要更改任何參數。
(2)DaemonSet
在這里將Fluentd部署為DaemonSet，而不會創建單獨的Service Account和ClusterRole。但在生產環境中，Fluentdpod應該使用訪問受限的單獨服務帳戶運行。
可以使用以下Kubernetes資源將Fluentd部署為DaemonSet：
Go
- api Version: extensions/v1beta1
- kind: DaemonSet
- metadata:
- name: fluentd
- namespace: kube-system
- labels:
- k8s-app: fluentd-logger
- spec:
- template:
- metadata:
- labels:
- k8s-app: fluentd-logger
- spec:
- containers:
- - name: fluentd
- image: fluent/fluentd-kubernetes-daemonset:elasticsearch
- env:
- - name: FLUENT\_ELASTICSEARCH\_HOST
- value: "elasticsearch-master"
- - name: FLUENT\_ELASTICSEARCH\_PORT
- value: "9200"
- volumeMounts:
- - name: varlog
- mountPath: /var/log
- - name: dockerlogs
- mountPath: /var/lib/docker/containers
- readOnly: true
- volumes:
- - name: varlog
- hostPath:
- path: /var/log
- - name: dockerlogs
- hostPath:
- path: /var/lib/docker/containers
在這個例子中，掛載了兩個卷：一個在/var/log，另一個在/var/log/docker/containers，系統組件和Docker運行時分別放置日志。
正在使用的映像已經配置了智能默認值以與DaemonSet一起使用，但可以更改配置。
將上述YAML資源保存在名為fluentd-ds.yaml的文件中，并通過以下命令應用該資源：
Properties files
- kubectl apply -f fluentd-ds.yaml
這將在Kubernetes集群中的每個節點上啟動一個Fluentdpod。
現在將看到如何實現流和日志代理Sidecar模式。
(3)Sidecar
首先，看看當應用程序將日志寫入文件而不是數據流時的Streaming Sidecar模式。可以運行一個Sidecar來讀取這些日志，并將其寫回stdout/stderr流。
Go
- apiVersion: v1
- kind: Pod
- metadata:
- name: my-app
- spec:
- containers:
- - name: legacy-app
- image: busybox
- args:
- - /bin/sh
- - -c
- - >
- i=0;
- while true;
- do
- echo "$i: $(date)" >> /var/log/output.log;
- i=$((i+1));
- sleep 1;
- done
- volumeMounts:
- - name: varlog
- mountPath: /var/log
- - name: streaming-Sidecar
- image: busybox
- args: \[/bin/sh, -c, 'tail -n+1 -f /var/log/output.log'\]
- volumeMounts:
- - name: varlog
- mountPath: /var/log
- volumes:
- - name: varlog
- emptyDir: {}
在這個例子中，有一個虛擬容器將日志寫入容器的/var/log目錄中的文件。現在，容器運行時無法獲取這些日志，這就是實現了一個Streaming Sidecar來從/var/log位置跟蹤日志并將其重定向到stdout流。
這一日志流將由容器運行時獲取并作為JSON文件存儲在節點上的/var/log目錄中，節點級日志代理然后將獲取該文件。
現在看看日志代理Sidecar。在這種模式中，將Fluentd部署為Sidecar，它將直接寫入Elasticsearch存儲后端。
在此沒有安裝Elasticsearch插件的預構建鏡像，而創建自定義Docker鏡像超出了本文討論的范圍。與其相反，將使用在DaemonSet示例中使用的相同Fluentd映像。
Go
- apiVersion: v1
- kind: Pod
- metadata:
- name: my-app
- spec:
- containers:
- - name: count
- image: busybox
- args:
- - /bin/sh
- - -c
- - >
- i=0;
- while true;
- do
- echo "$i: $(date)" >> /var/log/output.log;
- i=$((i+1));
- sleep 1;
- done
- volumeMounts:
- - name: varlog
- mountPath: /var/log
- - name: logging-agent
- image: fluent/fluentd-kubernetes-daemonset:elasticsearch
- env:
- - name: FLUENT\_ELASTICSEARCH\_HOST
- value: "elastisearch-master"
- - name: FLUENT\_ELASTICSEARCH\_PORT
- value: "9200"
- volumeMounts:
- - name: varlog
- mountPath: /var/log
- volumes:
- - name: varlog
- emptyDir: {}
結論
鑒于Pod和節點的短暫性，將來自Kubernetes集群的日志存儲在單獨的存儲后端中非常重要。可以使用多種模式來設置在本文中討論的日志記錄架構。
在此建議為生產系統混合使用Sidecar和節點級模式。這包括使用DaemonSet模式設置集群范圍的節點級日志記錄，以及為不支持將日志寫入流(stdout/stderr)或不以標準日志格式寫入的應用程序實現Streaming Sidecar容器。這個流容器將自動顯示要選取的節點級代理的日志。
對于存儲后端的選擇，可以選擇自托管的開源解決方案，例如Elasticsearch，或者可以使用云托管的Elasticsearch、Stackdriver以及Cloudwatch等選項選擇托管服務路線。選擇適合后端將取決于希望在架構中實現的成本、查詢和日志分析要求。
原文標題：Kubernetes Logging in Production，作者：Kentaro Wakayama
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
