Kubernetes中怎么實現一個ESaaS架構

Kubernetes中怎么實現一個ESaaS架構，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

1. 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也利用不了老的數據。但是為了防止刪除數據失敗，還是建議調度到不同的服務器。

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

• client /data也有元數據信息，作為“smart router”來接受集群請求并轉發。

• master的/data目錄也有集群元數據，不能和data node共享/data目錄。

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

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

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

  	podAntiAffinity:
  	  requiredDuringSchedulingIgnoredDuringExecution:
  	  - weight: 100
  	    podAffinityTerm:
  	      labelSelector:
  	        matchExpressions:
  	        - key: es-cluster-name
  	          operator: In
  	          values:
  	          - ${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.

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

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

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

  	  initContainers:
  	  - name: init-sysctl
  	    image: busybox
  	    imagePullPolicy: IfNotPresent
  	    command: ["sysctl", "-w", "vm.max_map_count=262144"]
  	    securityContext:
  	      privileged: true

  
  

5. 如何關閉ES swap的配置？

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

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

  	securityContext:
  	  privileged: false
  	  capabilities:
  	    add:
  	      - IPC_LOCK
  	      - SYS_RESOURCE

  
  

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

• POD中注入環境變量NUMBER_OF_MASTERS；

• 如果集群scale up/down后，可能需要動態設置這個環境變量；

• 個人覺得，不人為設定ES集群的minimum_master_nodes配置項，由ES集群觸發選舉時自己根據master node數動態調整。

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

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

8. 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/*)

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

• ES集群的監控狀態是green；

• 確保縮容后，max(index1.replicas, index2.replicas,…) + 1 < data-node-num

• 其他檢查

• 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操作前需要檢查：

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

• 第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實例。

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

• 服務器down了以后，由于調度部署時考慮了HA，因此不會影響正規的ES集群的使用。

• 接著大概5min(通過pod-eviction-timeout設置)時間，會在新的Node上recreate新的client/master/data容器。這樣就繼續維持原有ES集群的規模。

12. 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集群共用）

13. 自研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。

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

• 初始化部署ES集群時，用戶可以勾選是否一并自動創建對應的Kibana服務；

• 也提供單獨創建Kibana服務的頁面入口，要求用戶選擇對接的ES集群；

• 通過注入環境變量ELASTICSEARCH_URL: http://es-client.namespace-1.svc.pro.es::9200

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

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

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

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

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

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

21. 引導檢查

• 啟動報錯：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

• 啟動報錯：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=262144
  	sysctl -p

  
  

• 啟動報錯：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

  
  

• 啟動報錯：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 65536
  	hard nofile 65536

  
  

• Heap size check 堆大小檢查

• File descriptor check 文件描述符（文件句柄）檢查

• Memory lock check 內存鎖住檢查

• Maximum number of threads check 線程最大值檢查

• Maximum size virtual memory check 虛擬內存最大值檢查

• Maximum map count check map count最大值檢查

• Client JVM check JVM客戶端檢查

• Use serial collector check

• System call filter check

• OnError and OnOutOfMemoryError checks

• Early-access check

• G1GC check G1垃圾回收器檢查

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

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。