【雲計算】K8S DaemonSet 每一個node上都運行一個pod

時間 2019-12-05

標籤雲計算 k8s daemonset 每一個 node 上都運行一個 pod 简体版

原文原文鏈接

Kubernetes容器集羣中的日誌系統集成實踐

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

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

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

易擴展：可以支撐集羣規模的增加github
開銷低：儘可能佔用較少的系統資源docker
入侵小：儘可能不須要改動應用容器和雲平臺系統數據庫
大集中：將全部分佈在各個主機節點上的日誌集中在一塊兒分析和查詢swift
易部署：方便自動化部署到分佈式集羣中api
易定製：方便處理不一樣日誌格式，方便對接不一樣的存儲方式緩存
實效性：日誌在產生以後須要能在短期內便可以進行查看分析服務器
社區活躍：方便將來的維護和更新，方便功能擴展

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的特色：

將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的架構

在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更流行
文檔數據庫：能夠做爲文檔數據庫使用，存儲文檔大數據，日誌大數據
實時數據分析查詢系統：支持大數據量的實時分析查詢
徹底分佈式：可隨着節點數水平擴展存儲量和查詢速度
高可用：能夠自動檢測破壞的分片，自動從新平衡各個節點上存儲的分片數據，可備份冷數據到對象存儲
支持插件擴展：可自定義插件支持不一樣的備份目標

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的對象存儲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這個環境變量做爲資源使用。

Fig11-在Kubernetes集羣中部署Kibana

總體日誌管理系統的架構

在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比較好。

參考資料：

Kubernetes容器集羣中的日誌系統集成實踐：http://oicwx.com/detail/1124477

輕鬆瞭解Kubernetes部署功能：http://www.tuicool.com/articles/qyaIBz