子安饮墨馀三斗，留与卿儿作赋来
分类目录归档：aws
Kubernetes 原生 Deployment 只支持 RollingUpdate 和 Recreate 两种策略。对于线上核心业务，RollingUpdate 的问题很明显：
kubectl rollout undo 需要等待新 Pod 重新滚动，P0 故障时每秒都在烧钱生产环境需要的是：先放 5% 流量到新版本，观察 5 分钟，指标正常再逐步加到 50%、100%；异...
在 Kubernetes 集群中实施安全策略（禁止特权容器、强制资源限制、镜像来源白名单等），长期以来的标准方案是 OPA Gatekeeper 或 Kyverno。它们功能强大，但也带来了额外的运维负担：
Kubernetes 集群跑有状态服务（数据库、消息队列、对象存储）时，存储始终是最大的痛点：
Rook 把 Ceph 变成 Kubernetes 的一等公民——用 Operator 模式管理分布式存储，让存储和计算在同一个控制平面内声明式管理。
Rook 是 CNC...
当团队同时使用 OpenAI、Claude、Gemini、Azure OpenAI 等多家 LLM 服务时，运维面临几个棘手问题：
.env 里，轮转和审计成本高LiteLLM Proxy 正是解决这些问题的开源方案 —— 一个统一的 LLM API 网关...
生产环境的 Kubernetes 集群一旦出事——误删 Namespace、etcd 损坏、跨区域迁移——没有备份等于裸奔。传统的 etcd snapshot 只覆盖集群状态，不管 PV 数据；手动写 CronJob 导出 YAML 又维护成本高、恢复时还原顺序容易出错。
Velero（前身 Heptio Ark）是 VMware 开源的 Kubernetes 备份/恢复/迁移工具，支持： - 集群资源（Deployment、ConfigMap、CRD 等）的声明式备份 - PersistentVolume 数据快照（通过 CSI 或云厂商插件） - 定时调度、TTL 自动过期、跨...
在非 Kubernetes 的服务器环境中（边缘节点、单体应用服务器、CI Runner），我们通常用 docker-compose 编排容器。但它带来几个尴尬问题：
docker compose up -d，与系统的 init 体系割裂，重启后需要额外 enabledepends_on 只做启动顺序，不做健康依赖，复杂场景照样翻车容器安全扫描（如 Trivy）解决了镜像构建阶段的漏洞发现，但运行时阶段的异常行为——容器内反弹 Shell、敏感文件读取、异常网络外连——传统工具几乎无能为力。Kubernetes 集群一旦被攻破，从横向移动到数据外泄，整个链路可能在几分钟内完成，而你的告警系统可能毫无感知。
Falco 是 CNCF 毕业项目，基于 eBPF/kernel module 在内核层实时捕获系统调用，用规则引擎检测运行时威胁，填补了从「镜像安全」到「运行时安全」的最后一块拼图。
Falco 的核心架构：
┌────────────────────────────────────────────...运维工程师大概都经历过这些场景：
.env 文件通过 Slack/钉钉明文发一份过来.env，漏改一台就是 P0 事故.env 文件毫无审计能力.env.prod）区分，一旦复制错误直接打到生产数据库.env 是开发阶段的便利工具，但它从来不是为生产环境设计的密钥管理方案。当团队规模超过 5 人、服务超过 10 个时，散落的 .env 文件就是一颗定时炸弹。
在 CI/CD 流水线中构建容器镜像，传统方案是 Docker-in-Docker（DinD）或挂载宿主机 Docker Socket。两种做法都有硬伤：
--privileged 特权模式，Pod 拥有宿主机几乎所有权限，一旦被攻破等同于节点沦陷/var/run/docker.sock 的容器都能操控宿主机上所有容器，安全审计直接红灯生产环境需要一种 无...
运维团队的开发环境管理是个老问题：项目 A 需要 Node 18 + Python 3.11，项目 B 需要 Node 20 + Python 3.12 + Go 1.22。传统方案是装一堆 *env 工具——nvm 管 Node、pyenv 管 Python、goenv 管 Go、rbenv 管 Ruby。
实际痛点：
.bashrc 越来越臃肿