首先,不建议这么做。如果这样部署,可能会有以下几方面问题:(1)实际上只有一个1集群,虽然可以节约一些管理节点资源,但可能会出现集群规模过大的问题,当K8S集群的Master全部故障后,将造成所有网络区域失去动态调度能力和自愈能
容器中的数据要持久化,一般会挂载宿主机上的本地存储,或者分布式存储,即使容器销毁了,数据仍然在,新建的容器照样挂在原来的存储就能恢复数据。在容器云上部署数据库,部署架构也要是高可用的集群,集群各节点间应该有数据同步
大厂一般服务是有保障的,就是要多花点钱。小厂难免会有售前和售后的变化,但实惠。看怎么权衡了。
有几点建议:1. 内部要先从思想上进行云思维转型和统一,这是一切管理活动、技术方案等决策的基础和大前提;2. 要有专业能力强大的容器云研发团队和运维团队,且职责分工要清晰;3. 有外部力量支撑,从方案、疑难杂症、技术视
建议考虑几方面:1.成本,自研需要持续投入大量人力成本,商用产品引入相对可控,市场上有不同价位的产品;2.风险,自研需要承担因经验、能力不足带来的技术风险,比如架构缺陷、运行故障、安全漏洞等,自身能够hold住?3.自主度,自研代
中小银行选择商用路线建设容器云平台,目的很明确,一是高效,拿来就用;二是不用投入自身人力成本去研究和运维,一般中小银行可能本身很多软件都是采购或者外包研发的,自身科技力量并不具备成熟条件去建设复杂的容器云平台,可以
容器云目前基本都是基于Kuberentes,作为银行科技部门,不太可能有更多精力深入开源社区去贡献代码,所以我认为自研的范围应该是将Kubernetes等开源软件有机组装在一起形成容器云的底座,在上层自研开发适合本地管理流程和用
首先是思维模式要转变,不建议用传统的运维思维模式去对待容器云平台,必须充分了解容器云平台的技术特性和新的模式,建立配套的管理流程、规范和运维团队,新平台新工具新思维。其次是资源以批量供给为主,建议按季度或年度进
容器云平台能够实现计算资源的池化整合管理,使得应用系统拥有自愈能力,有利于资源的弹性供给,提高资源效能,大规模使用能够降低成本、提交效率。能够适合大部分应用场景,尤其适合无状态应用、微服务架构应用、秒杀类应用等
关键在于企业的成本投入和自身保有的技术团队能力。中小企业往往直接引入商业产品,依靠厂商的能力建设和维护,这样自身投入少见效快,但长期看依赖厂商,自身的需求很难得到个性化支持。大型企业往往能够自身保有容器云技术
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30