ElasticSearch容器化从0到1实践（三）

容器化从0到1实践（三）"/>

ElasticSearch容器化从0到1实践（三）

文章目录

• 部署Elasticsearch
• • Elasticserch 样例
• Elasticserch历史环境及痛点
• 关键问题点方案落地
• • ES集群是否启动TLS/ES是否启动认证
  • ES节点角色拆分方式
  • 参考文档

上一节说到了ECK落地的26个关键问题，这一节将对这26个关键点的实施进行详细的说明，并给出符合业务的合理建议。

另外如果你认真看了上一节提到的26个关键问题，并且也对这些关键点表示认同的话，本节一定要细细品鉴，我自认为可以让你收获巨大。

部署Elasticsearch

Elasticserch 样例

在正式开始之前，首先通过官方的示例来创建Elasticsearch集群，简单了解下大概的流程。

cat <<EOF | kubectl apply -f -
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:name: quickstart
spec:version: 8.10.3nodeSets:- name: defaultcount: 1config:node.store.allow_mmap: false
EOF

观察es服务的启动情况

kubectl get pod | grep es
kubectl get es

至此，一个简单的Es集群就在K8S集群中跑起来了。

但是，这远远还不够，真真在生产环境中使用还会涉及到很多问题，这里先简单描述下现有环境以及需要兼容的问题。

Elasticserch历史环境及痛点

现有环境问题整理，如下

	说明	痛点	备注
环境	存在测试、开发、灰度、生产等多套环境	环境复杂，维护成本较高
部署方式	ansible方式部署、采用Ecs+数据云盘方式	有部署门槛，资源碎片严重，维护成本较高
数据管理方式	数据云盘	扩容、更换都需要手动操作
流量接入	直连IP + 默认端口	方式不统一、对业务透明度差
Elasticsearch认证	无认证	不安全	都为内网调用，可以接受
集群版本	6+、7+	版本不统一、多个小版本存在
进程管理方式	无	依赖告警发现进程问题， 无法自愈
配置管理	无	配置混乱，无法复用

根据现有服务现状以及痛点问题， 通过容器化一次性解决，接下来对关键点问题逐步处理，给出合理方案。

关键问题点方案落地

ES集群是否启动TLS/ES是否启动认证

通过ECK方式启动的集群默认会开启TLS，用户在访问时需要通过证书连接。基于现有网络环境及当前的使用方式，决定维持现有状态关闭TLS和认证，在配置文件中增加下面2处配置即可。

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:name: quickstartnamespace: elasticsearch
spec:version: 7.13.0http: # 指定协议类型tls:selfSignedCertificate:disabled: truenodeSets:- name: defaultcount: 1config:node.store.allow_mmap: falsexpack.security.enabled: false # 关闭xpack认证

具体配置管理方式及逻辑可以参考源码进行分析，参考文档：=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22133925528%22%2C%22source%22%3A%22u012881331%22%7D

ES节点角色拆分方式

让我歇歇…

参考文档

官方安装文档：.8/k8s-deploy-eck.html