《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/fabric8/fluentd-kubernetes/這個鏡像和https://github.com/fabric8io/docker-fluentd-kubernetes這個Plugins.

Fig01-Fluend架構

Fig02-Fluentd功能

Fluentd的特點：

1. 將JSON作為統一的中間層日志格式做日志處理
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等共享存儲.

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

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&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/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

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4457.html