site logo

Marico's space

site logo

Marico's space

首页
我的日志
我的游记
世界·视野
编程技术

技术合作:

look@marico.cc

+86 18660050334

 

EKS 生产环境加固指南：安全、Karpenter、成本与升级实战

服务器技术 2026-08-31 20:56:54 7

搭一个EKS集群20分钟就够，但把它跑稳、跑安全、跑省钱，那可就是另一回事了。Demo上跑通和扛住双十一流量之间，隔着安全加固、智能弹性伸缩、成本管控和版本升级这些硬活儿。

这篇聊聊EKS生产环境该做的那些事：安全策略怎么配、Karpenter怎么调、成本怎么砍、二次运营怎么搞。

EKS责任共担模型

┌─────────────────────────────────────────────────────────────────┐
│ AWS 负责（控制平面） │
│ • Kubernetes API server、etcd、调度器、控制器管理器 │
│ • 控制平面3可用区高可用 │
│ • 控制平面打补丁和可用性保障 │
├─────────────────────────────────────────────────────────────────┤
│ 你负责（数据平面 + 配置） │
│ • 工作节点（或者用 EKS Auto Mode / Fargate） │
│ • Pod安全、网络策略、RBAC权限控制 │
│ • 密钥管理、镜像扫描 │
│ • 插件管理、版本升级、成本优化 │
└─────────────────────────────────────────────────────────────────┘

第一部分：安全加固

1. RBAC权限控制和最小权限原则

默认拒绝 → 按角色授予具体权限 ├── 开发人员：只能读写自己命名空间的 Pod 和日志
├── CI/CD：只能部署到特定命名空间
├── 平台团队：cluster-admin（限少数人）
└── 应用服务：用最小权限的 ServiceAccount（IRSA）

IRSA（IAM Roles for Service Accounts，服务账号的IAM角色）： 把Kubernetes的ServiceAccount映射到IAM角色，Pod获取AWS权限时不需要节点级别的凭证。

apiVersion: v1
kind: ServiceAccount
metadata: name: s3-reader annotations: eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/s3-read-role

EKS Pod Identity（IRSA的升级版）：关联方式更简单，不需要管理OIDC信任策略。

2. 网络策略（默认拒绝）

默认情况下，所有Pod之间可以互相通信。必须锁死：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: name: default-deny-all namespace: production
spec: podSelector: {} policyTypes: - Ingress - Egress

然后按需显式放行需要的流量。用VPC CNI的网络策略功能或Cilium来执行。

3. 密钥加密

  • 信封加密：用KMS加密etcd里的Kubernetes密钥
  • External Secrets Operator：从阿里云密钥管理服务（Secrets Manager）或Parameter Store同步（根本不要把密钥存在etcd里）
  • 绝对不要把密钥提交到Git或打包进镜像
# EKS集群开启KMS信封加密
encryptionConfig: - resources: ["secrets] provider: keyArn: arn:aws:kms:eu-west-1:123456789:key/xxx

4. Pod安全标准

强制执行Pod Security Admission（已废弃的PodSecurityPolicy的替代方案）：

apiVersion: v1
kind: Namespace
metadata: name: production labels: pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/warn: restricted

restricted级别会禁止：特权容器、访问宿主命名空间、以root运行、权限提升。

5. 镜像安全

  • ECR镜像扫描：推送时扫描，发现严重漏洞就阻断部署
  • 镜像签名：用Cosign/Notation保证供应链安全
  • 准入控制：用Kyverno或OPA Gatekeeper强制策略（只允许已签名镜像、不许用:latest标签、必须设资源限制）

6. 控制平面日志

开启所有控制平面日志类型 → CloudWatch：

api | audit | authenticator | controllerManager | scheduler

审计日志是安全取证的命根子——它记录了对集群的每一次API调用。

第二部分：Karpenter智能计算

Karpenter已经取代Cluster Autoscaler成为生产环境标配。它根据实际Pod需求在秒级时间内调度合适规格的节点。

为什么选Karpenter而不是Cluster Autoscaler

特性 Cluster Autoscaler Karpenter
节点选择 固定的节点组 动态选择最优实例类型
扩容速度 分钟级 秒级
资源打包 有限 智能整合
Spot处理 基础 高级（多样化、中断处理）
实例灵活性 按节点组 任意满足约束的实例

Karpenter NodePool（v1 API）

apiVersion: karpenter.sh/v1
kind: NodePool
metadata: name: default
spec: template: spec: requirements: - key: karpenter.sh/capacity-type operator: In values: ["spot", "on-demand"] - key: kubernetes.io/arch operator: In values: ["arm64", "amd64"] # 兼容ARM64和x86 - key: karpenter.k8s.aws/instance-category operator: In values: ["c", "m", "r"] nodeClassRef: name: default disruption: consolidationPolicy: WhenEmptyOrUnderutilized consolidateAfter: 30s limits: cpu: 1000

Karpenter生产最佳实践

  1. SQS中断处理 — 配置Spot中断队列，让Karpenter优雅地排空节点（提前2分钟预警）
  2. NodePool隔离 — 系统Pod和应用Pod用不同的NodePool
  3. 中断预算 — 限制Karpenter一次能整合多少节点
  4. AMI版本锁定 — 锁定AMI版本让升级可预期（别让它自动更新）
  5. 开启整合 — 启用后会自动打包 workloads，减少节点数量
  6. 多样化实例类型 — 允许多种实例类型，Spot中断时存活概率更高

第三部分：成本优化

EKS费用一不小心就上天。来看看怎么控：

计算成本杠杆

手段 节省效果
Karpenter整合 30-50%（打包减少浪费）
无状态 workload 用 Spot 比按需最高省90%
Graviton（arm64）节点 性价比提升20-40%
基础负载用储蓄计划 稳态按需最高省72%
正确设置Pod资源请求 避免节点过度配置

基础负载 + 突发模式

基础负载（可预期） → 按需 + 储蓄计划（承诺消费）
突发流量（波动大） → Spot实例（便宜、可中断）
关键系统Pod → 按需（绝对不能中断）

正确设置Pod资源请求

resources: requests: cpu: 250m # Pod实际需要的（从监控数据来） memory: 512Mi limits: memory: 512Mi # 防止OOM影响邻居 # 不设CPU limit — 让它突发（CPU是可以压缩的）

关键点：CPU/内存请求设太大，Karpenter就得调度更多或更大的节点。用VPA推荐值或监控数据来校准请求。

干掉NAT网关费用

通过VPC终端节点路由AWS API流量（S3/DynamoDB的网关终端节点免费）：

不用VPC终端节点：Pod → NAT网关（$0.045/GB） → S3
用VPC终端节点： Pod → S3网关终端节点（免费） → S3

第四部分：网络

VPC CNI配置

  • 前缀委托 — 给ENI分配/28前缀（每个节点跑更多Pod）
  • 自定义网络 — Pod放在和节点不同的子网
  • Pod安全组 — 在Pod级别应用安全组（不只是节点级别）

入口和负载均衡

方案 适用场景
AWS Load Balancer Controller ALB（七层）或NLB（四层）入口
Ingress（ALB） HTTP/HTTPS路由、路径路由
Gateway API Ingress的现代替代（表达能力更强）
VPC Lattice 跨集群服务网格，带IAM认证

服务网格（需要时再加）

不要默认就上服务网格。只有当你真的需要时才加Istio/Linkerd：

  • 所有服务间mTLS通信
  • 高级流量管理（重试、熔断）
  • 详细的七层可观测性

简单场景下，VPC Lattice或App Mesh就够了。

第五部分：可观测性

指标 → CloudWatch Container Insights + Prometheus（托管版）
日志 → Fluent Bit → CloudWatch Logs / OpenSearch
链路 → ADOT（OpenTelemetry） → X-Ray
仪表盘 → 托管Grafana

必监控的核心指标

  • 节点CPU/内存压力
  • Pod重启次数（崩溃循环）
  • Pending状态的Pod（容量不足）
  • Karpenter调度延迟
  • 持久卷使用量
  • API服务器延迟

第六部分：版本升级

EKS支持的Kubernetes版本周期约14个月。得提前规划升级：

升级策略

  1. 读变更日志 — 检查废弃的API（用kubent或Pluto找出它们）
  2. 先升级控制平面 — AWS处理，一次只升一个小版本
  3. 升级插件 — VPC CNI、CoreDNS、kube-proxy必须兼容
  4. 升级节点 — 滚动替换（Karpenter让这事简单——排空+用新AMI调度节点）
  5. 先在非生产环境测试 — 永远如此

EKS Auto Mode（一键简化）

EKS Auto Mode（正式发布）自动管理计算、弹性和升级：

  • AWS在后台管理节点调度、打补丁、Karpenter
  • 你专注 workloads，不用管基础设施
  • 代价：控制权少一点、成本稍高一点，但运维负担大大降低

适合用Auto Mode的场景：平台团队小、希望最小化Kubernetes运维开销。

第七部分：韧性

备份和灾难恢复

  • Velero — 备份集群状态和持久卷
  • 多可用区 — 节点分布在3个AZ（Karpenter会自动处理）
  • Pod中断预算 — 确保中断期间保持最小副本数
  • 跨区域DR — GitOps（ArgoCD）从Git向灾备集群重新部署

Pod中断预算

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: name: api-pdb
spec: minAvailable: 2 selector: matchLabels: app: api

保证节点排空或升级期间至少2个API Pod在运行。

生产就绪检查清单

安全
☐ 最小权限RBAC
☐ IRSA / Pod Identity（不用节点级AWS凭证）
☐ 每个命名空间默认拒绝网络策略
☐ 密钥加密（KMS信封或External Secrets）
☐ Pod安全标准（restricted）
☐ ECR镜像扫描 + 准入控制
☐ 控制平面审计日志已开启 计算
☐ Karpenter配置Spot + 按需 + Graviton
☐ SQS中断处理
☐ 已开启整合
☐ Pod资源请求设置合理 成本
☐ VPC终端节点（消除NAT费用）
☐ 基础负载用储蓄计划
☐ 无状态 workload 用 Spot 可观测性
☐ Container Insights + Prometheus
☐ 集中日志（Fluent Bit）
☐ 分布式链路追踪（ADOT） 韧性
☐ 多可用区节点分布
☐ Pod中断预算
☐ Velero备份
☐ 已验证升级路径 GitOps
☐ ArgoCD / Flux声明式部署
☐ 所有集群配置在Git管理

EKS生产常见错误

错误 后果 修复方法
不设置资源请求/限制 节点过度分配，OOM被杀 根据监控数据设请求值
所有流量走NAT网关 数据处理费用爆表 S3/DynamoDB用VPC终端节点
没有网络策略 被入侵后横向移动 默认拒绝+显式放行
节点级IAM凭证 Pod权限过大 用IRSA / Pod Identity
还在用Cluster Autoscaler 扩容慢、效率低 迁移到Karpenter
没有PDB 升级时业务中断 设置Pod中断预算
忽视版本支持窗口 被迫紧急升级 制定定期升级节奏
etcd里的密钥没加密 泄露风险 KMS信封加密

总结

生产级EKS归结为七大支柱：

  1. 安全 — RBAC、IRSA、网络策略、Pod安全标准、镜像扫描、审计日志
  2. 计算 — Karpenter配合Spot+按需+Graviton，智能整合
  3. 成本 — VPC终端节点、储蓄计划、Spot、合理资源请求
  4. 网络 — VPC CNI调优、ALB Controller、Gateway API
  5. 可观测性 — Container Insights、Prometheus、ADOT链路追踪
  6. 升级 — 定期节奏、插件兼容性，或者用EKS Auto Mode
  7. 韧性 — 多可用区、PDB、Velero备份、GitOps

如果团队小、Kubernetes运维是负担，认真考虑EKS Auto Mode——它帮你搞定大部分计算、弹性和升级的复杂度，让你专心搞业务。