AWS EKS Fargate 无节点运维实战：3 步部署 Serverless 容器负载

痛点：节点运维的隐性成本

运维 Kubernetes 最头疼的不是 Pod，是节点。AMI 升级、安全补丁、容量规划、Spot 中断处理……节点层面的运维占据了大量精力。

AWS EKS Fargate 提供了一种 Serverless 方案：只管 Pod，不管节点。Pod 调度到 Fargate 后，底层计算资源由 AWS 全托管，按 vCPU/内存实际用量计费。

本文基于生产实践，带你 3 步跑通 EKS Fargate，并给出选型建议和避坑指南。

方案概述：Fargate 工作原理

EKS Fargate 的核心是 Fargate Profile：你定义命名空间 + 标签选择器，匹配的 Pod 自动调度到 Fargate 而非 EC2 节点。

┌─────────────────────────────────────────────┐
│               EKS Control Plane             │
└─────────────────────────────────────────────┘
                      │
         ┌────────────┴────────────┐
         ▼                         ▼
┌─────────────────┐       ┌─────────────────┐
│   EC2 节点组     │       │  Fargate Profile │
│ (自管节点)       │       │ (AWS 托管计算)    │
│                 │       │                 │
│  ┌───┐ ┌───┐   │       │  ┌───┐ ┌───┐   │
│  │Pod│ │Pod│   │       │  │Pod│ │Pod│   │
│  └───┘ └───┘   │       │  └───┘ └───┘   │
└─────────────────┘       └─────────────────┘

实操步骤：3 步部署 Fargate 工作负载

第一步：创建 Fargate Profile

# 前提：已有 EKS 集群，这里假设集群名为 my-cluster

# 创建 Fargate Pod 执行角色（首次需要）
cat > fargate-trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks-fargate-pods.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

aws iam create-role \
  --role-name AmazonEKSFargatePodExecutionRole \
  --assume-role-policy-document file://fargate-trust-policy.json

aws iam attach-role-policy \
  --role-name AmazonEKSFargatePodExecutionRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy

# 创建 Fargate Profile：匹配 fargate-workloads 命名空间的所有 Pod
aws eks create-fargate-profile \
  --cluster-name my-cluster \
  --fargate-profile-name fp-default \
  --pod-execution-role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/AmazonEKSFargatePodExecutionRole \
  --selectors namespace=fargate-workloads \
  --subnets subnet-xxx subnet-yyy  # 私有子网

第二步：部署测试工作负载

# 创建命名空间
kubectl create namespace fargate-workloads

# 部署 Nginx 测试
kubectl apply -f - << 'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-fargate
  namespace: fargate-workloads
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25-alpine
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"
        ports:
        - containerPort: 80
EOF

# 等待 Pod 就绪（Fargate 首次调度约 30-60 秒）
kubectl get pods -n fargate-workloads -w

第三步：验证 Fargate 调度

# 确认 Pod 运行在 Fargate 节点
kubectl get pods -n fargate-workloads -o wide

# 节点名格式：fargate-ip-x-x-x-x.region.compute.internal
# 查看节点标签确认
kubectl get nodes -l eks.amazonaws.com/compute-type=fargate

# 检查 Pod 详情
kubectl describe pod -n fargate-workloads -l app=nginx | grep -A5 "Node:"

三个常见坑

坑一：DaemonSet 无法在 Fargate 运行

现象：监控 Agent（如 Datadog、Fluent Bit DaemonSet）无法采集 Fargate Pod 日志。

原因：Fargate 每个 Pod 独占一个微型 VM，没有传统意义上的"节点"，DaemonSet 无处部署。

解决： - 日志：使用 Firelens（Fluent Bit Sidecar）或直接发送到 CloudWatch Logs - 监控：用 ADOT Sidecar 或应用内 SDK 上报

# Firelens Sidecar 示例
spec:
  containers:
  - name: app
    image: my-app:latest
  - name: log-router
    image: amazon/aws-for-fluent-bit:stable
    firelensConfiguration:
      type: fluentbit

坑二：Fargate Pod 启动慢

现象：Pod 从 Pending 到 Running 需要 30-90 秒，影响弹性伸缩响应速度。

原因：Fargate 需要即时分配微型 VM + 拉取镜像，冷启动不可避免。

解决： - 使用 ECR 并开启镜像缓存 - 预留一定 Replica 数，避免从 0 扩容 - 对延迟敏感的负载，用 EC2 节点组 + Karpenter

坑三：不支持 EBS 持久卷

现象：使用 storageClassName: gp3 的 PVC 无法挂载。

原因：Fargate Pod 不支持 EBS CSI 驱动，无法挂载块存储。

解决： - 使用 EFS（NFS）作为持久存储 - 将状态存储到外部（RDS、ElastiCache、S3） - 有状态负载保留在 EC2 节点组

# EFS 存储类配置
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-xxxxxx
  directoryPerms: "700"

成本对比：Fargate vs EC2 节点

场景	Fargate	EC2 节点组
0.5 vCPU / 1GB × 10 Pod × 730h	~$53/月	m5.large 按需 ~$70/月
突发流量（日均 2h 高峰）	按实际用量	需预留容量或 Spot
节点运维成本	零	AMI/补丁/扩缩容

结论：稳定负载用 EC2 + Spot 更省，突发/低频负载用 Fargate 更划算。

生产选型建议

场景	推荐
无状态 API、定时任务、Job	✅ Fargate
数据库、有状态服务	❌ EC2 节点组
需要 DaemonSet 监控	❌ EC2 节点组
开发测试环境	✅ Fargate（省心）
高 QPS 低延迟服务	⚠️ 混合部署

总结

EKS Fargate 的价值是用成本换运维复杂度：

适合场景：无状态负载、定时任务、开发环境、突发流量
不适合场景：有状态服务、需要 DaemonSet、对启动延迟敏感
最佳实践：混合架构，核心服务用 EC2 节点组，辅助负载用 Fargate

Fargate 不是银弹，但在合适的场景下，能让你把精力从"修节点"转移到"写业务"。先在非核心负载试点，验证成本和延迟后再扩大范围。

饮墨