《Kubernetes容器集群中的日志系統(tǒng)集成實(shí)踐》要點(diǎn):
本文介紹了Kubernetes容器集群中的日志系統(tǒng)集成實(shí)踐,希望對您有用。如果有疑問,可以聯(lián)系我們。
Kubernetes是原生的容器編排管理系統(tǒng),對于負(fù)載均衡、服務(wù)發(fā)現(xiàn)、高可用、滾動(dòng)升級、自動(dòng)伸縮等容器云平臺的功能要求有原生支持.今天我分享一下我們在Kubernetes集群中日志管理的實(shí)踐方案.在這個(gè)方案中,除了Docker和Kubernetes,主要還涉及的技術(shù)包括:Fluentd、Elasticsearch、Kibana和Swift.
Fig00-Kubernetes日志系統(tǒng)中涉及的技術(shù)
評估容器云平臺日志系統(tǒng)的標(biāo)準(zhǔn):
Fluentd是一個(gè)實(shí)時(shí)日志收集系統(tǒng),它把JSON作為日志的中間處理格式,通過靈活的插件機(jī)制,可以支持豐富多樣的日志輸入應(yīng)用、輸出應(yīng)用、以及多種日志解析、緩存、過濾和格式化輸出機(jī)制.
Fluentd將JSON作為數(shù)據(jù)處理的中間格式,通過插件式的架構(gòu)可擴(kuò)展地支持不同種應(yīng)用或系統(tǒng)作為日志源和日志輸出端.假設(shè)有M種輸入源Wordpress、MySQL、Tomcat……;N種輸出端MySQL、MongoDB、ElasticSearch……那么處理日志的代碼模塊由MxN減少為M+N.我們在Kubernetes集群中收集日志主要用到https://hub.docker.com/r/fabric8/fluentd-kubernetes/這個(gè)鏡像和https://github.com/fabric8io/docker-fluentd-kubernetes這個(gè)Plugins.
Fig01-Fluend架構(gòu)
Fig02-Fluentd功能
Fluentd的特點(diǎn):
每個(gè)Node節(jié)點(diǎn)上都要有Fluentd-Elasticsearch這個(gè)Pod,有兩種方式支持:1. 放在/etc/kubernetes/manifest下,用腳本自動(dòng)啟動(dòng);2. 用DaemonSet啟動(dòng).這兩種模式都是為了保證在每一個(gè)Kubernetes集群節(jié)點(diǎn)上都有一個(gè)Fluentd的駐留Pod運(yùn)行來收集日志.Kubernetes中DaemonSet這個(gè)API對象就是為了駐留Pod而設(shè)計(jì)的.
Fig03-Fluentd在Kubernetes集群中的部署架構(gòu)
在Kubernetes集群中部署Fluentd時(shí),可以采用類似下面的YAML文件,將使用Docker鏡像Fluentd-Elasticsearch的Pod部署到每一個(gè)Kubernetes節(jié)點(diǎn)上.
Fig04-Fluentd在Kubernetes集群中的部署YAML
Fluentd pod的運(yùn)行時(shí)狀態(tài):
Fig05-Fluentd在Kubernetes集群中的運(yùn)行狀態(tài)
選用Fluentd的理由:
Elasticsearch是一個(gè)實(shí)時(shí)的分布式搜索和分析引擎.它可以用于文檔存儲,全文搜索,結(jié)構(gòu)化搜索以及實(shí)時(shí)分析,與常見的互聯(lián)網(wǎng)應(yīng)用最典型的應(yīng)用場景是日志分析查詢和全文搜索.
在ElasticSearch中有三類節(jié)點(diǎn):第一類是Data Node,用來存儲數(shù)據(jù),ElasticSearch中對于一份數(shù)據(jù)可以有多個(gè)副本,以提供數(shù)據(jù)高可用能力;第二類是Client Node,或者叫查詢節(jié)點(diǎn),提供對查詢的負(fù)載均衡;第三類是Master Eligible node,或者叫索引節(jié)點(diǎn),這些節(jié)點(diǎn)可以被選舉為Master Node,而Master Node會控制整個(gè)ElasticSearch集群的狀態(tài).
Fig06-Elasticsearch的架構(gòu)
我們在Kubernetes中,三類節(jié)點(diǎn)都是一個(gè)包含同一個(gè)鏡像Pod
elasticsearch-cloud-kubernetes,區(qū)別只是啟動(dòng)時(shí)的環(huán)境role不一樣.查詢和索引節(jié)點(diǎn)需要提供對外的Web服務(wù),需要發(fā)布為一個(gè)Kubernetes Service.數(shù)據(jù)節(jié)點(diǎn)需要綁定一個(gè)持久化存儲,我們用Kubernetes PV創(chuàng)建出存儲卷,數(shù)據(jù)節(jié)點(diǎn)上面通過Kubernetes PVC綁定到相應(yīng)的數(shù)據(jù)卷.PV的實(shí)際存儲可以是NFS、GlusterFS等共享存儲.
Fig06-Elasticsearch的架構(gòu)
我們在Kubernetes中,三類節(jié)點(diǎn)都是一個(gè)包含同一個(gè)鏡像Pod
elasticsearch-cloud-kubernetes,區(qū)別只是啟動(dòng)時(shí)的環(huán)境role不一樣.查詢和索引節(jié)點(diǎn)需要提供對外的Web服務(wù),需要發(fā)布為一個(gè)Kubernetes Service.數(shù)據(jù)節(jié)點(diǎn)需要綁定一個(gè)持久化存儲,我們用Kubernetes PV創(chuàng)建出存儲卷,數(shù)據(jù)節(jié)點(diǎn)上面通過Kubernetes PVC綁定到相應(yīng)的數(shù)據(jù)卷.PV的實(shí)際存儲可以是NFS、GlusterFS等共享存儲.
Fig08-ElasticSearch與傳統(tǒng)數(shù)據(jù)庫的對比
在Kubernetes集群中部署ElasticSearch,我們會部署類似圖中的3種節(jié)點(diǎn):es-data類是用來存放索引數(shù)據(jù)的;es-master類是用來提供索引寫服務(wù)的;es-client是用來提供索引查詢服務(wù)的.
Fig09-ElasticSearch在Kubernetes集群中的部署
在部署es-data節(jié)點(diǎn)的時(shí)候,他們的數(shù)據(jù)卷我們是以共享存儲卷掛載的,這里采用PVC/PV的模式掛載一個(gè)NFS的PV提供數(shù)據(jù)卷,如下圖所示.
Fig10-ElasticSearch數(shù)據(jù)在Kubernetes集群中的持久化存儲
ElasticSearch允許對于單個(gè)索引或整個(gè)集群做備份和恢復(fù).備份恢復(fù)所支持的目標(biāo)存儲倉庫類型包括:
S3倉庫:將AWS S3作為備份倉庫
安裝命令:
sudo?bin/elasticsearch-plugin?install?repository-s3
創(chuàng)建倉庫示例:
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
創(chuàng)建倉庫示例:
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
創(chuàng)建倉庫示例:
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
創(chuàng)建倉庫示例:
PUT?_snapshot/my-gcs-repository-1 { "type":?"gcs", "settings":?{ "bucket":?"my_bucket", "service_account":?"_default_" } }
作為私有云部署的環(huán)境,多數(shù)基于OpenStack的IaaS層,可以采用OpenStack的對象存儲Swift作為備份.
Swift倉庫:將OpenStack Swift作為備份倉庫
安裝命令:
sudo?bin/elasticsearch-plugin?install?org.wikimedia.elasticsearch.swift/swift-repository-plugin/2.1.1 創(chuàng)建倉庫示例: 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的理由:
Kibana跟ElasticSearch的集成相對來說比較直觀,利用https://hub.docker.com/r/fabric8/kibana4/鏡像,設(shè)置好ELASTICSEARCH_URL參數(shù)就可以,Kibana是一個(gè)部署在Kubernetes集群中的Web前端服務(wù),而它引用ELASTICSEARCH_URL這個(gè)環(huán)境變量作為資源使用.
在Kubernetes集群中的每個(gè)節(jié)點(diǎn)上運(yùn)行一個(gè)Fluentd的容器,收集容器的日志發(fā)送給到ElasticSearch集群中.ElasticSearch集群會保存一周的日志作為熱數(shù)據(jù)以供實(shí)時(shí)分析和查詢,用戶可以通過Kibana查看任意Node、Namespace、Service、Pod和容器的數(shù)據(jù).對于超過一周的日志數(shù)據(jù),ElasticSearch會自動(dòng)備份到Swift對象存儲的相應(yīng)Bucket中.
Fig12-整體Kubernetes日志管理系統(tǒng)的架構(gòu)
Q:請問Kubernetes宿主機(jī)的日志是如何收集的?
A:跟收集容器的日志是類似的,事實(shí)上容器的日志也是從主機(jī)的日志目錄收集過來的.
Q:如果把移動(dòng)設(shè)備的整機(jī)日志輸入系統(tǒng),尤其是移動(dòng)設(shè)備需要注意哪些問題?產(chǎn)生日志目前想到有兩種方案:(1)使用APP轉(zhuǎn)發(fā)給Fluentd(2)使用Syslog,個(gè)人感覺第二個(gè)更合適,或者還有其他更好的方案么?
A:抱歉,我們比較關(guān)注的是云平臺服務(wù)器端的日志,移動(dòng)設(shè)備的日志沒有研究過.如果是移動(dòng)設(shè)備日志通過服務(wù)器的API上傳到服務(wù)器了,那么就是一樣的處理.一般我們的理解,移動(dòng)設(shè)備的日志是通過應(yīng)用自己的一些日志程序,定期壓縮發(fā)送到服務(wù)器或者第三方的日志手機(jī)平臺,然后在服務(wù)器端,當(dāng)作普通的服務(wù)器應(yīng)用日志來處理,只不過要打上移動(dòng)設(shè)備和用戶的相關(guān)Tag.
Q:ElasticSearch是可以設(shè)置備份周期的時(shí)間吧?如果我想保留一個(gè)月的日志來進(jìn)行查詢?
A:可以設(shè)置.但是要通過自己的腳本或者crontab任務(wù)來實(shí)現(xiàn).ES目前主要提供的是通過REST API創(chuàng)建、刪除備份和通過保留的備份恢復(fù)某個(gè)集群.
Q:Fluentd可否設(shè)置收集容器應(yīng)用指定目錄日志(非標(biāo)準(zhǔn)輸出目錄),怎么設(shè)置?
A:容器應(yīng)用目錄在容器內(nèi),Fluentd是收集不到的,除非你的輸出目錄也是外部掛載的的共享目錄.如果是一個(gè)單純Docker Engine管理的節(jié)點(diǎn),可以通過–volumn-from訪問另一個(gè)容器存儲的數(shù)據(jù),當(dāng)然這也是在那個(gè)容器-v聲明的volumn而不是任意目錄;這種方式對Kubernetes集群沒什么幫助.
Q:ElasticSearch日志的保留策略, 怎么設(shè)置呢,是調(diào)API刪除還是ElasticSearch自帶呢?
A:我們現(xiàn)在用的方式是用時(shí)間做索引,然后腳本定時(shí)刪除.
Q:數(shù)據(jù)節(jié)點(diǎn)PVC/PV 掛載的文件系統(tǒng)是那種呢?實(shí)際使用上遇到什么問題沒有?
A:我們用過的主要是NFS和GlusterFS.最初實(shí)現(xiàn)的PV比較弱,PVC不能通過Label與PV匹配,只能通過size和訪問類型匹配,無法準(zhǔn)確選擇PV存儲.現(xiàn)在最新Kubernetes支持PVC的selector支持選擇帶有特定Label的PV了.
Q:請問Kubernetes宿主機(jī)的日志是如何收集的?
A:用相應(yīng)的不同的Fluentd插件,類似的mount到相應(yīng)的主機(jī)日志目錄即可.現(xiàn)在容器的日志也是通過主機(jī)收集的.
Q:日志包括容器的捕獲的標(biāo)準(zhǔn)輸出日志和應(yīng)用打到日志文件中的日志.對于這兩類場景,如何用Fluentd實(shí)現(xiàn)新啟動(dòng)容器的日志自動(dòng)發(fā)現(xiàn)和收集?
A:對于打到日志文件中的日志,原則上建議日志目錄是主機(jī)綁定上的或是共享目錄.日志的自動(dòng)發(fā)現(xiàn)和收集需要通過fluentd的插件,將指定的目錄的文件過濾出來,例如標(biāo)準(zhǔn)輸出日志肯定在主機(jī)的/var/lib/docker/containers/container-id/下.我們集成的Fluentd鏡像,已經(jīng)打包配置好了相應(yīng)的的插件https://github.com/fabric8io/fluent-plugin-kubernetes_metadata_filter,可以參考.
Q:我們目前也使用了Fluentd收集容器日志,收集容器寫到log文件中的日志比收集從標(biāo)準(zhǔn)輸出的日志要慢,請問你們有什么調(diào)優(yōu)的方法嗎?
A:文件日志比標(biāo)準(zhǔn)輸出慢是正常的,調(diào)優(yōu)Fluentd的性能可能要根據(jù)Fluentd的說明逐漸積累經(jīng)驗(yàn)先定位哪里慢,再試驗(yàn)加快方法,跟各種系統(tǒng)的性能調(diào)優(yōu)是同樣的思路.下面這個(gè)鏈接有些調(diào)優(yōu)建議.http://docs.fluentd.org/articles/performance-tuning
Q:請問如何處理集群自我恢復(fù)機(jī)制,比如elasticsearch-master、elasticsearch-client 掛了?
A:我們在Kubernetes集群中,elasticsearch-master和elasticsearch-client都是以Relication Controller或Replication Set方式啟動(dòng)的,系統(tǒng)會自動(dòng)保證服務(wù)的高可用.其他集群也是類似的機(jī)制,和一般Web應(yīng)用的高可用是一樣,要有機(jī)制保證重啟服務(wù),要有機(jī)制做服務(wù)發(fā)現(xiàn)和負(fù)載均衡,在K8s集群是靠Relication Controller和Kube-proxy.
Q:請問,在Kubernetes集群中的每個(gè)節(jié)點(diǎn)上運(yùn)行一個(gè)Fluentd的容器,這個(gè)節(jié)點(diǎn)是容器還是部署Docker的節(jié)點(diǎn)?
A:這個(gè)是主機(jī)節(jié)點(diǎn)(可能是物理機(jī)或虛擬機(jī)),就是Kubernetes的Node,部署Docker的節(jié)點(diǎn).推薦的官方方法,是通過Kubernetes的DaemonSet做部署.當(dāng)然也可以自己在每個(gè)節(jié)點(diǎn)上維持自動(dòng)的啟動(dòng)腳本,運(yùn)行一些每個(gè)節(jié)點(diǎn)都要啟動(dòng)的Pod服務(wù).
Q:請問,Kubernetes的master是單點(diǎn)的,你們是否有優(yōu)化過,現(xiàn)在1.3了,你們平臺升級是否是熱部署?
A:我們是用podmaster做至少3節(jié)點(diǎn)master高可用部署,api-server是多活的,controllermanager 和schedule是1活2備.平臺升級現(xiàn)在是手動(dòng)的,不會影響運(yùn)行中的服務(wù).但是現(xiàn)在平臺升級需要工程師小心翼翼的手動(dòng)操作,還不是自動(dòng)化的.
Q:請問Fluentd和Flume除了開發(fā)語言不一樣,有什么本質(zhì)上的區(qū)別?以及ES日索引的分片數(shù)量建議是?
A:Fluentd和Flume的設(shè)計(jì)理念是類似的,一個(gè)用CRuby,一個(gè)用JRuby,與Fluentd和Logstash的情況類似,Fluentd的鏡像會小一些,運(yùn)行時(shí)內(nèi)存消耗會小一些,而Flume的鏡像因?yàn)橐虬麶DK差不多要幾百兆.在圍繞容器的Linux環(huán)境中,Java的跨平臺性本身帶來不了特別大優(yōu)勢,反而Fluentd鏡像小的優(yōu)勢更加明顯.另外一個(gè)對我們的系統(tǒng)實(shí)踐意義比較大,就是fluentd跟Kubernetes集群的方案做的簡單明了.ES默認(rèn)的shards數(shù)是5,一般的集群情況要根據(jù)使用情況測一下,對于不同的index,這個(gè)shards數(shù)可以是不一樣的.Shards的個(gè)數(shù)盡量不設(shè)1吧,設(shè)1的話,將來想要增加分片時(shí),移動(dòng)的數(shù)據(jù)量太大了.在沒有很充分的生產(chǎn)測試經(jīng)驗(yàn)之前,設(shè)置2到5比較好.
文/王昕
文章出處:Docker
轉(zhuǎn)載請注明本頁網(wǎng)址:
http://www.fzlkiss.com/jiaocheng/4457.html