ES集群中，某個data/master/client節點掛了之后，分別該怎么辦？
PS：我的環境中，所有data節點都是client，不會獨立部署client。

• 如果獨立部署client，那么client掛了recreate一個新的即可，注意要清理舊的/data數據。
• master /data保存集群元數據，某個master down了recreate一個新的即可，新的master node 其實可以利用舊的master node的/data數據，也可以不用。調度上不需要干預。但是建議要清理/data數據。
• data節點掛了后，不允許利用原來的數據進行重啟，需要recreate一個新的空白的data node。調度上需要干預，確保新的這個data node沒有用之前的老的data node的/data數據。其實刪除舊data Node掛了之后，需要清理/data目錄的，新的data node也利用不了老的數據。但是為了防止刪除數據失敗，還是建議調度到不同的服務器。

client和master的/data目錄都有持久化的數據嗎？

• client /data也有元數據信息，作為“smart router”來接受集群請求并轉發。
• master的/data目錄也有集群元數據，不能和data node共享/data目錄。

如何保證data node的HA？跨服務器，跨機架。

• 首先給服務器打上機柜機架的Lable（esaas.hosts.rack=${rack_id}）

• 通過Pod Anti-affinity做Pod調度的反親和性；

  podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- weight: 100podAffinityTerm:labelSelector:matchExpressions:- key: es-cluster-nameoperator: Invalues:- ${es-cluster-name}topologyKey: esaas.hosts.rack=${rack_id}

• 注意使用requiredDuringSchedulingIgnoredDuringExecution類型的pod anti-affinity時，需要k8s admission controller disable LimitPodHardAntiAffinityTopology，否則會默認使用topologyKey: kubernetes.io/hostname，而不能使用自定義topologyKey。

• 線上按照上面的方式進行跨機架部署，在開發測試環境，跨服務器部署就行了，使用topologyKey: kubernetes.io/hostname.

如何設置ES容器的vm屬性vm.max_map_count？

• 通過init container進行設置，要求init contaienr的privilege為true。

• 所有類型的node(client, master, data)都默認使用一樣的vm配置。

  initContainers:- name: init-sysctlimage: busyboximagePullPolicy: IfNotPresentcommand: ["sysctl", "-w", "vm.max_map_count=262144"]securityContext:privileged: true

如何關閉ES swap的配置？

• 方法1：關閉物理服務器的swap；

• 方法2：配置每個ES node的配置項bootstrap.mlockall: true，要求es容器添加CAP_IPC_LOCK，SYS_RESOURCE這兩個Linux Capacity。

  securityContext:privileged: falsecapabilities:add:- IPC_LOCK- SYS_RESOURCE

ES配置項minimum_master_nodes設置也是通過env注入，然后在容器啟動腳本run.sh中重新生成elasticsearch.yml。

• POD中注入環境變量NUMBER_OF_MASTERS；
• 如果集群scale up/down后，可能需要動態設置這個環境變量；
• 個人覺得，不人為設定ES集群的minimum_master_nodes配置項，由ES集群觸發選舉時自己根據master node數動態調整。

修改file descriptors，建議212644（64K）。

• 修改容器內/etc/security/limits.conf, 也應該是需要privilege，或者對應Linux capability。

es data通過K8S StatefulSet部署，每個es data Pod都會通過volumeClaimTemplates創建對應的PV, 將宿主機上的/data/${es_cluster_name}掛載到es data容器內的/data目錄。容器漂移或者recreate時，舊的服務器上es垃圾數據需要做清理。

• HostPath PV支持Recycle這種Reclain Policy。（目前只有HostPath和NFS支持Recycle）
• Recycle —> basic scrub (rm -rf /thevolume/*)

scale down 和 scale up時具體分別該如何操作？

• scale down/up es-clients，直接按照HA的思路進行scale，無需其他操作；
• scale down/up es-masters，按照HA的思路進行scale后，需要調ES接口修改minimum_master_nodes。
• scale down/up es-datas, 按照HA的思路進行scale up后，無需其他操作；scale down時，需要將對應hostpath上的目錄(數據)進行清理。每次縮容只允許減1個es data node，scale down操作前需要檢查：
  • ES集群的監控狀態是green；
  • 確保縮容后，max(index1.replicas, index2.replicas,…) + 1 < data-node-num
  • 其他檢查

某個物理服務器要下線，該如何操作？

• 第3點提到HA方案，可以保證每個服務器上最多只會存在某個ES集群中的單個cient/master/data節點，因此服務器下線最多只會down掉ES集群的單個cient/master/data節點，對于正規的ES集群是不影響的。這種情況，直接在服務器上執行kubectl drain將deployment，StatefulSet pods驅逐出去，并會自動在其他合適的服務器上recreate一個新的cient/master/data節點。ES集群在整個過程中始終保持正常工作。
• 如果用戶部署的是單節點的ES實例，那么按照上面的步驟，必然會導致用戶的數據丟失，ES服務長時間不能用。因此需要對用戶進行風險提示，并建議先進行擴容，然后待新節點同步數據完成后，才能干掉原來的es實例。

某個服務器突然down了，接下來是什么自動流程？

• 服務器down了以后，由于調度部署時考慮了HA，因此不會影響正規的ES集群的使用。
• 接著大概5min(通過pod-eviction-timeout設置)時間，會在新的Node上recreate新的client/master/data容器。這樣就繼續維持原有ES集群的規模。

ES插件的安裝流程？

• CaaS集群內部提供ElastcSearch Plugin倉庫，存放常用插件提供下載；
• 用戶在初始化部署ES集群時可以選擇想要安裝plugins（支持site和jar類型），在init container中下載插件文件到plugin-volume，ES啟動時自動加載這些plugins；
• 如果在ES集群使用過程中用戶想安裝plugins，對于site類型的plugin，調用Kubernetes exec接口下載對應Site plugin文件到對應的插件目錄即可；對于jar類型的plugin，同樣的先現在插件到對應的plugin-volume目錄，由于需要重啟ES實例，通過執行kubectl exec POD_NAME -c CONTAINER_NAME reboot 或者 docker kill $containerName來重啟ES容器而不用recreate Pod。
• 由于多個ES不能共享同一個plugin目錄，因此需要給每個ES實例都劃分獨立的plugin-volume,掛載宿主機上不同的hostpath；
• 對于ES管理類plugin，需要指定插件部署到哪個ES node上（建議部署在某個master node上），后面訪問該plugin只能通過訪問該ES node的plugin API；
• 對于ES功能類plugin（比如ik分詞器），需要在所有ES集群 nodes(client, master, data)上安裝該plugin。
• 安裝jar插件重啟es節點前，必須檢查es集群健康狀態為green。
• es節點重啟時，注意ES的Fault Detection機制，配置discovery.zen.fd.ping_interval(1s), ping_timeout(30s),ping_retries(3)，也就是說默認90s內沒ping通就認為節點失敗，然后進行分片遷移。我們關注這個配置，有需要可以適當調大。
• 討論決定，先只支持jar類型的插件，后續考慮sites類的插件（比如通過ESaaS本地存放sites plugin，所有ES集群共用）

自研ES監控工具如何與ES集群對接？

• 監控工具支持API動態增加ES集群信息，只需要把集群中任一node（client/master/data）的IP和Port(9200)添加到監控工具中，有client就給client的信息，如果只有data node，則給data node的9200到監控工具；
• ESaaS創建ES集群時，配置是否自動添加到監控平臺，如果是，則部署完ES集群后回調監控平臺的”ADD_ES_CLUSTER“接口；
• ESaaS頁面提供到監控平臺的跳轉鏈接，由監控平臺做好監控信息的權限管理。監控添加ES集群時需要帶上用戶的ID。

Kibana服務的部署如何與ES集群對接？

• 初始化部署ES集群時，用戶可以勾選是否一并自動創建對應的Kibana服務；
• 也提供單獨創建Kibana服務的頁面入口，要求用戶選擇對接的ES集群；
• 通過注入環境變量ELASTICSEARCH_URL: http://es-client.namespace-1.svc.pro.es::9200

所有ES nodes的elasticsearch.yaml中的discovery hosts只需要配置master nodes的域名或者IP列表，當然如果配置所有的（client, data, master nodes）IP列表，也不會有異常。

初始化創建ES集群的時候，注意確保成功啟動所有master nodes后，再去創建data nodes。client nodes的創建順序沒有要求。

ES node的JVM內存配置，支持8,16,32g。最大不允許超過32g，否則反而會因為GC問題等導致性能更差。

ES集群的日志收集，接入EFK日志系統。同時提供ES集群各個容器的web console能力，讓用戶能在web console查看（慢）日志等操作。

ES zen discovery我們通過域名(K8S Service Name)來解析es master IP List, 需要注意hosts.resolve_timeout，默認5s。

ES 2.x和5.x，6.x在node角色劃分不一樣，目前我只考了2.x版本，5.x和6.x需做適度調整。

引導檢查

• Heap size check 堆大小檢查
• File descriptor check 文件描述符（文件句柄）檢查

  • 啟動報錯：max file descriptors [65535] for elasticsearch process likely too low, increase to at least [65536]

  • 解決方式：ulimit -n 65536 或者 vi /etc/security/limits.conf

    soft nofile 65536hard nofile 65536
• Memory lock check 內存鎖住檢查
• Maximum number of threads check 線程最大值檢查

  • 啟動報錯：max number of threads [1024] for user [push] is too low, increase to at least [2048]

  • 解決方法：vi /etc/security/limits.d/90-nproc.conf

    soft nproc 2048
• Maximum size virtual memory check 虛擬內存最大值檢查
• Maximum map count check map count最大值檢查

  • 啟動報錯：max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

  • 解決方法：vi /etc/sysctl.conf

    vm.max_map_count=262144sysctl -p
• Client JVM check JVM客戶端檢查
• Use serial collector check
• System call filter check
  • 啟動報錯：system call filters failed to install; check the logs and fix your configuration or disable system call filters at your own risk
  • 解決方法：elasticsearch.yml加上bootstrap.system_call_filter: false
• OnError and OnOutOfMemoryError checks
• Early-access check
• G1GC check G1垃圾回收器檢查

用戶在ESaaS Portal上自助申請ES集群時，除了指定每個nodes的cpu,mem之外，還需要指定需要的本地存儲空間大小，Kubernetes 1.9在調度時需要考慮服務器存儲空間是否能滿足需求。