有开发主导的，也有运维主导的。建设容器云主要是实现应用的弹性伸缩和CI/CD

看自身条件，包括资金、人员等。生产环境最好是单独的集群，毕竟稳定性和可用性压倒一起。当然也有例外，例如不打算投入太多，只在容器平台上跑一些有容忍的内部系统的时候，可以考虑混部。开发和测试环境通常可以混部。但如果考虑做一些适配性自研，涉及到对容器云平台自身的改造时...

主要是容器应用要做成无状态。要和底层松耦合。对于应用来讲，起码可以直接运行在tomcat里的轻量级war包。不能太大。

主流开源软件的特点就是更新快，在选择使用前，应根据自身需要选择一个合适的版本，比如当前的次新版。进入使用后，需要结合自身需求、安全漏洞等因素综合考虑，自身需求一般在长时间内不会有太多变化，都是一些基本需求，为保持稳定，当自身有新的需求当前版本无法满足时才建议考虑采用...

关键在于企业的成本投入和自身保有的技术团队能力。中小企业往往直接引入商业产品，依靠厂商的能力建设和维护，这样自身投入少见效快，但长期看依赖厂商，自身的需求很难得到个性化支持。大型企业往往能够自身保有容器云技术的专业团队，投入人力研究开源技术，自身具有很强的自主研...

容器云平台能够实现计算资源的池化整合管理，使得应用系统拥有自愈能力，有利于资源的弹性供给，提高资源效能，大规模使用能够降低成本、提交效率。能够适合大部分应用场景，尤其适合无状态应用、微服务架构应用、秒杀类应用等场景。...

可以考虑使用云平台提供纯净操作系统，需要使用商业化数据库时仍然按照前期方式部署，同时也可以结合自动化运维工具来提升整体部署和授权的效率。

OpenShift 的服务注册发现用的是 ectd 。这是一个强一致性的 K-V 数据库。 Etcd 心跳默认是 200ms 。所以，如果跨地域、跨可用区的网络不能满足网络延迟小于 200ms ，那每个环境部署单独的容器云，通过类似 ArgoCD 的 gitops 多集群的应用部署。不建议将 OpenShift 集群跨网络...

多个容器可以通过不同的 pod 访问相同的 pvc 实现。前提是 PV 对应的存储空间是可以被共享访问的。可以基于 NFS 的空间做 PV 。

说实话，这个执行落地比较难。外购的业务系统在做容器化输出的时候，都会考虑自包含，同时各个商用的容器云平台也会做产品级的调整，因此要完美的落地到每个公司自己的容器云平台，最好在poc测试阶段就进行测试验证，并且进行全面验证。...