Pulumi 与云原生 IaC

• Component Resource 概念
• 可复用抽象与封装
• 与内置资源（Custom Resource）的区别

Pulumi Component Resource 是用户自定义的、逻辑分组并封装一组资源的组件，它把多个底层资源（如 VM + 网络 + 安全组 + 存储）封装成一个可复用的逻辑单元，对使用者暴露统一的输入输出接口。区别于 Custom Resource（对应单个云资源，由 provider 管理），Component Resource 是纯逻辑组合，不映射到单个云资源，可包含任意逻辑（循环、条件、子资源）。可复用抽象的价值：把"安全组 + 子网 + 实例"这类重复模式封装成团队标准组件，参数化输入（vpc、subnet、size、tags），内置默认安全策略，供多个环境/项目复用，保证一致性与治理。实践：定义组件函数（component），内部用循环/条件组织资源，输出暴露关键属性（如实例 ID、IP），配合 Policy 与文档化，形成组织级"黄金组件库"。Component Resource 是 Pulumi 做"可复用抽象"的核心机制。

本题考查 Component Resource 的定位。关键在于区分"逻辑组件"（Component，封装一组资源）与"单资源"（Custom Resource），并说明它如何通过封装+参数化实现团队级可复用抽象。回答要落到"复用 + 一致性 + 治理"。

• Stack 概念与多环境管理
• 状态后端（local/cloud/self-managed）
• 状态隔离与并发

Pulumi Stack 是一个隔离的部署实例（对应一个环境，如 dev/staging/prod），Stack 保存了资源与目标的映射（state）。Stack 管理：往往一个环境一个 Stack（如 project/dev、project/prod），通过 Stack 命令切换环境，Stack 配置（pulumi config）区分环境参数，secret 用加密方式存储。状态后端设计：Pulumi 支持本地（local）、Pulumi Cloud（托管 state）、自管理后端（self-managed，如 S3/OSS/Blob + 锁）。设计要点：状态隔离——各环境独立 Stack，避免跨环境互相影响；并发安全——用支持锁的后端（Pulumi Cloud 或自管理带锁）防止多人同时 apply 冲突；加密与版本化——敏感 state 加密存储、后端开启版本控制便于回滚；访问控制——后端按最小权限授权。落地：多环境用多 Stack + 远程后端 + 锁 + 加密，实现环境隔离与协作安全。

Stack 是 Pulumi 的环境隔离单元，后端是状态存储。关键是"一个环境一个 Stack + 远程有锁后端 + 加密 + 最小权限"，保证多环境隔离与并发安全。回答要先讲 Stack 概念再讲后端设计。

• 通用编程语言优势（循环/条件/抽象）
• 类型安全（编译期检查）
• 与声明式 DSL 的对比

Pulumi 用通用编程语言（Python/TS/Go/Java/C#）定义基础设施，优势明显：其一，表达力——可用循环、条件、函数、类、模块、第三方库等编写复杂逻辑，比声明式 DSL（HCL）更灵活，能表达"批量创建、条件分支、复杂依赖"；其二，抽象与复用——通过函数/类/组件封装复杂模式，形成可复用库；其三，类型安全——利用语言类型系统（TS 类型、Go 静态类型、Python 类型标注）在编译/静态检查阶段发现参数错误、拼写错误、类型不匹配，避免运行时才发现基础设施配置错误；其四，生态与测试——用同一语言写单元测试、与现有代码库集成。类型安全基础设施：把基础设施定义为类型化对象，IDE 自动补全、编译期校验、重构安全，显著降低配置错误。落地：用类型化语言定义资源、用组件封装、用测试验证，提升基础设施代码质量与可维护性。

本题核心是"通用语言 vs 声明式 DSL"。优势落在表达力、抽象复用、类型安全、生态测试四点，尤其突出类型安全能在编译期拦截错误。回答要对比 HCL 说明通用语言的价值。

• protect 资源保护
• retainOnDelete 保留删除
• deleteBeforeReplace 语义与误用风险

Pulumi 提供资源保护与危险操作防护选项。protect：标记资源受保护，防止被 update/delete 意外删除（如生产数据库、生产数据）；protect 开启时删除会报错，需先解除保护或强制，防止误删。retainOnDelete：删除资源时不在云厂商处删除实际资源（保留副本），用于数据安全/迁移场景，但需注意会留下"孤儿"资源产生成本与漂移。deleteBeforeReplace：删除旧资源后再创建新资源（默认先建后删），适用于抢占式资源（如某些不能并存或会被重名的资源），但其风险是"先删后建"期间有停机窗口，若创建失败则服务不可用。误用风险：滥用 protect 导致无法正常更新/删除，需人工解除；滥用 retainOnDelete 造成成本与资源泄漏；滥用 deleteBeforeReplace 造成停机与可用性风险。实践：按资源语义谨慎选择——生产数据用 protect，迁移场景用 retainOnDelete，确实无法并存的资源才用 deleteBeforeReplace，并评估停机影响。

本题考"保护与防护选项的语义与风险"。关键要讲清三个选项各自语义（protect 防删、retainOnDelete 保留副本、deleteBeforeReplace 先删后建）以及各自的误用风险（无法更新、造成孤儿资源、停机窗口）。回答要落到"按需谨慎选用"。

• Automation API 概念
• 程序化创建/更新/销毁
• 应用场景（自服务平台、编排）

Pulumi Automation API 是 Pulumi 的编程式 SDK，允许在应用代码中直接调用 Pulumi 引擎（up、preview、destroy、select stack 等），把基础设施部署嵌入到应用程序中，无需 CLI。它实现"程序化基础设施"：通过代码创建/选择 Stack、配置、执行 preview/up/destroy、读取输出，并捕获事件与日志。适用场景：自服务平台（用户通过 UI 提交请求，后端动态创建/销毁环境）、CI/CD 流水线集成、动态环境编排（如 PR 环境、临时环境）、把 IaC 封装进业务系统。优点：自动化、可编程、可嵌入业务流程；注意：需管理并发与安全（凭证管理、权限控制）、处理错误与回滚。落地：用 Automation API 在应用中动态执行 Pulumi，实现"环境即服务"。

本题考查 Automation API 的定位。核心是"把 Pulumi 引擎编程化嵌入应用"，实现程序化、动态的基础设施管理。回答要讲清它能做什么（循环/动态创建销毁）与适用场景（自服务、CI/CD）。

• Policy as Code 概念
• 合规规则与拦截
• 集成与实施

Pulumi Policy as Code（Policy Packs）允许用代码定义基础设施合规策略，在 preview/up 时自动审查并强制规则。实现：用 Policy Pack（TypeScript/Python）编写规则（如"必须打标签""禁止开放 0.0.0.0/0 的 SSH""存储必须加密"），策略可设为 advisory（警告）或 mandatory（强制拦截），Pulumi 在部署时评估每个资源，不满足强制策略则阻止部署。合规自动化：策略代码化纳入版本管理，与 CI/CD 集成（每个 PR/apply 自动跑策略），实现"合规即门禁"；用统一策略管理多 Stack 策略。价值：把合规从"人工检查"变为"自动强制"，提前发现问题、减少违规、可审计。注意：策略需覆盖常见规范（标签、加密、网络暴露、成本），并随治理要求演进。落地：编写 Policy Pack → 设 advisory/mandatory → 集成 CI → 门禁拦截，实现合规自动化。

本题考 Policy as Code 的应用。核心是"用代码定义合规规则并在部署时自动强制"。回答要讲清 Policy Pack 的机制（advisory/mandatory）、与 CI 集成、以及合规自动化的价值。

• Pulumi 与 Terraform 互操作
• 导入（import）机制
• 迁移策略与风险

Pulumi 与 Terraform 可以互操作：Pulumi 支持导入已有 Terraform 资源（通过 import 或 state 转换），也可在 Pulumi 中调用 Terraform provider/资源（如 pulumi terraform state 导入、Aws 等原生 provider），同时 Pulumi 生态提供 pulumi convert 把 Terraform 代码转换为 Pulumi 代码。迁移策略：一是"逐资源导入"——用 Pulumi 的 import 或 pulumi import 把已有云资源纳入 Pulumi 管理，避免破坏现有资源；二是"代码转换"——用转换工具把 Terraform HCL 转为 Pulumi（TS/Go/Python），再人工审查与修正；三是"混合共存"——迁移期间 Terraform 与 Pulumi 并存，分模块/分环境逐步迁移，避免全量切换。风险控制：迁移前备份 state、小范围试点（先一个模块/环境）、对比资源与依赖、验证幂等性、回滚预案。落地：理解互操作 → 选迁移方式（导入/转换/混合）→ 试点 → 逐步迁移 → 验证与回滚。

本题考互操作与迁移。核心是"导入现有资源 + 转换代码 + 混合共存逐步迁移"，强调小步试点与回滚，避免一次性切换。回答要讲清工具能力与迁移节奏。

• 多云统一抽象
• 抽象层设计（组件/接口）
• 跨云差异与治理

Pulumi 天然支持多云（同一套代码管理 AWS/Azure/GCP/K8s 等），统一抽象层设计要点：其一，用 Component Resource 封装跨云通用模式——把"创建 VM + 网络 + 安全组"这类通用模式封装成组件，内部按云平台分支实现，对外暴露统一接口（如 createNode(args)），屏蔽云差异；其二，用条件/映射处理云差异——同一抽象在不同云渲染不同资源（if cloud == 'aws' 用 aws.，否则用 azure.），通过配置或映射表驱动。其三，统一治理——把标签、加密、网络策略、成本约束做成统一组件/策略，跨云统一执行。其四，可测试与可维护——抽象层用语言特性（接口、类型、测试）保证质量。注意：抽象层要平衡"统一"与"云原生能力"，避免过度抽象掩盖云特性（如 AWS 特有能力），可提供"标准抽象 + 云扩展"两级。落地：Component 封装通用模式 → 条件/映射处理差异 → 统一策略治理 → 类型/测试保障质量。

本题考多云抽象层设计。核心是"用 Component 封装通用模式 + 条件逻辑处理云差异 + 统一策略治理"，并注意避免过度抽象。回答要落到"统一接口 + 云差异 + 治理"。

• 状态管理（后端/锁）
• 并发隔离（Stack/Provider）
• 多团队安全实践

Pulumi 通过状态管理与并发隔离保证多团队安全。状态管理：状态存于后端（Pulumi Cloud/self-managed S3 等），支持加密与版本化；用带锁的后端防止并发写入冲突——同一 Stack 同时被两个 apply 操作时，锁保证串行，避免状态损坏。并发隔离：按"环境/团队"拆分 Stack，每个 Stack 独立状态，团队间互不干扰；用 Provider instance 隔离（不同团队/项目用不同 provider 配置和凭证），限制访问范围；Stack 级权限（Pulumi Cloud 的 RBAC）控制谁能查看/更新/删除。多团队安全实践：命名空间划分（project/stack 规范）、最小权限（后端与云凭证最小化）、分支/PR 评审、变更审计（谁在何时改了哪个 Stack）、敏感信息用 secret 加密。落地：后端带锁 + 按环境拆分 Stack + Provider/权限隔离 + RBAC + 审计，保证多团队并发安全。

本题考多团队并发安全。核心是"状态锁防并发 + Stack 隔离环境 + Provider/RBAC 隔离权限 + 审计"。回答要讲清状态并发隔离与权限隔离两个层面。

• 编程式 vs 声明式
• 差异对比
• 适用边界

Pulumi 编程式（真实语言）与 Terraform 声明式（HCL）的差异：表达力——Pulumi 用编程语言（循环/条件/函数/抽象/复用），Terraform 用声明式 DSL（HCL 有 count/for_each 有表达力但弱于语言）；类型安全——Pulumi 有编译期类型检查，Terraform 靠 plan 校验；状态与预览——两者都有 state 与 plan/preview，机制类似；生态——Terraform provider 生态成熟、社区大，Pulumi 也有丰富 provider 但相对年轻。适用边界：Terraform 适合——团队熟悉 HCL、需声明式可读性、依赖 Terraform 生态/模块、云中立、简单到中等复杂度；Pulumi 适合——团队擅编程、需复杂逻辑（动态循环、条件、抽象复用）、需类型安全与测试、多语言集成、自服务/自动化场景。落地：简单声明选 Terraform，复杂逻辑与编程生态选 Pulumi，按团队技能与场景边界选择。

本题考差异与适用边界。核心是"编程式 vs 声明式"的差异（表达力、类型安全、生态），并落到场景边界。回答要对比后给出选型建议，避免"哪个更好"争议。

• 循环（批量创建）
• 条件（按环境分支）
• 函数抽象（复用）

Pulumi 编程式 IaC 用真实语言表达复杂基础设施，优势明显。循环：用 for 循环/列表推导批量创建同构资源（如为 50 个服务各建一个 Target Group、为 10 个可用区建子网），比 HCL 的 count/for_each 更直观、可编程（可嵌套、可计算）。条件：用 if/elif/switch 按环境/配置分支（如 dev 不加 WAF、prod 加 WAF 与多 AZ），实现声明式难以表达的"条件化基础设施"。函数抽象：把"创建微服务基础设施"封装成函数/类/组件，参数化（name、size、tags），内部组合资源，多处复用，保证一致性与可维护。组合：循环+条件+抽象可构建复杂拓扑（如根据服务清单动态生成资源、按环境差异渲染），并配合类型与测试保证正确性。落地：用循环处理批量、条件处理分支、函数/组件抽象复用，充分发挥编程语言优势。

本题考编程式表达优势。核心是"循环、条件、函数抽象"三个机制如何表达复杂基础设施，与 HCL 对比。回答要落到三者如何组合实现批量、分支与复用。

• stack config 配置
• secret 加密管理
• 多环境参数化

Pulumi Stack 配置与多环境管理要点：stack config——用 pulumi config set 按 Stack 存配置（如 pulumi config set aws:region us-east-1），配置按 Stack 隔离，不同环境不同值；secret——敏感配置用 pulumi config set --secret（或代码中 pulumi.secret()）加密存储，Pulumi 用密钥加密后在 state 中保存，代码中不暴露明文。多环境参数化：一个 project 多个 Stack（dev/staging/prod），各 Stack 有独立 config 与 state；组织方式——用 Stack 文件（Pulumi.dev.yaml/Pulumi.prod.yaml）保存各环境配置，程序里用 config.get_xxx() 读取环境参数，按环境差异渲染资源；可把环境差异（region、instance size、副本数、是否启用 WAF）集中到 config 管理。实践：config 存非敏感参数、secret 存敏感参数、各环境独立 Stack + Stack 文件、代码参数化读取。落地：Stack 隔离环境 + config 参数化 + secret 加密，实现多环境一致管理。

本题考 Stack 配置与多环境。核心是"config 存参数、secret 加密、多 Stack 隔离环境、代码参数化"。回答要讲清非敏感与敏感配置的区分与多环境组织。

• Provider 版本锁定
• preview diff 检查
• 升级回归风险把控

Pulumi Provider 版本与升级管理要点：版本锁定——在项目配置（Pulumi.yaml/dependencies）中锁定 provider 版本，避免自动升级导致意外行为变化；用 package 版本固定（如 aws provider 固定版本），保证可复现。preview diff——升级/变更前先跑 pulumi preview 检查 diff，确认只有预期变更（无意外替换/删除），再批准 up；diff 是安全门禁。升级回归风险把控——升级 provider 前审阅升级说明（破坏性变更、弃用项、默认值变化），在非生产环境（dev/staging）先升级验证，用 preview 对比升级前后 diff，确认无破坏性变更后再 prod 升级；保留回滚策略（版本可回退、state 可恢复）。实践：锁定版本 + 升级前 preview diff + 非生产先行 + 审阅变更说明 + 回滚预案。落地：版本锁定保证可复现，preview diff 与分环境升级控制回归风险。

本题考 provider 升级管理。核心是"版本锁定 + preview diff 门禁 + 非生产先行 + 回滚"，避免升级引入破坏性变更。回答要落到升级流程的风险控制。

• 云资源管理能力
• Kubernetes 管理能力
• Policy as Code 能力

Pulumi 与 Terraform 在三个方面能力对比：云资源——两者都支持主流云（AWS/Azure/GCP）与大量 provider，Terraform provider 生态更成熟、社区更大，Pulumi 也有丰富 provider 且跨云统一；K8s——两者都支持 Kubernetes 资源管理，Pulumi 用真实语言（TS/Go/Python）操作 K8s 更灵活，支持跨云 K8s 统一管理，Terraform 用 kubernetes provider 管理 K8s 资源但表达力弱一些；Policy as Code——Terraform 需配合 OPA/conftest、checkov 等外部工具做策略，Pulumi 内置 Policy as Code（Policy Packs，TypeScript/Python 定义规则，advisory/mandatory 拦截），与部署流程集成更紧密。总体：Terraform 生态成熟、声明式、云中立，Pulumi 编程语言灵活、内置策略、K8s 表达力强。选型按团队技能与场景（生态 vs 灵活/策略集成）。

本题考能力对比。核心是"云资源（Terraform 生态成熟）、K8s（Pulumi 灵活）、Policy as Code（Pulumi 内置）"。回答要按三个维度对比并给出选型视角。

• 状态后端差异
• 并发锁机制
• preview 预览机制

Pulumi 与 Terraform 状态管理差异：状态后端——Terraform 用本地 tfstate 或远程后端（S3/OSS/azure + DynamoDB 等）存状态，Pulumi 用 Pulumi Cloud 或 self-managed 后端（S3/OSS 等）存状态；两者都支持远程后端实现共享与版本化。并发锁——Terraform 用后端锁（如 DynamoDB 表）对 state 加锁，防止并发 apply 冲突；Pulumi 的 Cloud 后端自带锁，self-managed 后端也支持锁，机制类似。preview——Terraform 用 terraform plan 生成变更计划供评审，Pulumi 用 pulumi preview 生成预览（diff）供评审，两者都做"先预览后 apply"；差异在于 Pulumi 的 preview 与语言/组件集成，可编程式调用（Automation API）。整体：两者状态管理理念一致（远程后端 + 锁 + 预览），实现细节不同（后端生态、锁实现、预览集成方式）。选型看团队既有生态与需求。

本题考状态管理差异。核心是"后端、锁、preview 三者实现对比"。回答要指出两者理念一致、细节不同（Terraform S3+DynamoDB、Pulumi Cloud/self-managed），避免夸大差异。

• 测试框架（Unit/Integration）
• 基础设施单元测试
• 测试断言与验证

Pulumi 提供测试框架支持基础设施单元测试与集成测试。单元测试：用 @pulumi.test 或 unit test 工具（如 pulumi.testing）在"内存中"运行程序，不实际创建资源，通过 mock 或干跑断言资源配置是否正确（如"创建了 3 个实例""安全组包含 22 端口""实例大小正确"）。集成测试：用真实部署（preview/up）验证资源在云上的实际效果，或结合 pulumi up 后断言输出。断言方式：遍历资源树（allResources、getResource）检查属性，或对 preview 结果做断言。价值：用测试验证基础设施代码逻辑（循环/条件/组件是否正确），避免"配置错误到运行时才发现"，提升 IaC 质量与可维护性。实践：单元测试覆盖逻辑（组件组装、参数化、条件分支），集成测试覆盖真实部署，配合 CI 在每次变更跑测试。落地：单元测试（内存断言）+ 集成测试（真实部署）+ CI 集成，形成基础设施测试体系。

本题考 Pulumi 测试。核心是"单元测试（内存断言资源配置）+ 集成测试（真实部署）"。回答要讲清测试框架机制与断言方式，落到质量保障。

• preview/up 门禁
• Policy as Code 集成
• secret 管理与 CI

Pulumi 的 CI/CD 集成要点：preview/up 门禁——CI 中先跑 pulumi preview 生成 diff 供评审，人工/自动批准后再 pulumi up，可设门禁（如 diff 无预期变更才通过、必须 reviewer 批准）；用 PR 分支流程（preview on PR，up on merge）。Policy as Code——CI 中运行 Policy Pack 对 preview 做合规检查，mandatory 策略不满足则阻止合并/部署，实现"合规门禁"。secret 管理——CI 中敏感配置用 pulumi config set --secret 加密存储（不落明文），provider 凭证用 CI 的 secret 变量/密钥管理（如 GitHub Actions secrets、Vault），避免硬编码；Pulumi Cloud 的 secret 加密与组织级权限管理。落地：CI 组件（preview → 评审 → up）+ Policy 门禁 + secret 加密/密钥管理，形成安全、合规、可审计的 IaC 流水线。

本题考 CI/CD 集成。核心是"preview→up 门禁 + Policy 合规门禁 + secret 加密管理"。回答要讲清把 IaC 纳入 CI/CD 的三个关键管控。

• state 不一致处理
• 导入现有资源
• destroy 失败排障

Pulumi 排障常见场景及处理：state 不一致——云资源被外部修改或 state 丢失导致状态与真实不符，可用 pulumi refresh 更新 state 对齐真实资源，或用 pulumi state 命令修复/编辑 state；若 state 与资源冲突，先 refresh 再 preview 确认差异。导入现有资源——对已有云资源用 pulumi import（或 pulumi import 命令）把资源纳入 Pulumi 管理，先写代码声明资源再 import 关联，避免破坏；import 后需确保代码与资源属性一致。destroy 失败——pulumi destroy 失败常因资源被保护（protect）、依赖未解除、云服务拒绝删除（如非空存储桶）、权限不足；处理：先 pulumi preview destroy 看原因，解除 protect、删除依赖资源、检查权限，用 --target 定向删除或分步处理，必要时手动清理云资源后 refresh。落地：refresh 对齐 state、import 导入现有资源、定位 destroy 失败原因（protect/依赖/权限）分步处理。

本题考排障。核心是"refresh 对齐 state、import 导入、destroy 失败原因排查（protect/依赖/权限）"。回答要给出具体排障手段与处理步骤。

• 多云 provider 管理
• Kubernetes provider 管理
• 混合编排能力

Pulumi 能统一管理多云与云原生资源，混合编排能力强。云厂商 provider：用各云 provider（aws/azure/gcp）管理云资源，同一项目可同时用多个云 provider，实现跨云资源编排。Kubernetes provider：用 kubernetes provider 管理 K8s 资源（Deployment/Service/ConfigMap 等），也可用 k8s 原生资源对象；支持 Helm charts、Kustomize。混合编排：在同一个 Pulumi 程序中混合云资源与 K8s 资源——例如先创建云上 EKS/托管集群（aws provider），再在集群上部署 K8s 资源（kubernetes provider），并传递依赖（集群 ID/凭证给 K8s 程序）；用组件封装"云 + K8s"的完整应用栈。能力：跨云静态资源与 K8s 动态编排统一管理，用真实语言表达复杂依赖，配合 provider 配置与凭证隔离。落地：云 provider 管云资源、K8s provider 管集群内资源、组件串联形成完整栈，实现多云与云原生统一 IaC。

本题考混合编排。核心是"云 provider 与 K8s provider 在同一程序混合编排、传递依赖"。回答要落到"云资源 + 集群内资源统一管理"。

• 依赖图与依赖解析
• 并行执行与并行度控制
• 循环依赖处理

Pulumi 自动构建资源依赖图并据此并行执行。资源依赖解析：Pulumi 通过资源引用（把一个资源的输出传给另一个资源的输入）自动建立依赖，无依赖的资源可并行创建，有依赖的按序执行。并行度控制：Pulumi 默认并行执行独立的资源，可通过 --parallel 控制并行数（默认 10），避免并发过高触发云限流或资源竞争；对大规模部署可调并行度平衡速度与稳定性。循环依赖处理：当资源互相引用形成循环依赖（如 A 需要 B 的输出、B 又需要 A 的输出）时，Pulumi 会报错；解决：用 apply/all 组合输出、拆分资源、用 dependsOn 显式声明、或重构设计打破循环（如把配置提取为独立资源/变量）。实践：依赖自动解析 + 并行控制 + 循环依赖重构，保证正确、高效、可并行的部署。落地：利用自动依赖图并行、控制并行度、打破循环依赖，实现可靠高效的 Pulumi 部署。

本题考依赖图与并行。核心是"自动依赖解析、并行度控制、循环依赖打破"。回答要讲清 Pulumi 如何自动构建依赖并处理循环，依赖图自动解析独立资源并行执行，循环依赖需通过重构或 apply 组合打破。