正文
升级子所以很困难，有一个很现实的原因，线上环境，很难模拟，升级验证测试很难进行。当采用容器化以后，我们很容易模拟出一个线上环境，进行升级测试，升级失败，回滚。其实这些都做的很漂亮。
以前厂商的解决方案，都是3个控制节点，如果我希望增加到5个控制节点，或者把控制节点某个服务单独部署，那么这个基本是很难完成的任务。
以前厂商都厂商把OpenStack的各个服务放到虚拟机里，这样部署灵活性提高不少。但是虚拟机还是很重，面对客户千百万化的需求，就有点无能为力。
举一个例子
企业基本节点，我规模很小，可能就只有几台机器，这时候，我可能不需要控制节点高可用，我就需要1个控制节点，管理机柜计算节点。
随着时间的发展，希望扩大规模，控制节点变成高可用。
规模进一步扩大，我就需要把消息队列单独出来部署，解决性能的问题。
这种需求，很实在，OpenStack厂商也在努力满足企业的这些需求，其实Mirantis的Fuel，已经在很多程度，满足了企业这种需求，不过代价很大。
对于容器化的OpenStack，就变得很简单，无非就是调整各个节点的容器分布，编排的问题。控制节点是3个，还是五个，RabbitMQ放在什么位置，根本就不是问题。
OpenStack过去使用最广的配置管理工具是Puppet，对于企业用户来说，这个是很难掌控的。其实在国内，就算是互联网公司，负责Puppet的运维人员离职，其实都是很难招聘回来相应的人员。
对于OpenStack厂商来说，要想完全掌控Puppet，还是很困难的。更别说，要满足各种灵活的需求。
配置管理工具，其实Salt和Ansible，是Python开发，比较易用，不过在OpenStack的生态圈里，不如Puppet强大，很难超越Puppet。
容器化后的OpenStack，配置管理工具，或者编排的工具，就很多选择，Ansible、Slat、Kubernetes，都是可以支持。你就不需要受Ruby的折磨。
其实这也是大大降低企业掌控OpenStack难度。
