Kubernetes资源配额管理与Prometheus监控告警体系搭建实战

Kubernetes集群的资源管理直接影响应用的稳定性和资源利用率。未配置资源限制的Pod可能因内存溢出拖垮节点，也可能因CPU抢占导致关键服务延迟飙升。本文从资源配额、LimitRange、监控采集到告警规则，搭建一套完整的K8s资源管控与监控体系。

Kubernetes资源请求与限制配置

每个容器应配置resources.requests和resources.limits。requests决定调度器分配节点的依据，limits设置容器可使用的资源上限。两者配置不当是K8s集群中最常见的问题来源。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: api
        image: registry.example.com/api:v2.1
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1Gi"
        ports:
        - containerPort: 8080

CPU单位m表示毫核，1000m等于1个CPU核心。memory单位支持Mi、Gi。requests.cpu=500m表示调度时保证分配0.5核CPU，limits.cpu=1000m表示容器最大可使用1核。当容器CPU使用量超过limits时触发节流（throttle），内存超过limits时被OOM Kill。

requests和limits的比值建议保持在1:2以内。如果requests远小于limits，调度器可能将过多Pod调度到同一节点，导致节点资源争抢。如果requests等于limits，资源利用率会降低但稳定性更好。

LimitRange设置命名空间默认值与约束

开发者忘记配置resources时，LimitRange可提供默认值并约束资源申请范围：

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: production
spec:
  limits:
  - type: Container
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    max:
      cpu: "4000m"
      memory: "4Gi"
    min:
      cpu: "50m"
      memory: "64Mi"
    maxLimitRequestRatio:
      cpu: "4"

maxLimitRequestRatio限制limits与requests的比值不超过4，防止开发者设置极低requests导致过度调度。min设置防止容器配置过低无法运行。

ResourceQuota命名空间级配额管理

多团队共享集群时，ResourceQuota限制各命名空间的总资源消耗：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: production
spec:
  hard:
    requests.cpu: "20"
    requests.memory: "40Gi"
    limits.cpu: "40"
    limits.memory: "80Gi"
    pods: "50"
    services: "20"
    configmaps: "30"
    persistentvolumeclaims: "10"

当命名空间资源使用达到配额上限时，新Pod创建会被拒绝。kubectl describe quota可查看当前使用量。配额规划时应预留20%的缓冲，避免Pod滚动更新时因配额不足导致新Pod无法创建。

ResourceQuota配额与PriorityClass结合的驱逐策略

当节点资源不足时，Kubelet按QoS等级驱逐Pod。QoS分为Guaranteed、Burstable和BestEffort三档。Guaranteed（requests等于limits）优先级最高，BestEffort（未设置resources）优先级最低，优先被驱逐。

# 高优先级应用使用Guaranteed QoS
resources:
  requests:
    cpu: "1000m"
    memory: "2Gi"
  limits:
    cpu: "1000m"
    memory: "2Gi"

# 配合PriorityClass确保关键Pod优先调度
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
preemptionPolicy: PreemptLowerPriority
globalDefault: false

关键服务配置Guaranteed QoS + 高优先级PriorityClass，在节点资源紧张时可抢占低优先级Pod的资源。非关键批处理任务使用BestEffort QoS，在资源不足时被优先驱逐。

AlertManager告警规则与通知路由

Prometheus采集的指标需要转化为可执行的告警。AlertManager支持分组、抑制和静默规则，避免告警风暴。告警规则定义在Prometheus配置中：

groups:
- name: k8s-resource-alerts
  rules:
  - alert: PodCPUThrottling
    expr: rate(container_cpu_cfs_throttled_periods_total[5m]) / rate(container_cpu_cfs_periods_total[5m]) > 0.25
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Pod {{ $labels.pod }} CPU节流超过25%"

  - alert: PodMemoryHigh
    expr: container_memory_working_set_bytes / container_spec_memory_limit_bytes > 0.9
    for: 3m
    labels:
      severity: critical
    annotations:
      summary: "Pod {{ $labels.pod }} 内存使用率超过90%"

  - alert: NodeDiskHigh
    expr: (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 > 85
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "节点 {{ $labels.instance }} 磁盘使用率超过85%"

  - alert: PodCrashLoop
    expr: kube_pod_container_status_restarts_total > 5
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Pod {{ $labels.pod }} 重启次数超过5次"

for字段指定持续时间阈值，避免瞬时波动触发告警。severity标签用于AlertManager路由不同通知渠道：

route:
  group_by: ["alertname", "namespace"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: "default-webhook"
  routes:
  - matchers: ["severity=critical"]
    receiver: "pagerduty-critical"
    group_wait: 10s
  - matchers: ["severity=warning"]
    receiver: "slack-warning"
    repeat_interval: 8h

receivers:
- name: "pagerduty-critical"
  webhook_configs:
  - url: "https://events.pagerduty.com/X/integration/xxxx"
- name: "slack-warning"
  slack_configs:
  - api_url: "https://hooks.slack.com/services/xxxx"
    channel: "#ops-alerts"
- name: "default-webhook"
  webhook_configs:
  - url: "http://alert-router:8080/alert"

critical级别告警通过PagerDuty推送至值班手机，10秒内触发。warning级别发送到Slack频道，8小时内不重复。group_by将同一命名空间的同类告警合并为一条通知，避免告警轰炸。inhibit_rules可配置抑制规则，例如节点宕机时抑制该节点上所有Pod的告警。