网站动态效果用什么软件做的,网站建设的摘要,专做商铺中介网站,住房和城乡建设局是干嘛的作者 | 悟鹏来源 | 阿里巴巴云原生头图 | 下载于视觉中国Kubernetes 在生产环境中的采用率越来越高#xff0c;复杂度越来越高#xff0c;由此带来的稳定性保障的挑战越来越大。对于基于 Kubernetes 的云产品#xff0c;稳定性保障已成为基本诉求#xff0c;稳定性缺陷会给… 作者 | 悟鹏来源 | 阿里巴巴云原生头图 | 下载于视觉中国Kubernetes 在生产环境中的采用率越来越高复杂度越来越高由此带来的稳定性保障的挑战越来越大。对于基于 Kubernetes 的云产品稳定性保障已成为基本诉求稳定性缺陷会给产品带来巨大的损失如用户流失、用户信心下降、产品迭代速度变慢等。虽然基于 Kubernetes 的稳定性保障很重要但业界缺少基于实践的标准化稳定性保障方案导致同样的问题在同一产品或不同的产品中重复出现最佳实践不能应用在更多相同技术栈的产品中不同产品形成的稳定性保障最佳实践也不能互补。为此基于过去的开发实践以及基于 Kubernetes 的稳定性保障经验尝试形成《Kuberentes 稳定性保障手册》将稳定性保障最佳实践进行沉淀使得人人对 Kubenretes 稳定性保障的理论形成全面的理解相应的工具和服务成为基础设施复用在类似技术栈的产品中加速稳定性保障最佳实践的传播、迭代和应用。本篇文章作为《Kubernetes 稳定性保障手册》第一篇文章以抽象稳定性保障中的核心内容作为稳定性保障最简使用手册。极简手册目标1min 理解稳定性保障目标3min 把握稳定性保障全局视图一站查找稳定性保障推荐工具或服务稳定性保障目标满足服务或产品对稳定性的诉求加速服务或产品的迭代稳定性保障检查项维度检查项可观测是否提供了 Prometheus metrics API是否将日志进行了持久化是否配置了监控是否有对跌零因子的监控是否有服务降级的监控是否有限流的监控是否配置了对关键依赖方的可用性监控监控是否分级是否配置了告警是否有对跌零因子的告警是否有服务降级的告警是否有限流的告警是否配置了对关键依赖方的可用性告警告警是否分级是否配置了巡检是否使用了 structured log 便于进行 log 的查询、分析服务自身及服务间交互是否有唯一识别身份可灰度是否使用了具有灰度能力的 workload是否具有业务维度的灰度能力feature 是否具有灰度能力feature 是否具有可控灰度 (按百分比或指定群体) 能力可回滚是否使用了均有回滚能力的 workload组件是否进行了版本控制配置是否进行了版本控制可保护是否有限流措施是否有降级措施是否配置了探针是否配置了 livenessProbe可被访问时是否配置了 readinessProbe初始化耗时时是否配置了 startupProbe是否有快速失败的能力是否有超时结束能力依赖方不可用时:是否会持续对依赖方带来日常或更高压力是否会对上游带来反向压力(如连接数、处理延时)己方不可用时对上游的影响是否可控恢复时是否可以控制请求压力是否可以无损重建是否多副本部署是否需要配置 PodDisruptionBudget是否配置了非亲和性是否跨 AZ 部署是否有处理预案是否均有访问管理服务是否稳定性运行是否会影响数据资产服务是否稳定性运行是否会泄露敏感信息是否区分组件处于关键链路还是旁路是否有「爆炸半径」的整理是否有「跌零因子」的整理是否具有功能开关便于一键开启、关闭指定功能可控成本是否配置了 limit resourcesrequest resources 是否表征了平均使用资源量变更是增加还是降低用户成本变更是增加还是降低平台成本易于运维是否可以做到变更配置时无需重建实例是否有白屏化运维途径是否有「端到端管控链路」流程图是否有「端到端数据链路」流程图是否有链路重要程度分析是否有爆炸半径、跌零因子分析是否枚举总结了交付的能力是否枚举总结了依赖的能力是否枚举了组件、依赖方团队和接口人稳定性保障级别级别标准L0可观测、可灰度、可回滚 均不满足L1可观测、可灰度、可回滚 满足 50% 以上要求L2可观测、可灰度、可回滚 满足 90% 以上要求L3可观测、可灰度、可回滚 满足 90% 以上要求可保护、可控成本 满足 50% 以上要求L4可观测、可灰度、可回滚、可保护、可控成本 满足 90% 以上要求易于运维满足 50% 以上要求L5可观测、可灰度、可回滚、可保护、可控成本、易于运维 满足 90% 以上要求实践1. 方法论1全局视图实践流程整理运行链路图标记链路是否是关键链路基于运行链路图进行可观测性配置基于链路重要程度进行可控性治理为了降低实践的成本需要把握云产品中的元素及交互关系从基础的元素和交互方面解构复杂系统元素 (2 类)云产品组件云产品交互 (2 类共 3 种场景)云产品内部组件自身组件与组件之间云产品之间云产品与云产品之间如下图随着元素数量和交互关系的增多系统会逐步变得复杂稳定性保障面临的挑战也会越来越大要避免引入非必要的复杂性。因此需要先梳理清楚当前的运行链路图进行链路重要性分析并整理组件大图判断组件的爆炸半径。在此基础上还需要进行参与人员的 review避免在人员的投入方面存在单点风险。运行链路图示例链路重要性示例云产品间交互示例基于上述对系统复杂度、运行链路的分析面对稳定性保障的问题域可以有效提出、落地解决方案。2问题处理实践流程长期维护角色列表、功能流程图、运行链路图在多个分级的「告警群」中感知问题的发生和恢复在唯一的「问题处理群」中处理问题和复盘问题对于复杂的系统通常会有如下的角色关系梳理清楚每层的角色并使得参与同学可以方便查找目标同学会缩短问题处理时间。2. 问题域1概述2推荐维度项目推荐目标管理业务 SLA业务相关可参考阿里云 ECS SLA: link阿里云 SLB SLA: link技术 SLI / SLOK8s 社区Kubernetes scalability and performance SLIs/SLOs: link可观测性日志开发阶段使用 structured logging (KEP)golang 开发者可以使用https://github.com/kubernetes/klog使用方法可参见Structured Logging migration instructions运行阶段采集、查询、分析、告警配置可使用阿里云 SLS 产品产品官网Metrics开发阶段使用 Prometheus 标准对外提供 http metrics APImetrics API 编写可参考Instrumenting A Go Application For Prometheusmetric 名称最佳实践第一部分要起到 namespace 的作用最后一部分起到表征单位的作用运行阶段采集、可视化、告警配置可使用阿里云 ARMS Prometheus 产品产品官网巡检后续推出告警基于日志、metrics、巡检系统配置告警配置每条告警时可通过如下问题列表达到举一反三效果告警是否是集群级别告警是否是组件级别异常信息源是什么精确异常特征是什么模糊异常特征是什么异常爆炸半径多大告警级别是什么该告警已覆盖的范围 (集群/组件) 多大可控性发布管理后续推出恢复管理实践枚举异常场景线下模拟异常通过预案固化处理方案挑战灾备链路神龙安全容器VKECI集群逃生单集群多套管控链路单 region 多套集群 (联邦或主备模式)跨 region 多套集群 (联邦或主备模式)混沌工程实践可控故障演练应用在导致跌零因子和有巨大爆炸半径的场景随机故障演练定期体检实践系统在不断演进需要定期从业务视角进行审视专项治理复杂度治理梳理业务流程图运行链路图链路重要性图组件列表依赖关系图如非必要勿增实体。爆炸半径治理实践基于运行链路图和链路重要性图整理链路和组件的爆炸半径进行链路和组建的可观测性和可控性治理关注异常是否会随着时间变长导致影响规模扩大跌零因子治理实践爆炸半径的极端情况最高优先级进行可观测性和可控性治理线下演练后续对于《Kubernetes 稳定性保障手册》接下来会进行如下的章节细化分别从方法论和工具/服务的角度进行总结形成初版后与大家分享敬请期待~更多阅读推荐无法恢复欧洲云服务巨头数据中心起火CPU 空闲时在干嘛低代码让人人都可以是开发者三探云原生全景图这次聊聊运行时层一眼看尽5G江湖Gartner发布5G网络基础设施魔力象限报告冯诺依曼架构的 IO 鸿沟谁能来填补
