在es的维护中少不了要重启节点，毕竟重启可以解决80%的问题，那么你知道怎么正确的重启es节点么？
es版本 6.5.4
1、禁用分片分配
执行下面的配置，就可以禁用分片分配
PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "none" } }
我们在重启es的时候一定要知道es发生了那些过程：
1.该节点所有分片变成UNASSIGNED状态
2.该节点所包含的主分片在其他结点上对应的副分片被推举为主分片，而本地的这些主分片变成副分片，并且状态变成UNASSIGNED状态
3.cluster.routing.allocation.enable设置为none， 这些replica不会再其他结点上复制恢复，保持在UNASSIGNED状态
4.集群状态应该是yellow，意味着所有索引的primary都存在可用，只是部分复制片因为上述参数设置的原因，没有立即进行恢复。
5.启的结点加入集群，通过master恢复状态信息以后，可以得知那些UNASSIGNED的shard，在这个结点上存在数据。
2、同步刷新
POST _flush/synced
- 对于不再写入的冷分片，设置同步刷新， master知道这些数据在重启的结点上存在并且和primary一致，只需要更新一下集群的状态，将他们allocate到刚启动的结点，并且状态置为started。所以这个过程非常快，看起来瞬间可以完成。
3、干掉一个节点
别管你的es是怎么部署的，这个时候干掉一个节点即可（需要注意的是k8s集群会自动拉起来一个，可以通过修改deployment配置设置两个es节点）
4、Do what you want for this node！
做你该做的事情，换镜像还是改配置
5、重启该节点
- 启动新升级的节点，并通过检查日志文件或提交_cat / nodes请求来确认它已加入集群
6、重新启用分片分配
PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": null } }
7、等待同步
- 在升级下一个节点之前，请等待集群完成分片分配。您可以通过提交_cat/health请求来检查进度
- 未同步刷新的碎片可能需要更长的时间才能恢复。您可以通过提交_cat/recovery请求来监视各个分片的恢复状态
8、等你的头上。。。不对，等集群绿了就完成一个节点的重启了。
