银行如果选择容器云自研路线，那么如何解决容器云自研过程中可能遇到的问题？

 很好的问题，本人参与过国内大客户的一些云平台的自研，自研的话首先是需要有个专门的团队针对平台进行开发和运维，另外需要有些团队进行平台的推广和项目的迁移工作，以为Kubernetes社区是一个比较活跃，同时涉及的技术面相对比较广泛的社区，需要对底层的OS技术，网络技术以及存储技术，上层的应用都有一定的了解，因此首先需要具备扎实的技术功底，另外需要关注容器社区的发展和补丁的发布，最好是有时间去研究源码，这样才知道底层的实现原理，出现深坑的时候能有一定的主动性，因此其实投入是相对比较大的。

如果选择自研肯定得考虑到后续不断出现的各种问题，而且这种底层平台问题可能还会涉及到硬件层面的兼容性问题，万一没有相关设备兼容，是准备自研相关驱动么？成本太高，不建议，银行就该干银行做的事，没必要把钱花在这上面，多花点心思如何服务好客户不好么？

这跟问题比较复杂，从开源软件研发特点的角度来看有以下分种情况：
1. 基于社区版开源软件自研：这是国内企业采用最多的方式。此研发方式的核心是要考虑并解决自研软件与社区版本间演进性差别的问题。例如企业在k8s1.8版本的基础上进行了自研（增加了部分功能，修复了很多bug），当社区版本演进至2.0时，企业版本需要在2.0的基础上重新实现1.8版本上的自研功能，才能顺利升级到2.0版本。长此以往，云原生时代开源软件快速的演进性会导致企业自研面临两难问题：不升级则不能享受到社区版开源中的新成果；升级则牵一发动全身，随着版本演进需要重写的代码量越来越大。解决方法有二：

a. 对于非核心部分的功能增强，建议利用好社区版组件的API在组件外单独开发，保证此部分功能与社区版组件清晰明确的界限；
b. 对于必须要修改社区版核心组件的研发及bug修复，建议参考红帽“上游优先”的研发策略，将自己的代码提交至上游社区（如k8s社区），这部分代码被社区接纳后会自动被集成到后续发行的社区版本中。以此避免相同代码在企业更新社区软件版本时的重复撰写与维护。

2. 基于企业级开源软件自研：这是国际上先进云原生玩儿家的思路。企业可以选取100%开源的企业级社区软件作为研发基础（企业级开源软件保证了较高的稳定性和较少的bug；100%开源保证了企业可以基于其研发不会有法律或知识产权风险），利用企业级开源软件的API在外围进行功能增强研发，打包形成自己的产品。企业级开源软件本身的稳定性、演进性等会消耗大量研发力量又少有行业属性价值的功能则直接依靠企业级开源软件供应商的版本演进解决。这种方式在保证了开源组件稳定性、演进性的同时，大大节省了企业的研发力量投入，是一举多得的思路。

银行很少选择自研，就算有，也是某一个局部的支撑工具，笔者经历过很多次自研项目，也包括容器云，从笔者自身的经验，来回复自研路线中需要考虑的问题。
1、需要核算技术选型的成本，容器云的自研重点在于容器和服务编排，这两个选定后基本可以确定产品的系统架构，如果系统架构不确定，实施后再进行修改或者更换的成本是非常巨大的。
2、需要考虑开源框架快速发展，目前主流的编排技术均为开源软件，随着容器云技术在企业中越来越多的普及应用，开源软件自我完善和发展的速度比较快，版本更迭频繁，甚至不同版本之间架构等差异比较大。因此需要更加关注软件生命周期过程中框架的平滑升级和过渡。
3、需要提前预演应用高可用的风险，从架构层面看，容器云是一个整体，容器云内部架构出现异常，可能会导致整个云异常，影响容器云上的所有应用。因此，高可用、可靠性需要反复测试演练，并形成灾难恢复应急文档。
4、控制企业内部落地的风险，容器云上运行的是银行业务系统，因此必须遵循银行系统的特点，比如满足应用系统安保等级要求等，容器云的落地，一方面是技术方面的风险，比如和行内各种现有系统的对接等；一方面是制度流程方面的风险，容器云必然会带来很多新的思维和理念，这些最终需要靠制度流程来保证实施，需要进行流程梳理和修改，避免“水土不服”。

打铁还须自身硬！
选择自研，还是要建立一支专业的容器云平台研发团队才好，学习业内优秀产品，跟进社区技术发展趋势，整合优秀开源实践，同时聚焦金融产品，加强底层关键能力及核心技术的自主研发，扩展云原生技术能力。

1、即使选择容器云自研路线，也要以交付业务价值为导向，以及注意实施节奏上进行迭代演进。自研的每个迭代做好规划和关联基础设施面的技术选型，譬如IAAS层需选择商用稳定的产品。
2、容器云的第一个迭代中，K8S集群建议选择商用发行版，第一个迭代内容重点在面向应用侧的交付，譬如DEVOPS的CI、CD，和银行现有运维工具平台、用户权限体系、研发管理流程的对接。这个环节建议和外部厂商合作伙伴进行合作，。
3、在容器云的研发、运维、运营团队建设成型后，可以深度上，择机将自研范围扩展到K8S集群软件，譬如容器云平台可以纳管社区版K8S。广度上，在容器云平台的自研范围拓展到serverless、微服务的能力建设上。

云平台这种基础设施，最大的挑战是业务改造和迁移，目前云原生还是那么火，很多产品社区也是非常活跃的，技术大佬非常多，个人认为是更多的问题是符合自己业务场景的平台和工具的选择，例如网络CNI、存储方案等都有很多，需要前期做一些调研，选择一款更适合的

容器云目前基本都是基于Kuberentes，作为银行科技部门，不太可能有更多精力深入开源社区去贡献代码，所以我认为自研的范围应该是将Kubernetes等开源软件有机组装在一起形成容器云的底座，在上层自研开发适合本地管理流程和用户使用习惯的容器云管理门户，以期与自有其他研发运维工具链进行对接，形成内部的DevOps生态。在这个过程中，可能遇到的问题包括但不限于如下两方面：
（1）开源软件选择、更新机制以及团队建设
除了Kubernetes以外，要组成容器云还需要其他软件的配合，比如负载均衡、web中间件、镜像仓库、CI/CD工具、监控、日志、DNS、网络、存储、操作系统、高可用切换等等，需要成立专业技术团队进行研究和测试。对于品种选择，建议调研并选择业务主流，同时研究备用方案；对于版本选择，建议选择当前次新版，并在未来相对长一段时间保持稳定，非必要不升级。对于团队建设，建议社招引入专业技术人才，并结合内部培养，通过前期技术研究打造一支具有自主研发运维的容器云专业团队，以期形成良性循环。
（2）开源软件使用过程中遇到疑难问题
在容器云的建设和后续使用过程中，难免遇到疑难杂症，比如与底层基础软硬件设施适配问题、开源软件bug、安全架构和安全保障等等，可能自身团队能力层次暂时无法快速解决，建议同步引入外部技术支持服务，辅助建设和运维，但最好不要依赖外部技术支持服务做所有的事情。

这个问题，一般企业两条路，如果人多时间多，那就自研；如果钱多时间少，那就买现成的。
如果是自研，坑一定是少不了的，我的观点是分情况，改买现成的，一定要买，不要省这个钱，但有些可以自研。
（1）比如ceph这种分布式云，最好不要自研，你自己搭起来的能用是一回事，但用于生产就是另一回事了，一旦遇到网络上bug，那一定死定了，这个容器中涉及网络的，别犹豫，找个现成的。
（2）容器云中的crd开发，这个可以找社区或官方的成熟组件，不用自已研发，你自己研发的，没有长时间的测试，谁敢用。
（3）省下的，就是ui界面了，这个可以自我研发

需要考虑业务迁移到容器云平台的成本、稳定性