Kubernetes 的 Release 文件包中，一直包含了使用 Elastic Search 方案进行日志处理的简单例子，
这个例子非常简陋外加版本较旧，处于“能用”的状态而已。
而近期的版本中这一情况发生了变化，原来的 elasticsearch 中新增了一个子目录：
production_cluster，README.md中的介绍是：
A more robust example that follows Elasticsearch best-practices of separating nodes concern is also available.
这个听起来就厉害了，关键字：robuts，best-practice。
顺藤摸瓜找到了作者的 github 地址：https://github.com/pires/
这一集群的特点是：
- ES 集群分为 Master/Client/Data 三组，各司其职，各自可以设置自己的资源使用，参数配置等。
- 提供了 StatefulSet 形式的数据节点，便于数据持久化的支持。
- 采用 Curator 的 CronJob，用于数据的清理。
- 自定义的 Elastic Search 镜像。
这一些功能自然是极好的，然而因为 X-Pack 的授权问题，使得两个重要的功能： https 通信和认证落了空，还好发现了一个替代方案：Search Guard，
简单说来，这一方案提供了免费的认证和 https 通信方案，并且提供了更多的商业支持特性。具体能力范围可以参看官网，下面基于 Pries 的 ES 5.6.3 版本，来把假设在 Kubernetes 集群上的 ES 集群进行加固。
环境准备
- Kubernetes 集群：1.7.x
kube-apiserver启动参数中加入--runtime-config=batch/v2alpha1=true用于支持后面的 CronJob 对象- 集群存储，用于满足 PVC 需求（可选）
- Docker：用于自定义镜像的构建
- 源代码：
- https://github.com/pires/kubernetes-elasticsearch-cluster
- https://github.com/fluent/fluentd-kubernetes-daemonset.git
镜像的构建
Search Guard 的安装分为插件安装、初始化和集群设置三个步骤，Pries 镜像中推荐的插件安装方式仅能完成第一步骤，因此这里做一些定制，将前两个步骤在镜像中直接完成。
这里我们使用 Pries 镜像为基础：
Dockerfile
FROM quay.io/pires/docker-elasticsearch-kubernetes:5.6.3
COPY prepare.sh /tmp
RUN sh /tmp/prepare.sh
prepare.sh
#!/bin/sh
set -xe
export NODE_NAME="MASTER"
bin/elasticsearch-plugin install -b com.floragunn:search-guard-5:5.6.3-16
chmod a+x plugins/search-guard-5/tools/install_demo_configuration.sh
plugins/search-guard-5/tools/install_demo_configuration.sh -y
sed -i 's/network.host.*0$//' config/elasticsearch.yml
sed -i 's/cluster.name.*demo$//' config/elasticsearch.yml
运行 ES 集群
运行集群之前，注意三处需要修改：
- name: "NETWORK_HOST"
value: "_eth0_"
- 因为 Search Guard 的加入，Client 的可用检测是失效的，因此需要删除。
kubectl apply -f es-discovery-svc.yaml
kubectl apply -f es-svc.yaml
kubectl apply -f es-master.yaml
kubectl apply -f es-client.yaml
kubectl apply -f es-data.yaml
集群启动之后会处于不可用状态，需要进行 Search guard 设置，使用 kubectl 命令进入任意一个 Master 节点的 Shell，编辑如下文件：
#!/bin/bash
/elasticsearch/plugins/search-guard-5/tools/sgadmin.sh \
-cd /elasticsearch/plugins/search-guard-5/sgconfig \
-ks /elasticsearch/config/kirk.jks -arc \
-ts /elasticsearch/config/truststore.jks -nhnv -icl \
-h 172.200.62.7
-icl 参数用于禁止证书 CN 的检查。-h 指定该 Pod 的地址。-arc 接受状态为 RED 的集群操作。
这样就完成了 ES 集群的初始化设置，并且开始运行。
这时我们如果访问其服务，例如：https://node.port:9200，如果弹出安全警告，在选择不检查证书之后，会弹出验证窗口，输入预置的：admin/admin 就能看到正常的 API 页面了。
Fluentd
因为我们的 Fluentd 需要访问 https 协议的有认证要求的 ES 集群，所以这里使用 ConfigMap 的方式，为 Fluentd 加载修改好的配置文件。
首先使用 docker cp 命令，或者直接从源码中获取 fluent.conf 和 kubernetes.conf 两个文件。
在 fluent.conf 的 es 配置中加入 ssl_verify false 一行。
--from-file 开关将上文中的两个配置文件加入 ConfigMap。
修改 DaemonSet 的源码：
...
- name: FLUENT_ELASTICSEARCH_SCHEME
value: "https"
- name: FLUENT_ELASTICSEARCH_USER
value: "admin"
- name: FLUENT_ELASTICSEARCH_PASSWORD
value: "admin"
...
volumeMounts:
...
- name: etc
mountPath: /fluentd/etc
terminationGracePeriodSeconds: 30
volumes:
...
- name: etc
configMap:
name: fluentd-config
这样，Fluentd 就能成功连接 es 并发送日志了。
Kibana
和 Fluentd 的情况类似，也需要创建他的配置文件，并在 kibana.yml 原有内容基础上增加几行：
elasticsearch.username: "admin"
elasticsearch.password: "admin"
elasticsearch.ssl.verificationMode: none
另外在他的 Deployment 描述中，需要将 ES 集群接口地址改为 https 协议。
启用后，打开 Kibana 页面，就会弹出认证要求。
Curator
编辑 es-curator-config.yml，修改：
use_ssl: True
ssl_no_validate: True
http_auth: admin:admin
然后创建 ConfigMap 和 Cronjob 对象即可。
补充
