基于Kubernetes的ESaaS架构及实现细节(一)
基于Kubernetes的ESaaS架构及实现细节(一)
WaltonWang 发表于4个月前
基于Kubernetes的ESaaS架构及实现细节(一)
  • 发表于 4个月前
  • 阅读 945
  • 收藏 14
  • 点赞 3
  • 评论 0

移动开发云端新模式探索实践 >>>   

摘要: ESaaS(ElasticSearch as a Service)是ElasticSearch on Kubernetes的产品实现,是利用Docker和Kubernetes等容器虚拟化和编排调度系统,将ElasticSearch抽象为CaaS(Container as a Service)平台上的一种服务,实现秒级创建和扩缩容一个用户自定义的ElasticSerach集群,并且保证高可用和数据安全等方面。本文是基于LocalDisk构建ESaaS的架构探索,下一篇介绍这个方案需要注意和考虑的关键实现细节。

概述

ESaaS(ElasticSearch as a Service)是ElasticSearch on Kubernetes的产品实现,是利用DockerKubernetes等容器虚拟化和编排调度系统,将ElasticSearch抽象为CaaS(Container as a Service)平台上的一种服务,实现秒级创建和扩缩容一个用户自定义的ElasticSerach集群,并且保证高可用和数据安全等方面。

关键组件

  • ElasticSearch 2.x
  • Kubernetes 1.9
  • Docker 1.12.6

解决的痛点:

  • ES集群初始化部署周期长,从申请服务器到交付,可能需要数天。
  • 部署过程自动化程度不高,开发测试环境中纯手动部署,线上半自动化部署,经常出错需要调测环境。
  • 集群的扩容也是人为操作,效率低且容易犯错。
  • ES服务器经常面临资源浪费的情况。
  • 各种插件的安装麻烦,并且有些需要重启节点,人为操作不当会带来风险。
  • 没有提供完善的ES集群和服务器的监控告警方案。
  • 没有提供配套的Kibana服务,人工部署Kibana并对接ES效率低。
  • ES集群之间没做资源隔离,机架机柜的物理隔离等。
  • 没有接入日志系统,查看系统和ES集群日志很不方便。

目标

  • 集群统一管理Portal,提供ES集群自助申请和集群信息看板;
  • 提供用户配额管理;
  • 秒级扩容缩容;
  • 完整的平台和ES集群监控和告警能力;
  • 提供统一的ES集群配置修改入口;
  • 外围插件的自助部署;
  • 节点的自助安全重启等;

架构

高可用部署架构

输入图片说明

必要说明

  • ESaaS Portal提供用户云上自助申请ES集群和运维的入口,ESaaS做好相关业务逻辑能力,最终调用后端Kubernetes API进行ES集群的创建和管理;ESaaS Portal要求对接权限管理系统,进行用户登录验证和权限控制;
  • 为了保证ElasticSearch集群的高可用,在开发测试环境,要求同一个ES集群的同一个role(比如client/master/data)的ES nodes不能有多个部署在同一台服务器上;在生产环境,以上情况则要求跨机架部署;
  • ES集群在Kubernetes中目前均考虑使用本地存储,不用分布式存储;
  • ES集群的data node Pod需要挂载两个hostpath volume,分别为存储data的data volume和存储ES plugin的plugin volume,对应服务器上的hostpath /es/$cluser-name/data/data/es/$cluser-name/data/plugin;
  • ES集群的master和client node Pod需要挂载一个hostpath volume,存储ES plugin的plugin volume,对应服务器上的hostpath /es/$cluser-name/client(or master)/plugin;
  • ESaaS平台提供Apache httpd服务用于托管常用插件,称为ES Plugin Repository,目前优先考虑托管jar类型plugin。某个ES集群要给某个或者某些ES nodes安装jar plugins时,将从ES Plugin Repository中下载plugin文件到对应的/es/$cluser-name/client(or data,master)/plugin;

逻辑架构

输入图片说明

必要说明

  • 每个ES集群的data nodes的部署通过一个Kubernetes StatefulSet来管理;

  • 每个ES集群的master nodes的部署通过一个Kubernetes Deployment来管理,并通过一个Kubernetes Headless Service来做master nodes的反向代理,这样在KubeDNS中该Headless Service Name对应解析到每个ES master nodes Pod的IP地址;

  • 每个ES集群的client nodes的部署通过Kubernetes Deployment来管理,并通过一个Kubernetes NodePort Service来做client nodes的反向代理(后续ES集群数多了后,考虑使用Ingress Nginx来代理ES client),每个ES集群对外暴露$Client-IP:$NodePort;

  • 同一个ES集群中所有nodes的elasticsearch.yml均使用如下规则的部分配置:

    	cluster.name: "elasticsearch-${NAMESPACE}"
    
    	node.name: "${POD_NAME}-${NAMESPACE}"
    
    	network.host: ${POD_IP}
    
    	# hosts填写ES master的Headless Service Name
    	discovery.zen.ping.unicast.hosts: “es-${NAMESPACE}”
    

在下一篇博文 ESaaS架构及实现细节(二) 中将介绍这个方案需要注意和考虑的关键实现细节,内容涉及二十多项。

  • 打赏
  • 点赞
  • 收藏
  • 分享
共有 人打赏支持
粉丝 148
博文 86
码字总数 176224
×
WaltonWang
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: