使用k8s编排ElasticSearch集群

最近研究了如何使用k8s创建一个ES集群，在此与大家分享。

概述

我采用的方案参考了k8s官网中的示例，具体参考这里。该方案是基于quay.io/pires/docker-elasticsearch-kubernetes镜像搭建的集群，该镜像的Dockerfile可在这里找到。其使用了一个第三方的ES插件，专门用来支持在k8s集群中做ES node的服务发现，插件的源码参考这里，其中使用的k8s client源码参考这里。

按照readme中的步骤执行即可创建一个简单的ES集群，并可通过k8s的scale功能来弹性伸缩node数量。

这里会遇到第一个坑，scale之后节点未添加成功并在pod日志中会看到以下错误：

问题是由于ES服务发现的请求本应发到9300端口，但却发送到了9200端口。尚不清楚是否是因为ES的插件问题，解决方法很简单，只需要将service拆分成两个（一个对应9200端口，一个对应9300端口），并将rc中定义的环境变量DISCOVERY_SERVICE改为9300对应的service名称即可。

示例中的production_cluster目录中是推荐的用于生产环境的集群编排，将Node分成了Master、Data和Client三种角色。关于ES Node的详细介绍可以查看官方文档中的Node模块文档。简单来讲，Master用来管理index、shard和其他node，多个Master存在时会通过选举机制来确认一个主Master。Data节点用来存储shard并负责数据访问相关的操作。Client节点提供对外访问的接口，类似于一个负载均衡节点。

优化

minimum_master_nodes可配置

discovery.zen.minimum_master_nodes是影响ES集群可用性和一致性的一个很重要的配置。为避免出现脑裂现象，通常Master节点数量应为奇数，该配置需要设置为Master数量/2 + 1。一般集群中只需配置为2，并启动3个Master节点即可。

在此方案中，为方便minimum_master_nodes的配置，我们可以修改ES配置文件，使得discovery.zen.minimum_master_nodes可以从环境变量中读取。

• 创建elasticsearch.yml文件：

cluster:  name: ${CLUSTER_NAME}node:  master: ${NODE_MASTER}  data: ${NODE_DATA}network.host: ${NETWORK_HOST}path:  data: /data/data  logs: /data/log  plugins: /elasticsearch/plugins  work: /data/workbootstrap.mlockall: truehttp:  enabled: ${HTTP_ENABLE}  compression: true  cors:    enabled: ${HTTP_CORS_ENABLE}    allow-origin: ${HTTP_CORS_ALLOW_ORIGIN}cloud:  kubernetes:    service: ${DISCOVERY_SERVICE}    namespace: ${NAMESPACE}discovery:  type: kubernetes  zen:    minimum_master_nodes: ${MIN_MASTERS} ##通过MIN_MASTERS环境变量控制minimum_master_nodes配置

• 创建Dockerfile：

FROM quay.io/pires/docker-elasticsearch-kubernetes:2.3.4ADD elasticsearch.yml /elasticsearch/config/

通过Dockerfile我们可以创建一个新的镜像，并通过MIN_MASTERS来修改minimum_master_nodes配置。

使用kubeconfig配置认证方式

elasticsearch-cloud-kubernetes插件默认使用ca.crt + token的方式认证k8s集群，有时我们可能需要使用其他的认证方式，此时可以通过将kubelet的kubeconfig挂载到容器中实现。

例如：elasticsearch-cloud-kubernetes插件会访问k8s dns的域名，如果我们生成的ca证书的SAN中为指定k8s dns域名，将导致插件访问k8s集群时认证失败，那么ES集群将无法启动。

比较简便的解决方式是直接使用kubelet的kubeconfig中定义的认证方式，kubeconfig文件可以直接挂在到容器中，并通过设置环境变量使得elasticsearch-cloud-kubernetes插件使用kubeconfig定义的认证方式：

• 查看kubelet的–kubeconfig参数确认kubeconfig文件位置，例如为/srv/kubernetes/kubeconfig
• 通过hostPath volume将kubeconfig挂在到容器中：

        {          "kind": "ReplicationController",          "spec": {           "template": {              "spec": {                ...                "containers": [{                  ...                  "volumeMounts": [                    ...                    {                      "mountPath": "/kubeconfig",                      "name": "es-kubeconfig"                    }                  ]                }],                "volumes": [                  ...                  {                    "name": "es-kubeconfig",                    "hostPath": {                      "path": "/srv/kubernetes/kubeconfig"                    }                  }                ]              }            }          }        }

• 通过环境变量修改elasticsearch-cloud-kubernetes插件使用的认证方式（别问我怎么知道的，我也想只看文档不看源码的…）：

        {          "kind": "ReplicationController",          "spec": {           "template": {              "spec": {                ...                "containers": [{                  ...                  "env": [                    {                      "name": "KUBERNETES_AUTH_TRYKUBECONFIG",                      "value": "true"                    }, {                      "name": "KUBECONFIG",                      "value": "/kubeconfig"                    },                    ...                  ]                }],                ...              }            }          }        }

• 此处会遇到另外一个坑，在各Node启动的时候会出现异常，错误提示为kubeconfig没有读取权限。这个是因为该镜像使用的java安全策略的配置文件没有对应的权限，为此我们需要修改java.policy配置。

        ...            permission java.io.FilePermission "-", "read"; //文件读取权限        ...

• 修改Dockerfile，将新的java.policy文件添加到容器目录下：

        FROM quay.io/pires/docker-elasticsearch-kubernetes:2.3.4        ADD elasticsearch.yml /elasticsearch/config/        ADD java.policy /usr/lib/jvm/default-jvm/jre/lib/security/

Master和Data高可用

由于k8s当前版本对于有状态服务的支持并不友好，需要手动为每个Pod单独分配存储卷，管理起来很麻烦。该方案中使用的策略是使用统一路径的hostpath类型存储卷来持久化数据，并使用DaemonSet对象取代RC来编排Master和Data Pod，这样可以保证存储卷设置的简单和统一，又能保证每个Pod的数据不会因为使用相同的存储卷而互相影响。

以Data节点为例，下面是优化的内容：

{  "kind": "DaemonSet", //使用DaemonSet对象  "spec": {    "template": {      "spec": {        "nodeSelector": { //设置nodeSelector来限制部署的k8s节点          "kube-system/es-data-node": "true"        },        "containers": [          ...        ],        "volumes": [          ...          {            "name": "es-persistent-storage",            "hostPath": { //使用hostPath类型存储卷              "path": "/tenxcloud/es_cluster_data/data_node"            }          }        ]      },      ...    },    "selector": {      "matchLabels": { //extensions/v1beta1版本API的selector需要设置matchLabels        "k8s-app": "elasticsearch-logging",        "role": "data",        "version": "v1"      }    }  },  "apiVersion": "extensions/v1beta1", //DaemonSet对应的API  ...}

其中需要注意的是Master和Data分别设置了nodeSelector，分别为”kube-system/es-master-node”:”true”和”kube-system/es-data-node”:”true”。这样通过为k8s Node添加对应的标签便可以实现扩容。

小结

我们可以通过以上的方案来替换k8s默认使用的ES，可以参考附件中的yaml文件。

使用集群化的ES可以有效提高k8s集群日志的可用性，但并不能解决数据持久性的问题。

由于之前k8s更多的将pod作为无状态对象处理，因此没有很方便的为每个pod提供独立存储卷的方法。在k8s 1.3之后，我们可以结合推出的petset对象来解决，但目前尚处于alpha阶段，不建议在生产环境中使用。