摘要：ES叢集是進行大資料存儲和分析，快速檢索的利器，本文簡述了ES的叢集架構，并提供了在Kubernetes中快速部署ES叢集的樣例；對ES叢集的監控運維工具進行了介紹，并提供了部分問題定位經驗，最後總結了常用ES叢集的API調用方法。
本文分享自華為雲社群《Kubernetes中部署ES叢集及運維》，原文作者：minucas。
ES叢集分為單點模式和叢集模式，其中單點模式一般在生産環境不推薦使用，推薦使用叢集模式部署。其中叢集模式又分為Master節點與Data節點由同一個節點承擔，以及Master節點與Data節點由不同節點承擔的部署模式。Master節點與Data節點分開的部署方式可靠性更強。下圖為ES叢集的部署架構圖：
1、采用k8s statefulset部署，可快速的進行擴縮容es節點，本例子采用 3 Master Node + 12 Data Node 方式部署
2、通過k8s service配置了對應的域名和服務發現，確定叢集能自動聯通和監控
工欲善其事必先利其器，中間件的運維首先要有充分的監控手段，ES叢集的監控常用的三種監控手段：exporter、eshead、kopf，由于ES叢集是采用k8s架構部署，很多特性都會結合k8s來開展
通過k8s部署es-exporter将監控metrics導出，prometheus采集監控資料，grafana定制dashboard展示
github位址：https://github.com/mobz/elasticsearch-head
ES-head元件可通過谷歌浏覽器應用商店搜尋安裝，使用Chrome插件可檢視ES叢集的情況
github位址：https://github.com/lmenezes/cerebro
資源配置：關注ES的CPU、Memory以及Heap Size，Xms Xmx的配置，建議如機器是8u32g記憶體的情況下，堆記憶體和Xms Xmx配置為50%，官網建議單個node的記憶體不要超過64G
索引配置：由于ES檢索通過索引來定位，檢索的時候ES會将相關的索引資料裝載到記憶體中加快檢索速度，是以合理的對索引進行設定對ES的性能影響很大，目前我們通過按日期建立索引的方法（個别資料量小的可不分割索引）
CPU和Load比較高的節點重點關注，可能的原因是shard配置設定不均勻，此時可手動講不均衡的shard relocate一下
shard配置最好是data node數量的整數倍，shard數量不是越多越好，應該按照索引的資料量合理進行分片，確定每個shard不要超過單個data node配置設定的堆記憶體大小，比如資料量最大的index單日150G左右，分為24個shard，計算下來單個shard大小大概6-7G左右
副本數建議為1，副本數過大，容易導緻資料的頻繁relocate，加大叢集負載
索引名可使用進行正則比對進行批量删除，如：-2021.05.*
在定位問題的時候發現節點資料shard已經移走但是節點負載一直下不去，登入節點使用top指令發現節點kubelet的cpu占用非常高，重新開機kubelet也無效，重新開機節點後負載才得到緩解
ES叢集的健康狀态分為三種：Green、Yellow、Red。
Green(綠色)：叢集健康；
Yellow(黃色)：叢集非健康，但在負載允許範圍内可自動rebalance恢複；
Red(紅色)：叢集存在問題，有部分資料未就緒，至少有一個主分片未配置設定成功。
可通過API查詢叢集的健康狀态及未配置設定的分片：
其中 priority 字段則表示該 task 的優先級
其中reason 字段表示哪種原因導緻的分片未配置設定，detail 表示詳細未配置設定的原因
其中node為es叢集節點的id，可以通過curl ‘ip:port/_node/process?pretty’ 進行查詢
點選關注，第一時間了解華為雲新鮮技術~