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

文章目录

部署Elasticsearch
- [Elasticserch 样例](#Elasticserch 样例)
Elasticserch历史环境及痛点
关键问题点方案落地

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

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

部署Elasticsearch

Elasticserch 样例

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

Bash 复制代码

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

观察es服务的启动情况

Bash 复制代码

kubectl get pod | grep es
kubectl get es

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

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

Elasticserch历史环境及痛点

现有环境问题整理，如下

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

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

关键问题点方案落地

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

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

YAML 复制代码

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

具体配置管理方式及逻辑可以参考源码进行分析，参考文档：https://blog.csdn.net/u012881331/article/details/133925528?csdn_share_tail={"type"%3A"blog"%2C"rType"%3A"article"%2C"rId"%3A"133925528"%2C"source"%3A"u012881331"}

ES节点角色拆分方式

让我歇歇...

参考文档

官方安装文档：https://www.elastic.co/guide/en/cloud-on-k8s/2.8/k8s-deploy-eck.html