温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

Kubernetes中怎么实现一个ESaaS架构

发布时间:2021-08-09 13:58:45 来源:亿速云 阅读:106 作者:Leah 栏目:云计算

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在调度时需要考虑服务器存储空间是否能满足需求。

看完上述内容是否对您有帮助呢?如果还想对相关知识有进一步的了解或阅读更多相关文章,请关注亿速云行业资讯频道,感谢您对亿速云的支持。

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI