本文整理自2024云栖大会刘佳旭演讲

引言

大家好，我是来自弹性计算容器服务的技术专家刘佳旭（花名：佳旭），很荣幸今天有机会做分享，我今天分享的主题是《ACK高可用稳定性最佳实践》。

随着云原生技术的快速发展以及在企业IT领域的深入应用，云原生场景下的高可用架构，对于企业服务的可用性、稳定性、安全性越发重要。通过合理的架构设计和云平台的技术支持，云原生高可用架构可以提供高可用性、弹性扩展性、简化运维管理、提升可靠性和安全性等多方面的优势，为企业提供了更加可靠和高效的应用运行环境。

Kubernetes是云原生的核心技术之一，提供了容器编排和管理的能力，包括基础设施自动化、弹性扩展性、微服务架构和自动化运维等，Kubernetes的应用高可用架构是云原生高可用的基石。本次会以阿里云容器服务ACK（Alibaba Cloud Container Service for Kubernetes）为例，介绍基于ACK的应用高可用架构和治理的最佳实践。

Kubernetes集群的

高可用场景的错误案例和痛点！

高可用架构容灾设计是K8s系统稳定性的基石，在生产环境有非常重要的意义。

我们先来看一下Kubernetes集群的高可用场景的错误案例和痛点，然后再看看ACK是如何通过架构设计、产品能力和最佳实践来应对这些问题的。

案例一：集群节点单可用区部署，可用区级别异常导致服务下线

在集群节点单可用区部署的场景中，K8s集群中的节点都被部署在同一个可用区中，可用区级别的异常（如可用区网络故障、硬件故障等）可能导致整个集群中的服务不可用。

案例二：集群节点多可用区部署，业务Pod没有配置按可用区打散

用户通过配置Pod打散调度规则，K8s自动将Pod分散调度到多可用区，从而确保某一可用区发生故障时集群范围内业务仍然能够正常运行。

在集群节点多可用区部署的场景中，如果业务Pod没有配置按可用区均匀打散，单可用区故障依然可能导致业务全部或者部分受损、服务下线。

案例三：对集群应用可用性、可用区维度节点可用性的健康监控告警不足

K8s层面应用的高可用监控对业务至关重要，需要在部分受损的情况下就可以告警或者通知自愈系统进行修复，可以显著提升1-5-10的快速告警能力；可用区级别健康节点监控，可以感知集群层面底层资源可用性并进行告警。

案例四：多集群的应用分发、流量控制以及高可用管理复杂

多个集群的应用分发、安全策略、流量控制、全局监控、作业分发如果没有统一管理平台纳管，会带来显著的复杂性。 在ACK的产品能力上，可以通过ACK One Fleet舰队，统一管理多个集群实例来提高整个系统的可用性，并在单个集群出现问题时自动切换到另一个集群实例上，从而保证系统的稳定运行。

ACK单集群高可用架构

在总结了常见的Kubernetes场景错误配置和痛点后，我们来看看ACK的单集群高可用架构以及如何应对高可用稳定性风险的。

我们来看一下ACK单集群高可用架构。左面是ACK集群的高可用架构图，上半部分是在ACK VPC中的资源，包括ACK的元集群（元集群是ACK专有版集群的形态，承载用户ACK托管版集群的控制面组件和托管组件），ACK元集群的节点和以Pod形态运行的托管组件分布在多个可用区，实现了高可用容灾能力；下半部分是在用户VPC中的资源，包括ECS、SLB、ECI等。

对于一个ACK托管版集群，包含控制面和数据面两部分。控制面组件全部以Pod形式运行在ACK的元集群中，使用KoK的架构进行管理，ACK负责管理控制面组件的全生命周期；数据面资源在用户的VPC中，ACK为用户提供可配置的高可用产品能力和最佳实践。

控制面实现可用区+节点级别高可用

全部控制面组件实现与阿里云ECS的可用区能力对齐的高可用打散。在3AZ地域，ACK Pro托管集群控制面的SLA是99.95%。对于不具备3AZ 的地域，ACK Pro托管集群控制面SLA是99.5%（不具备单可用区的故障容忍）。

以APIServer为例，多副本跨AZ、跨节点高可用部署方式，任何一个AZ失效不影响服务可用性。同时，支持etcd分区的增强治理能力，也就是：APIServer自动探测后端etcd端点健康度，自动移除异常为No Leader的后端etcd端点，即使etcd出现网络分区异常，ACK APIServer依然正常服务。控制面整体基于KoK架构，Pod形式自动化管理托管组件，具体包括：自动化强制跨AZ打散、探活健康检查以及自愈、自适应副本弹性、升级管理、节点异常自动迁移等。

数据面支持客户

配置丰富的高可用策略+最佳实践

在数据面，结合Kubernetes原生的调度能力（例如：拓扑分布约束 Topology Spread Constraints）和阿里云云产品能力，ACK对Pod支持基于节点、部署集、AZ等不同故障域，实现不同等级的高可用策略；对于应用负载，可以使用K8s的健康检查和自愈、PDB等策略提升应用负载的稳定性；负载均衡、虚机节点、云盘等云资源均支持Kubernetes场景下多AZ高可用配置以及相应的容器化配置界面。下面对数据面高可用最佳实践展开介绍。

单集群高可用

最佳实践-节点/可用区高可用

左上部分是业务Pod按节点、部署集和可用区打散调度以及容灾能力的示意图。应该将Pod尽量按节点和AZ打散，按需可以进行更严格的按部署集节点打散。

业务按节点打散分布

配置Pod的按节点反亲和调度策略，实现Pod按节点打散，达到业务的节点级别高可用。

业务按部署集节点打散分布

配置Pod的按部署集节点反亲和调度策略，实现物理机打散，达到业务的物理机级别高可用。

部署集是控制ECS实例分布的策略，将ECS实例分散部署在不同的物理服务器上，避免由于一台物理机失效导致多台ECS实例宕机。通过为节点池指定部署集，能够保证节点池扩容出的ECS实例不会分布于同一物理机上。

业务按多可用区打散分布

配置Pod的按AZ反亲和调度策略，实现Pod按可用区均匀打散，达到业务的可用区级别高可用。

单集群高可用

最佳实践-工作负载高可用

基于Kubernetes的功能，可以参考如下最佳实践来增强应用负载的可用性。

配置Pod拓扑分布约束

拓扑分布约束Topology Spread Constraints，可以确保Pod在不同的节点和可用区之间均匀分布，以提高应用程序的高可用性和稳定性。

适用于Deployment、StatefulSet、DaemonSet、Job、CronJob等工作负载。

配置Pod反亲和

Pod反亲和（PodAntiAffinity）用于调度Pod到不同节点，以提高应用程序的高可用性和故障隔离能力。

配置Pod Disruption Budget

PDB允许定义一个最小可用副本数，当节点处于维护或故障状态时，集群将确保至少有指定数量的副本保持运行。PDB可以防止过多的副本同时终止，尤其适合多副本处理流量型的场景。

配置Pod健康检测与自愈

配置不同类型的探针来监测和管理容器的状态和可用性，包括存活探针（Liveness Probes）、就绪探针（Readiness Probes）、启动探针（Startup Probes）

存活检查（Liveness）：用于检测何时重启容器。

就绪检查（Readiness）：确定容器是否已经就绪，且可以接受流量。

启动探测（Startup Probes）：用于检测何时启动容器。

单集群高可用最佳实践-企业版

容器镜像服务高可用配置

企业版容器镜像服务高可用配置包括可用区容灾和跨地域容灾两种最佳实践。

可用区容灾：使用企业版容器镜像服务及同城冗余OSS Bucket

生产环境使用企业版容器镜像服务，不使用个人版容器镜像服务，因为前者支持高可用、安全扫描等产品能力。

对于企业版镜像服务，在支持OSS同城冗余的地域，创建实例默认会创建支持同城冗余的OSSBucket，实现跨可用区高可用；如果OSS在地域新增支持同城冗余，用户可以在OSS控制台将镜像服务Bucket转换为同城冗余，进而实现镜像服务的同城冗余能力。

跨地域容灾：使用多地域企业版容器镜像服务，配置异地容灾

至少在两个不同的地域开通企业版容器镜像服务，将容器镜像同时推送至多个不同地域的企业版实例，来实现异地容灾。

概要流程如下：

1. 为不同地域的实例配置相同的自定义域名，并在集群中使用自定义域名拉取容器镜像。

2. 为不同地域间的实例配置镜像同步规则，确保核心的业务镜像存在于不同地域的实例中。

3. 为实例配置访问控制。

4. 切换域名解析实现容灾。

单集群高可用最佳实践-云资源

高可用以及K8s配置界面

阿里云云产品的高可用产品能力提供了Kubernetes的配置界面，以便用户按需灵活配置高可用能力。

以负载均衡高可用配置为例，我们来看一下云产品的高可用配置如何通过容器界面透出的。负载均衡系列云产品CLB/NLB/ALB均支持跨AZ容灾的产品能力。用户可以通过Kubernetes Service Annotation来指定CLB的主备可用区；指定NLB的多可用区。用户可以通过ALBConfig指定ALB的多可用区。注意应该与节点池中ECS可用区保持一致，可以减少跨可用区数据转发，提升网络访问性能。云产品的容器化配置方式都可以在阿里云官网查找。

单集群高可用最佳实践–应用可用性和

可用区内节点可用性的监控告警

配置应用负载副本不可用的监控告警

基于kube-state-metrics与工作负载副本相关的指标:

kube_deployment_status_replicas_unavailable

kube_deployment_status_replicas

kube_daemonset_status_number_unavailable

kube_statefulset_status_replicas

kube_statefulset_status_replicas_available 等等

来聚合分析应用负载 Deployment/Statefulset/Daemonset的不可用副本数、副本总数等。

基于该类指标可以发现应用是否存在不可用副本以及不可用副本占总副本数的百分比，实现服务部分受影响、全部影响的监控告警。ACK默认集成开启。

Prometheus告警示例如下：

集群可用区内不健康节点百分比的监控告警

K8s 的 kube-controller-manager 组件有统计可用区内的不健康节点数、健康节点百分比和节点总数，可以配置相关告警。

Prometheus告警示例如下：

多集群高可用最佳实践–多集群

通过ACK One Fleet管理

随着Kubernetes集群的广泛应用，企业往往需要运行和管理多个Kubernetes集群，由此带来一系列的问题，例如多集群的管理、对外提供统一的入口、多集群资源的调度等问题。ACK One舰队管理的Fleet实例是由ACK托管的，可以管理任意环境的Kubernetes集群，为企业提供一致的云原生应用管理体验。

该框图介绍了通过ACK One Fleet的统一控制面，对多集群进行应用分发、流量控制、安全策略、全局监控、组建管理和集群管理等功能，高效纳管公有云和IDC等形态集群。

通过多AZ、多集群实现集群容灾；通过ACK One GitOps多集群应用发布，实现应用容灾；通过ACK One多集群网关和同城Global Ingress，实现流量容灾。

高可用最佳实践案例

我们来看一个高可用最佳实践的案例 - 小红书。

小红书的线上生产环境（基于ACK Pro集群构建）以及业务对于稳定性有非常高的要求，将集群业务按可用区、部署集、节点充分打散，实现了不同故障容灾等级的高可用能力。

可用区高可用：确保可用区级别故障不会影响集群整体服务

部署集高可用：确保部署集内的ECS实例分散部署在不同物理服务器上，有效降低因单台服务器故障导致的服务中断风险。

节点高可用：确保单节点异常不会影响整体业务。

总结

云原生场景下的高可用架构设计和最佳实践，对于企业服务的可用性、稳定性、安全性至关重要，可以有效提高应用可用性和用户体验，提供故障隔离和容错能力等。本次分享介绍了ACK的高可用与稳定性架构及其最佳实践，基于全网数万个ACK Pro集群在控制面和数据面上的高可用性能力和经验总结，通过了在大规模、丰富场景的线上环境中的验证和锤炼，希望能这些经验为有相关需求的企业提供参考和帮助。目前，ACK的高可用稳定性架构、产品能力和最佳实践已经成为ACK集群稳定性的基石，ACK会继续为客户提供安全、稳定、性能、成本持续优化升级的云原生产品和服务！

阿里云容器团队诚招【开发&SRE】【产品经理】【PDSA】- 杭州、北京、深圳的岗位均可，欢迎大家帮助推荐。

/ END /