本文整理自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配置界面
