300+ ACK 小集群整合至统一共享集群架构与迁移方案

📊 一、现状分析

• 集群规模：300+ 套最小规格集群（每套 3 Master + 3 Worker）
• 业务形态：以无状态应用为主，配套 RDS 实例、HostPath 本地存储
• 依赖服务：ACK（容器服务）、ACR（镜像仓库）、EDAS（企业级分布式应用服务）、SLB（负载均衡）
• 核心痛点 ：
  • 资源碎片化严重，节点装箱率低，存在大量闲置计算/存储资源
  • 300+ 套控制面独立运维，版本升级、安全补丁、监控告警成本高
  • HostPath 强依赖节点本地磁盘，存在数据丢失风险且无法跨节点调度
  • 缺乏统一弹性能力，无法按业务波峰波谷动态调整资源

🎯 二、目标与架构设计原则

原则	说明
资源共享	通过 Namespace 实现业务逻辑隔离，共享底层计算、网络、存储资源
存储改造	全面替换 HostPath，采用 NAS（共享读写）/云盘（高性能独占）/OSS（海量非结构化）
弹性能力	启用 HPA（Pod级）+ CA/ACK弹性组件（节点级），实现秒级/分钟级动态伸缩
服务整合	保留原有 SLB/RDS，通过 Service/Ingress 统一暴露与路由，减少云产品实例数量
管控统一	应用发布/回滚交由 EDAS 托管，监控接入 CMS ，日志统一采集至 SLS

🏗️ 三、目标架构概览

┌─────────────────────────────────────────────────────────────┐
│                    ACK 共享控制面 (托管多AZ)                   │
│  etcd 自动备份 / 审计日志 / RAM 统一鉴权 / 网络插件 Terway     │
└───────────────────────┬─────────────────────────────────────┘
                        │
        ┌───────────────┼───────────────┬───────────────┐
        ▼               ▼               ▼               ▼
   通用节点池      计算优化节点池     高内存节点池     弹性节点池(ECI)
  (Web/API)      (批处理/计算密集型) (缓存/内存DB)   (突发/临时负载)
        │               │               │               │
        └───────────────┼───────────────┘               │
                        ▼                               ▼
              ┌─────────────────┐               ┌──────────────┐
              │ 多租户运行时层   │               │  外部云服务   │
              │ ns-teamA/prod   │◄──Ingress──►│ SLB / RDS    │
              │ ns-teamB/dev    │               │ ACR / CMS    │
              │ ns-legacy-001   │               │ SLS / EDAS   │
              └────────┬────────┘               └──────────────┘
                       ▼
        ┌─────────────────────────────────────┐
        │ 治理与可观测面                       │
        │ ResourceQuota / LimitRange / NP     │
        │ EDAS(发布回滚) / CMS(监控) / SLS(日志)│
        └─────────────────────────────────────┘

💾 四、存储改造方案（HostPath → 分布式存储）

1. 存储选型策略

场景	推荐存储	挂载模式	说明
多节点共享配置/静态资源/日志归档	NAS	ReadWriteMany	支持高并发读写，跨 AZ 可用，按需付费
数据库/缓存/高频 IO 应用	云盘 (ESSD)	ReadWriteOnce	低延迟高 IOPS，单 Pod 独占挂载
海量图片/视频/备份文件	OSS + CSI	ReadOnlyMany/ReadWriteOnce	通过 ossfs 或 gocryptfs 挂载，适合归档

2. 迁移实施步骤

1. 评估阶段：梳理 HostPath 数据量、访问频率、读写模式、依赖应用
2. 创建 PVC ：为每个业务定义 StorageClass，生成对应 PVC
3. 数据同步 ：使用 rsync/rclone/ossutil 将 HostPath 数据迁移至 NAS/云盘
4. 分批切换 ：修改 Deployment volumeMounts 指向 PVC，灰度验证数据一致性
5. 性能验证：压测 IO 延迟/吞吐，调整云盘性能级别或 NAS 带宽规格

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-nas-pvc
  namespace: ns-teamA
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: nas-default
  resources:
    requests:
      storage: 100Gi

🚀 五、应用迁移与隔离

1. 命名空间与资源配额

• 按原集群/业务线/环境划分 Namespace（如 ns-legacy-001, ns-payment-prod）
• 通过 ResourceQuota 限制 CPU/Memory/PVC 数量，防止资源抢占

apiVersion: v1
kind: ResourceQuota
metadata:
  name: quota-ns-teamA
  namespace: ns-teamA
spec:
  hard:
    requests.cpu: "16"
    requests.memory: 32Gi
    limits.cpu: "32"
    limits.memory: 64Gi
    persistentvolumeclaims: "20"

2. 无状态应用部署

• 使用 Deployment 管理 Pod，配合 HPA 实现指标驱动扩缩容
• 探针补充（Readiness/Liveness/Startup）保障流量安全摘除与自愈

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
  namespace: ns-teamA
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app-deployment
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Pods
          value: 2
          periodSeconds: 60

📈 六、弹性伸缩协同机制

组件	职责	触发条件	协同策略
HPA	Pod 级扩缩容	CPU/内存/QPS/自定义指标超阈值	优先扩容 Pod，利用现有节点资源
CA / ACK 弹性组件	节点级扩缩容	Pod Pending / 节点资源利用率过高/过低	HPA 扩容导致 Pending 时触发 CA 扩容
伸缩防抖	避免频繁震荡	缩容冷却时间 scale-down-delay-after-add: 10m	负载下降后延迟缩节点，先缩 Pod 再缩节点

💡 ACK 最佳实践 ：启用 ack-kubernetes-elasticity（基于 Karpenter 架构），支持按需实例/Spot 实例混合调度，结合 EDAS 发布策略实现无缝弹性。

🌐 七、网络与访问管理

1. SLB 集成

• 通过 type: LoadBalancer 自动创建 SLB 实例，或通过 Annotation 绑定已有 SLB
• 支持会话保持、健康检查、跨 AZ 容灾

apiVersion: v1
kind: Service
metadata:
  name: app-service
  namespace: ns-teamA
  annotations:
    service.beta.kubernetes.io/alicloud-loadbalancer-id: "lb-xxxxxxxx"
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app: my-app

2. Ingress 统一入口

• 部署 ALB Ingress Controller，按域名/路径路由，复用单台 ALB
• 统一 TLS 证书管理、WAF 集成、限流熔断

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: ns-teamA
spec:
  ingressClassName: alb
  rules:
    - host: app1.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app1-service
                port:
                  number: 80

3. 网络隔离

• 默认启用 deny-all NetworkPolicy，按业务白名单开放跨 Namespace/Service 访问
• Terway CNI 原生支持安全组绑定，实现 Pod 级网络策略

📊 八、可观测性体系（CMS + SLS）

1. 云监控 CMS

• 安装 ack-node-exporter 与 ack-cloudmonitor 组件，自动采集：
  • 节点/Pod 资源使用率、HPA 伸缩事件、CA 节点变更日志
  • SLB 连接数、RDS QPS/延迟、NAS/云盘 IO 性能
• 配置多维度告警规则（CPU>80%、HPA 频繁抖动、节点 NotReady、PVC 容量>90%）

2. 日志服务 SLS

• 部署 logtail-ds DaemonSet，通过 aliyun-log-controller 自动识别 Namespace/Label
• 按 Namespace 创建独立 Project/Logstore，实现日志存储隔离与权限管控
• 支持日志索引、实时查询、智能告警、审计合规

# SLS 采集配置示例（通过 Annotation 自动注入）
apiVersion: v1
kind: Pod
metadata:
  namespace: ns-teamA
  annotations:
    aliyun.log.project: "proj-ns-teamA"
    aliyun.log.logstore: "app-logs"
    aliyun.log.logtail.config: "app-log-config"
spec:
  containers:
    - name: app
      image: registry.cn-hangzhou.aliyuncs.com/xxx/app:latest

🔄 九、应用发布与回滚（EDAS 托管）

能力	EDAS 实现方式
应用接入	将 ACK 集群注册至 EDAS，自动同步 Namespace/Deployment 状态
发布策略	支持分批发布、金丝雀、蓝绿发布；结合 HPA 实现流量与资源联动
版本管理	自动保留历史镜像版本与配置快照，支持一键对比差异
一键回滚	点击回滚自动恢复至上一稳定版本，Pod 滚动替换，零停机切换
流量治理	集成 EDAS 微服务治理（限流、熔断、降级、路由标签）

⚠️ 注意 ：EDAS 接管后，建议关闭手动 kubectl apply，统一通过 EDAS 控制台或 API 发布，确保发布过程可追溯、可审计、可回滚。

🛡️ 十、灾备与安全基线

• 数据备份：定期执行 ETCD 快照 + PVC 云盘快照 + RDS 逻辑备份，纳入 CMS 监控
• 权限管控：RAM 角色映射至 Namespace，遵循最小权限原则；EDAS 操作日志接入 SLS 审计
• 安全策略 ：启用 Pod 安全标准 (PSS)，禁止 hostNetwork/privileged；镜像强制 ACR 漏洞扫描
• 回滚预案：旧集群保留 30 天只读状态，关键业务配置 DNS 双写/SLB 权重切换，支持分钟级回切

🗺️ 十一、实施路径（分阶段落地）

阶段	周期	核心任务	交付物
Phase 1 准备	2~3周	搭建共享集群、配置 EDAS/CMS/SLS 对接、存储/网络压测、选取 5 个试点应用	基线集群模板、监控/日志看板、迁移 SOP
Phase 2 迁移	4~8周	按业务优先级分批迁移、数据同步、Ingress 路由切换、EDAS 接管发布	迁移清单、灰度切换记录、性能基线报告
Phase 3 调优	2~4周	HPA/CA 阈值校准、ResourceQuota 优化、SLS 告警策略固化、Spot 实例接入	弹性策略文档、成本优化报告
Phase 4 收尾	1~2周	旧集群只读观察、资源释放、账单对账、归档清理	下线确认单、ROI 分析、运维手册

⚠️ 十二、关键风险与应对

风险	影响	应对策略
爆炸半径过大	单集群故障波及所有业务	ACK 多AZ控制面 + 定期 etcd/PV 备份 + 混沌演练 + 核心业务保留独立集群
Noisy Neighbor	某业务突发拖慢共享池	严格 ResourceQuota + 节点池隔离 + Pod 优先级抢占 + 网络 QoS
迁移数据不一致	业务中断或脏数据	双写过渡期 + 数据校验脚本 + 可回滚切换流程 + EDAS 灰度发布
弹性震荡	HPA/CA 频繁扩缩容	设置 stabilizationWindowSeconds + 缩容冷却 + 基于复合指标触发
权限/策略爆炸	300+ 业务难以维护	EDAS 角色模板 + RAM 细粒度授权 + SLS/CMS 按 Namespace 隔离

---

✅ 预期收益

• 节点规模缩减 60%~80%，管理面从 300+ 降至 1 套
• 资源装箱率提升至 70%+ ，结合 Spot/弹性池降低计算成本 40%+
• 发布/回滚效率提升 3倍 ，监控/日志统一管控，MTTR 缩短 50%
• 彻底消除 HostPath 单点风险，存储高可用与跨节点调度能力就绪