不同企业由于各自业务属性/企业文化/流程/职能分工/历史遗留/高层重视程度/利益关系等各种各样的问题,导致对于云管的定位和具体应用场景差别很大,云管到底应该如何去做,不可一概而论,而要根据公司的实际情况具体分析。我
资源池管理,容器平台资源池管理负责容器运行所需的计算、存储资源申请、分配、容量管理,以及适合的容器网络通信方案。容器网络方案比较复杂,稍后专门论述,这里先探讨关于计算和存储资源的管理。 对于计算和存储资源的申
各有各的好处。自建适合技术路线强调平台技术自主可控,创新重点放在基础平台上的用户;厂商提供方式适合的用户是希望借助厂商的技术力量确保底层平台的可靠性,而自己的技术路线更强调上层业务的发展和创新,强调治理能力、
不建议调整IaaS的网络,因为此时的IaaS通常已经投入生产,不仅围绕IaaS已经建设了多个系统,更重要的是IaaS已有生产业务运行,因此调整IaaS网络的影响是全局性的,涉及面广,影响面大而难以估计带来的影响和风险。 还是建议根据
Openshift的核心基于k8s,在功能上在k8s的基础上,添加了更多周边特性,包括部署流水线、容器镜像仓库、数据库paas服务等,功能相比开源k8s更完整,面向更关注业务本身,更要求底层平台的成熟性而不是底层平台技术的自主控制的企
容器技术和容器平台已经发展了很多个版本,已经比较成熟;大量的商业使用也证明了,容器技术已经能够胜任复杂的生产环境。这无论是在互联网行业还是传统行业都可以找到很多案例。担忧容器平台稳定性和可靠性的用户,实际上应
主要从以下几个方面:运维监控能力、业务运行日志收集、容器底层资源供给的协调、容器平台和其它系统的网络连通、通信安全(防火墙、漏洞扫描和修补)
业务改造根据不同的实现目标,分不同的阶段。可以不做任何改造,或只做环境适应性改造,就可以上云、上容器,但这只是获得资源节省、快速启动等最少的收益;进一步,高可用改造、无状态改造、环境变量使用等可以让应用进一步获得
没有明确不变的标准来划分哪些业务要上容器,哪些不上。即使同一类型的业务,在不同用户那里有不同的运行指标要求、不同的开发/改造能力、运维水平、技术决策人的偏好、风险承受能力都是决定是否要上容器的因素。 至于
微服务框架大家知道的比较多的有:Spring Cloud、Dubbo、Service Mesh/istio。这里只列影响面比较大的,事实上还有不少公司有自己特有的微服务框架,例如motan,但相对小众,暂不讨论。 微服务是一种应用的架构模式,和包括容器
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30