90DaysOfDevOps Day 61：用 Terraform 与 Kubernetes Provider 管理集群资源，并落地多环境部署策略

文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本文对应 90DaysOfDevOps 项目「基础设施即代码IaC」专题的 Day 61。前两节我们已经用 Terraform 分别向 VirtualBox 部署了虚拟机见 day59.md、向 Docker 部署了容器见 day60.md 与 docker.tf本节将把目光转向 Kubernetes讲解如何用 Terraform 的 Kubernetes Provider 直接管理集群内的命名空间、Deployment 与 Service并系统对比「terraform workspaces」与「目录结构 模块复用」两种多环境部署策略。读完本文你将能基于仓库中的 kubernetes.tf 完整复现一次「声明式创建 → 集群验证 → 端口访问」的 nginx 部署并具备为开发、预发、生产环境选择合适隔离方案的能力。为什么要在 Kubernetes 环境里使用 Terraform在此前的章节中我们已经熟悉了用kubectl直接操作 Kubernetes 资源。但当我们已经在用 Terraform 管理虚拟机、容器乃至集群本身时Terraform 在集群内部的资源管理上同样有不可替代的价值。Day 61 文档明确给出了两个核心理由统一工作流Unified workflow如果你已经用 Terraform 部署了 Kubernetes 集群那么可以沿用同一套工作流与工具继续部署集群内部的资源不必在kubectl命令与 Terraform 声明之间来回切换。生命周期管理Lifecycle managementTerraform 不只是「创建工具」它同时覆盖变更change、更新update与删除deletion所有对资源的操作都会沉淀在状态文件state中可追溯、可回滚。在 Provider 的选择上文档指出主要有两条路径使用官方 Kubernetes Providerhashicorp/kubernetes直接管理 Deployment、Service、Namespace 等原生对象或者使用 Helm Providerhashicorp/helm管理 Helm Chart 的发布与升级。本节实战选用的是前者。值得补充的是作者的演示实践中还有一个专门的配套仓库tf_k8deploy用于演示如何用 Terraform 在 AWS、Azure、GCP 三大主流云厂商上部署 Kubernetes 集群——这正对应「用 Terraform 管理集群本身」这一层而本文要做的是更下一层的「用 Terraform 管理集群内部对象」。实验环境与前置准备本机安装有 Terraform示例环境截图可见初始化时安装的 kubernetes Provider 为 v2.8.0满足仓库配置中 2.0.0的版本约束。本机可用minikube提供本地 Kubernetes 集群与前几节演示保持一致并已生成~/.kube/configkubeconfig 文件。准备一个全新的项目目录用于存放本次的kubernetes.tf。仓库中对应的实际文件位于 2022/Days/IaC/Kubernetes/kubernetes.tf可直接作为参考蓝本。实战用 Terraform 在 minikube 中部署 nginx与上一节 Docker 演示在 docker.tf 中部署 nginx 并映射到本机 8000 端口的思路一致本次我们向 Kubernetes 集群声明式地部署 nginx定义一个名为nginx的命名空间、一个包含 2 个副本的 Deployment以及一个 NodePort 类型的 Service。完整配置 kubernetes.tf 逐段拆解terraform { required_providers { kubernetes { source hashicorp/kubernetes version 2.0.0 } } } provider kubernetes { config_path ~/.kube/config } resource kubernetes_namespace test { metadata { name nginx } } resource kubernetes_deployment test { metadata { name nginx namespace kubernetes_namespace.test.metadata.0.name } spec { replicas 2 selector { match_labels { app MyTestApp } } template { metadata { labels { app MyTestApp } } spec { container { image nginx name nginx-container port { container_port 80 } } } } } } resource kubernetes_service test { metadata { name nginx namespace kubernetes_namespace.test.metadata.0.name } spec { selector { app kubernetes_deployment.test.spec.0.template.0.metadata.0.labels.app } type NodePort port { node_port 30201 port 80 target_port 80 } } }这份配置由四部分构成Provider 声明与配置required_providers锁定 Kubernetes Provider 的源与版本 2.0.0provider kubernetes中的config_path指向本机~/.kube/configTerraform 将复用 kubeconfig 中的认证信息连接集群——这也是它能与 minikube 开箱即用的原因。命名空间Namespacekubernetes_namespace.test创建一个名为nginx的命名空间作为后续资源的隔离边界。Deployment声明 2 个副本replicas 2通过selector.match_labels与template.metadata.labels关联app MyTestApp容器镜像为nginx容器名为nginx-container暴露容器端口 80。注意 Deployment 的namespace通过表达式kubernetes_namespace.test.metadata.0.name引用命名空间资源而不是硬编码字符串。Servicetype NodePort将集群内 80 端口映射到节点端口 30201selector.app同样采用引用表达式kubernetes_deployment.test.spec.0.template.0.metadata.0.labels.app从 Deployment 的模板标签中动态取值保证 Service 与 Deployment 的标签永远一致、不会因手写失误而失配。这种「资源间通过属性引用attribute reference互相连接」正是 Terraform 声明式风格的体现Terraform 会依据引用关系自动构建依赖图从而以正确的顺序创建资源先命名空间再 Deployment最后 Service。部署工作流init → apply在新建的项目文件夹中第一步是初始化工作目录下载 Providerterraform init截图可见初始化过程成功安装了 Kubernetes Provider 并完成后端初始化输出Terraform has been successfully initialized!。第二步执行terraform apply应用这份配置。文档中强调在 apply 之前可以先确认集群当前的命名空间情况apply 之后则观察创建结果terraform apply如上图所示Apply complete! Resources: 3 added, 0 changed, 0 destroyed.Terraform 一次性创建了kubernetes_namespace.testnginx、kubernetes_deployment.test、kubernetes_service.test三个资源——所有变更都被写入 Terraform 状态后续的更新与销毁同样由 Terraform 接管。验证与访问kubectl 与端口转发资源创建完成后用kubectl验证集群内的实际状态先确认nginx命名空间已经出现再查看该命名空间下的全部资源kubectl get ns kubectl get all -n nginx输出应包含nginx命名空间、期望副本与就绪副本均为 2 的 Deployment、2 个运行中的 nginx Pod以及 NodePort 类型端口 30201的 Service。接下来是访问验证。由于演示基于 minikube其 Docker 网络对 Ingress 场景存在限制文档给出的做法是使用kubectl port-forward将 Service 端口转发到本机kubectl port-forward -n nginx svc/nginx 30201:80随后在浏览器打开http://localhost:30201/即可看到标准的 nginx 欢迎页至此一条完整的「Terraform 声明 → 集群验证 → 服务可达」链路已经跑通。如果想深入尝试更复杂的 Terraform 与 Kubernetes 组合示例官方 HashiCorp Learn 站点提供了 Kubernetes Provider 的系列教程文档中有明确推荐。多环境策略terraform workspaces 与目录结构之争上面的 demo 只有单一环境。如果我们要在**生产production、预发staging、开发development**三个环境上跑同一套代码且保证形态一致Day 61 文档给出了 Terraform 的两种主流做法并逐条列出了各自的利弊。方案一terraform workspaces单一后端内的多个命名空间Workspace 允许你在同一个后端backend中维护多个互相隔离的命名状态切换环境只需terraform workspace select。优点Pros容易上手学习成本低提供便捷的terraform.workspace表达式可在配置中按环境动态取值最大限度地减少代码重复。缺点Cons容易发生人为操作失误而这恰恰是我们引入 Terraform 想消除的所有环境的状态存储在同一后端中隔离性弱代码库本身无法直观、无歧义地展示「某段配置到底属于哪个环境」的部署情况。方案二文件结构目录布局 模块复用通过目录层级来隔离环境每个环境拥有独立的目录与独立的后端将通用资源抽成模块module实现复用。优点Pros后端彼此隔离安全性更好环境之间的状态、凭据互不渗透降低人为操作失误的可能性代码库能够完整、真实地反映当前已部署的状态。缺点Cons部署多个环境需要多次执行terraform apply每个环境一次存在更多代码重复但可以通过模块modules将其最小化。综合来看workspace 适合快速起步、原型验证而生产级的多环境治理通常更青睐「目录 模块」的隔离方式。文档特别指出模块Module是「一组组合使用的资源的容器」由同一目录下的若干.tf文件构成既能把虚拟机、VPC、安全组、Kubernetes 集群等资源按职责拆分也可以复用社区现成的第三方模块——这正是我们在 day60.md 中介绍过的模块概念的延伸。仓库配套资源与下一步在 90DaysOfDevOps 仓库中与本节直接相关的素材包括kubernetes.tf本节实战的完整配置源文件与本文代码一致可直接复制使用day60.md 与 docker.tf上一节 Docker 容器 Provisioner 模块的基础铺垫IaC/Terratest仓库中还存在examples与test两个子目录从目录结构看是为基础设施代码准备的自动化测试配套可作为深入 IaC 工程质量的方向。本节之后Day 62 将继续沿着 Kubernetes 与多环境管理的主题展开读者可继续阅读 day62.md 衔接学习路径。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐Kaluma与Node.js对比嵌入式JavaScript运行时的独特优势与应用场景Kaluma与Node.js对比嵌入式JavaScript运行时的独特优势与应用场景 Kaluma是一款专为RP2040Raspberry Pi PicoSkaffold多集群部署策略跨环境管理Kubernetes应用Skaffold多集群部署策略跨环境管理Kubernetes应用 在Kubernetes开发中跨多个集群或环境部署应用是常见需求。Skaffold通过灵活的云原生DevOps90DaysOfDevOps Day 51用 minikube 部署你的第一个本地 Kubernetes 集群90DaysOfDevOps Day 51用 minikube 部署你的第一个本地 Kubernetes 集群 本篇是《90DaysOfDevOps》Kube文档/教程上一篇GARbro视觉小说资源处理全攻略从入门到精通下一篇3个步骤掌握Emby高级功能emby-unlocked开源工具完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考