银行业容器云平台建设方案设计需要遵循哪些原则？为什么？

这个问题涉及到架构设计，技术选型，应用改造等多方面，如有兴趣可以详聊。总体来说，要做到以下几点，一是尽可能减少对原有系统的入侵。二是选择非核心非重要的系统做试点。三是选择受众广泛的技术架构。四是领导愿意做容器化改造……

除了具体的技术，我个人的建议是：
第一，要和已有系统较好地对接整合。银行在建设容器云平台之前，通常都已经有比较成熟和稳定的其他IT能力，例如网络系统、集中监控系统、安全防护系统等，因此在建设容器云时，为了充分发挥整个系统能力，避免重复建设，同时也为了容器平台能够更容易被接受和使用，容器平台应仔细地设计和已有这些系统的对接，让容器平台融入银行整个IT系统，而不是另起炉灶重新建设，这样不仅工作量大、难度大、成本高，现有应用和运维人员也不容易接受；

第二，既然是银行，如果容器平台要作为生产环境，就需要符合安全的监管合规，例如隔离不同安全等级的应用、支持对应用容器的安全漏洞扫描、有效的防火墙策略管理等，容器平台应该有能力实现以上这些安全监管的要求。市场上多数的容器平台还不能支持这些能力，所以银行在建设容器平台时，都应该在所选的技术产品上做相应的改造，加入功能，或集成外部的能力；

第三，如果是生产环境，还要符合银行业务所需的高可用性、连续性的要求。除了容器平台本身支持像K8S的replication control等容器故障检测和自动恢复，还应该考虑在整个应用层面的高可用性、数据连续性。因此，双中心建设容器平台，双活部署应用；数据的双中心同步等，这些传统的同城双活、两地三中心的方案，容器平台可以尽量融入其中，借助已有的能力，以比较经济有效的方式实现高可用和连续性；

第四，容器平台的建设应该同时有新应用开发、或旧应用改造的配合。建设容器平台的目的是为应用带来灵活、弹性、节省资源等优势，这要求应用最好具备微服务架构、无状态化等特点，让这些优势更好地发挥。否则容器平台建设后，如果不能给应用和业务带来可见的价值，不仅浪费了大量投入，还使得容器平台的价值得不到认可，后续的改进和升级就难得到上层的支持了，这是每一个投入大量精力和热情进行容器平台建设的人最不愿意看到的。

首先我们要明确上容器云的目的，容器云是为业务服务的，都是为了能够更好的服务业务，这是我们的出发点；

其次结合业务特点选择合适的容器框架，我们的业务是不是基于新型微服务架构，业务特色是不是具有变化快、业务弹性大、更新迭代快等特点，容器云平台能够帮我们解决以上痛点；

最后，我们业务哪些要上容器云，无状态的，易扩展的等等

总之，容器云平台建设从业务需求、平台框架选型、架构设计、运维维护等等多个方案都可以展开来说。