资源管理

节点有 4 核 CPU、8GB 内存

Pod A: Request CPU=1核, Limit CPU=2核
Pod B: Request CPU=1核, Limit CPU=2核
Pod C: Request CPU=1核, Limit CPU=2核

三个 Pod 都能调度成功（Request 之和 = 3核 ≤ 4核）
运行时 CPU：
  - 空闲时，A 可以用到 2 核，B 和 C 同理
  - 争抢时，按 Request 比例分配：各得 1/3 的 CPU

内存则不同：
  - Request 内存 = 保底，Limit 内存 = 最后一条红线
  - 一旦某个 Pod 内存使用超过 Limit，内核 cgroup 的 OOM Killer 直接把进程杀掉（kubelet 只是事后把原因上报为 OOMKilled）

resources:
  requests:
    cpu: "200m"      # 0.2 核，调度保底
    memory: "256Mi"   # 256MB 内存保底
  limits:
    cpu: "500m"       # 最多用 0.5 核
    memory: "512Mi"   # 超过 512MB 就 OOMKill

# Guaranteed：Request == Limit
resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

# Burstable：有 Request 但不等于 Limit，或只设了其中一项
resources:
  requests:
    cpu: "200m"
    memory: "256Mi"
  limits:
    cpu: "1000m"      # CPU 不等于 Request → Burstable
    memory: "512Mi"

# BestEffort：什么都没设
# 整个 resources 字段为空

1. BestEffort Pod（最先被杀）
2. Burstable Pod（使用量超过 Request 的先杀）
3. Guaranteed Pod（最后被杀，但超过 Limit 的仍然会被 OOMKill）

apiVersion: v1
kind: LimitRange
metadata:
  name: app-limits
  namespace: production
spec:
  limits:
    # 针对容器的限制
    - type: Container
      # 默认值（没设 limits 时自动填入）
      default:
        cpu: "500m"
        memory: "512Mi"
      # 默认 Request（没设 requests 时自动填入）
      defaultRequest:
        cpu: "100m"
        memory: "128Mi"
      # 最大值：不允许超过
      max:
        cpu: "4"
        memory: "8Gi"
      # 最小值：不允许低于
      min:
        cpu: "50m"
        memory: "64Mi"
      # Limit/Request 比例上限
      maxLimitRequestRatio:
        cpu: "4"       # limits.cpu / requests.cpu ≤ 4
        memory: "2"    # limits.memory / requests.memory ≤ 2

# 查看命名空间的 LimitRange
kubectl get limitrange -n production

# 查看详细信息（默认值和限制范围一目了然）
kubectl describe limitrange app-limits -n production

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: production
spec:
  hard:
    # 计算资源总量
    requests.cpu: "20"         # 所有 Pod 的 CPU Request 之和不超过 20 核
    requests.memory: "40Gi"    # 所有 Pod 的内存 Request 之和不超过 40GB
    limits.cpu: "40"           # 所有 Pod 的 CPU Limit 之和不超过 40 核
    limits.memory: "80Gi"      # 所有 Pod 的内存 Limit 之和不超过 80GB
    # 对象数量限制
    pods: "50"                 # 最多 50 个 Pod
    services: "10"             # 最多 10 个 Service
    configmaps: "20"           # 最多 20 个 ConfigMap
    secrets: "20"
    persistentvolumeclaims: "10"

LimitRange（个体约束）
  ├─ 给没设资源的 Pod 填默认值
  ├─ 限制单个 Pod 的 min/max
  └─ 限制 Limit/Request 比例

ResourceQuota（整体约束）
  ├─ 限制 namespace 的所有 Pod 资源总和
  ├─ 限制 Pod/Service/ConfigMap 等对象的数量
  └─ 超限时 API Server 直接拒绝创建

# 查看命名空间的 ResourceQuota
kubectl get resourcequota -n production

# 查看使用情况（已用/总量）
kubectl describe resourcequota team-quota -n production

# QA 环境 — 紧凑型
resources:
  requests:
    cpu: "50m"        # 0.05 核，够跑就行
    memory: "128Mi"
  limits:
    cpu: "200m"       # Limit/Request ≈ 4，给测试时一些弹性
    memory: "256Mi"   # 内存 Limit/Request ≈ 2
# 副本数：1（QA 不需要高可用）
replicas: 1

# 预发环境 — 中间态
resources:
  requests:
    cpu: "200m"       # 接近生产但缩减
    memory: "512Mi"
  limits:
    cpu: "500m"       # Limit/Request ≈ 2.5
    memory: "1Gi"
# 副本数：2（验证多副本行为）
replicas: 2

# 生产环境 — 保守型
resources:
  requests:
    cpu: "500m"       # 保底值能扛日常峰值
    memory: "1Gi"
  limits:
    cpu: "2000m"      # Limit/Request ≈ 4，给流量突发留空间
    memory: "4Gi"     # 内存 Limit/Request ≈ 4
# 副本数：3+ 并配 HPA
replicas: 3
# HPA 配置
hpa:
  minReplicas: 3
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

# values-qa.yaml
resources:
  requests:
    cpu: "50m"
    memory: "128Mi"
  limits:
    cpu: "200m"
    memory: "256Mi"
replicas: 1

# values-staging.yaml
resources:
  requests:
    cpu: "200m"
    memory: "512Mi"
  limits:
    cpu: "500m"
    memory: "1Gi"
replicas: 2

# values-production.yaml
resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    cpu: "2000m"
    memory: "4Gi"
replicas: 3
hpa:
  enabled: true
  minReplicas: 3
  maxReplicas: 10

helm install myapp ./myapp-chart -f values-qa.yaml -n qa
helm install myapp ./myapp-chart -f values-staging.yaml -n staging
helm install myapp ./myapp-chart -f values-production.yaml -n production