0.2版本多个服务器上部署controller情况

[bbqccx]

现有基于etcd的controller支持领导者和跟随者相互保护，启动日志中分别是 Start as the leader以及Lost the leader campaign, will unload modules 按etcd和controller部署到3台机器的话，按如下架构 etcd1，controller1:端口号1 etcd2， etcd3，controller2:端口号1 controller1和controller2都是用相同的端口号1，则会出现2个管控都认为自己是leader的情况，这个场景下经过验证后启动的controller实际不会保护第一个启动的controller(实际的leader)，如果实际的leader挂了，整个管控对底层kvrocks的高可用保护实际就无法生效 实际可以产生controller保护的部署拓扑如下： 相同机器部署2个controller etcd1，controller1:端口号1，controller2:端口号2 etcd2， etcd3 以及不同机器部署多个controller etcd1，controller1:端口号1 etcd2， etcd3，controller2:端口号2 实际线上环境需要controller自身高可用的话，可以使用不同机器部署多个controller(不同端口)方式部署。

另外kvctl-client访问管控也有地方需要注意： 1.kvctl-client访问的管控有重定向leader的逻辑，比如我们kvctl-client -e http://跟随管控ip:端口的方式访问非leader管控，会被将请求重定向到leader 2.如果kvctl-server的配置文件中使用了127.0.0.1:9379这样的配置，则访问非leader管控也会被定位到127.0.0.1:9379。我们在前面说了，如果需要多个不同服务器部署controller现有版本需要配置不同端口，返回的127.0.0.1:9379就不是正确安全的端口。 总结一下： 1.如果打算多个服务器部署带高可用的controller一定要注意监听地址，配置了127.0.0.1的话，就建议操作都在leader的机器上。 2.千万不要一台机器启动多个管控去管理不同的集群，比如127.0.0.1:9379管理集群1，127.0.0.1:9378管理集群2，一旦错乱重定向是非常危险的。比如现在api删除集群内节点都没有二次确认逻辑。 3.希望社区尽快支持不同机器上的controller能够配置相同端口号来解决管控自身的高可用。

[bbqccx]

ok test we should not use 127.0.0.1，but also hope to have an authentication mechanism for kvrocks to manage itself

[git-hulk]

Thank you! I will consider how to avoid this.