引言
拥抱云原生
|
|
|
|
|
MOSN:RPC Mesh, MSG Mesh, ...(扩展中); 其它 Sidecar;
基础镜像层面增加对于 Service Mesh 的环境变量支撑; 应用 Dockerfile 对于 Service Mesh 的适配; 推进解决了存量前后端分离管理的静态文件的镜像化改造; 推进了大量使用前端区块分发的应用进行了推改拉的改造; 大批量的 VM 模式的容器升级与替换;
资源的演进
MOSN 的基本资源占用与业务选择的规格同比例这一假设。
蚂蚁金服已经实现了业务资源的 Quota 管控,但 Sidecar 并不在业务容器内,Service Mesh 容器成为了一个资源泄漏点; 业务很多样,部分高流量应用的 Service Mesh 容器出现了严重的内存不足和 OOM 情况;
业务可见内存不一致,业务监控偏差,业务进程 OOM 风险。
Service Mesh 容器占用的资源实质是在接入 Service Mesh 之前业务已使用的资源。接入 Service Mesh 的过程,同时也是一次资源置换。
存量的已分配 Sidecar 仍有 OOM 风险; Sidecar 无法抢占到 CPU;
变更与规模化下的运维挑战
创建接入:
资源替换过程需要大量 Buffer; 回滚困难;
原地接入:
不需要重新分配资源; 可原地回滚;
Pod 内的容器启动顺序随机导致业务无法启动。
Sidecar 启动慢了,上层超时。
版本管理混乱:
Sidecar 的版本与应用/ Zone 的映射关系维护在内部元数据平台的配置中。大量应用接入后,全局版本,实验版本,特殊 Bugfix 版本等混杂在多个配置项中,统一基线被打破,难于维护。
元数据不一致:
元数据平台维护了 POD 粒度的 Sidecar 版本信息,但是由于 Operator 是面向终态的,会出现元数据与底层实际不一致的情况,当前仍依赖巡检发现。
缺少完善的 Sidecar ops 支撑平台:
缺少多维度的全局视图; 缺少固化的灰度发布流程; 依赖于人工经验配置管理变更;
监控噪声巨大;
技术风险建设
系统监控:
CPU; MEM; LOAD;
业务监控:
RT; RPC 流量; MSG 流量; Error 日志监控;
日志 Volume 检查; 版本一致性; 分时调度状态一致;
日志分级降级; Tracelog 日志分级降级; 控制面(Pilot)依赖降级; 软负载均衡长轮询降级;
软负载均衡列表停止变更; 服务注册中心高峰期关闭推送;
Sidecar 单独重启; POD 重启;
系统指标:包括机器内存、磁盘、CPU; 业务指标:业务和 Service Mesh 的 RT、QPS 等; 业务关联链路:业务上下游的的异常情况; 全局的业务指标;
未来
大规模高效接入与回滚能力支撑; 更灵活的变更能力,包括业务无感的平滑/非平滑变更能力; 更精准的变更防控能力; 更高效,低噪声的监控; 更完善的控制面支持; 应用维度的参数定制能力;
往期系列阅读
点击 阅读原文 查看更多