AZ-a: etcd-0 (4C8G, 100GB SSD NVMe)
AZ-b: etcd-1 (4C8G, 100GB SSD NVMe)
AZ-c: etcd-2 (4C8G, 100GB SSD NVMe)
│
├── Raft Leader Election → 同一时刻仅一个 Leader 接受写入
├── 默认线性一致性读：通过 ReadIndex 与 Leader 确认最新 commit index，可由任意成员响应（并非全部打到 Leader）；追求极致读吞吐可显式用 serializable 读走本地副本（可能读到旧值）
└── 3 节点部署 → 容忍 1 个 AZ 故障

                    ┌──────────────────────┐
                    │   External LB        │  (AWS NLB / 阿里云 SLB / HAProxy)
                    │   VIP: 10.0.0.100    │
                    └──────┬───────┬───────┘
                           │       │
              ┌────────────┘       └────────────┐
              ▼                                  ▼
    ┌──────────────────┐              ┌──────────────────┐
    │ API Server #1    │              │ API Server #2    │  (无状态，生产建议 ≥3 个跨 AZ；图中简化为 2)
    │ AZ-a             │              │ AZ-b             │
    └────────┬─────────┘              └────────┬─────────┘
             │                                 │
             └───────────┬─────────────────────┘
                         ▼
              ┌──────────────────┐
              │   etcd Cluster   │  (3 或 5 节点，跨 AZ)
              │   Raft Quorum    │
              └──────────────────┘
                         │
    ┌────────────────────┼────────────────────┐
    ▼                                             ▼
┌──────────────┐ Leader Election ──────────┐
│ Scheduler    │  ───────────── │ Scheduler (standby) │
│ Controller   │                │ Controller (standby)│
│ Manager      │                │ Manager             │
└──────────────┘                └─────────────────────┘

Region: cn-hangzhou
├── AZ-a
│   ├── Master-1 (API Server + Scheduler + ControllerManager)
│   ├── etcd-1
│   └── Worker Nodes (3-5 台)
├── AZ-b
│   ├── Master-2 (API Server + Scheduler + ControllerManager)
│   ├── etcd-2
│   └── Worker Nodes (3-5 台)
└── AZ-c
    ├── Master-3 (API Server + Scheduler + ControllerManager)
    ├── etcd-3
    └── Worker Nodes (3-5 台)

跨 AZ 通信：
├── etcd 节点间：内网 HTTPS 2380（peer）/ 2379（client）
├── API Server → etcd：内网 HTTPS 2379
├── Worker → API Server：通过 LB（跨 AZ 负载均衡）
└── Worker 间 Pod 通信：CNI 跨 AZ 路由（VPC 原生或 Overlay）

<team>-<env> 模式

team-alpha-dev        team-beta-dev
team-alpha-qa         team-beta-qa
team-alpha-staging    team-beta-staging
team-alpha-prod       team-beta-prod

# 共享基础设施
kube-system           monitoring
ingress-nginx         cert-manager
argocd                vault

第一层：集群级隔离
├── Prod 集群（独立集群，物理隔离）
└── Non-Prod 集群
    ├── Dev/QA/Staging 共用集群
    └── 按 namespace 逻辑隔离

第二层：命名空间级隔离
├── 每个团队 × 每个环境一个 namespace
├── ResourceQuota 限制 CPU/Memory/Storage
├── LimitRange 设置默认 request/limit
└── NetworkPolicy 限制跨 namespace 流量

第三层：RBAC 权限隔离
├── 每个 namespace 一个 ServiceAccount
├── RoleBinding 限制团队只能操作自己的 namespace
└── ClusterRole 只读（如查看节点状态）

# 第一层：集群总配额（防止超卖）
# 集群所有 namespace requests 之和 < 节点总 capacity

# 第二层：Namespace 配额（按团队分配）
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha-prod
spec:
  hard:
    requests.cpu: "20"        # 最多申请 20 核
    requests.memory: "40Gi"   # 最多申请 40GB
    limits.cpu: "40"          # 使用上限 40 核
    limits.memory: "80Gi"     # 使用上限 80GB
    persistentvolumeclaims: "10"  # 最多 10 个 PVC
    requests.storage: "500Gi"
    services: "20"
    configmaps: "50"
    secrets: "50"
    pods: "100"
    services.nodeports: "0"   # 禁止使用 NodePort

# 第三层：单个 Pod 限制（LimitRange）
apiVersion: v1
kind: LimitRange
metadata:
  name: team-alpha-limits
  namespace: team-alpha-prod
spec:
  limits:
  - type: Container
    default:
      cpu: "500m"
      memory: "512Mi"     # 未指定 limit 的容器默认值
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"     # 未指定 request 的容器默认值
    max:
      cpu: "4"
      memory: "8Gi"       # 单个容器最大限制
    min:
      cpu: "50m"
      memory: "64Mi"      # 单个容器最小限制

Capsule Tenant "tenant-A"
├── Namespace: tenant-a-dev
├── Namespace: tenant-a-prod
├── NetworkPolicy: 跨 namespace 隔离 + 只允许到 ingress
├── ResourceQuota: 汇总所有子 namespace 配额
└── RBAC: Tenant Owner 角色（只能操作自己的 namespace）

默认策略（Deny-All Baseline）：
┌──────────────────────────────────────┐
│ 1. 每个 namespace 默认拒绝所有 ingress │
│ 2. 每个 namespace 默认拒绝所有 egress  │
└──────────────────────────────────────┘

逐层放行（Least Privilege）：
┌──────────────────────────────────────┐
│ 3. 允许同 namespace 内 Pod 互访       │
│ 4. 允许 DNS 查询（UDP 53 → kube-system）│
│ 5. 允许访问 Ingress Controller       │
│ 6. 允许访问监控/metrics 端点          │
│ 7. 允许特定跨 namespace 业务调用      │
└──────────────────────────────────────┘

# 1. 默认拒绝所有 ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: team-alpha
spec:
  podSelector: {}        # 匹配所有 Pod
  policyTypes:
  - Ingress

---
# 2. 默认拒绝所有 egress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: team-alpha
spec:
  podSelector: {}
  policyTypes:
  - Egress

---
# 3. 放行 DNS（必须最先放行）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: team-alpha
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    ports:
    - protocol: UDP
      port: 53

集群规模选择：
├── < 100 Pod → Flannel（简单够用）
├── 100-2000 Pod → Calico（NetworkPolicy + 高性能）
└── > 2000 Pod → Cilium（eBPF 性能 + Hubble 可观测性）

功能需求选择：
├── 只需要基本网络 → Flannel
├── 需要 NetworkPolicy → Calico
├── 需要 L7 策略 + 可观测性 → Cilium
└── 需要 Service Mesh → Cilium（无 sidecar）vs Istio（sidecar）

Service A (sidecar: istio-proxy)
    │
    ├── mTLS ──→ Service B (sidecar)
    │              │
    │              └──→ Service C (sidecar)
    │
    ├── Telemetry → Prometheus (metrics)
    ├── Tracing → Jaeger (traces)
    └── Logs → stdout → Fluent Bit → Loki

安全环模型（Defense in Depth）：

第一环：集群边界（Ingress Controller）
├── HTTPS 终止 + cert-manager 自动证书
├── Rate Limiting
├── WAF 规则
└── 只允许白名单 path/method

第二环：命名空间边界（NetworkPolicy）
├── 默认拒绝所有跨 namespace 流量
├── 白名单放行特定 namespace/service
└── 禁止 Pod 出公网（通过 egress gateway）

第三环：Pod 边界（NetworkPolicy + mTLS）
├── 只允许声明过的 ingress/egress
├── Istio mTLS STRICT 模式
├── L7 策略：HTTP method + path + header 控制
└── Sidecar 资源限制 egress 范围

第四环：出口控制
├── Egress NetworkPolicy：只允许特定域名
├── Cilium DNS Policy：FQDN 级别出口过滤
├── 出口流量审计（Hubble / Istio access log）
└── 异常流量检测与告警

# 出口限制到特定 FQDN（Cilium 特有）
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: egress-whitelist
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: my-service
  egress:
  - toFQDNs:
    - matchName: "api.trusted-partner.com"
    - matchName: "monitoring.internal.com"
  - toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: kube-system
        k8s-app: kube-dns
    toPorts:
    - ports:
      - port: "53"
        protocol: UDP

                    ┌─────────────────────────┐
                    │    Git / OCI / Bucket   │
                    └───────────┬─────────────┘
                                │
                                ▼
                ┌──────────────────────────────┐
                │   source-controller          │  CRD: GitRepository
                │   拉源码 → 缓存 → artifact    │
                └───────────┬──────────────────┘
                            │
              ┌─────────────┴─────────────┐
              ▼                           ▼
  ┌──────────────────────┐   ┌──────────────────────┐
  │ kustomize-controller │   │   helm-controller    │
  │ CRD: Kustomization   │   │ CRD: HelmRelease     │
  │ kustomize build → apply │ │ helm install/upgrade  │
  └──────────────────────┘   └──────────────────────┘
              │                           │
              └───────────┬───────────────┘
                          ▼
                  ┌───────────────┐
                  │  Kubernetes   │
                  └───────────────┘

apps/frontend/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
├── overlays/
│   ├── production/
│   │   ├── kustomization.yaml    ← resources: [../../base], patches
│   │   └── replica-count.yaml    ← patch: replicas: 5
│   ├── staging/
│   │   ├── kustomization.yaml
│   │   └── resource-limits.yaml
│   └── qa/
│       ├── kustomization.yaml
│       └── ingress.yaml
└── components/
    └── monitoring/
        └── kustomization.yaml    ← 可复用组件（ServiceMonitor 等）

发布流程：
1. 金丝雀发布（Canary 5% → 观察 15min）
   ├── Istio VS weight: baseline=95, canary=5
   ├── 监控：错误率、延迟 P99、CPU/Memory
   └── 异常 → 立即回滚（weight: canary=0）

2. 滚动发布（逐步替换）
   ├── maxSurge: 1, maxUnavailable: 0（零停机）
   ├── 新 Pod Ready 后才删旧 Pod
   └── ReadinessProbe 必须配置（否则判断不了新 Pod 是否 Ready）

3. 蓝绿切换（关键版本）
   ├── 部署 Blue（当前）、Green（新版本）两组 Deployment
   ├── Service selector 初始指向 Blue
   ├── 验证 Green 健康 → 切 Service selector 到 Green
   └── 回滚 → 切回 Blue

apiVersion: apps/v1
kind: Deployment
spec:
  # 1. 滚动策略：先起新再删旧，全程不减少可用副本
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1           # 最多多出 1 个 Pod
      maxUnavailable: 0     # 发布过程中始终保持所有 Pod 可用
  template:
    spec:
      # 4. 优雅关闭窗口：需 > preStop + 应用退出时间
      terminationGracePeriodSeconds: 45
      containers:
        - name: app
          # 2. readinessProbe：未 Ready 不进 Endpoints，避免打到没准备好的 Pod
          readinessProbe:
            httpGet: { path: /healthz, port: 8080 }
            initialDelaySeconds: 5
            periodSeconds: 5
            failureThreshold: 3
          # 3. preStop：先 sleep 让 Endpoints 摘除生效，避免"关闭中仍收到新连接"
          lifecycle:
            preStop:
              exec: { command: ["/bin/sh", "-c", "sleep 10"] }
---
# 5. PDB：滚动发布/节点维护/驱逐时，保证最小可用副本，防止被一次性打空
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
spec:
  minAvailable: 80%        # 或 maxUnavailable，二选一
  selector:
    matchLabels: { app: my-app }

PR 环境生命周期：

GitHub PR Open / Push
    │
    ▼
CI Pipeline
    │
    ├── Build Image + Push to Registry
    ├── 生成 PR Overlay YAML → Commit to GitOps Repo
    │   └── Render template from gitops/templates/pr/{project}/{service}/
    ├── ArgoCD Sync → 创建 PR 环境
    │   ├── Namespace: pr-{pr_number}-{service}
    │   ├── Deployment: version=pr-{pr_number}-{service}
    │   ├── Service: selector: app=pr-{pr_number}-{service}
    │   ├── HTTPRoute: host=pr-{pr_number}.qa.example.com
    │   └── Istio DR/VS: subset=pr-{pr_number}
    └── 通知开发者：http://pr-{pr_number}.qa.example.com

PR Merged / Closed
    │
    ├── 删除 GitOps 中 PR overlay 目录
    ├── ArgoCD Sync → 自动清理 PR 资源
    ├── ArgoCD prune → 删除 Namespace + 所有资源
    └── 回收 PR 号码（避免 namespace 名冲突）

多集群监控架构（Push 模式）：

┌──────────────────────────────────────────────────┐
│          中央存储：VictoriaMetrics / Thanos         │
│                                                     │
│  ┌─────────────────────────────────────────────┐  │
│  │  VM Cluster (vminsert → vmstorage → vmselect) │  │
│  │  - 压缩率高（比 Prometheus 省 7 倍存储）      │  │
│  │  - 支持多租户                                  │  │
│  └─────────────────────────────────────────────┘  │
│            ▲                                       │
│            │ remote_write                          │
│  ┌─────────┴──────────┐                           │
│  │  Thanos Receive     │                           │
│  │  (备选方案)         │                           │
│  └────────────────────┘                           │
└──────────────────────────────────────────────────┘
       ▲                          ▲
       │ remote_write             │ remote_write
┌──────┴──────┐          ┌───────┴──────┐
│ Cluster A   │          │ Cluster B    │
│ Prometheus  │          │ Prometheus   │
│ (15d local) │          │ (15d local)  │
└─────────────┘          └──────────────┘

# 第一层：数据采集
---
- Prometheus Operator + ServiceMonitor（自动发现）
- kube-prometheus-stack（一站式部署 Prometheus + Grafana + Alertmanager）
- Node Exporter（DaemonSet，节点指标）
- kube-state-metrics（Deployment、Pod、PVC 等资源状态）

# 第二层：指标聚合
---
- Prometheus per cluster（自建，15 天本地保留）
- remote_write → VictoriaMetrics 集群（1 年保留）
- Recording Rules 预计算常用 PromQL（减少查询延迟）

# 第三层：可视化
---
- Grafana（统一 Dashboard，数据源指向 VictoriaMetrics）
  - 集群概览 Dashboard
  - 业务 SLO Dashboard
  - 成本分析 Dashboard
- Grafana Alerting（替代 Alertmanager 的 UI 管理）

# 第四层：告警
---
- PrometheusRule → Alertmanager
- Alertmanager 路由: 按 severity / team 分发到不同钉钉群
- VictoriaMetrics vmalert（作为备份评估引擎）

# 可用性 SLI（5 分钟窗口）
- record: job:http_requests:success_rate5m
  expr: |
    sum(rate(http_requests_total{status=~"2..|3.."}[5m])) by (job)
    /
    sum(rate(http_requests_total[5m])) by (job)

# Error Budget Burn Rate（1h / 6h / 3d 多窗口）
- record: job:http_requests:error_budget_burn_rate1h
  expr: |
    (
      1 - sum(rate(http_requests_total{status=~"2..|3.."}[1h])) by (job)
      / sum(rate(http_requests_total[1h])) by (job)
    )
    / (1 - 0.999)   # 除以 (1 - SLO)，SLO=99.9%

# Error Budget 剩余百分比（30 天窗口）
- record: job:http_requests:error_budget_remaining30d
  expr: |
    1 - (
      (1 - sum(rate(http_requests_total{status=~"2..|3.."}[30d])) by (job)
      / sum(rate(http_requests_total[30d])) by (job))
      / (1 - 0.999)
    )

# P1：快速消耗（2% Error Budget 在 1 小时内烧完 → burn rate > 14.4）
- alert: SLOBurnRateCritical
  expr: |
    job:error_budget_burn_rate1h > 14.4
    AND
    job:error_budget_burn_rate5m > 14.4
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "{{ $labels.job }} Error Budget 快速消耗"
# burn rate 14.4 = 在1小时内消耗了 2% 的月度 Error Budget（14.4×1h/720h≈2%）；6h 窗口 burn rate 6 → 5%，3d 窗口 burn rate 1 → 10%

# P2：中速消耗（5% Error Budget 在 6 小时内 → burn rate > 6）
- alert: SLOBurnRateHigh
  expr: |
    job:error_budget_burn_rate6h > 6
    AND
    job:error_budget_burn_rate30m > 6
  for: 15m
  labels:
    severity: warning

# P3：慢速消耗（10% Error Budget 在 3 天内 → burn rate > 1）
- alert: SLOBurnRateLow
  expr: |
    job:error_budget_burn_rate3d > 1
    AND
    job:error_budget_burn_rate6h > 1
  for: 1h
  labels:
    severity: info

第一阶段（1-2 月）：只观察不告警
├── 建立 Dashboard，让团队熟悉指标含义
└── 修正 SLI 计算逻辑

第二阶段（3-4 月）：只 P1 告警
├── 每月 Error Budget 回顾会议
└── 建立 SLO 违规复盘流程

第三阶段（5 月+）：发布决策集成
├── Error Budget 冻结策略
├── 发布前评估预算余量
└── 每季度调整 SLO 目标

┌──────────┐    ┌──────────┐    ┌──────────┐
│ Pod A    │    │ Pod B    │    │ Pod C    │
│ stdout   │    │ stdout   │    │ stdout   │
└────┬─────┘    └────┬─────┘    └────┬─────┘
     │               │               │
     ▼               ▼               ▼
┌──────────────────────────────────────────┐
│          Promtail (DaemonSet)             │
│  - 添加 K8s 标签（namespace/pod/container） │
│  - 推送日志到 Loki Distributor             │
└─────────────────────┬────────────────────┘
                      │
                      ▼
┌──────────────────────────────────────────┐
│           Loki (Distributed)              │
│  Distributor → Ingester → Object Store    │
│  (S3/GCS/OSS 做长期存储，低成本)           │
└──────────────────────────┬───────────────┘
                           │
                           ▼
                   ┌──────────────┐
                   │   Grafana    │  LogQL 查询 + 与 Metric 关联
                   └──────────────┘

                  ┌─────────────┐
                  │ Prometheus  │  Pro集群
                  └──────┬──────┘
                         │ alerts
                         ▼
                  ┌─────────────┐
  Webhook Bridge  │Alertmanager │  ← 唯一收敛点
  (业务侧告警) ──→│ (主实例)    │
                         │
            ┌────────────┴────────────┐
            ▼                         ▼
     ┌─────────────┐          ┌─────────────┐
     │  Watchdog?   │          │  Routing:    │
     │  → HC.io     │          │  severity →  │
     └─────────────┘          │  team        │
                              └──────┬───────┘
                                     │
            ┌────────────────────────┼────────────────────┐
            ▼                        ▼                    ▼
    ┌──────────────┐      ┌──────────────┐     ┌──────────────┐
    │ DingTalk Prod│      │DingTalk Staging│    │  Feishu P0   │
    └──────────────┘      └──────────────┘     └──────────────┘

# Alertmanager 路由配置
route:
  receiver: webhook-dingtalk-prod  # 默认接收器
  group_by: ['alertname', 'cluster', 'namespace']
  group_wait: 30s      # 同组告警聚合等待
  group_interval: 5m   # 同组告警重复间隔
  repeat_interval: 4h  # 未恢复告警重发间隔（太长导致遗漏，太短导致噪音）
  routes:
    # Watchdog 独立通道（永远排除在 silence 之外）
    - matchers:
        - alertname = "Watchdog"
      receiver: dead-mans-switch
      group_wait: 10s
      continue: false

    # P0 → 飞书 On-call 群（带 @所有人）
    - matchers:
        - severity = "P0"
      receiver: feishu-oncall
      group_wait: 10s
      repeat_interval: 15m
      continue: true

    # Staging/QA → 对应钉钉群
    - matchers:
        - env =~ "staging|qa"
      receiver: webhook-dingtalk-staging
      continue: false

    # 邮件备份（P0/P1）
    - matchers:
        - severity =~ "P0|P1"
      receiver: email-fallback
      continue: true

inhibit_rules:
  # 集群级故障抑制具体节点/Pod 告警
  - source_matchers:
      - alertname = "KubeAPIDown"
    target_matchers:
      - severity =~ "warning|info"
    equal: ['cluster']

  # 节点 NotReady 抑制其上 Pod 的 Restart/Pending 告警
  - source_matchers:
      - alertname = "NodeNotReady"
    target_matchers:
      - alertname =~ "Pod.*Restart|Pod.*Pending"
    equal: ['cluster', 'instance']

  # 高 severity 抑制低 severity 同名告警
  - source_matchers:
      - severity = "P0"
    target_matchers:
      - severity =~ "P1|P2"
    equal: ['alertname', 'cluster']

# 绝对禁止：alertname=~".+"（会误伤 Watchdog 心跳）
# 正确姿势：显式排除 Watchdog

# 安全 silence 脚本
amtool silence add \
  alertname!=Watchdog \
  --comment="上线窗口 silence（排除 Watchdog）" \
  --duration=2h

阶段 1: Inform（看清花费）— 不可跳过
├── 建立标签体系（Label Schema）
├── 部署 OpenCost / Kubecost
├── 强制标签准入（Kyverno Policy）
└── Grafana 成本 Dashboard

阶段 2: Optimize（优化浪费）— 按 ROI 排序
├── 闲置资源识别（VPA Recommender）
├── 清理孤儿 PVC（无 Pod 使用的 EBS 卷）
├── 启用 Karpenter Consolidation
├── Spot 节点混合策略
└── 批量降低虚高 requests

阶段 3: Operate（固化流程）— 防止反弹
├── CI 集成成本检查（PR 改 resources → 自动估算月度影响）
├── 周度/月度自动报告
├── 超预算自动告警
└── 季度 FinOps Review（各团队 Owner 负责成本趋势）

# 必须标签（Kyverno ClusterPolicy 强制校验）
required_labels:
  - app.kubernetes.io/name  # 服务名
  - team                    # 负责团队
  - env                     # 环境
  - cost-center             # 成本中心编号

helm install vpa fairwinds-stable/vpa \
  --namespace vpa --create-namespace \
  --set updater.enabled=false \           # 不自动重启 Pod
  --set admissionController.enabled=false \
  --set recommender.enabled=true          # 只跑推荐

# 找出 requests 虚高的 Deployment（用量 < 20% requests）
kubectl get vpa -A -o json | jq -r '
  .items[] |
  select(.status.recommendation != null) |
  .metadata.namespace as $ns |
  .metadata.name as $name |
  .status.recommendation.containerRecommendations[]? |
  {ns: $ns, name: $name, container: .containerName,
   cpu_recommended: .lowerBound.cpu,
   cpu_current: (.target.cpu // "N/A"),
   mem_recommended: .lowerBound.memory}
' | jq -s 'sort_by(.cpu_recommended)'

helm install goldilocks fairwinds-stable/goldilocks
kubectl label namespace production goldilocks.fairwinds.com/enabled=true
# Dashboard 直接展示推荐值 + 采纳后节省金额

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]  # 优先 Spot，没有时 fallback On-Demand
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]       # 多规格可选提升 Spot 可用性
      expireAfter: 720h                  # 节点最多跑 30 天（定期轮换）
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized   # v1 合法取值：WhenEmpty | WhenEmptyOrUnderutilized（旧的 WhenUnderutilized 已废弃）
    consolidateAfter: 30s
    budgets:
      - nodes: "10%"                # 每次中断不超过 10% 节点，限制爆炸半径

第一层：无状态服务
├── 全量 Spot
├── 配置 PDB（minAvailable: 1）
├── 安装 Node Termination Handler
└── 容忍 2% 中断率

第二层：有状态服务
├── 全部 On-Demand
├── annotation: karpenter.sh/do-not-disrupt: "true"
└── 0% 容忍中断

第三层：批处理/后台任务
├── Spot
├── 无 PDB（中断后自动重试）
└── 优先使用 cheapest instance

# 示意：不同负载用不同 NodePool，各自定制实例族与合并策略
# CPU 密集：instance-category=["c"]，consolidationPolicy=WhenEmptyOrUnderutilized
# GPU 推理：instance-category=["g","p"]，consolidationPolicy=WhenEmpty（加载模型贵，不轻易合并）
# 每个 NodePool 设 limits（cpu / nvidia.com/gpu）作硬上限，防误配导致成本失控

# 安装 OpenCost（接入已有 Prometheus）
helm install opencost opencost/opencost \
  --namespace opencost --create-namespace \
  --set opencost.prometheus.external.enabled=true \
  --set opencost.prometheus.external.url=http://prometheus.monitoring:9090

# 按 team label 分摊的成本
curl -s "http://opencost.opencost:9003/allocation" \
  -d "window=lastmonth" \
  -d "aggregate=label:team" \
  -d "shareIdle=true" \
  -d "shareTenancyCosts=true" | \
  jq '.data[0] | to_entries[] | {team: .key, cost: (.value.totalCost | floor)}'

# 月度成本预测超预算
- alert: MonthlyCostProjectionExceeded
  expr: (sum(increase(opencost_total_cost[24h])) * 30) > 45000
  for: 1h
  labels:
    severity: warning
  annotations:
    summary: "月度成本预测 ${{ $value | printf \"%.0f\" }} 超预算"

# Namespace 成本异常翻倍（对比上周同期）
- alert: NamespaceCostAnomaly
  expr: |
    (sum by (namespace) (increase(opencost_total_cost[1h]))
    /
    sum by (namespace) (increase(opencost_total_cost[1h] offset 7d))) > 2
  for: 30m

#!/bin/bash
# find-orphan-pvc.sh
kubectl get pvc -A -o json | jq -r '
  .items[] | select(.status.phase == "Bound") |
  "\(.metadata.namespace)/\(.metadata.name)"
' | while IFS='/' read ns pvc; do
  count=$(kubectl get pods -n "$ns" -o json | jq --arg pvc "$pvc" \
    '[.items[].spec.volumes[]? | select(.persistentVolumeClaim.claimName == $pvc)] | length')
  [ "$count" -eq 0 ] && echo "ORPHAN PVC: $ns/$pvc"
done

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: ebs.csi.aws.com               # 云上用 CSI driver（in-tree 卷插件已迁移到 CSI）
parameters:
  type: gp3
  iops: "6000"
allowVolumeExpansion: true                  # 允许在线扩容（配合 CSI + 文件系统 resize）
volumeBindingMode: WaitForFirstConsumer     # 延迟绑定，保证卷与消费它的 Pod 落在同一 AZ
reclaimPolicy: Retain                       # PV 回收策略：Retain 防误删丢数据

spec:
  persistentVolumeClaimRetentionPolicy:
    whenDeleted: Retain    # 删除 StatefulSet 时保留 PVC（数据安全）
    whenScaled: Delete     # 缩容时删除多余副本的 PVC（避免孤儿卷积累成本）

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  minReplicas: 3
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target: { type: Utilization, averageUtilization: 70 }
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300   # 缩容前观察 5min，避免抖动

# namespace 打标签即启用三档策略（privileged / baseline / restricted）
metadata:
  labels:
    pod-security.kubernetes.io/enforce: restricted   # 强制拦截
    pod-security.kubernetes.io/audit: restricted     # 审计日志
    pod-security.kubernetes.io/warn: restricted      # 客户端告警

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources: ["secrets"]
    providers:
      - kms:                 # 生产首选 KMS v2（1.29 GA），密钥托管在外部 KMS、支持轮转
          apiVersion: v2
          name: aws-kms
          endpoint: unix:///var/run/kmsplugin/socket.sock
      - identity: {}         # 兜底：允许读取历史未加密数据