1. 课程导入与平台交付全景

在云原生平台工程中，Terraform 与 Kubernetes 常被同时提及，但它们解决的问题并不相同。理解两者的角色边界与协作方式，是后续所有章节的基础。本节先建立一张“平台交付全景图”：谁负责基础设施，谁负责工作负载编排，二者在什么位置交接，以及一条从代码到可用集群的交付链路究竟长什么样。

一、两个工具，两种职责

Terraform 是基础设施的声明式编排器。它面向云厂商 API、网络、计算、存储、IAM 等资源，通过 HCL 描述“期望状态”，由 provider 把期望状态翻译成实际 API 调用，并用 state 文件记录已管理资源的映射关系。它的核心能力是：资源生命周期管理、依赖关系推导、变更计划（plan）与幂等收敛。

Kubernetes 是工作负载的声明式编排器。它面向容器、Pod、Service、Ingress、ConfigMap、Deployment 等对象，通过 YAML/Manifest 描述“期望状态”，由控制器循环不断把实际状态拉向期望状态。它的核心能力是：调度、自愈、滚动更新、服务发现与弹性伸缩。

两者都是“声明式 + 控制器/执行器收敛”的模型，但作用层级不同：Terraform 管理的是集群及其依赖的基础设施，Kubernetes 管理的是集群内部运行的应用与配置。把它们混为一谈，往往会导致职责错位——例如用 Terraform 去管理 Pod，或用 kubectl 去创建 VPC。

二、平台交付全景：从代码到可用集群

一个典型的平台交付链路可以拆成四层，每层都有明确的输入、工具与输出：

• 基础设施层：VPC、子网、安全组、NAT、负载均衡、节点池、托管控制面。由 Terraform 管理，输出集群 endpoint、CA 证书、kubeconfig 等连接信息。
• 集群引导层：把 Kubernetes 控制面与节点组件装好，并安装基础插件（CNI、CoreDNS、CSI、metrics-server）。托管集群由云厂商完成大部分工作，自建集群则常用 kubeadm 或 Cluster API。
• 平台能力层：Ingress Controller、证书管理、日志与监控、策略引擎、GitOps 控制器、命名空间与 RBAC 基线。这一层通常由 Helm/Kustomize 或 GitOps 工具交付。
• 应用交付层：业务 Deployment、Service、配置与密钥、HPA、PDB 等，由研发或平台团队通过 CI/CD 或 GitOps 持续发布。

这四层不是简单的线性关系，而是“基础设施先就绪，平台能力再叠加，应用最后运行”的依赖顺序。Terraform 主要覆盖第一层，并向第二、三层提供集群接入点；Kubernetes 及其生态覆盖第二到第四层。

三、核心价值：为什么要用 Terraform 管 Kubernetes 基础设施

如果只用控制台点击创建集群，会面临三个现实问题：环境不可复制、变更不可审计、多集群难以一致。Terraform 带来的价值正好对应这三点：

• 可复制：同一份 HCL 在 dev/staging/prod 用不同变量渲染，得到结构一致、参数可追溯的集群。
• 可审计：每次变更先 terraform plan，把“将要新增/修改/销毁什么”变成可评审的文本，而不是某个人在控制台上的操作记忆。
• 可组合：用 module 封装“标准集群”，把网络、节点池、插件、标签策略打包，业务团队按需引用，避免重复造轮子。

而 Kubernetes 的价值在于：把应用运行所需的调度、服务发现、配置注入、滚动发布、自愈等能力标准化，使应用不再关心“跑在哪台机器上”。两者结合，才形成“基础设施可编程 + 工作负载可编排”的完整平台交付能力。

四、一条最小交付链路的示例

下面用一段简化的 Terraform 片段说明“基础设施层”如何向“集群层”交接。示例以某云厂商托管集群为假设场景，参数为教学示例值，并非实测结果：

variable "cluster_name" { default = "demo-platform" }
variable "node_count"   { default = 3 }

module "k8s_cluster" {
  source       = "./modules/managed-k8s"
  cluster_name = var.cluster_name
  node_count   = var.node_count
  node_size    = "4c8g"
}

output "cluster_endpoint" {
  value = module.k8s_cluster.endpoint
}

output "kubeconfig" {
  value     = module.k8s_cluster.kubeconfig
  sensitive = true
}

执行 terraform plan 时，Terraform 会推导出 VPC → 子网 → 安全组 → 集群 → 节点池的依赖顺序，并给出“将创建 N 个资源”的计划。执行 terraform apply 后，输出中的 cluster_endpoint 与 kubeconfig 就是交给 Kubernetes 侧的“接入凭证”。后续用 kubectl get nodes 能看到 3 个节点处于 Ready，说明基础设施层与集群引导层已经打通。

五、学习路径与常见误区

本课程后续会沿着“基础设施 → 集群引导 → 平台能力 → 应用交付”这条主线展开。建议的学习顺序是：先掌握 Terraform 的 provider、resource、state、module 与 plan/apply 工作流；再理解 Kubernetes 的对象模型与控制器机制；然后学习如何用 Terraform 交付集群、用 Helm/Kustomize 交付平台组件、用 GitOps 交付应用。

需要提前避开的误区有三个：第一，用 Terraform 管理集群内所有 YAML，导致 state 膨胀、plan 缓慢、权限过大；第二，把 kubeconfig 明文写进代码仓库，造成凭证泄露；第三，忽略 state 的远程后端与锁机制，多人协作时互相覆盖。理解这些边界，比记住某个命令更重要。

建立全景认知后，后续每一节都会落到具体对象与操作上：如何写 provider、如何设计 module、如何规划网络与节点池、如何把集群接入 GitOps。先把“谁管什么、在哪交接、如何判断成功”这三件事想清楚，后面的实现就有了稳定的坐标系。