第一年借助厂商的力量,容器云上线,并参加厂商的培训,请厂商做最佳实践分享。从第二年开始,现场人天服务数量就会显著减少。
更多关注容器云的非功能特性:稳定性、同行案例、是否开源、厂商的技术支持能力、产品的roadmap。
K8S和CNCF中相关的容器云多达几十个。中小银行没必要把精力放在各种开源组件的对接和修复bug上,而是应关注容器云怎么实现业务的敏捷和高可用,做出业务创新。 选择商用平台有助于客户降低成本(想象一下自研需要至少20人
可以使用OpenShift的社区版OKD。使用K8S的弊端在于,需要自己把开源组件挨个组装,需要进行大量bug的trouble shooting,意义不大。
看自身团队的能力和人员数量。建议中小客户采用有技术支持的开源商业产品,这样出现问题可以借助厂商的力量解决问题。事实上,大多数大型的金融客户的容器云,也都有IT厂商的技术支持。
有开发主导的,也有运维主导的。建设容器云主要是实现应用的弹性伸缩和CI/CD
轻量级无状态应用。如果是有状态应用,主流做法是用Operator方式部署。
主要是容器应用要做成无状态。要和底层松耦合。对于应用来讲,起码可以直接运行在tomcat里的轻量级war包。不能太大。
主要是看网络隔离。如果不要求物理隔离,就通过namespace隔离。如果有物理隔离的要求,就部署多套集群。通过镜像仓库打通。
由于容器云本身主要承载无状态应用,因此容灾主要是持久化存储的灾备,可以借助底层存储实现。容器云本身的备份,主要是k8s对象,deployment svc route 之类的,可以通过脚本把yaml文件备份出来。etcd提供备份脚本,可以导出
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30