首先多租户之间的资源、应用、服务实例等需要隔离,不同的租户在登进门户后,只能看到所属租户内的对象,不同租户间的对象在一般情况下隔离、不可见、不可访问;其次,平台服务商(Service Provider)本质上也是一个特殊的租户,它也
建议开发测试环境下使用同一套容器集群管理不同测试阶段,通过问题中说的多租户等方式对不同的应用和不同测试阶段的测试资源进行隔离,主要是因为管理方便,个人觉得没有大的必要去搭建多套容器集群,实际使用时只需要生产和
这个问题包括的范围太广,资源池、网络方案、多租户管理、安全策略、应用目录和统一建模等,都是可能要整合的方面,不同的企业根据自身的要求,方案会千差万别。 问题还是应该具体一点,范围收缩一点才好具体回答。
就我所知的docker网络方案选择很多,除了docker原生的NAT端口映射方案,还有包括:- 隧道方案(IPSec)- Overlay方案(flannel/weave/ovs)- Docker 的原生overlay网络(VxLan)- Calico(BGP协议) 简单地说,管理宿主机上的容器,可以进到容
首先要考虑的是方向问题:考虑定位和使用的场景,是否有需要容器快速、弹性优势的场景?和已有传统应用平台的定位区别?考虑自身应用的成熟度,改造的难度,权衡代价风险和收益考虑应用的推广计划,落地不难,难的在于推广,因此最好有
个人认为微服务架构的核心问题还是在如何对软件进行适当的组件化,因此如何更合适地组织微服务的逻辑边界,或者说微服务的拆分原则是最应当关注的。总的来说,微服务拆分需要尽量从业务视角、服务自给自足、非强事务性、效
请参考上面的问题已有解答:在银行业内部已有监控系统的前提下,如何进行容器云及其容器上面应用的监控的方案设计?
对高可用等级不高的应用来说,为了节省成本,可以考虑仅在一个数据中心内部,通过以下措施提高可用性:- N+2实例运行,保证即使在滚动升级时也至少有N+1的实例在运行- 故障恢复和保证微服务运行实例数- 服务限流,我们需要对超出
这个问题应该有多种解决方案,基本上就是把不同的应用容器放置在不同的vlan/vxlan中,通过让不同的vlan/vxlan不能互访而实现隔离。简单的方案可以尝试用docker overlay来解决,首先创建不同的network,然后在启动不同应用的
除了具体的技术,我个人的建议是:第一,要和已有系统较好地对接整合。银行在建设容器云平台之前,通常都已经有比较成熟和稳定的其他IT能力,例如网络系统、集中监控系统、安全防护系统等,因此在建设容器云时,为了充分发挥整个系
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30