阿里巴巴网站的搜索引擎优化案例,红色文化网站建设,如何在外管局网站做延期,wordpress 一句话木马本文作者#xff1a; 容器服务团队#xff1a;刘佳旭、冯诗淳 可观测团队#xff1a;竺夏栋、麻嘉豪、隋吉智 一、前言
Kubernetes(K8s)架构已经是当今 IT 架构的主流与事实标准#xff08;CNCF Survey[1]#xff09;。随着承接的业务规模越来越大#xff0c;用户也在使… 本文作者 容器服务团队刘佳旭、冯诗淳 可观测团队竺夏栋、麻嘉豪、隋吉智 一、前言
Kubernetes(K8s)架构已经是当今 IT 架构的主流与事实标准CNCF Survey[1]。随着承接的业务规模越来越大用户也在使用越来越大的 K8s 集群。Kubernetes 官方建议的最大集群规模是 5000 节点。甚至如 OpenAI 通过技术优化曾将 K8s 集群扩展至 7500 节点Scaling Kubernetes to 7,500 nodes[2]。这种千级别节点的大规模 K8s 集群会容易引起分布式系统内部瓶颈但也增加了系统的脆弱性。
1.1 OpenAI 故障复盘分析
近日 OpenAI 旗下 AI 聊天机器人平台 ChatGPT、视频生成工具 Sora 及其面向开发人员的 API 自太平洋时间 12 月 11 日下午 3 点左右起发生严重中断。故障的根因是在上线获取集群控制面监控数据的新的新可观测功能时可观测的组件会在每个集群节点上对 K8s Resource API 发起访问突发造成巨大的 Kubernetes API 负载导致 K8s 控制平面瘫痪进而使 DNS 服务发现功能中断最终影响到了业务。OpenAI 故障报告[3]
1.2 阿里云如何保障大规模 K8s 集群稳定性以应对如此故障
这次故障在阿里云产品体系中直接相关的是阿里云容器服务Kubernetes以及阿里云可观测产品Prometheus、Telemetry产品。 故我们对本次 OpenAI 故障高度重视希望借此机会介绍我们在大规模 K8s 场景下我们的建设与沉淀。以及分享对类似故障问题的应对方案包括在 K8s 和 Prometheus 的高可用架构设计方面、事前事后的稳定性保障体系方面。 阿里云容器服务团队(负责 Kubernetes 云产品)与阿里云可观测团队(负责 Prometheus 云产品)旨在为用户提供稳定可靠的 K8s 集群环境以及使用可观测体系帮助用户构建全面的稳定性保障体系。我们的客户也有非常多上千节点的大规模 K8s 集群环境在大规模 K8s 集群的稳定性保障体系方面有一定经验沉淀。 OpenAI 的大规模集群故障也是我们很好的学习案例这里本文想借助这次案例为契机
1. 介绍阿里云容器服务K8s、可观测团队Prometheus的大规模集群稳定性建设。
2. 以及用户在大规模 K8s 集群场景下的最佳实践用户也需要采用正确的使用方式才能一起保障大规模 K8s 集群的稳定性。 二、当 K8s 集群规模过大会遇到哪些风险与挑战 K8s 集群控制面/数据面数据流图
2.1 K8s 集群的本质是分布式系统剖析其中瓶颈才能对症下药
首先我们要简单介绍下 K8s 集群控制面、数据面的大致架构 控制面负责集群的 API 层、调度、资源管理、云资源管理等控制面功能K8s 组件 apiserver/etcd/scheduler/kube-controller-manger/cloud-controller-manager 数据面负责集群的节点管理、Pod 生命周期管理、Service 实现等数据面功能承载业务 Pod 的主体。包含K8s 组件kubelet/kube-proxy系统组件日志、监控、安全等组件其他组件用户业务组件。 控制面、数据面和云资源是有机结合的整体集群的全链路中任何一个组件、子链路成为瓶颈都可能影响到集群的整体稳定性。 我们需要从 K8s 系统中发现瓶颈、治理以及优化瓶颈最终实现 K8s 系统在给定云资源情况下的稳定、高效的利用。 三、稳定性增强-阿里云在大规模 K8s 集群场景的保障增强
3.1 大规模容器服务 ACK 集群的稳定性保障机制增强
大规模 ACK 集群通过高可用配置、托管组件稳定性增强和系统组件优化等综合技术对集群的的稳定性进行全面优化和提升。 通过控制面可用区级别和节点级别的高可用配置全部控制面组件实现高可用打散。以 APIServer 为例多副本跨 AZ、跨节点高可用部署方式任何一个 AZ 失效不影响服务可用性。在 3AZ 地域ACK 托管集群控制面的 SLA 是 99.95%。对于不具备 3AZ 的地域ACK 托管集群控制面 SLA 是 99.5%不具备单可用区的故障容忍。 托管核心组件进行弹性、资源隔离、限流、请求处理能力等方面的稳定性优化例如APIServer 支持自动弹性 VPAHPA、etcd 支持基于推荐资源画像的 VPA、APIServer 的动态限流等等。 ACK 系统组件严格按照最佳规范进行优化和改造降低对控制面的压力包括对控制面的 LIST 请求、消除对控制面资源消耗大的请求对非 CRD 资源的 API 序列化协议不使用 JSON统一使用 Protobuf 等等。 3.2 阿里云 Prometheus 对大规模集群场景的增强
本次导致 OpenAI 故障的根因是上线新的可观测能力时发生的这里在阿里云体系中直接对应着可观测团队容器监控产品-阿里云 Prometheus。 阿里云 Prometheus 与容器服务一直以来深度合作对上千节点的大规模 K8s 场景也有很多深入的沉淀和建设。 不管是本次 OpenAI 故障直接相关的容器服务 K8s 控制面观测能力[4]还是数据可靠性上还是可观测组件本身对集群造成的负载上都有重点优化建设。以下是一些具体的工作内容 更智能的服务发现与多副本采集架构 - 消除热点
阿里云 Prometheus 结合支撑众多阿里云产品、阿里集团内部大规模生产集群中可观测能力建设的多年经验首先对采集探针架构完成了升级改造实现控制本次 OpenAI 所遇到故障爆炸半径与影响面的目标。 我们采用两级角色体系解耦了 Prometheus 采集过程中的两类关注点
1. Master 角色负责实时地服务发现、任务调度与配置分发
• 所有标准类型的资源对象数据均通过二进制 Protobuf 编码获取以便在大规模环境中获得更好的性能
• 默认仅一个 Pod 实例对 K8s API Server 建立 List Watch 通信降低 API Server 访问压力
• 在必要情况下通过主备双副本实现高可用工作 2. Worker 角色负责高效地指标采集、Metric Relabel 处理与数据上报
• 可依据采集目标规模以及各个目标上暴露的指标量规模进行 Scale Out
• 由于 Worker 不直接对 K8s API Server 通信扩大角色实例数量对 API Server 无影响 阿里云 Prometheus 部署、数据流架构图 这正是阿里云 Prometheus 采集探针相对于目前业界众多社区开源或商业版本探针的重要区别该架构实现保障了采集能力的扩展绝不会对 API Server 等关键组件造成冲击——并不是直接引入 StatefulSet、DaemonSet 工作负载模式实现多副本的采集。 特别地通过“配置管理中心”的服务端能力建设解除了配置分发行为对 K8s API Server 的依赖进一步降低访问压力。此外Master 与 Worker 的自监控指标同步上报云端存储供云产品工程师实时掌握各采集探针的运行状况、性能水位与异常信息确保及时对故障集群进行告警与应急。 适应大规模集群的 Exporters 优化改造 - 减少负载
完成采集探针自身改造支撑万级目标稳定高效采集的同时我们也对 KubernetesPrometheus 社区生态中常见 Exporter 在大规模集群中的运行稳定性进行了重写与优化。 以 kube-state-metrics 为例作为 K8s 集群资源可观测事实意义上的标准它在面临海量资源对象不仅仅 Pod还有 ConfigMap、Ingress、Endpoint 等情况下需要更多的内存运行资源来避免 OOMKilled当节点规格限制不足以执行 VPA 操作时官方推荐方案仍然是通过 StatefulSet 工作负载拉起多个 kube-state-metrics 副本并且每个实例都对 K8s API Server 执行完整的 ListWatch 访问后再通过 Shard Hash 的方式来实现 HPA 的目标——这同样会酿生本次 OpenAI 的故障。 为此我们也积极拥抱大数据社区的前沿技术如通用内存列式数据格式对 kube-state-metrics 进行重构改写获得更高的数据压缩比通过单副本运行即可实现大规模集群中资源状态指标的稳定产出避免造成对 K8s API Server 的访问压力。
实现业务故障隔离的托管采集探针 - 旁路采集方案
传统 Prometheus 采集探针直接部署在用户容器集群内对集群内服务发现的采集目标定期抓取指标数据并上报阿里云 Prometheus 数据网关。 虽然云产品工程师具备对采集探针专业化的运维监控技能但由于没有直接操作集群环境的权限以往线上技术支持流程都依赖将命令发给用户执行操作不仅效率低并且可能遇到交流中理解不一致导致的排查方向错误。 另外当灾难发生时由于采集探针与业务同集群无法正常工作但灾难阶段又正是用户最需要一双“眼睛”来观测系统与业务的受损程度的时候。 因而我们着手转向 Serverless 这种服务模型。Prometheus 采集探针本质上是个 Probe不一定要部署在用户集群只要满足网络打通的条件所有探针运行在云产品托管的集群池中即可将采集能力 Serverless 化不仅可降低用户集群资源负担也有助于提升组件运维的灵活度。 在 OpenAI 本次故障中由可观测组件引起 K8s API Server/ CoreDNS 服务不可用同时导致集群内所有的观测活动陷入瘫痪在最需要可观测的时刻却进入了盲区。而使用托管探针模式则将观测组件本身与集群的故障隔离开来。尽管由于 API Server 不可用无法及时发现新的监控目标但已调度下发的采集任务仍可继续执行数据上报至云端存储也不再依赖于集群内的 CoreDNS。 综上使用托管形态的阿里云 Prometheus 容器监控服务可以屏蔽用户环境复杂性组件运行稳定性得到了更好的保障为更快的灾难恢复提供架构支撑在这种灾难性故障下托管探针模式的阿里云 Prometheus 容器监控服务依然能够确保一定程度的数据完整性。 可靠的数据链路 - out-of-band 带外数据链路建设
可观测性的另一个挑战是监控采集组件如果部署在用户集群侧当集群环境出现问题时监控系统也会一并宕掉不能起到观测异常现场的作用。 阿里云容器服务通过建设“带外数据链路(out-of-band)”来解决此问题。
ControlPlane 组件自身监控数据的带外数据链路
反映集群稳定性的关键指标、ControlPlane 组件的监控指标[5]数据通过托管侧的组件透出数据不受集群本身环境影响我们内部称为“带外数据链路(out-of-band)”。当集群本身异常时只会影响和集群内部环境相关的“带内链路(in-band)”而不会影响这些“带外数据链路(out-of-band)”。保证了集群稳定性的关键数据的可靠性。 阿里云容器服务托管集群通过部署单独的组件监控 ControlPlane 组件自身的监控数据。当关键控制面组件异常时保证监控数据的可靠性。 容器层以下的节点的虚拟机、硬件、操作系统层问题的带外数据链路
同理集群关键组件的事件、能感知集群中的节点ECS底层异常的主动运维事件也通过“带外数据链路”(out-of-band)直接写入到用户的 SLS 事件中心中。 以此方案形成与用户集群环境完全解耦的数据源、数据采集链路保证监控数据的可靠性。 参考文档容器服务托管节点池[6]对 ECS 系统事件[7]的透出。 四、最佳实践 - 用户如何正确地使用大规模 K8s 集群
K8s 本质是一个非常易用的分布式系统分布式系统由于 PAC 原则永远都存在承载能力的上限。 这里就还是需要 K8s 集群的用户不管作为 K8s 组件开发者还是 K8s 运维人员采用正确的使用方式来使用 K8s 集群才能在千级别节点的大规模 K8s 集群中保证集群的稳定性。 在此经过阿里云容器服务团队的经验沉淀我们提供涵盖事前预防观测、事后快速定位和恢复的成熟产品能力帮助用户构建集群稳定性运维体系。 4.1 集群规模控制容量规划正确的发布流程安全发布流程
首先站在运维的角度来看我们需要时刻考虑减小爆炸半径。
首先当用户的业务规模还未发展成需要一个大规模 K8s 集群来承载的程度时我们建议用户通过合理的容量规划来控制集群规模的大小如可以通过微服务架构等方式拆分业务的部署结构在不同的集群上以此来减小 K8s 规模。
其次站在发布的安全生产流程上我们需要考虑可灰度、可回滚、可监控的安全发布最佳实践。且每批灰度间隔需要充分观测逻辑是否符合预期且在观测到异常问题后应该马上回滚。
4.2 事前 - 观测能力与关键报警配置
成熟的集群控制面观测能力
首先用户可以通过我们阿里云容器服务提供的集群 ControlPlane 观测能力清晰感知到集群控制面组件的当前状态。我们提供 ACK 集群控制面监控大盘[8]以及控制面组件日志监控[9]功能帮助用户清晰透明地观测集群稳定性问题。 查看 ACK 集群控制面监控大盘[8] 在我们遇到的典型大规模集群故障场景如下图
场景 1用户侧组件异常请求泛滥导致 APIServer 负载过高
场景 2大请求导致的 K8s 集群 SLB 带宽被打满导致 APIServerRT 飙升、或者只读请求飙升。 我们可以通过集群控制面观测能力剖析问题样例如下 上面可观测能力可以帮助决策出精准的诊断路径 【问题快速发现】依据 API-Server 指标水位进行问题定位。 【根因快速定位】依据 API-Server 访问日志定位问题瓶颈应用并精准降级详见本文 4.3.4 节如何快速定位对控制面组件造成主要压力的“元凶”请求组件并快速降级。 【止血/闭环问题】停止/优化应用的 List-Watch 资源行为、性能最佳实践参考本文 4.2.3 节阿里云的组件稳定性优化。 经历经验沉淀的关键报警规则
虽然有强大的可观测能力但用户不可能每时每刻盯着监控大盘阿里云容器服务报警中心功能[10]为客户提供经过经验沉淀的 K8s 集群运维关键报警规则模版。 其中包括上文所提到的集群核心组件异常报警规则可以覆盖如 ControlPlane 组件异常、APIServer 的 SLB 带宽打满等场景的预警。 非常推荐用户确保这些报警规则开启并订阅通知到负责集群运维的 SRE 人员。您只需要购买集群时默认开启报警规则或在容器服务控制台运维管理-报警配置中开启规则并添加通知对象即可订阅。 开发 K8s 组件的最佳实践
规范组件 LIST 请求
必须使用全量 LIST 时添加 resourceVersion0从 APIServer cache 读取数据避免一次请求访问全量击穿到 etcd从 etcd 读取大量数据需要基于 limit 使用分页访问。加快访问速度降低对控制面压力。
序列化编码方式统一
对非 CRD 资源的 API 序列化协议不使用 JSON统一使用 Protobuf相比于 JSON 更节省传输流量。
优选使用 Informer 机制
大规模场景下频繁 LIST 大量资源会对管控面 APIServer 和 etcd 产生显著压力。频繁 LIST 的组件需要切换使用 Informer 机制。基于 Informer 的 LISTWATCH 机制优雅的访问控制面提升访问速度降低对控制面压力。
客户端访问资源频度
客户端控制访问大规模全量资源的频度降低对管控的资源和带宽压力。
对 APIServer 访问的中继方案
大规模场景下对于 Daemonset、ECI pod 等对 APIServer 进行访问的场景可以设计可横向扩容的中继组件由中继组件统一访问 APIServer其他组件从中继组件获取数据。例如 ACK 的系统组件 poseidon 在 ECI 场景下作为 networkpolicy 中继使用。降低管控的资源和带宽压力提升稳定性。 当前阿里云 Prometheus 也是采用此类中继逻辑来减少的集群负载从而避免随 K8s 和部署应用的规模笛卡尔积式地增大对集群的负载当然此类中继逻辑都需要针对组件定制开发。
4.3 事后 - 快速恢复与止血
K8s 故障的应急处理与快速恢复不仅需要建立常态化的故障演练和应急支撑机制还应涵盖从故障发生到恢复的全链路响应流程包括故障的实时监测、精准定位以及问题的及时解决。
定期演练和应急预案
需要通过定期开展演练与评估持续优化和演进应急预案可以提升整体故障应对能力和恢复速度减少故障对业务的影响时长和严重程度。这种系统性的能力建设将为 K8s 环境的稳定性和可靠性提供强有力的保障。 从具体应急措施的角度控制面由于请求压力过大导致出现无响应、OOM 甚至雪崩本质上需要限制请求尤其是 LIST 大量资源的请求这些请求处理的过程中对 etcd 和 apiserver 都会带来显著的开销apiserver 作为 etcd 的一种缓存集群中全部资源会缓存在 apiserver 内存中与此同时请求到达 apiserver 后apiserver 处理请求过程中产生的编解码也会占用缓存如果请求频繁而且请求资源数量巨大都会导致控制面 apiserver 内存骤增。 同时在有条件的情况下尽量扩容 Master 节点/组件内存和 CPU 资源。在实际应急中这个措施出于硬件资源的限制不总是能满足此时就需要更加依靠限流策略应急。 应急的限流策略
应急的限流策略包括1降低 apiserver inflight request 参数需要重启 APIServer 或者2根据监控发现访问压力过大的请求下发在故障演练充分验证过的 APF 限流规则包括针对指定 UA例如 OpenAI 案例中的 Telemetry 组件对应的 UA实现动态生效的限流效果。
CoreDNS 缓存策略可能会造成误导
注意不建议做 CoreDNS 的永久缓存[11]serve_stale 开启当真实发生集群控制面异常时延长 CoreDNS 内的缓存并不能延续业务 Pod 的正常运转状态CoreDNS 内过期缓存的 DNS 解析关系会让业务 Pod 发起的访问触达到完全错误的 IP 地址。 并且 CoreDNS 的缓存时长会一定程度上掩盖控制面组件已经异常的现象造成集群还正常运转的假象增加排查难度与排查时间。
快速定位对控制面组件造成主要压力的“元凶”请求组件并快速降级
如何通过控制面监控大盘定位到主要压力来源。 通过 daemonset 方式部署的组件并对集群控制面有高频率、大范围的 list、watch 请求是我们所遇到的集群控制面故障的最大元凶。 阿里云容器服务 APIServer 监控大盘的客户端粒度分析 阿里云容器服务 APIServer 监控大盘提供追溯调用来源方 client/操作资源 resource/操作行为 verb 等细粒度指标。 帮助 K8s 集群用户在出现控制面高负载预警或故障时能准确定位到大负载压力的来源并帮助决策快速降级掉“元凶”应用快速恢复整个集群稳定性。 admission controller (准入控制器) 造成的压力
K8s 提供动态准入Dynamic Admission Control能力由 admissionwebhook 配置以及 admissioncontroller 组成是 K8s 非常杰出的机制能像 AOP 一样帮助进行集群资源生命周期的改造行为。 但是 admissionwebhook 是第二大部分我们遇到的集群控制面故障的元凶admissionwebhook 由于会把用户自定义行为加入到 K8s 关键的资源生命周期中可能加大 K8s 集群本身的不稳定性。同时由于 admissionwebhook 会拦截所有监听的 k8s 对象的请求若定义不当admissionwebhook 在大规模 K8s 集群下会产生海量的 APIServer 负担。阿里云容器服务的控制面监控大盘专门设计希望通过控制面监控大盘定位到 admission controller 造成的压力。 阿里云容器服务 APIServer 监控大盘的准入控制 admissionwebhook 负载分析 五、总结
K8s 是业界主流的基础设施架构Prometheus 也已经成为新一代指标监控的实施标准我们面对的是巨大的客户体量超大规模的 K8s 集群可能遇到的风险及挑战是不可避免的。 我们只有持续关注故障沉淀下来的经验希望通过一次次故障事件学习并自审不断优化才能在应对挑战时更加从容以求更好地为用户提供更稳定、更可靠的基础设施。
链接
[01] CNCF Survey
https://www.cncf.io/reports/cncf-annual-survey-2023/
[02] Scaling Kubernetes to 7,500 nodes
https://openai.com/index/scaling-kubernetes-to-7500-nodes/
[03] OpenAI 故障报告
https://status.openai.com/incidents/ctrsv3lwd797
[04] 容器服务 K8s 控制面观测能力
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/monitor-control-plane-components/?spma2c4g.11186623.0.i1
[05] ControlPlane 组件的监控指标
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/monitor-control-plane-components/?spma2c4g.11186623.help-menu-85222.d_2_9_3_4.2532123eK3yhIa
[06] 容器服务托管节点池
https://www.alibabacloud.com/help/zh/ack/ack-managed-and-ack-dedicated/user-guide/overview-of-managed-node-pools?spma2c63.p38356.0.i5
[07] ECS 系统事件
https://www.alibabacloud.com/help/zh/ecs/user-guide/overview-of-ecs-system-events?spma2c63.p38356.0.i11#DAS
[08] ACK 集群控制面监控大盘
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/view-control-plane-component-dashboards-in-ack-pro-clusters?spma2c4g.11186623.0.i3
[09] 控制面组件日志监控
https://www.alibabacloud.com/help/zh/ack/ack-managed-and-ack-dedicated/user-guide/collect-control-plane-component-logs-of-ack-managed-cluster?spma2c63.p38356.help-menu-85222.d_2_9_2_5.43d44d31DICEnA
[10] 报警中心功能
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/alert-management?spma2c4g.11186623.0.i2
[11] CoreDNS 的永久缓存
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/dns-resolution-policies-and-caching-policies?spma2c4g.11186623.help-menu-85222.d_2_3_6_2.416b26cbrKataV#section-wvr-c0p-mtx
