1. 项目概述用Pulumi统一编排DigitalOcean云资源与Kubernetes集群你有没有试过一边在DigitalOcean控制台点点点创建Droplet、Load Balancer和Volume一边又用kubectl apply -f部署YAML清单到K8s集群最后还得手动维护两套配置——一套是云基础设施的Terraform.tf文件另一套是应用层的Helm values.yaml我干了三年DevOps前两年就是这么过来的改个节点规格要同步改三处扩容时漏掉一个DNS记录就导致服务半天不可用。直到去年把整个DigitalOceanK8s栈迁到Pulumi才真正实现“一次定义、全栈生效”。这个标题说的不是概念演示而是我在生产环境跑了一年半的真实方案用TypeScript写一份代码同时声明DigitalOcean的Droplet集群、VPC网络、托管数据库以及上面运行的Kubernetes集群注意是DO原生托管K8s不是自建再把应用服务、Ingress、Secret全部串起来。它解决的核心问题很实在——告别多工具割裂、配置漂移和状态不一致。适合正在用DigitalOcean做SaaS产品后端、需要快速迭代K8s环境的中小团队也适合想从Terraform平滑过渡到更灵活IaC范式的工程师。关键词里提到的“infraestrutura como código”基础设施即代码在这里不是口号每行TypeScript都对应真实云资源生命周期每次git push都会触发完整环境重建连K8s集群证书轮换都自动完成。2. 整体架构设计与技术选型逻辑2.1 为什么放弃Terraform而选择Pulumi很多人看到标题第一反应是“Terraform不是更成熟吗”——这话没错但成熟不等于适配所有场景。我们当时评估了三个关键痛点第一类型安全缺失。Terraform HCL是弱类型语言写完droplet_size s-2vcpu-4gb根本不知道这个规格名是否真实存在直到apply时报错而Pulumi用TypeScriptIDE能实时提示DigitalOcean所有合法机型s-1vcpu-1gb、m-4vcpu-16gb等还能自动补全参数文档。第二逻辑复用困难。Terraform模块化靠module {}块但跨模块传参像填表格比如要把Droplet的IP地址传给K8s ConfigMap得先输出再引用中间出错难调试Pulumi里直接const nodeIp droplet.ipv4Address; const config new k8s.core.v1.ConfigMap(..., { data: { NODE_IP: nodeIp } });变量天然可传递。第三K8s原生集成深度不足。Terraform Provider for Kubernetes只能管理基础资源Pod/Service对Operator、CRD、Helm Release支持弱Pulumi的pulumi/kubernetes包直接封装了Helm v3 API连helm repo add bitnami https://charts.bitnami.com/bitnami这种操作都能用new k8s.helm.v3.Release()一行代码搞定。提示这不是贬低Terraform而是明确场景边界——如果你的环境90%是AWS/Azure且团队已熟练掌握HCL继续用Terraform完全合理但当你需要高频操作K8s、频繁重构基础设施、或团队主力是JS/TS开发者时Pulumi的编程模型优势会指数级放大。2.2 为什么坚持用TypeScript而非Python或Go标题里明确写了TypeScript这绝非随意选择。我们对比了Pulumi官方支持的三种语言Python语法简洁但类型检查弱mypy需额外配置K8s对象字段如spec.containers[0].ports[0].containerPort容易拼错运行时才暴露Go类型安全强但开发效率低——写个简单的Deployment要定义5个结构体编译等待时间长TypeScript完美平衡。VS Code里输入new k8s.apps.v1.Deployment({自动弹出metadata、spec字段提示按CtrlClick能跳转到pulumi/kubernetes源码看字段定义更重要的是团队前端工程师能直接参与IaC开发——他们写Vue组件用TS写基础设施代码还是TS零学习成本。实测数据用TS编写相同功能的Pulumi程序比Python版本少37%的调试时间比Go版本快2.1倍的迭代速度基于我们内部CI流水线统计。2.3 DigitalOcean托管K8s vs 自建K8s为什么选前者标题里“DigitalOcean e o Kubernetes”并列但没说明是托管还是自建。我们明确采用DO托管K8sdigitalocean.KubernetesCluster理由很务实运维负担归零不用操心etcd备份、API Server高可用、kubelet升级——DO每月自动打补丁我们只关注应用网络无缝打通DO托管K8s默认使用VPC网络Droplet、DB、K8s Node都在同一内网postgres://db.internal:5432这种连接串直接生效省去Service Mesh或Private Link配置成本可控托管集群本身免费只收Node费用而自建需额外3台Master节点至少$45/月且故障率更高。当然有代价无法自定义kube-proxy模式、不能修改CNI插件。但对我们业务来说DO默认的calico网络ipvs代理完全够用为这点自由度增加运维复杂度不值得。3. 核心细节解析与实操要点3.1 环境准备从零搭建Pulumi工作流别跳过这步很多教程直接贴代码结果读者卡在环境配置上。以下是我在Ubuntu 22.04上验证过的最小可行步骤第一步安装Node.js与Pulumi CLI# 官方推荐用nvm管理Node版本避免系统Node冲突 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 18.18.2 # Pulumi 3.110要求Node 18.17 nvm use 18.18.2 # 安装Pulumi CLI注意必须用curl安装apt源版本太旧 curl -fsSL https://get.pulumi.com/ | sh export PATH$PATH:$HOME/.pulumi/bin pulumi version # 应输出v3.110.0第二步配置DigitalOcean访问凭证# 创建Personal Access Token需勾选read/write权限 # 然后设置环境变量生产环境务必用Pulumi Secrets管理 export DIGITALOCEAN_TOKENyour_token_here # 验证是否生效 pulumi config set digitalocean:token $DIGITALOCEAN_TOKEN --secret第三步初始化Pulumi项目mkdir do-k8s-infra cd do-k8s-infra pulumi new typescript --name do-k8s-demo --description DigitalOcean K8s infra --yes # 此时生成基础框架index.ts、Pulumi.yaml、package.json npm install pulumi/digitalocean pulumi/kubernetes pulumi/random --save-dev注意pulumi/random用于生成密码等敏感值避免硬编码。很多新手忽略这点直接把DB密码写进代码这是严重安全隐患。3.2 关键资源依赖关系设计Pulumi的威力在于显式声明依赖。下面这张表不是理论模型而是我们生产环境的真实依赖链箭头表示“被依赖于”资源类型依赖项为什么必须这样设计实操教训digitalocean.Vpc无所有网络资源起点必须最先创建曾因VPC未创建就建Droplet导致资源创建失败且状态混乱digitalocean.KubernetesClusterVPC、SSH密钥DO托管K8s必须指定VPC和SSH密钥忘记传SSH密钥会导致Node无法SSH登录排查耗时2小时digitalocean.DatabaseClusterVPCDB必须和K8s在同一VPC才能内网互通初始配置在default VPCK8s在自定义VPC服务连不上DBk8s.ProviderKubernetesClusterK8s资源需通过Provider连接集群Provider未正确指向新集群导致资源创建到旧集群k8s.core.v1.SecretProviderSecret需通过Provider注入K8sProvider配置错误Secret始终显示Pending这个依赖图决定了代码组织顺序必须先new digitalocean.Vpc()再new digitalocean.KubernetesCluster({ vpcUuid: vpc.id })最后new k8s.Provider(...)。Pulumi会自动解析依赖并按序执行但开发者必须理解逻辑链否则调试时会迷失。3.3 TypeScript代码核心结构拆解以下代码不是Demo片段而是我们生产环境index.ts的精简版已脱敏每行都有实际业务含义import * as pulumi from pulumi/pulumi; import * as digitalocean from pulumi/digitalocean; import * as k8s from pulumi/kubernetes; import * as random from pulumi/random; // 1. 生成随机字符串作为资源前缀避免命名冲突 const prefix new random.RandomString(prefix, { length: 6, special: false, upper: false, }); // 2. 创建VPC显式指定region避免跨区延迟 const vpc new digitalocean.Vpc(do-vpc, { region: sfo3, // 旧金山机房离我们用户最近 ipRange: 10.10.0.0/16, }); // 3. 创建SSH密钥用Pulumi管理密钥而非手动上传 const sshKey new digitalocean.SshKey(do-ssh-key, { name: pulumi.interpolate${prefix.result}-ssh-key, publicKey: ssh-rsa AAAAB3NzaC1yc2E... your_public_key, }); // 4. 创建DigitalOcean托管K8s集群关键参数详解 const cluster new digitalocean.KubernetesCluster(do-k8s-cluster, { region: sfo3, version: 1.28.4-do.0, // 固定小版本避免自动升级导致兼容问题 vpcUuid: vpc.id, // 强制绑定到刚创建的VPC nodePool: { name: default-pool, size: s-2vcpu-4gb, // 平衡成本与性能 nodeCount: 3, // 生产环境最低3节点保证高可用 tags: [k8s-node], // 便于后续监控打标 }, maintenancePolicy: { day: saturday, // 维护窗口设在周末 hour: 03:00, // 凌晨3点业务低峰期 }, }); // 5. 创建K8s Provider让后续K8s资源知道连哪个集群 const k8sProvider new k8s.Provider(k8s-provider, { kubeconfig: cluster.kubeConfigs[0].rawConfig, // 直接取DO返回的kubeconfig }); // 6. 创建PostgreSQL托管数据库同VPC内网直连 const db new digitalocean.DatabaseCluster(do-db, { engine: pg, version: 15, size: db-s-1vcpu-2gb, // 小型DB足够支撑初期业务 region: sfo3, vpcUuid: vpc.id, numNodes: 1, }); // 7. 创建K8s Secret将DB密码注入集群 const dbSecret new k8s.core.v1.Secret(db-secret, { metadata: { namespace: default }, data: { // 密码用base64编码Pulumi自动处理 password: db.dbUserPassword.apply(p Buffer.from(p).toString(base64)), } }, { provider: k8sProvider }); // 8. 部署Nginx应用验证K8s资源创建成功 const nginxDeployment new k8s.apps.v1.Deployment(nginx-dep, { metadata: { namespace: default }, spec: { replicas: 2, selector: { matchLabels: { app: nginx } }, template: { metadata: { labels: { app: nginx } }, spec: { containers: [{ name: nginx, image: nginx:1.25, ports: [{ containerPort: 80 }], }], }, }, }, }, { provider: k8sProvider }); // 9. 创建LoadBalancer Service对外暴露Nginx const nginxService new k8s.core.v1.Service(nginx-svc, { metadata: { namespace: default }, spec: { type: LoadBalancer, selector: { app: nginx }, ports: [{ port: 80, targetPort: 80 }], }, }, { provider: k8sProvider });这段代码的关键在于参数选择有据可依version: 1.28.4-do.0不是随便写的。我们查过DO官方文档1.28.x是当前LTS版本.do.0表示DO定制版含安全补丁避免用1.28这种模糊版本导致升级不可控nodeCount: 3源于K8s调度原理单节点故障时剩余2节点仍能维持Pod驱逐与重调度dbUserPassword.apply(...)用.apply()链式调用确保Secret创建时DB密码已生成这是Pulumi响应式编程的核心技巧。4. 实操过程与核心环节实现4.1 首次部署全流程与关键命令部署不是pulumi up一键完事而是分阶段验证。以下是我在客户环境执行的标准流程附真实耗时阶段一预检与规划约2分钟pulumi preview --diff # 显示将创建哪些资源Droplet/K8s/DB等 # 输出关键信息 # digitalocean:index/vpc:Vpc: (create) # digitalocean:index/kubernetesCluster:KubernetesCluster: (create) # digitalocean:index/databaseCluster:DatabaseCluster: (create) # ~ kubernetes:core/v1:Secret: (update) # 注意Secret会更新因为密码每次生成不同阶段二执行部署约18分钟pulumi up --skip-preview --yes # 跳过二次确认适合CI/CD # 实际日志节选 # Updating (prod): # ... creating digitalocean:index/vpc:Vpc (do-vpc) [12s] # ... creating digitalocean:index/sshKey:SshKey (do-ssh-key) [3s] # ... creating digitalocean:index/kubernetesCluster:KubernetesCluster (do-k8s-cluster) [420s] ← 最耗时DO创建K8s集群需7分钟 # ... creating digitalocean:index/databaseCluster:DatabaseCluster (do-db) [180s] ← DB创建需3分钟 # ... creating kubernetes:core/v1:Secret (db-secret) [8s] # ... creating kubernetes:apps/v1:Deployment (nginx-dep) [5s] # ... creating kubernetes:core/v1:Service (nginx-svc) [15s] ← LB需分配公网IP稍慢注意--skip-preview仅用于CI/CD本地开发务必先pulumi preview看变更影响。曾有同事跳过这步误删了生产DB后果严重。阶段三部署后验证5分钟内必须完成# 1. 验证K8s集群连通性 export KUBECONFIG$(pulumi stack output kubeconfig) # 获取kubeconfig kubectl get nodes # 应显示3个Ready状态节点 kubectl get pods -A # 所有系统Pod应Running # 2. 验证DB内网连通性从K8s Pod测试 kubectl run db-test --rm -i --tty --imagepostgres:15 --restartNever \ --envPGPASSWORD$(pulumi stack output dbPassword) \ --command -- psql -h $(pulumi stack output dbHost) -U doadmin -d defaultdb # 3. 验证应用服务 curl $(pulumi stack output nginxServiceIp) # 应返回Nginx欢迎页4.2 K8s集群证书轮换自动化实现DO托管K8s集群证书1年过期手动轮换极痛苦。Pulumi方案让它全自动原理DO API提供/v2/kubernetes/clusters/{cluster_id}/rotate端点但Pulumi Provider不直接支持。我们用pulumi.runtime.invoke调用DO REST API// 在index.ts末尾添加 const rotateCert pulumi.runtime.invoke(digitalocean:index/getKubernetesCluster:getKubernetesCluster, { name: cluster.name, }).then(clusterInfo { // 调用DO API轮换证书需安装pulumi/digitalocean插件 return pulumi.runtime.invoke(digitalocean:index/rotateKubernetesClusterCertificates:rotateKubernetesClusterCertificates, { clusterId: clusterInfo.id, }); }); // 设置轮换为每年自动触发 const certRotationSchedule new digitalocean.ScheduledAction(cert-rotation, { region: sfo3, type: kubernetes_cluster_rotate_certificates, resourceType: kubernetes_cluster, resourceId: cluster.id, // 每年1月1日凌晨2点执行 executionTime: 0 2 1 1 *, });这个方案的价值在于证书轮换后cluster.kubeConfigs[0].rawConfig会自动更新所有依赖它的K8s Provider无需重启新生成的Secret和Deployment自动使用新证书。我们上线半年证书轮换零故障。4.3 敏感信息安全管理实践标题里没提安全但生产环境必须解决。我们采用三层防护第一层Pulumi Secrets加密存储# 创建stack时启用加密 pulumi stack init prod --secrets-providerawskms://alias/pulumi-secrets?regionus-east-1 # 或用本地加密适合小团队 pulumi stack init prod --secrets-providerpassphrase第二层TypeScript代码中避免明文// ❌ 错误硬编码密码 const db new digitalocean.DatabaseCluster(do-db, { dbUserPassword: my-secret-password, // 绝对禁止 }); // ✅ 正确用random生成并存入Secrets const dbPassword new random.RandomPassword(db-pass, { length: 16, special: true, }); const db new digitalocean.DatabaseCluster(do-db, { dbUserPassword: dbPassword.result, // result是Outputstring });第三层K8s Secret不存敏感值到Git// 创建Secret时从Pulumi Stack获取密码而非代码里写死 const dbSecret new k8s.core.v1.Secret(db-secret, { data: { password: pulumi.secret(dbPassword.result), // 显式标记为secret } });实操心得曾因忘记pulumi.secret()导致DB密码以明文形式出现在pulumi stack export输出中。现在所有敏感字段都加pulumi.secret()CI/CD流水线还增加扫描脚本检测代码中是否出现password、secret等关键词。5. 常见问题与排查技巧实录5.1 典型问题速查表问题现象可能原因排查命令解决方案pulumi up卡在creating digitalocean:index/kubernetesCluster:KubernetesCluster超15分钟DO机房资源不足curl -X GET https://api.digitalocean.com/v2/regions/sfo3 -H Authorization: Bearer $TOKEN查看sfo3区域available字段换区域如nyc3或等资源释放kubectl get nodes返回No resources foundK8s Provider未正确指向集群pulumi stack output kubeconfig | head -20检查clusters[0].cluster.server是否为https://...而非http://确保cluster.kubeConfigs[0].rawConfig被正确传入ProviderNginx Service的EXTERNAL-IP一直pendingDO LoadBalancer配额超限doctl compute load-balancer list查看当前LB数量删除不用的LB或升级DO账户pulumi preview显示~ kubernetes:core/v1:Secret但实际未更新Secret内容未变Pulumi认为无需更新pulumi stack output dbPassword对比前后值用pulumi refresh强制同步状态或修改Secret内容触发更新DB连接超时psql: error: connection to server at xxx.db.ondigitalocean.com failedDB未在VPC内或安全组未放行pulumi stack output dbHost确认域名doctl databases get id查看private_network_uuid确保DB和K8s集群vpcUuid一致且DB的private_network_uuid非空5.2 三个血泪教训与独家技巧教训一不要在同一个Pulumi Stack里混用托管K8s和自建Droplet我们曾尝试在同一个Stack里既创建DO托管K8s又创建Droplet作为CI Runner。结果发现Droplet的public_ipv4和K8s的load_balancer_ip在pulumi up过程中会竞争公网IP配额导致随机一个资源创建失败。独家技巧严格分Stack——do-k8s-prod只管托管K8sDBVPCdo-runner-prod单独管Droplet。用pulumi stack reference跨Stack引用IP地址比混在一起稳定十倍。教训二K8s Deployment的replicas不要设为0来“暂停”服务有同事为临时下线服务把replicas: 2改成replicas: 0。结果pulumi up后Pulumi认为Pod数从2→0是正常变更但下次pulumi up时若忘记改回服务永远不恢复。独家技巧用K8s原生方式暂停——创建HorizontalPodAutoscaler并设minReplicas: 0或用kubectl scale deploy nginx-dep --replicas0手动操作。Pulumi只管理声明式配置不介入运行时扩缩容。教训三pulumi destroy不会删除DO托管K8s的自动备份执行pulumi destroy后DO控制台仍显示K8s集群的备份快照占用空间且收费。独家技巧在destroy前先用DO API清理备份# 获取集群ID CLUSTER_ID$(pulumi stack output clusterId) # 删除所有备份 curl -X DELETE https://api.digitalocean.com/v2/kubernetes/clusters/$CLUSTER_ID/backups \ -H Authorization: Bearer $TOKEN我们已把这个命令封装成pulumi destroy --pre-hook ./cleanup-backups.sh。6. 进阶扩展与生产就绪建议6.1 多环境管理dev/staging/prod三套独立Stack标题没提环境但生产必须支持。我们的方案是Stack命名规范do-k8s-dev、do-k8s-staging、do-k8s-prod资源配置差异devK8s节点用s-1vcpu-2gbDB用db-s-1vcpu-1gb关闭自动备份staging节点用s-2vcpu-4gbDB用db-s-2vcpu-4gb开启每日备份prod节点用m-4vcpu-16gbDB用db-m-4vcpu-16gb开启每小时备份跨区复制。关键技巧用pulumi config区分环境参数# 在dev stack中 pulumi config set nodeSize s-1vcpu-2gb pulumi config set dbSize db-s-1vcpu-1gb # 在prod stack中 pulumi config set nodeSize m-4vcpu-16gb pulumi config set dbSize db-m-4vcpu-16gb代码中读取const nodeSize pulumi.config.get(nodeSize) || s-2vcpu-4gb;6.2 CI/CD集成GitHub Actions全自动部署把Pulumi接入CI/CD是释放生产力的关键。我们用GitHub Actions实现# .github/workflows/pulumi.yml name: Pulumi Deploy on: push: branches: [main] paths: [infrastructure/**] # 只监听infrastructure目录变更 jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: 18.18.2 - name: Install Pulumi uses: pulumi/actionsv4 with: pulumi-version: 3.110.0 - name: Configure DO Token run: echo DIGITALOCEAN_TOKEN${{ secrets.DIGITALOCEAN_TOKEN }} $GITHUB_ENV - name: Pulumi Login run: pulumi login --cloud-url https://api.pulumi.com - name: Deploy to Prod run: | pulumi stack select do-k8s-prod pulumi up --non-interactive --skip-preview --yes注意secrets.DIGITALOCEAN_TOKEN必须在GitHub仓库Settings → Secrets中配置且权限设为Environment: production避免泄露。6.3 成本监控用Pulumi输出实时账单数据标题没提成本但DigitalOcean账单是运维重点。我们用Pulumi自动计算预估月费// 在index.ts中添加 const monthlyCost pulumi.all([ cluster.nodePool.nodeCount, pulumi.output(cluster.nodePool.size).apply(size { // 查DO官网价格表s-2vcpu-4gb $0.03/hr ≈ $21.6/month const prices: Recordstring, number { s-1vcpu-2gb: 10.8, s-2vcpu-4gb: 21.6, m-4vcpu-16gb: 86.4, }; return prices[size] || 0; }), db.numNodes, pulumi.output(db.size).apply(size { const dbPrices: Recordstring, number { db-s-1vcpu-1gb: 15, db-s-2vcpu-4gb: 30, db-m-4vcpu-16gb: 120, }; return dbPrices[size] || 0; }), ]).apply(([nodeCount, nodePrice, dbNodes, dbPrice]) { return (nodeCount * nodePrice) (dbNodes * dbPrice); }); // 输出到Pulumi Console export const estimatedMonthlyCost monthlyCost;每次pulumi up后控制台直接显示estimatedMonthlyCost: 216.0单位美元财务团队再也不用手工算账。我个人在实际操作中发现这套方案最强大的地方不是技术多炫酷而是把“基础设施”真正变成了可测试、可评审、可协作的代码资产。现在我们每周的架构评审会上前端工程师能指着index.ts里的k8s.apps.v1.Deployment代码说“这个副本数设2不够促销期间应该弹性到5”运维不再独自背锅开发也理解了自己写的代码跑在哪。这种协作深度是任何点点点平台都无法提供的。