云原生

背景与问题界定 某多云团队的"基础设施仓库"维护着 20 多个 Terraform 模块，覆盖 AWS、阿里云和自建 OpenStack 三个环境。随着服务数量增长到 200+个，Terraform 的状态管理（State）变得极其脆弱——一次错误的 terraform apply 导致跨环境的 S3 Bucket 被意外删除，依赖它的 Redis 集群配置丢失，恢复花了两天时间。更痛苦的是 Terraform 与 Kubernetes 之间的"地幔鸿沟"：Terraform 创建 VPC 和 EKS 集群，Kubernetes 上部署应用，但两个世界之间的状态无法互通——Kubernetes 不知道它用了哪些 AWS 资源，Terraform 也感知不到集群内的变化。Crossplane 从 2023 年开始提出了一种新的范式：用 Kubernetes 的 CRD 和控制器模式来管理"任何云资源"，让基础设施声明式地成为集群的一部分。 目标拆解与工程约束 状态管理的可靠性：基础设施的状态必须从"单点文件锁"（Terraform State + DynamoDB Lock）演进为"面向控制器的最终一致性"——不需要 state lock、terraform refresh 等手工操作，状态通过 CRD 的 status 自动持久化到 etcd。 平台一致性 API：开发团队不关心底层是 AWS 还是阿里云，他们只需要声明"我需要一个 16C32G 的 PostgreSQL 实例和一个 Redis 7.0 集群"，IaC 平台在背后自动映射到对应的云厂商资源。 GitOps 原生集成：基础设施的变更必须通过 Git 提交触发，由 ArgoCD 或 Flux CD 自动调谐，而不是运维人员在终端执行 terraform plan && terraform apply 的手动流程。 多云统一编排：同一套 IaC 模板必须能够适应多个云厂商的差异——比如 AWS 的 RDS 和阿里云的 RDS 参数命名不同，但对外暴露的抽象语义必须一致，实现"写一次，跑遍多云"。 方案设计 架构设计采用"分层抽象"模型。底层是 Crossplane Provider（如 provider-aws、provider-helm），中间层是 Crossplane Composite Resource（XRD），最上层是开发团队直接使用的 Claim（声明式请求）： ...

背景 这类问题在真实项目里很常见：高并发、复杂依赖、发布频繁、团队协作面广。只有把边界条件提前定义清楚，系统才会在压力下保持稳定。 实践要点 先定义目标：可用性、延迟、成本哪个优先。 把关键路径显式化：超时、重试、降级、回滚。 把策略写进代码和流程，而不是只停留在文档。 代码片段 apiVersion: v1 kind: ConfigMap metadata: name: sample 总结 工程实践最怕“看起来正确”。把策略做成可观测、可验证、可回滚的闭环，才能在生产环境里真正稳定运行。 稳定性不是某个技巧，而是持续的系统化约束。

成本高不一定是机器贵 很多集群成本高，核心原因是资源配置粗放： request 远大于实际使用 HPA 指标失真导致过度扩容 长尾任务长期占用节点 第一件事：拉齐 request 和真实负载 建议先看 7 到 14 天数据，按 P95 使用量设置 request，再保留安全余量。盲目按峰值配置，浪费通常最大。 第二件事：把弹性策略拆开 在线服务：偏稳定，防抖优先 离线任务：可抢占，成本优先 把工作负载分层后，调参会清晰很多。 第三件事：节点池治理 基础池用稳定机型承载核心服务 弹性池接临时流量和批任务 定期清理空转节点 额外收益点 镜像瘦身缩短拉取时间 减少跨可用区流量 对低优先级任务使用 Spot/抢占实例 小结 成本优化不是一次性动作，而是持续运营。先让容量模型可信，再谈更激进的降本策略。