📚 课程目录第4章 IaC工具选型

4. IaC工具选型

在平台工程中，选择合适的基础设施即代码（IaC）工具直接决定了 SLO 作业模板的交付效率、状态收敛能力与运维复杂度。当前主流工具包括 Terraform、Pulumi、Ansible 和 Crossplane，它们在声明式/命令式、状态管理、云原生集成、编程语言支持等维度存在显著差异。

4.1 工具定位与核心差异

下表从关键维度对比四种工具的定位与设计哲学：

维度	Terraform	Pulumi	Ansible	Crossplane
范式	声明式（HCL）	声明式 + 命令式（通用语言）	命令式（Playbook）	声明式（Kubernetes CRD）
状态管理	远程状态文件（State）	远程状态文件（State）	无状态（每次幂等执行）	无状态（K8s 控制器模式）
执行环境	CLI / 自动化 Runner	CLI / SDK / 自动化	控制节点 / AWX / AAP	Kubernetes 集群内
编程语言	HCL（领域特定语言）	TypeScript / Python / Go / C# / Java	YAML（Playbook）	YAML（CompositeResource）
云原生集成	Provider 插件	Provider 插件	Module / Collection	原生 K8s CRD + Provider
SLO 模板适用性	模块化 + Workspace	函数 + 类 + 测试	Role + 变量覆盖	CompositeResource + Claim

  选型第一原则：如果团队以 Kubernetes 为控制面且需要平台抽象层，优先考虑 Crossplane；如果团队偏好通用编程语言和测试生态，Pulumi 更合适；如果已有 Ansible 自动化资产且需要配置管理，保留 Ansible；Terraform 适合多云状态管理场景，但需注意状态文件的安全与并发。

4.2 架构对比：状态驱动 vs 控制器驱动

下图展示了 Terraform/Pulumi 的“状态文件驱动”模式与 Crossplane 的“Kubernetes 控制器驱动”模式的核心差异：

4.3 适用场景矩阵

根据平台工程中常见的 SLO 作业模板需求，以下矩阵帮助快速决策：

场景	推荐工具	理由
多云基础设施编排（VM / 网络 / 数据库）	Terraform	Provider 生态最成熟，状态管理可靠，适合跨云资源依赖
平台 API 抽象 + 自助服务（K8s 原生）	Crossplane	CompositeResource 可定义平台级 SLO 模板，开发者通过 Claim 自助申请
应用团队使用通用语言编写 IaC	Pulumi	TypeScript / Python 等语言支持测试、循环、函数抽象，适合 CI/CD 集成
配置管理 + 软件部署（非容器化）	Ansible	无状态幂等执行，适合 OS 配置、中间件安装、滚动更新
SLO 模板需要版本化 + 单元测试	Pulumi / Terraform	Pulumi 支持原生测试框架；Terraform 可通过 Terratest 实现
平台团队控制面统一管理多集群资源	Crossplane	控制平面在 K8s 内，无需外部状态存储，天然支持 GitOps

4.4 集成 SLO 作业模板的代码示例

以下展示四种工具定义同一 SLO 模板（创建带监控告警的 Redis 实例）的代码风格差异：

Terraform（HCL）

# terraform-slo-redis.tf
resource "aws_elasticache_cluster" "redis" {
  cluster_id           = "slo-redis-${var.environment}"
  engine               = "redis"
  node_type            = var.node_type
  num_cache_nodes      = 1
  parameter_group_name = "default.redis7"

  tags = {
    SLO = "latency-p99-5ms"
  }
}

resource "aws_cloudwatch_metric_alarm" "redis_latency" {
  alarm_name          = "redis-p99-latency"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "2"
  metric_name         = "CacheLatency"
  namespace           = "AWS/ElastiCache"
  period              = "60"
  statistic           = "p99"
  threshold           = 5
  alarm_description   = "SLO: Redis p99 latency must be < 5ms"
}

Pulumi（TypeScript）

// pulumi-slo-redis.ts
import * as aws from "@pulumi/aws";

const environment = process.env.ENV || "dev";

const redis = new aws.elasticache.Cluster("slo-redis", {
  clusterId: `slo-redis-${environment}`,
  engine: "redis",
  nodeType: "cache.t3.micro",
  numCacheNodes: 1,
  tags: { SLO: "latency-p99-5ms" },
});

new aws.cloudwatch.MetricAlarm("redis-latency-alarm", {
  alarmName: "redis-p99-latency",
  comparisonOperator: "GreaterThanThreshold",
  evaluationPeriods: 2,
  metricName: "CacheLatency",
  namespace: "AWS/ElastiCache",
  period: 60,
  statistic: "p99",
  threshold: 5,
  alarmDescription: "SLO: Redis p99 latency must be < 5ms",
});

Ansible（YAML Playbook）

# ansible-slo-redis.yml
- name: Deploy Redis with SLO monitoring
  hosts: localhost
  gather_facts: no
  tasks:
    - name: Create ElastiCache Redis cluster
      amazon.aws.elasticache_cluster:
        cluster_id: "slo-redis-{{ environment }}"
        engine: redis
        node_type: "cache.t3.micro"
        num_cache_nodes: 1
        tags:
          SLO: "latency-p99-5ms"

    - name: Create CloudWatch latency alarm
      amazon.aws.cloudwatch_metric_alarm:
        alarm_name: "redis-p99-latency"
        comparison: "GreaterThanThreshold"
        evaluation_periods: 2
        metric: "CacheLatency"
        namespace: "AWS/ElastiCache"
        period: 60
        statistic: "p99"
        threshold: 5
        alarm_description: "SLO: Redis p99 latency must be < 5ms"

Crossplane（CompositeResource + Claim）

# crossplane-composition-redis.yaml
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: xredis.slo.platform.example.org
spec:
  compositeTypeRef:
    apiVersion: slo.platform.example.org/v1alpha1
    kind: XRedis
  resources:
    - name: redisCluster
      base:
        apiVersion: cache.aws.upbound.io/v1beta1
        kind: ElastiCacheCluster
        spec:
          forProvider:
            engine: redis
            nodeType: cache.t3.micro
            numCacheNodes: 1
      patches:
        - type: FromCompositeFieldPath
          fromFieldPath: spec.parameters.environment
          toFieldPath: spec.forProvider.clusterId
          transform:
            type: string
            string:
              fmt: "slo-redis-%s"
    - name: latencyAlarm
      base:
        apiVersion: cloudwatch.aws.upbound.io/v1beta1
        kind: MetricAlarm
        spec:
          forProvider:
            comparisonOperator: GreaterThanThreshold
            evaluationPeriods: 2
            metricName: CacheLatency
            namespace: AWS/ElastiCache
            period: 60
            statistic: p99
            threshold: 5
            alarmDescription: "SLO: Redis p99 latency must be < 5ms"

平台工程建议：Crossplane 的 Composition 模式天然适合构建 SLO 作业模板——平台团队定义 Composition（模板），应用团队通过 Claim（如 XRedis）自助申请资源，无需关心底层 Provider 细节。这比 Terraform 的 Module 抽象更贴近 Kubernetes 原生体验。

4.5 选型决策流程

以下流程图帮助平台团队根据自身条件快速定位推荐工具：

避坑提醒：不要在同一 SLO 模板中混用多种 IaC 工具管理同一资源生命周期。例如，用 Terraform 创建 Redis 集群，再用 Ansible 修改配置，会导致状态漂移。建议以“资源生命周期归属”为边界划分工具职责。

4.6 平台工程视角的选型总结

Crossplane 最适合构建“平台 API 层”——平台团队定义 SLO 模板（Composition），开发者通过 Kubernetes 资源声明（Claim）自助获取基础设施，天然支持 GitOps 和策略引擎（OPA）。
Terraform 适合已有大量 HCL 资产、需要严格状态锁和远程执行的环境，但需额外处理状态文件安全与并发问题。
Pulumi 适合应用开发团队主导的平台工程，利用通用语言实现 IaC 逻辑复用、单元测试和 CI/CD 深度集成。
Ansible 保留在配置管理和非容器化场景，但不应作为基础设施编排的主工具——其无状态模型在大规模资源依赖管理中存在局限性。

  最终建议：平台工程团队可采用“Crossplane + Terraform”混合策略——Crossplane 负责 K8s 控制面内的资源抽象与自助服务，Terraform 负责控制面外的基础设施（如 VPC、DNS、证书），通过 Crossplane 的 Terraform Provider 实现统一管理。