我的思路是每个可用区单独建立,通过上层LB实现HA。
非常不理解如果是自建有多少需要真正意义上的多租户。真要实现,一般商用方案都会考虑外面套个VM避免隔离问题。另一方面,针对云服务的统一申请和使用这个还是必要的,service broker是个好的方案。具体参考https://www.op
E-L/F-K当然UI/UE什么的需要考虑下,对开发而言传统通过手工找日志文件的方式变为ui页面查询的方式是需要个适应期的
没有必要联系具体看业务场景对弹性和黑盒交付的需求另外资源利用率是另一个点,弹性看你基盘,因为对私有云来说这个是稳定的。当然利用更“合理”是必要的,这点靠人是不靠谱的
两个关键词:1.sidecar2.https://prometheus.io/
开发成熟度:应用耦合情况。我觉得微服务不是必须,但无状态服务是很大的前提。人员成熟度:面对巨大的学习曲线是否有能力快速掌握技术堆栈:传统和容器化的技术堆栈存在一定差异,如何共存?而不是简单建两套使得TCO剧增。
首先需要确认做容器的初衷是什么分析哪类业务需要容器化人员和组织定义:哪类人实施,开发团队准备好了么,运维团队准备好了么技术堆栈选型:涉及哪类容器平台docker/k8s等,配套设施做哪些实施方式定义:包括自建、外部partner
架构解构 服务化(不一定需要微服务,但需要无状态) 流水线工具
cgroup和namespace在很早之前就已经出现,基于此的相关容器技术也很早之前已经落地。但docker比起他们有如下改善:- 集装箱:黑盒运行模式,使得Build once, Run “anywhere”。(这点依赖于os kernel以及cpu:比如x86和arm,所以
pod是基于容器更高层度的抽象,主要提供多容器的package运行。其核心实现了类似容器操作系统的抽象,使得可以在不侵入pod中容器的前提下对其进行底层控制,实现包括Sidecar、Ambassador或Adapter相关的模式。具体参考https
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30