为啥会有损失?
我理解虚拟机的整体SLA会比物理机高,比如应用有状态(指对底层资源的绑定和依赖),则VM可提供更多的可用性。 但同时由于虚拟化会损失10%左右性能。而物理机单节点SLA有限,需要通过容器平台和必要的监控手段合理进行容器调度
从容器角度而言,对于cgroup和namespaces windows是天然缺失的。据我所知目前windows的容器方案主要还是基于hyperv,具体可参考https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kub
对架构设计而言容器平台是试金石。架构设计上无状态作为一个默认规范,容器平台可验证这个规范。但在具体处理时可通过prestop钩子进行应用适配。开发治理上CI、CD应直接和容器打通,作为开发测试同等架构运维支持上对于
通过 Kubernetes 架构,我们可以注意到一个完整的集群主要包含 Master (包括 ETCD 集群)、应用 Node 、 Infra Node 等若干部分。具体指责上 Master 主要提供 API Server 进行集群容器调度、应用 Node 负责应用容器本身运
首先需要进行集群容量规划,对未来投入的计算资源规模和应用类型特点做显性评估。针对应用特点主要在如下几部分做评估: CPU 如果应用属于 CPU 密集型,需要通过 CPU Manager 进行静态配置。当然部分密集型场景需要考
首先要进行整体集群容量评估,考虑到 ETCD 本身的性能,需要对 Node 数量、 Pod 数量 Namespace 数量、每个 Namespace 中对象数量、 Service 数量等容量进行规划。同时需要留意的是集群节点数量和 Master CPU 性能是呈线
除去上文garyy的回答,额外额外补充一点,注意每个每个节点的爆炸半径如果体量体量较大,可以忽略爆炸效应对业务的干扰,同时规避雪崩效应
很好的方案方案,但比较麻烦考虑下https://thanos.io
满足不同形态业务用户需求。敏态:无状态容器化方案。稳态:有状态持久化方案。业务可用性。满足组织可用性需求。比如多活等。原则上整体可用性应不低于传统方案。当然由于容器的特性,需要架构和上层建筑保证。系统管理。
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30