DockOne微信分享（七十二）：Kubernetes容器叢集中的日誌系統整合實踐

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】本次課程將分享如何利用Fluentd、Elasticsearch、Kibana在Kubernetes叢集中構建一個高可用高可擴充的日誌系統，來收集、處理、分析和展示Kubernetes叢集中的容器日誌。

Kubernetes是原生的容器編排管理系統，對於負載平衡、服務發現、高可用、滾動升級、自動調整等容器雲平台的功能要求有原生支援。今天我分享一下我們在Kubernetes叢集中日誌管理的實踐方案。在這個方案中，除了Docker和Kubernetes，主要還涉及的技術包括：Fluentd、Elasticsearch、Kibana和Swift。

Fig00-Kubernetes日誌系統中涉及的技術

評估容器雲平台日誌系統的標準：

1. 易擴充：能夠支撐叢集規模的增長
2. 開銷低：盡量佔用較少的系統資源
3. 入侵小：盡量不需要改動應用程式容器和雲平台系統
4. 大集中：將所有分布在各個主機節點上的日誌集中在一起分析和查詢
5. 易部署：方便自動化部署到分布式叢集中
6. 易定製：方便處理不同日誌格式，方便對接不同的儲存方式
7. 實效性：日誌在產生之後需要能在短時間內即可以進行查看分析
8. 社區活躍：方便未來的維護和更新，方便功能擴充

Fluentd的介紹

Fluentd是一個即時日誌收集系統，它把JSON作為日誌的中間處理格式，通過靈活的外掛程式機制，可以支援豐富多樣的日誌輸入應用、輸出應用、以及多種日誌解析、緩衝、過濾和格式化輸出機制。

Fluentd的架構

Fluentd將JSON作為資料處理的中間格式，通過外掛程式式的架構可擴充地支援不同種應用或系統作為日誌源和日誌輸出端。假設有M種輸入源Wordpress、MySQL、Tomcat……；N種輸出端MySQL、MongoDB、Elasticsearch……那麼處理日誌的代碼模組由MxN減少為M+N。我們在Kubernetes叢集中收集日誌主要用到https://hub.docker.com/r/fabri ... etes/ 這個鏡像和https://github.com/fabric8io/d ... netes 這個Plugins。

Fig01-Fluend架構


Fig02-Fluentd功能

Fluentd的特點：

1. 將JSON作為統一的中介層日誌格式做Tlog
2. 基於Ruby的日誌收集工具：較基於JRuby的Logstash的Footprint小
3. 相容的輸入源輸出端基本和Logstash相當
4. 效能相關的部分為C代碼：速度較快
5. 支援外掛程式擴充：Input、Parser、Filter、Output、Formatter and Buffer

Fluentd在Kubernetes叢集中的部署架構

每個Node節點上都要有Fluentd-Elasticsearch這個Pod，有兩種方式支援：1. 放在/etc/kubernetes/manifest下，用指令碼自動啟動；2. 用DaemonSet啟動。這兩種模式都是為了保證在每一個Kubernetes叢集節點上都有一個Fluentd的駐留Pod運行來收集日誌。Kubernetes中DaemonSet這個API對象就是為了駐留Pod而設計的。

Fig03-Fluentd在Kubernetes叢集中的部署架構

在Kubenetes中的部署案例YAML

在Kubernetes叢集中部署Fluentd時，可以採用類似下面的YAML檔案，將使用Docker鏡像Fluentd-Elasticsearch的Pod部署到每一個Kubernetes節點上。

Fig04-Fluentd在Kubernetes叢集中的部署YAML
Fluentd pod的運行時狀態：

Fig05-Fluentd在Kubernetes叢集中的運行狀態

選用Fluentd的理由：

• 開銷低：核心代碼為C，外掛程式代碼為Ruby，不需要打包JDK
• 入侵小：用Pod部署，不干擾應用程式容器和主機服務
• 易部署：使用容器鏡像作為單容器Pod部署
• 易定製：很方便增加和更改適合自己應用的外掛程式

Elasticsearch

Elasticsearch是一個即時的分布式搜尋和分析引擎。它可以用於文檔儲存，全文檢索搜尋，結構化搜尋以及即時分析，與常見的互連網應用最典型的應用情境是日誌分析查詢和全文檢索搜尋。

Elasticsearch的架構

在Elasticsearch中有三類節點：第一類是Data Node，用來儲存資料，Elasticsearch中對於一份資料可以有多個副本，以提供資料高可用能力；第二類是Client Node，或者叫查詢節點，提供對查詢的負載平衡；第三類是Master Eligible node，或者叫索引節點，這些節點可以被選舉為Master Node，而Master Node會控制整個Elasticsearch叢集的狀態。

Fig06-Elasticsearch的架構

Elasticsearch在Kubernetes中的部署架構

我們在Kubernetes中，三類節點都是一個包含同一個鏡像Pod
elasticsearch-cloud-kubernetes，區別只是啟動時的環境role不一樣。查詢和索引節點需要提供對外的Web服務，需要發布為一個Kubernetes Service。資料節點需要綁定一個持久化儲存，我們用Kubernetes PV建立出儲存卷，資料節點上面通過Kubernetes PVC綁定到相應的資料卷。PV的實際儲存可以是NFS、GlusterFS等共用儲存。

Fig07-Elasticsearch在Kubernetes中的部署架構

Elasticsearch的特點

• 搜尋引擎：基於Apache Lucene的全文檢索搜尋引擎，作為開源搜尋引擎應用案例開始比solr更流行
• 文檔資料庫：可以作為文檔資料庫使用，儲存文檔大資料，日誌大資料
• 即時資料分析查詢系統：支援大資料量的即時分析查詢
• 完全分布式：可隨著節點數水平擴充儲存量和查詢速度
• 高可用：可以自動檢測破壞的分區，自動重新平衡各個節點上儲存的分區資料，可備份冷資料到Object Storage Service
• 支援外掛程式擴充：可自訂外掛程式支援不同的備份目標

Elasticsearch與傳統關聯式資料庫的類比

Elasticsearch與傳統資料的概念有許多類似之處，下面是Elasticsearch與傳統關係型資料庫的對比。

Fig08-Elasticsearch與傳統資料庫的對比

Elasticsearch在Kubernetes叢集中的部署

在Kubernetes叢集中部署Elasticsearch，我們會部署類似圖中的3種節點：es-data類是用來存放索引資料的；es-master類是用來提供索引寫服務的；es-client是用來提供索引查詢服務的。

Fig09-Elasticsearch在Kubernetes叢集中的部署

Elasticsearch資料在Kubernetes叢集中的持久化儲存

在部署es-data節點的時候，他們的資料卷我們是以共用儲存卷掛載的，這裡採用PVC/PV的模式掛載一個NFS的PV提供資料卷，如所示。

Fig10-Elasticsearch資料在Kubernetes叢集中的持久化儲存

日誌的備份和恢複

Elasticsearch允許對於單個索引或整個叢集做備份和恢複。備份恢複所支援的目標儲存倉庫類型包括：

S3倉庫：將AWS S3作為備份倉庫

安裝命令：

sudo bin/elasticsearch-plugin install repository-s3

建立倉庫樣本：

PUT _snapshot/my-s3-repository-1
{
"type": "s3",
"settings": {
"bucket": "s3_repository_1",
"region": "us-west"
}
}   

Azure倉庫：將Azure作為備份倉庫

安裝命令：

sudo bin/elasticsearch-plugin install repository-azure

建立倉庫樣本：

PUT _snapshot/my-azure-repository-1
{
"type": "azure",
"settings": {
    "container": "backup-container",
    "base_path": "backups",
    "chunk_size": "32m",
    "compress": true
}
}  

HDFS倉庫：將HDFS作為備份倉庫

安裝命令：

sudo bin/elasticsearch-plugin install repository-hdfs

建立倉庫樣本：

PUT _snapshot/my-hdfs-repository-1
{
"type": "hdfs",
"settings": {
"uri": "hdfs://namenode:8020/",
"path": "elasticsearch/respositories/my_hdfs_repository",
"conf.dfs.client.read.shortcircuit": "true"
}
}  

GCS倉庫：將Google Cloud Storage作為備份倉庫

安裝命令：

sudo bin/elasticsearch-plugin install repository-gcs

建立倉庫樣本：

PUT _snapshot/my-gcs-repository-1
{
"type": "gcs",
"settings": {
"bucket": "my_bucket",
"service_account": "_default_"
}
}  

作為私人雲端部署的環境，多數基於OpenStack的IaaS層，可以採用OpenStack的Object Storage ServiceSwift作為備份。

Swift倉庫：將OpenStack Swift作為備份倉庫

安裝命令：

sudo bin/elasticsearch-plugin install org.wikimedia.elasticsearch.swift/swift-repository-plugin/2.1.1
建立倉庫樣本：
PUT _snapshot/my-gcs-repository-1
{
"type": "swift",
"settings": {
    "swift_url": "http://localhost:8080/auth/v1.0/",
    "swift_container": "my-container",
    "swift_username": "myuser",
    "swift_password": "mypass!"
}
}  

選用Elasticsearch的理由：

• 易擴充：可以隨著增加節點水平擴充儲存容量和索引能力
• 大集中：將所有Pod和容器的資料集中在一起方便查詢和分析
• 易部署：使用容器鏡像作為單容器Pod部署
• 易定製：很方便增加和更改適合自己應用的外掛程式
• 實效性：日誌在產生之後需要能在短時間內即可以進行查看分析
• 社區活躍：Elasticsearch社區越來越活躍，大有趕超Solr之勢

Kibana

Kibana在Kubernetes中的部署

Kibana跟Elasticsearch的整合相對來說比較直觀，利用https://hub.docker.com/r/fabric8/kibana4/鏡像，設定好ELASTICSEARCH_URL參數就可以，Kibana是一個部署在Kubernetes叢集中的Web前端服務，而它引用ELASTICSEARCH_URL這個環境變數作為資源使用。

Fig11-在Kubernetes叢集中部署Kibana

整體日誌管理系統的架構

在Kubernetes叢集中的每個節點上運行一個Fluentd的容器，收集容器的日誌發送給到Elasticsearch叢集中。Elasticsearch叢集會儲存一周的日誌作為熱資料以供即時分析和查詢，使用者可以通過Kibana查看任意Node、Namespace、Service、Pod和容器的資料。對於超過一周的日誌資料，Elasticsearch會自動備份到SwiftObject Storage Service的相應Bucket中。

Fig12-整體Kubernetes日誌管理系統的架構

Q&A

Q：請問Kubernetes宿主機的日誌是如何收集的？

A：跟收集容器的日誌是類似的，事實上容器的日誌也是從主機的日誌目錄收集過來的。

Q：如果把行動裝置的整機日誌輸入系統，尤其是行動裝置需要注意哪些問題？產生日誌目前想到有兩種方案：（1）使用APP轉寄給Fluentd（2）使用Syslog，個人感覺第二個更合適，或者還有其他更好的方案嗎？

A：抱歉，我們比較關注的是雲平台伺服器端的日誌，行動裝置的日誌沒有研究過。如果是行動裝置日誌通過伺服器的API上傳到伺服器了，那麼就是一樣的處理。一般我們的理解，行動裝置的日誌是通過應用自己的一些日誌程式，定期壓縮發送到伺服器或者第三方的日誌手機平台，然後在伺服器端，當作普通的伺服器應用日誌來處理，只不過要打上行動裝置和使用者的相關Tag。

Q：Elasticsearch是可以設定備份周期的時間吧？如果我想保留一個月的日誌來進行查詢？

A：可以設定。但是要通過自己的指令碼或者crontab任務來實現。ES目前主要提供的是通過REST API建立、刪除備份和通過保留的備份恢複某個叢集。

Q：Fluentd可否設定收集容器應用指定目錄日誌（非標準輸出目錄），怎麼設定？

A：容器應用目錄在容器內，Fluentd是收集不到的，除非你的輸出目錄也是外部掛載的的共用目錄。如果是一個單純Docker Engine管理的節點，可以通過--volumn-from訪問另一個容器儲存的資料，當然這也是在那個容器-v聲明的volumn而不是任意目錄；這種方式對Kubernetes叢集沒什麼協助。

Q：Elasticsearch日誌的保留原則， 怎麼設定呢，是調API刪除還是Elasticsearch內建呢？

A：我們現在用的方式是用時間做索引，然後指令碼定時刪除。

Q：資料節點PVC/PV 掛載的檔案系統是那種呢？實際使用上遇到什麼問題沒有？

A：我們用過的主要是NFS和GlusterFS。最初實現的PV比較弱，PVC不能通過Label與PV匹配，只能通過size和訪問類型匹配，無法準確選擇PV儲存。現在最新Kubernetes支援PVC的selector支援選擇帶有特定Label的PV了。

Q：請問Kubernetes宿主機的日誌是如何收集的？

A：用相應的不同的Fluentd外掛程式，類似的mount到相應的主機日誌目錄即可。現在容器的日誌也是通過主機收集的。

Q：日誌包括容器的捕獲的標準輸出日誌和應用打到記錄檔中的日誌。對於這兩類情境，如何用Fluentd實現新啟動容器的日誌自動探索和收集？

A：對於打到記錄檔中的日誌，原則上建議日誌目錄是主機綁定上的或是共用目錄。日誌的自動探索和收集需要通過fluentd的外掛程式，將指定的目錄的檔案過濾出來，例如標準輸出日誌肯定在主機的/var/lib/docker/containers/container-id/下。我們整合的Fluentd鏡像，已經打包配置好了相應的的外掛程式https://github.com/fabric8io/f ... ilter，可以參考。

Q：我們目前也使用了Fluentd收集容器日誌，收集容器寫到log檔案中的日誌比收集從標準輸出的日誌要慢，請問你們有什麼調優的方法嗎？

A：檔案日誌比標準輸出慢是正常的，調優Fluentd的效能可能要根據Fluentd的說明逐漸積累經驗先定位哪裡慢，再實驗加快方法，跟各種系統的效能調優是同樣的思路。下面這個連結有些調優建議。 http://docs.fluentd.org/articl ... uning

Q：請問如何處理叢集自我恢複機制，比如elasticsearch-master、elasticsearch-client 掛了？

A：我們在Kubernetes叢集中，elasticsearch-master和elasticsearch-client都是以Relication Controller或Replication Set方式啟動的，系統會自動保證服務的高可用。其他叢集也是類似的機制，和一般Web應用的高可用是一樣，要有機制保證重啟服務，要有機製做服務發現和負載平衡，在K8s叢集是靠Relication Controller和Kube-proxy。

Q：請問，在Kubernetes叢集中的每個節點上運行一個Fluentd的容器，這個節點是容器還是部署Docker的節點？

A：這個是主機節點（可能是物理機或虛擬機器），就是Kubernetes的Node，部署Docker的節點。推薦的官方方法，是通過Kubernetes的DaemonSet做部署。當然也可以自己在每個節點上維持自動的啟動指令碼，運行一些每個節點都要啟動的Pod服務。

Q：請問，Kubernetes的master是單點的，你們是否有最佳化過，現在1.3了，你們平台升級是否是熱部署？

A：我們是用podmaster做至少3節點master高可用部署，api-server是多活的，controllermanager 和schedule是1活2備。平台升級現在是手動的，不會影響運行中的服務。但是現在平台升級需要工程師小心翼翼的手動操作，還不是自動化的。

Q：請問Fluentd和Flume除了開發語言不一樣，有什麼本質上的區別？以及ES日索引的分區數量建議是？

A：Fluentd和Flume的設計理念是類似的，一個用CRuby，一個用JRuby，與Fluentd和Logstash的情況類似，Fluentd的鏡像會小一些，運行時記憶體消耗會小一些，而Flume的鏡像因為要打包JDK差不多要幾百兆。在圍繞容器的Linux環境中，Java的跨平台性本身帶來不了特別大優勢，反而Fluentd鏡像小的優勢更加明顯。另外一個對我們的系統實踐意義比較大，就是fluentd跟Kubernetes叢集的方案做的簡單明了。ES預設的shards數是5，一般的叢集情況要根據使用方式測一下，對於不同的index，這個shards數可以是不一樣的。Shards的個數盡量不設1吧，設1的話，將來想要增加分區時，移動的資料量太大了。在沒有很充分的生產測試經驗之前，設定2到5比較好。

以上內容根據2016年7月28日晚群分享內容整理。分享人 王昕，清華大學通訊碩士，ISC2認證資訊系統安全專家（CISSP），資深架構師和軟體開發專家。曾任VMware、IBM進階研發經理，BEA、Lucent進階工程師，從事十餘年企業中介軟體、PaaS平台和SDN等產品的研發工作，有十多項美國和中國的在審專利發明。現為輕元首席架構師。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加：liyingjiesz，進群參與，您有想聽的話題或者想分享的話題都可以給我們留言。

• docker-elasticsearch-kubernetes.docx