AI云原生实战13-IDC的GPU闲置、云上的GPU太贵？混合云AI部署完整方案

📌AI云原生实战调研30篇系列 · 第13篇
🎯 混合云AI部署是75%企业的选择，但IDC的GPU在闲置、云上的GPU在烧钱。本文将带你从架构设计到完整YAML配置，搭建一个"数据不出域+GPU弹性扩缩"的生产级混合云方案。 读完这一篇，你能独立设计一套基于Amazon EKS的混合云AI架构。

你的IDC里躺着8张A100，利用率不到30%。云上按需租一张A100，一小时要花60块——训练一个大模型跑两周，光GPU费就是12万。

而隔壁团队的架构师老张，搞了一套混合云方案：

• 非核心推理任务 → 云上Spot实例，成本只有按需的20%
• 敏感数据业务 → 本地GPU兜底，数据不出域
• 集群通过KubeFed统一管理，一个API操作两个集群

他上个月拿到了最佳架构师奖。你还在手动ssh到不同集群部署模型。😶

📑 目录

一、混合云AI的"灵魂拷问"：为什么你有GPU还要上云？

二、架构设计原则：数据分级 + 计算弹性

2.1 数据分级策略

2.2 计算弹性策略

三、Amazon EKS混合云部署：从本地到云上的集群联邦

3.1 架构全景

3.2 EKS Anywhere：本地K8s集群

3.3 云端EKS集群配置

3.4 KubeFed v2集群联邦配置

3.5 ClusterAPI：节点声明式管理

四、网络连通：让IDC和云上通信如同局域网

4.1 网络方案对比

4.2 网络配置核心清单

4.3 CoreDNS跨集群服务发现

五、GPU调度策略：本地优先，云上兜底

5.1 调度优先级设计

5.2 调度器配置

六、Spot实例：60-90%成本优化与中断处理

6.1 Spot成本优势

6.2 Spot中断处理框架

七、模型同步：从本地训练到云上推理

7.1 同步架构设计

7.2 模型同步S3配置

八、完整部署实践：从零搭建混合云AI平台

8.1 部署流程图

8.2 一键部署脚本

8.3 验证命令

一、混合云AI的"灵魂拷问"：为什么你有GPU还要上云？

先上三个灵魂拷问：

1️⃣你IDC的GPU利用率是多少？低于40%的话，你花了100万买的硬件，有60万在吃灰。

2️⃣你的模型训练峰值需要多少GPU？可能偶尔需要集群跑128卡分布式训练，但平时可能只需要8张卡就够用了。图个峰值去建集群太贵，不建又不行。

3️⃣数据合规怎么搞？有些数据就是不能上公有云，有些业务又需要在云上弹性扩缩。你怎么拆分？

这三个问题，一个比一个要命。

混合云AI方案的诞生，就是这三个问题的解药。不是"上云还是不上云"的二选一，而是"该在哪跑就在哪跑"的灵活架构。

💡效率技巧 #1 —— 别让你的GPU在夜里"睡大觉"：很多公司的IDC GPU夜里利用率不到10%。正确的姿势：白天跑在线推理，夜里跑批量训练，再配合混合云把峰值load甩到云上。实践中，用这种"潮汐调度"能让GPU综合利用率从25%飙升到75%。

看一张大图，理解混合云AI的完整逻辑：

graph TD subgraph 本地IDC["🏭 本地IDC"] P1[敏感数据<br/>金融/医疗/政务] --> R1[本地GPU推理<br/>数据不出域] P2[本地训练集群<br/>常驻GPU] --> R2[模型训练<br/>固定成本] end subgraph 云端VPC["☁️ 公有云VPC"] P3[非敏感数据<br/>用户行为/公开数据] --> R3[Spot实例推理<br/>按需弹性] P4[突发训练任务<br/>峰值算力] --> R4[按需GPU实例<br/>弹性扩缩] end R1 <-->|模型同步<br/>增量+异步| R3 R2 -->|训练好的模型| R3 subgraph 管理面["🎮 统一管控"] C1[KubeFed<br/>集群联邦] --> R1 C1 --> R3 C1 --> R2 C1 --> R4 S1[Argo CD<br/>GitOps部署] --> C1 end style R1 fill:#4CAF50,stroke:#2E7D32,color:#fff style R2 fill:#2196F3,stroke:#1565C0,color:#fff style R3 fill:#FF9800,stroke:#E65100,color:#fff style R4 fill:#9C27B0,stroke:#6A1B9A,color:#fff style C1 fill:#F44336,stroke:#B71C1C,color:#fff

二、架构设计原则：数据分级 + 计算弹性

混合云AI架构的底层逻辑只有两条：数据去哪儿，计算就跟到哪儿。

2.1 数据分级策略

这是混合云的第一道选择题。不是什么数据都能上云，也不是什么都必须留在本地。

⚠️避坑警告 #1 —— L1数据不要在任何时候离开本地网络：哪怕"只是传一个batch做推理"也不行。数据出域就是合规事故。我在某银行见过一个真实的翻车案例：工程师觉得"就传10条数据到云上测试一下"，结果被DLP（数据防泄漏）系统抓个正着，全组通报批评。正确的做法：L1推理模型也用Triton Server在本地GPU上跑，远程只传加密后的推理结果。

2.2 计算弹性策略

弹性不是"云上无条件扩"。弹性也要讲策略：

弹性优先级策略： 1️⃣ 本地GPU还有空闲 → 优先本地跑 2️⃣ 本地不够但任务不紧急 → 等本地释放（队列排队） 3️⃣ 本地不够且任务紧急 → 创建云上GPU实例 4️⃣ 云上GPU还分On-Demand和Spot → 非关键任务走Spot

这个优先级不是靠人肉判断，是靠Kubernetes调度策略和Cluster Autoscaler自动完成的。

三、Amazon EKS混合云部署：从本地到云上的集群联邦

Amazon EKS提供了完整的混合云解决方案，从本地的EKS Anywhere到云端EKS，再加KubeFed做统一管理。

3.1 架构全景

graph LR subgraph 本地["🏭 本地IDC"] EKSA[EKS Anywhere<br/>本地K8s集群] LOCALGPU[本地GPU池<br/>A100/H100] end subgraph 云上["☁️ AWS云端"] EKSC[Amazon EKS<br/>云端K8s集群] SPOTGPU[GPU Spot实例池<br/>弹性扩缩] ONDEMAND[On-Demand GPU<br/>兜底保障] end subgraph 联邦["🔗 集群联邦层"] KF[KubeFed v2<br/>集群联邦] VA[Velero<br/>跨集群备份] end USER[User/CI/CD] --> KF KF --> EKSA KF --> EKSC EKSA --> LOCALGPU EKSC --> SPOTGPU EKSC --> ONDEMAND style KF fill:#F44336,stroke:#B71C1C,color:#fff style EKSA fill:#FF9800,stroke:#E65100,color:#fff style EKSC fill:#2196F3,stroke:#1565C0,color:#fff

3.2 EKS Anywhere：本地K8s集群

EKS Anywhere是AWS推出的本地Kubernetes发行版，跟云上的EKS是"同一套API，同一套体验"。

# eksa-cluster.yaml —— EKS Anywhere集群配置 apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: Cluster metadata: name: idc-ai-cluster namespace: default spec: clusterNetwork: cni: "cilium" # Cilium做CNI，支持NetworkPolicy pods: cidrBlocks: - 192.168.0.0/16 services: cidrBlocks: - 10.96.0.0/12 controlPlaneConfiguration: count: 3 machineGroupRef: name: idc-control-plane workerNodeGroupConfigurations: - count: 4 # 4个GPU工作节点 machineGroupRef: name: idc-gpu-workers name: gpu-worker workerNodeGroupAutoscaling: # 本地也做自动扩缩 maxCount: 8 minCount: 2 datacenterRef: kind: VSphereDatacenterConfig name: vsphere-datacenter kubernetesVersion: "1.29" # 跟云上EKS保持同版本 🔑

⚠️避坑警告 #2 —— EKS Anywhere和云上EKS必须同版本！KubeFed跨集群调度的一个硬性要求是K8s API版本兼容。如果本地是1.28、云上是1.30，KubeFed会报API版本不匹配错误。解决办法：在ClusterAPI模板中统一指定Kubernetes版本，升级时先升级本地、确认稳定后再升云上，保持版本差≤1个小版本。

3.3 云端EKS集群配置

# 通过eksctl创建云端EKS集群 apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: cloud-ai-cluster region: ap-northeast-1 # 东京区域，靠近IDC version: "1.29" managedNodeGroups: - name: spot-gpu-pool # Spot实例GPU池 instanceType: p4d.24xlarge # A100 40GB spot: true # 使用Spot实例 ✅ minSize: 0 # 支持从0开始扩缩 maxSize: 16 desiredCapacity: 0 labels: workload: inference instance-type: spot taints: - key: "spot" value: "true" effect: "NoSchedule" # Spot taint，只有容忍的Pod能调度 - name: ondemand-gpu-pool # On-Demand兜底池 instanceType: p4d.24xlarge spot: false minSize: 0 maxSize: 8 desiredCapacity: 0 labels: workload: inference instance-type: ondemand - name: cpu-pool # 轻量推理用CPU节点 instanceType: m6i.4xlarge spot: true minSize: 2 maxSize: 20 desiredCapacity: 2 addons: - name: kubefed # 安装KubeFed附件 - name: cluster-autoscaler # 集群自动扩缩

💡效率技巧 #2 —— 跨区域部署GPU节点池：不同AWS区域的GPU实例价格差异很大，最高能差到40%。比如美国西部（us-west-2）的p4d比东京便宜30%。如果你的业务对延迟不敏感（比如离线批量推理），用Cluster Autoscaler + 节点组标签做跨区域调度，成本还能再砍一刀。

3.4 KubeFed v2集群联邦配置

KubeFed v2是Kubernetes官方的集群联邦项目，能把多个K8s集群统一成一个"逻辑集群"来管理。

安装KubeFed：

# 在本地EKSA集群的管控节点上安装 kubefedctl federate --host-cluster-context idc-ai-cluster \ --kubefed-namespace kube-fed-system # 注册云端EKS集群到联邦 kubefedctl join cloud-ai-cluster \ --host-cluster-context idc-ai-cluster \ --host-cluster-namespace kube-fed-system \ --cluster-context cloud-eks-cluster-context

配置联邦资源分发：

# federated-deployment.yaml —— 联邦部署 apiVersion: types.kubefed.io/v1beta1 kind: FederatedDeployment metadata: name: inference-service namespace: ai-platform spec: template: # 基础模板 metadata: labels: app: inference-service spec: replicas: 3 selector: matchLabels: app: inference-service template: metadata: labels: app: inference-service spec: containers: - name: triton-server image: nvcr.io/nvidia/tritonserver:24.07-py3 args: ["tritonserver", "--model-store=/models"] resources: limits: nvidia.com/gpu: 1 ports: - containerPort: 8000 - containerPort: 8001 placement: # 分放置策略 🎯 clusters: # 指定分发到哪些集群 - name: idc-ai-cluster - name: cloud-ai-cluster overrides: # 集群级覆盖 - clusterName: idc-ai-cluster # ❗ 本地集群覆盖 clusterOverrides: - path: /spec/replicas value: 3 # 本地部署3个副本 - path: /spec/template/spec/containers/0/env value: - name: DATA_SOURCE value: "local-postgres" - clusterName: cloud-ai-cluster # ❗ 云端集群覆盖 clusterOverrides: - path: /spec/replicas value: 5 # 云端部署5个副本 - path: /spec/template/spec/tolerations # 容忍Spot实例taint value: - key: "spot" operator: "Equal" value: "true" effect: "NoSchedule"

关键逻辑解释：

• template：定义Pod的基本模板，跟普通Deployment一样
• placement：指定分发到哪些集群。可以加ClusterSelector按标签选择
• overrides：不同集群的差异化配置。本地用Postgres，云端用Spot实例

⚠️避坑警告 #3 —— Overrides的路径要跟集群实际API资源结构一致：KubeFed的path不支持Wildcard。比如你想改container的第0个元素的env，必须写成/spec/template/spec/containers/0/env。如果写成/spec/template/spec/containers/[name=triton-server]/env，KubeFed不会解析——它只认JSON Patch规范的路径语法。

3.5 ClusterAPI：节点声明式管理

ClusterAPI让GPU节点像Pod一样声明式管理——声明"我要8张A100"，ClusterAPI自动在云上创建对应的EC2实例并加入集群。

# clusterapi-machinedeployment.yaml —— ClusterAPI节点声明 apiVersion: cluster.x-k8s.io/v1beta1 kind: MachineDeployment metadata: name: gpu-node-pool-spot namespace: capa-system spec: clusterName: cloud-ai-cluster replicas: 2 template: spec: version: v1.29.2 bootstrap: dataSecretName: node-bootstrap-data infrastructureRef: apiVersion: infrastructure.cluster.x-k8s.io/v1beta2 kind: AWSMachineTemplate name: gpu-spot-machine-template --- apiVersion: infrastructure.cluster.x-k8s.io/v1beta2 kind: AWSMachineTemplate metadata: name: gpu-spot-machine-template namespace: capa-system spec: template: spec: instanceType: p4d.24xlarge # A100 40GB spotMarketOptions: # 使用Spot实例 ✅ maxPrice: "15.00" # 最高出价15美元/小时 iamInstanceProfile: "gpu-node-role" securityGroupOverrides: - sg-xxxxxxxxxxxxx subnet: filters: - name: tag:Name values: - "private-subnet-az-1a" rootVolume: size: 200 type: gp3 additionalSecurityGroups: - id: sg-yyyyyyyyyyy - id: sg-zzzzzzzzzzz

四、网络连通：让IDC和云上通信如同局域网

网络是混合云的第一道坎——搞不好网络，后面的所有方案都是空中楼阁。

4.1 网络方案对比

💡效率技巧 #3 —— 模型同步不要走公网：模型文件通常在2-15GB之间，走公网同步一次可能十几分钟甚至半小时。正确做法：本地用S3 Gateway或DataSync将模型先同步到同一区域的S3，然后再从S3分发到推理节点。这样走的是AWS基础设施网络，速度比公网快5-10倍。

4.2 网络配置核心清单

# 网络配置清单（抄作业用） ┌─────────────────────────────────────────────────┐ │ 1️⃣ VPC设计 │ │ - IDC网段: 10.0.0.0/8 │ │ - 云上VPC网段: 172.16.0.0/16 (不重叠！) │ │ - Pod CIDR: 192.168.0.0/16 │ │ │ │ 2️⃣ 路由配置 │ │ - Direct Connect VIF + VGW │ │ - VPC路由表→目标IDC: TGW(virtual gateway) │ │ - IDC路由表→目标VPC: Direct Connect │ │ │ │ 3️⃣ DNS解析 │ │ - Route53 Inbound Resolver (云→本地) │ │ - Route53 Outbound Resolver (本地→云) │ │ - 服务发现: CoreDNS + global forwarding │ │ │ │ 4️⃣ 安全策略 │ │ - Security Group: 仅放通指定端口 │ │ - NACL: 子网级ACL │ │ - 跨云通信加密: WireGuard/IPSec │ └─────────────────────────────────────────────────┘

4.3 CoreDNS跨集群服务发现

KubeFed解决了资源同步的问题，但跨集群的服务发现还需要单独配置：

# coredns-configmap.yaml —— 跨集群DNS转发 apiVersion: v1 kind: ConfigMap metadata: name: coredns namespace: kube-system data: Corefile: | .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa } cloud-eks.local { forward . 172.16.100.2 # 云端CoreDNS的ClusterIP } prometheus :9153 forward . /etc/resolv.conf cache 30 loop reload loadbalance }

五、GPU调度策略：本地优先，云上兜底

5.1 调度优先级设计

GPU调度是整个混合云最核心的机制。我的方案分三层：

第一层：本地GPU优先 └─ 离线推理Pod → 调度到本地GPU节点 └─ 训练Pod → 调度到本地GPU节点 第二层：本地不够 → 排队等待 └─ 非紧急任务 → 进入本地队列（延迟容忍） 第三层：本地不够且紧急 → 上云 └─ 紧急推理 → 调度到云端GPU节点 └─ 批量训练 → 调度到云端Spot节点

5.2 调度器配置

# scheduler-config.yaml —— 自定义调度配置 apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration profiles: - schedulerName: default-scheduler plugins: score: disabled: - name: NodeResourcesFit enabled: - name: NodeAffinity weight: 70 - schedulerName: local-first-scheduler plugins: filter: enabled: - name: NodeSelector score: enabled: - name: NodeAffinity weight: 80 pluginConfig: - name: NodeAffinity args: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: topology.kubernetes.io/region operator: In values: - idc-on-premises - weight: 50 preference: matchExpressions: - key: topology.kubernetes.io/region operator: In values: - aws-cloud

调度优先级Pod配置：

# inference-pod.yaml —— 推理Pod调度配置 apiVersion: v1 kind: Pod metadata: name: model-inference-pod annotations: scheduler.alpha.kubernetes.io/critical-pod: "" spec: schedulerName: local-first-scheduler affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: node-type operator: In values: - on-premises-gpu tolerations: - key: "node.kubernetes.io/unschedulable" operator: "Exists" effect: "NoSchedule" priorityClassName: high-priority containers: - name: inference image: myrepo/inference:latest resources: limits: nvidia.com/gpu: 1 env: - name: PRIORITY value: "HIGH"

六、Spot实例：60-90%成本优化与中断处理

Spot实例是混合云省钱的法宝，但也是双刃剑——省钱的同时也带来了中断风险。

6.1 Spot成本优势

💡效率技巧 #4 —— Spot价格不是固定的，选对时间省更多：Spot价格是动态变化的。统计显示，周二到周四白天Spot价格最高（大家都在用），周末深夜Spot价格最低（最低可达On-Demand的10%）。把非关键批量推理排到周末夜间，成本直接打到骨折。

6.2 Spot中断处理框架

Spot实例可能有2分钟的中断通知。你的模型推理服务必须在这2分钟内优雅退出。

# spot-interruption-handler.py —— Spot中断检测与优雅退出 import os import time import signal import requests import json class SpotInterruptionHandler: """ AWS Spot实例中断处理 监听Metadata Service的中断通知 → 优雅退出 """ INTERRUPT_URL = "http://169.254.169.254/latest/meta-data/spot/instance-action" def __init__(self): self.interrupted = False self.check_interval = 5 signal.signal(signal.SIGTERM, self._handle_sigterm) def _handle_sigterm(self, signum, frame): print("[SpotHandler] 收到SIGTERM信号，开始优雅退出...") self._graceful_shutdown("SIGTERM") def check_interruption(self): try: resp = requests.get(self.INTERRUPT_URL, timeout=2) if resp.status_code == 200: action = resp.json() if action.get("action") in ("stop", "terminate"): print(f"[SpotHandler] ⚠️ 收到中断通知！") self._graceful_shutdown("spot_interruption") return True except requests.RequestException: pass return False def _graceful_shutdown(self, reason: str): if self.interrupted: return self.interrupted = True print(f"[SpotHandler] 🚨 开始优雅关闭，原因：{reason}") self._save_checkpoint() self._mark_unavailable() time.sleep(30) os._exit(0) def _save_checkpoint(self): print(f"[SpotHandler] 保存检查点到S3...") # 实际生产中写入S3: aws s3 cp checkpoint s3://bucket/ def _mark_unavailable(self): print(f"[SpotHandler] 标记Pod {os.getenv('HOSTNAME', 'unknown')} 不可用") if __name__ == "__main__": handler = SpotInterruptionHandler() print("[SpotHandler] 开始监听Spot中断通知...") while True: try: if handler.check_interruption(): break time.sleep(handler.check_interval) except KeyboardInterrupt: break except Exception as e: print(f"[SpotHandler] 错误：{e}") time.sleep(10)

七、模型同步：从本地训练到云上推理

这是混合云最容易被忽视但最容易翻车的环节。

7.1 同步架构设计

graph LR subgraph 训练阶段["🎯 本地训练集群"] T[训练脚本<br/>PyTorch/DDP] --> M[模型权重<br/>2-15GB] M --> EX[模型导出<br/>TorchScript/ONNX] end subgraph 存储层["💾 模型存储"] EX --> S3[S3 / MinIO<br/>模型仓库] S3 --> V1[版本: v1.0.0] S3 --> V2[版本: v1.0.1] S3 --> V3[版本: v1.0.2] end subgraph 推理阶段["☁️ 云端推理集群"] S3 --> R1[Triton Server<br/>GPU推理节点1] S3 --> R2[Triton Server<br/>GPU推理节点2] S3 --> R3[Triton Server<br/>GPU推理节点3] end subgraph 同步策略["🔄 同步机制"] W[Watch模式<br/>监听S3新版本] --> D[Delta更新<br/>增量加载] D --> H[健康检查<br/>模型加载验证] H --> SW[流量切换<br/>蓝绿部署] end style T fill:#4CAF50,stroke:#2E7D32,color:#fff style S3 fill:#FF9800,stroke:#E65100,color:#fff style R1 fill:#2196F3,stroke:#1565C0,color:#fff style SW fill:#F44336,stroke:#B71C1C,color:#fff

7.2 模型同步S3配置

# model-sync.yaml —— 模型同步与自动加载 apiVersion: v1 kind: ConfigMap metadata: name: model-sync-config namespace: ai-platform data: model_repository: | storage_provider_config: s3: bucket: ai-models region: ap-northeast-1 use_https: true access_key_file: /secrets/s3-access-key secret_key_file: /secrets/s3-secret-key use_virtual_hosted_style: true model_config_poll_seconds: 30 model_load_retry_count: 3 model_load_thread_count: 4 version_policy: | specific: versions: [1, 2, 3] all: num_versions: 3 traffic_switch: | canary: initial_delay_minutes: 5 traffic_steps: [10, 50, 100] step_interval_minutes: 3 rollback_on_error: true --- apiVersion: apps/v1 kind: Deployment metadata: name: triton-inference-server namespace: ai-platform spec: replicas: 3 selector: matchLabels: app: triton-server template: metadata: labels: app: triton-server spec: containers: - name: triton image: nvcr.io/nvidia/tritonserver:24.07-py3 args: - "tritonserver" - "--model-repository=s3://ai-models" - "--model-control-mode=poll" - "--allow-model-control=true" - "--strict-model-config=false" resources: limits: nvidia.com/gpu: 1 env: - name: AWS_ACCESS_KEY_ID valueFrom: secretKeyRef: name: s3-credentials key: access-key - name: AWS_SECRET_ACCESS_KEY valueFrom: secretKeyRef: name: s3-credentials key: secret-key - name: AWS_DEFAULT_REGION value: ap-northeast-1 ports: - containerPort: 8000 - containerPort: 8001 - containerPort: 8002 volumeMounts: - name: dshm mountPath: /dev/shm volumes: - name: dshm emptyDir: medium: Memory sizeLimit: "8Gi"

八、完整部署实践：从零搭建混合云AI平台

好了，理论讲完了。我们来串一遍从零到一的完整部署流程。

8.1 部署流程图

sequenceDiagram participant U as 开发者 participant G as Git仓库 participant A as Argo CD participant L as 本地EKSA集群 participant C as 云端EKS集群 U->>G: git push YAML配置 G->>A: Webhook触发同步 A->>L: 同步本地集群配置 A->>C: 同步云端集群配置 Note over L,C: 步骤1：ClusterAPI创建GPU节点 L->>L: 检查本地GPU节点 C->>C: 创建Spot节点池 Note over L,C: 步骤2：KubeFed分发推理服务 L->>L: 部署3个推理副本 C->>C: 部署5个推理副本 Note over L,C: 步骤3：模型同步 U->>L: 本地训练新模型 L->>L: 模型导出→S3 C->>C: Triton检测新版本→加载 Note over L,C: 步骤4：流量路由 L-->>U: 敏感数据→本地推理 C-->>U: 非敏感数据→云端推理 Note over U,C: 步骤5：中断处理 C->>C: Spot中断通知 C->>C: 保存检查点→优雅退出 L->>L: 接管中断流量

8.2 一键部署脚本

#!/bin/bash # deploy-hybrid-cloud.sh —— 混合云AI平台部署 set -euo pipefail echo "================================================" echo "🚀 开始部署混合云AI平台" echo "================================================" # 1.1 部署本地EKSA集群 echo "📦 [1/6] 部署EKS Anywhere本地集群..." eksctl anywhere create cluster -f eksa-cluster.yaml echo "✅ 本地集群部署完成" # 1.2 创建云端EKS集群 echo "☁️ [2/6] 创建云端EKS集群..." eksctl create cluster -f cloud-eks-cluster.yaml echo "✅ 云端集群创建完成" # 1.3 配置Direct Connect专线 echo "🔗 [3/6] 配置Direct Connect..." aws directconnect create-virtual-interface \ --connection-id dxcon-xxxxxxxx \ --new-virtual-interface \ --virtual-interface-name ai-hybrid-vlan \ --vlan 100 \ --asn 65000 \ --virtual-gateway-id vgw-xxxxxxxx # 2.1 安装KubeFed echo "🔗 [4/6] 安装KubeFed集群联邦..." kubectl config use-context idc-ai-cluster helm repo add kubefed-charts https://raw.githubusercontent.com/kubernetes-sigs/kubefed/master/charts helm repo update helm upgrade --install kubefed kubefed-charts/kubefed \ --namespace kube-fed-system \ --create-namespace \ --set controllermanager.enable=false \ --set featureGates.PushReconciler=true # 2.2 注册云端集群到联邦 echo "🔗 注册云端集群..." kubefedctl join cloud-ai-cluster \ --host-cluster-context idc-ai-cluster \ --host-cluster-namespace kube-fed-system \ --cluster-context cloud-eks-cluster-context echo "✅ 集群联邦配置完成" # 3.1 部署联邦推理服务 echo "🤖 [5/6] 部署联邦推理服务..." kubectl apply -f federated-deployment.yaml kubectl apply -f federated-service.yaml echo "✅ 推理服务部署完成" # 3.2 配置Argo CD持续部署 echo "🎮 [6/6] 配置Argo CD..." kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml argocd cluster add idc-ai-cluster --name idc-cluster argocd cluster add cloud-eks-cluster-context --name cloud-cluster kubectl apply -f - <<EOF apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: ai-platform namespace: argocd spec: project: default source: repoURL: https://github.com/company/ai-platform-config targetRevision: main path: k8s-multi-cluster/ destination: name: idc-cluster namespace: ai-platform syncPolicy: automated: prune: true selfHeal: true EOF echo "================================================" echo "🎉 混合云AI平台部署完成！" echo "================================================" echo "" echo "📊 状态检查：" echo " kubectl get federateddeployment -A" echo " kubectl get pods -n ai-platform --context=idc-ai-cluster" echo " kubectl get pods -n ai-platform --context=cloud-eks-cluster-context" echo "" echo "🔗 访问推理服务：" echo " 本地: http://inference.idc-ai-cluster.svc:8000" echo " 云端: http://inference.cloud-eks-cluster.svc:8000"

8.3 验证命令

# 检查联邦资源是否同步 kubefedctl federate -f federated-deployment.yaml --dry-run # 验证跨集群服务发现 kubectl exec -it debug-pod -n default -- \ nslookup inference-service.cloud-eks-local # 触发模型更新 python3 trigger_model_update.py --model text-classifier --version 3

总结

混合云AI架构设计不是高科技，而是一道选择题——在数据安全、计算弹性、成本和运维复杂度之间找到你的最优解。

本文的核心要点：

1. 数据分级：L1敏感→本地IDC，L2/L3→云上，这是混合云的第一原则
2. 集群联邦：EKS Anywhere + EKS + KubeFed，一套API管两个世界
3. 网络是基础：Direct Connect或VPN，延迟和带宽决定一切
4. 调度策略：本地优先、云上兜底，KubeFed Overrides实现差异化
5. Spot省钱：60-90%成本优化，但必须配套中断处理
6. 模型同步：S3模型仓库 + Triton Server自动加载，蓝绿切换

📎 文末三件套

📦 源码获取

本文所有YAML配置和脚本已整理到GitHub仓库：

🔗GitHub:github.com/yourorg/ai-cloud-native-practice

📂 代码目录：ch13-hybrid-cloud-ai-deployment/

包含：EKS Anywhere配置、Cloud EKS配置、KubeFed联邦配置、Spot中断处理代码、Triton Server配置、一键部署脚本

🤔 思考题

1. 你们公司的GPU利用率是多少？低于40%的，认真考虑一下混合云架构是不是你的解药。
2. 如果你的Spot实例被回收了，模型推理服务能优雅退出吗？现在就去配一个中断处理器试试。
3. KubeFed的Overrides和Cluster API，你觉得哪个更适合你的场景？或者说，你有没有更好的方案？

📢 系列下一篇预告

第14篇：《模型优化三板斧——量化+剪枝+知识蒸馏》

• FP32转INT8精度只掉2%？模型量化实战深度对比
• 移除20%冗余神经元：结构化剪枝实践
• TinyBERT/DistilBERT：大模型压缩的蒸馏方案
• 300亿参数→30亿：一套完整的大模型"瘦身"流程
• 真实数据：优化后推理速度快4倍，显存减少75%

📅 预计下周三更新，敬请关注！

标签：#混合云 #Amazon EKS #GPU调度 #Spot实例 #KubeFed #AI部署 #IDC

系列：AI云原生实战调研30篇 · 第13篇

本文为作者原创，如需转载请联系作者获取授权。