一、ACK集群类型解析与选型决策
在开始对接使用阿里云Kubernetes集群托管服务之前，首先需要理解ACK提供的不同集群类型及其适用场景。阿里云容器服务Kubernetes版（ACK）目前主要提供两种集群形态：ACK托管集群和ACK专有集群。
ACK托管集群的控制面完全由阿里云托管，用户只需负责Worker节点的创建与运维。托管集群又细分为Pro版和基础版。Pro版适用于企业生产与测试环境，提供99.95%的区域级SLA保障，单集群默认支持最大5000个Worker节点并可申请提高配额；基础版则仅供个人学习与测试，单账号最多创建2个集群，单集群仅支持10个Worker节点且不支持提高配额。两者的另一个重要区别在于，Pro版收取集群管理费用，而基础版不收取集群管理费用。
需要先登录阿里云控制台，点击：阿里云控制台
ACK专有集群的控制面需要用户自行创建并运维。根据官方公告，ACK专有集群已于2024年8月21日起停止新建（云盒场景除外），官方推荐在生产环境中使用ACK托管集群Pro版，它具有更高的可靠性、安全性以及更好的调度效率。
从架构角度看，ACK托管集群的管控面由阿里云统一管理，包括kube-apiserver、kube-controller-manager、kube-scheduler和etcd等核心组件。每一个托管集群的管控面包含至少2个kube-apiserver实例和3个etcd实例，并部署在不同的可用区以提供可用区级别的高可用性。这种设计显著降低了用户的运维负担，让团队可以更专注于业务应用的开发和部署。
对于大多数企业的生产环境，ACK托管集群Pro版是最佳选择。它提供了可赔付的SLA保障，具备etcd高频冷热备机制和异地容灾能力，同时支持从基础版或专有集群热迁移至Pro版。在成本方面，Pro版虽然收取集群管理费用，但相比自行维护Master节点的专有集群，整体TCO通常更低，尤其适合希望减少Kubernetes运维投入、聚焦业务创新的团队。
二、ACK托管集群创建与初始化配置
选定集群类型后，接下来进入集群创建阶段。阿里云ACK托管集群支持通过多种方式创建，包括控制台、API、Terraform、SDK以及CLI等，其中控制台方式最为直观便捷。
2.1 控制台创建流程
在阿里云控制台中进入\"容器服务Kubernetes版\"，点击\"创建集群\"，选择\"ACK托管集群\"。创建过程中需要配置以下关键参数：
集群名称：自定义命名，创建后仍可修改。集群规格：选择Pro版或基础版，生产环境务必选择Pro版。地域和可用区：地域一经创建不可修改。建议选择与用户和业务资源部署地域较近的地域以降低网络延迟，同时配置至少两个不同可用区以保证高可用。Kubernetes版本：仅支持创建最近三个次要版本，建议使用当前最新版本以获得更好的稳定性、性能和安全性更新。自动升级：开启后可在维护窗口期内自动升级集群控制面和节点池，有效降低版本维护负担。专有网络（VPC）和交换机：可选择自动创建或使用已有VPC。建议选择2个及以上不同可用区的交换机以保障高可用。安全组：确定集群的网络边界和基础安全访问策略。
集群创建完成后，需配置kubectl工具进行连接操作。在ACK集群列表页点击目标集群的\"连接信息\"，获取集群访问凭证即kubeconfig文件。将该文件内容加入本地的kubectl配置中，即可通过kubectl命令行工具管理集群资源。也可通过阿里云Cloud Shell在线终端工具直接访问集群。
2.2 Terraform声明式创建
对于基础设施即代码（IaC）实践者，可以使用Terraform声明式创建ACK托管集群。以下是一个基于阿里云Provider的Terraform配置示例：
# provider.tf terraform { required_providers { alicloud = { source = \"aliyun/alicloud\" version = \"~> 1.212\" } } } provider \"alicloud\" { region = \"cn-hangzhou\" } # 创建VPC和交换机 resource \"alicloud_vpc\" \"ack_vpc\" { vpc_name = \"ack-vpc\" cidr_block = \"10.0.0.0/8\" } resource \"alicloud_vswitch\" \"ack_vsw\" { vswitch_name = \"ack-vswitch\" cidr_block = \"10.1.0.0/16\" vpc_id = alicloud_vpc.ack_vpc.id zone_id = \"cn-hangzhou-g\" } # 创建ACK托管集群Pro版 resource \"alicloud_cs_managed_kubernetes\" \"ack_pro\" { name = \"my-ack-pro-cluster\" cluster_spec = \"ack.pro.small\" version = \"1.30.1-aliyun.1\" vswitch_ids = [alicloud_vswitch.ack_vsw.id] new_nat_gateway = true pod_cidr = \"172.20.0.0/16\" service_cidr = \"172.21.0.0/20\" enable_ssh = false install_cloud_monitor = true worker_number = 3 worker_instance_types = [\"ecs.g6.large\"] worker_system_disk_category = \"cloud_efficiency\" worker_system_disk_size = 40 runtime = \"containerd\" runtime_version = \"1.6.20\" } output \"kubeconfig\" { value = alicloud_cs_managed_kubernetes.ack_pro.kube_config sensitive = true }
该配置创建了一个包含3个Worker节点的ACK托管集群Pro版。需要特别注意的是，Pod CIDR和Service CIDR等网络地址段在集群创建后不可修改，因此规划阶段必须谨慎评估。
三、集群网络规划与CNI插件选择
网络配置是ACK集群对接使用中最关键也最容易被忽视的环节。ACK提供了两种容器网络接口（CNI）插件：Terway和Flannel，创建集群后无法切换，因此必须在创建阶段做出正确选择。
Terway是阿里云自研的CNI插件，基于弹性网卡（ENI）资源构建云原生容器网络方案。Pod可以直接分配VPC中的IP地址，实现容器与ECS虚拟机共享相同的网络层。由于不依赖VXLAN等隧道封装技术，Terway模式通信效率更高，特别适合大规模集群和对网络性能、访问控制有较高要求的场景。Terway支持包含型ENI模式和独占型ENI模式：独占型模式下每个Pod分配独立的ENI，网络性能极佳；包含型模式下多个Pod共享一个ENI，可提高节点上的Pod部署密度，并支持DataPath V2加速能力。
Flannel是一种传统Overlay网络解决方案。它在主机网络栈路由表中配置路由规则，容器间网络通信通过主机路由转发到目的Pod所在的主机。Flannel具有BGP宣告能力，会将本网络域的容器路由宣告给交换机，对于跨域的容器网络请求，流量将经过交换机及BGP路由路径转发至对应网络域的网关设备。Flannel配置相对简单，适合集群规模较小（如小于500个节点）且对网络无特殊需求的场景。
在网络地址规划方面，需要定义VPC自身网段、vSwitch网段、Pod地址段和Service地址段。这几个网段之间不能重叠，且需根据集群规模预留充足的IP地址数量。Pod CIDR决定了集群最多能容纳的Pod数量，每个节点会从该CIDR中划分一个子网段分配给该节点上的Pod。Service CIDR则决定了集群中Service资源的数量上限。
公网访问配置也需在创建时明确。如果集群节点需要拉取公共镜像仓库中的镜像，则需要开通公网访问能力。但出于安全考虑，生产环境通常建议使用ACR私有镜像仓库并通过内网拉取，避免公网暴露。
四、存储对接：动态存储卷与静态存储卷实践
容器化应用中的数据持久化是上云过程中的核心挑战。ACK通过CSI（Container Storage Interface）插件提供了与阿里云存储产品的深度集成，支持云盘和NAS等多种存储类型。
动态存储卷是推荐的存储管理方式。它无需预先手动创建存储资源，应用在创建持久卷声明（PVC）时，系统会根据PVC指定的StorageClass按需自动创建一个全新的存储卷及对应的持久卷（PV）。这种方式更灵活，支持存储卷在线扩容，特别适合需要按需分配存储资源的场景。
以云盘为例，以下是一个用于动态存储卷的StorageClass配置示例：
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: alicloud-disk-ssd provisioner: diskplugin.csi.alibabacloud.com parameters: type: cloud_ssd zoneId: cn-hangzhou-g fstype: ext4 readOnly: \"false\" reclaimPolicy: Retain volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true
在StorageClass中，type参数指定云盘类型：cloud_essd为ESSD云盘，cloud_ssd为SSD云盘，cloud_efficiency为高效云盘。reclaimPolicy设置为Retain意味着即使PVC被删除，底层的云盘资源仍会保留，防止数据意外丢失。allowVolumeExpansion启用后，PVC创建后仍可扩容存储容量。
动态存储卷的使用流程包括两个步骤。首先创建PVC引用StorageClass：
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ssd-pvc spec: accessModes: - ReadWriteOnce storageClassName: alicloud-disk-ssd resources: requests: storage: 20Gi
然后在Pod或Deployment中直接挂载该PVC：
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-storage spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest volumeMounts: - name: data mountPath: /data volumes: - name: data persistentVolumeClaim: claimName: ssd-pvc
云盘适用于对磁盘I/O要求高的单副本应用，如MySQL、Redis等数据库服务。如果多个Pod需要同时读写同一份数据，则必须使用NAS作为共享存储。NAS同样支持动态存储卷方式，通过StorageClass指定NAS文件系统类型和挂载参数即可实现多Pod间的数据共享。静态存储卷则适用于纳管已存在的存量存储资源，通过先创建PV再创建PVC的匹配绑定方式完成接入。
在使用存储卷时，需要注意几个关键限制：NAS存储卷仅支持NFS协议，NAS文件系统需与集群VPC保持一致，且不支持跨VPC挂载。存储卷使用期间请勿在控制台删除对应的挂载点，否则会导致节点I/O异常。有状态应用建议使用StatefulSet配合volumeClaimTemplates，为每个Pod自动分配独立的PVC和PV，确保Pod重新调度后仍能挂载原有数据。
五、镜像仓库对接：ACR免密拉取配置
容器镜像的管理和拉取效率直接影响应用部署体验。阿里云容器镜像服务ACR与ACK天然集成，提供高可用且支持大并发的镜像托管能力。
在对接使用ACR时，最常见的问题是认证配置。如果未配置公开匿名拉取功能，ACK集群每次拉取私有镜像仓库中的镜像时都需要提供用户名和密码完成认证。传统方案是将用户名和密码存储在Secret中，但这会带来几方面的问题：Secret经过Base64编码后仍是明文形式存在泄露风险；每个工作负载都需要手动填入imagePullSecrets；Secret不支持跨命名空间使用，增加了管理复杂度。
阿里云ACK提供了免密组件aliyun-acr-credential-helper来完美解决上述痛点。免密组件自动化完成拉取镜像时的认证流程，无需在YAML中配置imagePullSecrets。其工作流程是：免密组件从ACR实例获取临时账号和临时密码，将凭证信息保存到Secret中，再将Secret关联到组件配置中指定的ServiceAccount。使用这些ServiceAccount的工作负载会自动使用Secret中保存的临时账号和密码拉取镜像。组件支持同时管理多个命名空间的ServiceAccount，并根据配置定时更新临时账号和密码以降低凭证泄露风险。
免密组件提供托管和自行运维两种形态。托管形态支持1.22及以上版本的ACK托管集群、ACK Serverless集群和ACK Edge集群，功能特性更丰富，包括支持通过RRSA跨账号拉取镜像，无需自行运维；自行运维形态支持1.20及以上版本的ACK托管集群和ACK专有集群。需要注意的是，免密组件目前仅支持与ACR企业版以及2024年9月8日及更早创建的ACR个人版配合使用。
对于多账号场景下多个ACK集群共享一套ACR的需求，需要通过转发路由器TR（Transit Router）打通ACR实例与各业务集群的网络连通性。在运维账号部署企业级ACR服务作为共享镜像仓库，通过CEN-TR实现跨账号网络互联，同时在业务账号内开启Private Zone服务完成ACR域名的内网解析。这种架构可以有效降低多账号场景下的ACR实例成本，同时实现镜像仓库的统一权限管理和运维。
跨账号拉取镜像时，需要确保双方的VPC网络连通且相关域名可正常解析。阿里云提供了基于RAM角色的跨账号授权方案，配合免密组件即可实现无感知的安全镜像拉取。
六、日志与监控体系构建
生产级集群的可观测性建设是保障系统稳定运行的基础。ACK通过与阿里云日志服务SLS和可观测监控Prometheus版的深度集成，提供了完整的日志采集与监控告警方案。
在日志采集方面，ACK支持Logtail和LoongCollector两种采集组件。Logtail是日志服务提供的经典日志采集Agent，基于日志文件进行无侵入式采集，无需修改应用程序代码，采集日志不会影响应用运行。LoongCollector是新一代采集Agent，是Logtail的升级版，未来还将融合ARMS的相关采集能力，包括Prometheus抓取和eBPF无侵入采集等。在创建ACK托管集群时勾选\"使用日志服务\"选项，系统会自动部署日志采集组件。
日志采集支持DaemonSet和Sidecar两种部署方式。DaemonSet方式下，日志采集组件以DaemonSet形式部署在kube-system命名空间，每个节点上的日志采集Pod负责采集该节点上所有Pod的数据，包括标准输出和日志文件。这种方式资源消耗较低，适合大规模集群。Sidecar方式则为每个需要日志采集的应用Pod单独部署一个日志采集容器，适合需要对不同应用日志进行差异化处理的场景。
通过创建AliyunLogConfig自定义资源（CRD），可以精细控制日志采集的路径、格式和目的地。配置完成后，日志数据实时上传至SLS，即可借助SLS的查询分析、可视化仪表盘和告警监控能力快速定位问题。
在监控方面，ACK托管集群Pro版默认集成托管版Prometheus服务。创建集群时选择启用\"容器监控\"，系统会自动安装Prometheus组件并开始采集集群的各项指标。托管Prometheus免去了用户自行搭建和维护监控系统的负担，提供开箱即用的Kubernetes监控大盘，覆盖集群、节点、Pod、容器等多个维度的资源使用情况和性能指标。通过PromQL查询和告警规则配置，可以构建从系统层面到应用层面的立体监控体系，并通过钉钉、邮件等渠道及时接收告警通知。
需要特别说明的是，仅ACK托管集群Pro版收取集群管理费用，但日志服务SLS和可观测监控Prometheus版会根据实际数据量单独计费。基础版和专有版不收取集群管理费用，但使用阿里云日志和监控服务时同样会产生费用。
七、应用部署与运维最佳实践
完成基础设施对接后，应用部署和日常运维是确保业务稳定运行的核心环节。ACK作为企业级容器平台，提供了丰富的应用生命周期管理能力。
工作负载类型的选择需要根据应用特性决定。Deployment适用于无状态应用，如Web服务和API服务，Pod副本完全一致且可随意替换，支持滚动更新和回滚。StatefulSet适用于有状态应用，如数据库和分布式缓存，每个Pod拥有唯一标识和稳定的存储挂载，支持有序部署和更新。DaemonSet适用于需要在集群每个节点上运行的应用，如日志采集器和监控代理。Job和CronJob则分别适用于一次性任务和定时任务。
滚动更新是生产环境中最常用的发布策略。通过配置Deployment的更新策略，可以实现零停机发布：
apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: spec: containers: - name: app image: my-app:v2 readinessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 10 periodSeconds: 5 livenessProbe: httpGet: path: /live port: 8080 initialDelaySeconds: 20 periodSeconds: 10
在该配置中，maxUnavailable设为0表示更新过程中始终维持原有的Pod数量，maxSurge设为1表示允许最多多创建1个额外Pod。这样的配置结合就绪探针和存活探针，可以确保新版本Pod在完全就绪后才逐步替换旧版本Pod，实现平滑的无感知发布。
健康检查是保障应用自愈能力的关键。就绪探针决定Pod是否应该接收流量，存活探针决定Pod是否需要被重启。合理配置探针的初始延迟时间、检测周期和超时阈值，可以避免应用启动阶段被误判为不健康，同时确保故障Pod能够被及时重启恢复。
在资源管理方面，节点池的设计至关重要。节点池是对集群中节点的逻辑分组，用于统一管理具有相同配置的节点，如ECS规格、操作系统、容器运行时等。通过节点池可以实现节点的批量创建、扩缩容和升级，大幅简化集群运维。建议按业务类型或资源规格划分节点池，例如Web节点池使用通用型ECS规格，计算密集型节点池使用高性能规格。对于生产环境，需要为每个容器设置合理的资源请求和限制，避免单个Pod过度占用节点资源导致其他Pod受到影响。设置资源请求后，Kubernetes调度器可根据各节点的剩余资源量做出最优的调度决策。
大规模集群运行时需要特别注意几个方面。ACK托管集群Pro版默认支持最大5000个Worker节点，当集群规模较大（如超过500个节点或10000个Pod）时，建议密切关注API Server的负载情况和etcd的性能表现。开启集群自动升级功能，在维护窗口期内自动完成Kubernetes版本升级和OS CVE漏洞修复，可以有效降低版本维护负担。对于复杂的业务场景，如果单集群无法满足隔离性要求或存在地域分布需求，可以考虑将服务拆分到多个集群中并启用ACK One多集群舰队，实现统一的应用部署、流量管理和全局监控。
最后，安全责任共担模型需要被充分理解。ACK负责集群管控面组件以及集群服务相关阿里云基础设施的默认安全性。用户需要负责部署在云上的业务应用安全防护，以及对云上资源的安全配置和更新。建议为不同的运维角色创建RAM子账号并授予最小必要权限，避免使用主账号密钥操作集群。
八、生产环境落地路径总结
从测试环境到生产环境的完整落地路径建议分为三个阶段。第一阶段为测试验证期，创建ACK托管集群基础版或Pro版小规格集群进行功能验证，熟悉控制台操作、kubectl命令以及基本部署流程。第二阶段为试点上云，选择非核心业务进行生产试点，逐步完善网络规划、存储方案、日志监控体系和CI/CD流水线的集成。第三阶段为全面生产化，启用托管集群Pro版并开启自动升级等高级特性，实施节点池精细化管理，配置完整的监控告警和备份恢复策略，保障核心业务稳定运行。
对于首次使用ACK的用户，建议先通过快速入门体验熟悉基本操作并及时释放资源避免产生预期外费用。阿里云ACK的兼容原生Kubernetes特性，意味着已有的Kubernetes知识体系可以直接复用，企业现有的Kubernetes工作负载和Helm Charts通常可以不做改动直接运行在ACK之上。通过合理规划集群类型、网络方案和存储策略，并结合托管服务提供的可观测性和自动化运维能力，企业可以快速构建起稳定、安全、高效的云原生基础设施。
常见问题解答
Q1：ACK托管集群Pro版和基础版的主要区别是什么？
A：Pro版适用于企业生产环境，提供99.95%的SLA保障，单集群支持最大5000个Worker节点，具备etcd高频冷热备和异地容灾能力，支持自动升级和热迁移等功能，收取集群管理费用。基础版仅供个人学习测试，单账号最多创建2个集群，单集群仅支持10个Worker节点且不支持提高配额，不提供SLA保障。
Q2：创建集群时应该在Terway和Flannel之间如何选择？
A：Terway是阿里云自研CNI插件，Pod直接分配VPC中的IP地址，不依赖隧道封装技术，通信效率更高，适合大规模集群和对网络性能有较高要求的场景。Flannel配置更简单，适合集群规模小于500个节点且无特殊网络需求的场景。网络插件在集群创建后不可更改，必须根据实际业务需求提前规划。
Q3：如何实现ACK集群免密拉取ACR私有镜像？
A：安装免密组件aliyun-acr-credential-helper，在集群中部署该组件后会自动完成拉取镜像时的认证流程，无需在YAML中配置imagePullSecrets。组件支持托管和自行运维两种形态，需配合ACR企业版使用，同时需要确保ACR实例与ACK集群的网络连通。
Q4：动态存储卷和静态存储卷分别适用于什么场景？
A：动态存储卷无需预先创建存储资源，通过PVC关联StorageClass自动创建和绑定PV，更灵活且支持在线扩容，适合按需分配存储的场景。静态存储卷适用于纳管已有的存量存储资源，通过预先创建PV再匹配绑定PVC的方式接入，不支持在线扩容。
Q5：ACK托管集群应该如何配置日志采集？
A：创建集群时勾选\"使用日志服务\"选项，系统自动部署Logtail或LoongCollector采集组件。支持DaemonSet和Sidecar两种部署方式，通过创建AliyunLogConfig CRD精细控制日志采集规则，数据实时上传至日志服务SLS进行存储和分析。
Q6：如何实现应用的零停机滚动更新？
A：在Deployment的更新策略中设置maxUnavailable为0、maxSurge为1，同时配置就绪探针和存活探针。确保新版本Pod在完全就绪后才逐步替换旧版本Pod，配合健康检查机制即可实现平滑的无感知发布。
