在kubernetes集羣中部署efk

本文將介紹在kubernetes 1.9集羣下配置elasticsearch、fluentd、kibana集中收集k8s集羣日誌信息。俗稱EFK，其中elasticsearch負責存儲日誌。fluentd負責將集羣中docker主機上的日誌發送給elasticsearch，所以fluentd在k8s集羣中須要以daemonset的方式運行。kibana負責圖形化展現日誌信息。

1、環境介紹
軟件環境：
K8s版本：1.9.0
docker版本：17.03.2-ce
Elasticsearch版本及鏡像下載地址：k8s.gcr.io/elasticsearch:v5.6.4
Kibana版本及鏡像下載地址：docker.elastic.co/kibana/kibana:5.6.4
Fluentd版本及鏡像下載地址：gcr.io/google-containers/fluentd-elasticsearch:v2.0.4

Master節點：
主機名：vm1
IP地址：192.168.115.5/24

Node節點：
主機名：vm2
IP地址：192.168.115.6/24


2、下載yaml文件和elasticsearch、fluentd、kibana對應版本的鏡像。
鏡像的下載須要使用方式實現。
Yaml文件下載地址：
https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/fluentd-elasticsearch

# mkdir efk
# cd efk/
# wget  \
https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml
# wget  \
https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/fluentd-elasticsearch/es-service.yaml
# wget  \
https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/fluentd-elasticsearch/fluentd-es-configmap.yaml
# wget  \
https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml
# wget  \
https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/fluentd-elasticsearch/kibana-service.yaml
# wget  \
https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml

3、經過下載好的yaml文件建立configmap、service、serviceaccount、clusterrole以及deployment等

經過dashboard面板上能夠看到fluentd在vm1和vm2上都有運行。

到這裏爲止，看上去一切好像都挺正常的。但是過來一會elasticsearch-loggin-0、elasticsearch-loggin-1兩個pod不斷的restart, vmware的終端console上能夠看出是由於java的oom引發的

此時筆記本的內存已消耗90%、磁盤活動時間已達100%。即便硬盤是pcie的ssd也經不起這樣折騰。

若是把es-statefulset.yaml的replicas參數修改成1，內存是將將夠，可是elasticsearch集羣又是斷腿的，運行不起來。

# kubectl logs elasticsearch-logging-0  -n kube-system

既然筆記本資源不足，爲了完成這個實驗。只好選擇使用臺式機了，幸虧個人臺式機有16G的內存，SSD硬盤也夠放的下虛擬機文件。

4、將vm1和vm2虛擬機文件從筆記本中複製到臺式機後啓動k8s集羣，並進行重建。

觀察了一會，發現全部的pod狀態都正常，不會出現oom問題自動restart


5、訪問kibana和elasticsearch驗證
接下來咱們臨時開啓api-server http協議的8888端口，用於測試kibana的訪問

# kubectl  proxy --address='192.168.115.5' --port=8888 --accept-hosts='^*$' &

訪問地址：
http://192.168.115.5:8888/api/v1/proxy/namespaces/kube-system/services/kibana-logging/


經過curl查看elasticsearch容器中信息，這裏能夠運行一個curl容器，或者直接用elasticsearch-logging-1容器

# kubectl exec -it curl -n kube-system /bin/sh
# curl http://elasticsearch-logging:9200
# curl -XGET http://elasticsearch-logging:9200/_cat

查看elasticsearch集羣的健康狀態、索引和節點信息

# curl -XGET http://elasticsearch-logging:9200/_cluster/health?pretty=true
# curl -XGET http://elasticsearch-logging:9200/_cat/indices?v
# curl -XGET http://elasticsearch-logging:9200/_cat/nodes?v

到目前爲止，咱們實現了在k8s集羣中使用efk進行日誌的集中管理。

6、一些問題
一、Elasticsearch java oom問題
這個在前文已經說明過了，解決方案只有加資源一條路。
這問題通常出如今咱們學習和測試環境中，生產環境通常不會遇到這種問題。
經過查看elasticsearch容器能夠看到實際上每一個pod上的jvm參數設置啓動內存和最大內存均爲2g，加上metaspace等，建議在生產環境，運行elasticsearch的節點至少要保證elasticsearch pod有3g以上的內存。

二、軟件版本兼容性問題
實驗過程當中有嘗試過使用其餘的鏡像搭配github上下載的yaml文件，最終證實了一切都是徒勞。

Kibana和elasticsearch的版本要能對應的上，在本文中使用的都是5.6.4版本

經過訪問kibana的地址，看樣子是沒找到索引文件。
實際上此問題的緣由是fluentd鏡像的版本不配合，沒法往elasticsearch集羣中寫入數據。

網絡上有五花八門的配置文檔，在這裏建議使用github上最新版本的yaml文件搭配yaml文件中的鏡像，能夠少走一些彎路。若是實在沒法下載到gcr.io上的鏡像，可使用github上配套的dockerfile，本身build鏡像。

三、安全性問題
在本文中，elasticsearch的數據是經過emptyDir方式保存的，若是要在生產環境中使用，須要將數據存儲修改爲其餘的存儲方案。
Kibana的訪問形式在本文中是使用api-server的http接口，在生產環境中，須要使用其餘方式實現。

四、耐心等待
須要足夠的耐心，在下載image或者使用dockerfile build都須要較長的時間。elasticsearch和kibana初始化也須要20分鐘左右的等待時間。能夠經過觀察pod的日誌查看整個過程是否存在異常。

鏡像及yaml文件百度雲下載地址
連接：https://pan.baidu.com/s/1snt75Pr 密碼：wu3s