我如何构建自愈 Kubernetes 平台（并将 On‑Call 减少 35%）

Source: Dev.to

为什么大多数 Kubernetes 集群仍然依赖人工

在很多团队中，Kubernetes 看起来是自动化的——但当节点饱和时，现实会出现：

• 有人在凌晨 2 点被呼叫
• 他们通过 SSH 或 kubectl 进入集群
• 将节点标记为 cordon（不可调度）
• 排空工作负载
• 希望自动扩缩容或 Karpenter 能正确替换节点

这种手动循环在高流量环境中每月会重复数十次。

当我与团队合作时，我通常会问：

为什么仍然有人在执行确定性的基础设施工作？

这个问题促使我构建了一个使用 Kubernetes Operator、Prometheus 智能和 Karpenter 的自愈节点修复平台。

平台工程方法（不仅仅是 DevOps 脚本）

我没有把警报直接接到 shell 脚本，而是把它视为平台问题来处理：

• 系统必须是有状态的
• 必须强制执行防护栏
• 必须可审计
• 必须与 Kubernetes 原语干净集成

这就是为什么解决方案被构建为 Kubernetes Operator，而不是 cron job 或 webhook 粘合剂。

平台的功能

平台持续评估真实的节点健康状态，而不仅仅是 kubelet 条件。

使用的信号

• CPU 长时间饱和
• 内存压力
• 磁盘耗尽
• Pod 驱逐风暴

所有信号均来自 Prometheus 指标，这比单纯的节点条件提供了更丰富的上下文。

架构概览

flowchart TD
    Prometheus --> Alertmanager --> NodeRemediationOperator
    NodeRemediationOperator -->|cordon node| Node
    NodeRemediationOperator -->|drain workloads safely| Node
    NodeRemediationOperator -->|delete node| Node
    NodeRemediationOperator -->|Karpenter provisions replacement| Karpenter

为什么使用 Operator 而不是自动化脚本

Operator 提供：

• 限速的修复（避免级联故障）
• 操作之间的冷却窗口
• 通过 CRD 实现的策略驱动行为
• 声明式安全控制
• 集群内部的状态可视化

一切都是 Kubernetes 原生且可观测的。

安全第一：生产防护栏

没有安全的自动修复就等同于混沌工程。平台强制执行：

• 每小时最大修复次数
• 必须的冷却时间
• PodDisruptionBudget 感知
• 基于标签的 opt‑in（remediable=true）
• 新集群的 dry‑run 模式

这让团队能够信任自动化，而不是害怕它。

节点饱和时会发生什么

1. Prometheus 检测到持续的饱和
2. Alertmanager 通知 Operator
3. Operator 验证策略和冷却时间
4. 节点被 cordon
5. 工作负载安全排空
6. 节点被删除
7. Karpenter 提供全新容量

没有 SSH。没有运行手册。没有人工干预。

可衡量的业务影响

这并不是通过增加工程师人数实现的——而是通过构建更好的平台实现的。

为什么这对工程团队很重要

该模式可以横向扩展到：

• EKS、GKE、AKS
• 无状态和有状态工作负载
• 合规和高可用环境

它将团队从被动运维转变为意图驱动的基础设施。

如何融入更大的平台

Operator 通常与以下组件一起部署：

• GitOps 流水线（ArgoCD / Flux）
• 基于 Terraform 的集群供应
• 基于 SLO 的警报
• 开发者自助模板
• 成本感知的自动扩缩容

它们共同构成了一个自助式内部平台——而不仅仅是一堆工具。

想在你的集群中实现类似功能吗？

如果你的团队：

• 大规模运行 Kubernetes
• 仍然手动处理节点问题
• 想要减少呼叫次数并提升可靠性

我可以帮助团队设计并实现生产级平台自动化——从 Operator 到内部开发者平台。

如果想讨论以下内容，请联系我：

• Kubernetes Operator
• EKS 平台架构
• 自动修复与自愈系统
• 平台工程最佳实践

aws #kubernetes #platform-engineering #devops #karpenter

自动化应该减轻人的压力——而不是增加它。 🚀