Kubernetes容器叢集中的日誌系統整合實踐
Kubernetes是原生的容器編排管理系統，對於負載均衡、服務發現、高可用、滾動升級、自動伸縮等容器雲平臺的功能要求有原生支援。今天我分享一下我們在Kubernetes叢集中日誌管理的實踐方案。在這個方案中，除了Docker和Kubernetes，主要還涉及的技術包括：Fluentd、Elasticsearch、Kibana和Swift。
Fig00-Kubernetes日誌系統中涉及的技術
評估容器雲平臺日誌系統的標準：
- 易擴充套件：能夠支撐叢集規模的增長
- 開銷低：儘量佔用較少的系統資源
- 入侵小：儘量不需要改動應用容器和雲平臺系統
- 大集中：將所有分佈在各個主機節點上的日誌集中在一起分析和查詢
- 易部署：方便自動化部署到分散式叢集中
- 易定製：方便處理不同日誌格式，方便對接不同的儲存方式
- 實效性：日誌在產生之後需要能在短時間內即可以進行檢視分析
- 社群活躍：方便未來的維護和更新，方便功能擴充套件
Fluentd是一個實時日誌收集系統，它把JSON作為日誌的中間處理格式，通過靈活的外掛機制，可以支援豐富多樣的日誌輸入應用、輸出應用、以及多種日誌解析、快取、過濾和格式化輸出機制。
Fluentd的架構
Fluentd將JSON作為資料處理的中間格式，通過外掛式的架構可擴充套件地支援不同種應用或系統作為日誌源和日誌輸出端。假設有M種輸入源Wordpress、MySQL、Tomcat……；N種輸出端MySQL、MongoDB、ElasticSearch……那麼處理日誌的程式碼模組由MxN減少為M+N。我們在Kubernetes叢集中收集日誌主要用到https://hub.docker.com/r/fabric8/fluentd-kubernetes/這個映象和https://github.com/fabric8io/docker-fluentd-kubernetes這個Plugins。
Fig01-Fluend架構
Fig02-Fluentd功能
Fluentd的特點：
- 將JSON作為統一的中間層日誌格式做日誌處理
- 基於Ruby的日誌收集工具：較基於JRuby的Logstash的Footprint小
- 相容的輸入源輸出端基本和Logstash相當
- 效能相關的部分為C程式碼：速度較快
- 支援外掛擴充套件：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中有三類節點：第一類是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等共享儲存。
Fig06-Elasticsearch的架構
ElasticSearch在Kubernetes中的部署架構
我們在Kubernetes中，三類節點都是一個包含同一個映象Pod
elasticsearch-cloud-kubernetes，區別只是啟動時的環境role不一樣。查詢和索引節點需要提供對外的Web服務，需要釋出為一個Kubernetes Service。資料節點需要繫結一個持久化儲存，我們用Kubernetes PV創建出儲存卷，資料節點上面通過Kubernetes PVC繫結到相應的資料卷。PV的實際儲存可以是NFS、GlusterFS等共享儲存。
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的物件儲存Swift作為備份。
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在Kubernetes中的部署
Kibana跟ElasticSearch的整合相對來說比較直觀，利用https://hub.docker.com/r/fabric8/kibana4/映象，設定好ELASTICSEARCH_URL引數就可以，Kibana是一個部署在Kubernetes叢集中的Web前端服務，而它引用ELASTICSEARCH_URL這個環境變數作為資源使用。
整體日誌管理系統的架構
在Kubernetes叢集中的每個節點上執行一個Fluentd的容器，收集容器的日誌傳送給到ElasticSearch叢集中。ElasticSearch叢集會儲存一週的日誌作為熱資料以供實時分析和查詢，使用者可以通過Kibana檢視任意Node、Namespace、Service、Pod和容器的資料。對於超過一週的日誌資料，ElasticSearch會自動備份到Swift物件儲存的相應Bucket中。
Fig12-整體Kubernetes日誌管理系統的架構
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/fluent-plugin-kubernetes_metadata_filter，可以參考。
Q：我們目前也使用了Fluentd收集容器日誌，收集容器寫到log檔案中的日誌比收集從標準輸出的日誌要慢，請問你們有什麼調優的方法嗎？
A：檔案日誌比標準輸出慢是正常的，調優Fluentd的效能可能要根據Fluentd的說明逐漸積累經驗先定位哪裡慢，再試驗加快方法，跟各種系統的效能調優是同樣的思路。下面這個連結有些調優建議。http://docs.fluentd.org/articles/performance-tuning
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比較好。
文/王昕
文章出處：Docker