⚡

应用部署Skill deploying-applications

这个技能专注于应用程序的部署策略，涵盖Kubernetes、无服务器计算、边缘函数和基础设施即代码（IaC）。它提供从开发到生产的全流程指导，包括CI/CD管道设置、GitOps自动化、服务网格选择及云原生架构，适用于DevOps工程师和云架构师。关键词：Kubernetes部署、Serverless架构、边缘计算、IaC工具（Pulumi、OpenTofu）、GitOps、CI/CD自动化、云原生应用部署、容器化技术。

CI/CD 0 次安装 0 次浏览 更新于 3/23/2026

name: 部署应用程序 description: 从Kubernetes到无服务器和边缘函数的部署模式。适用于部署应用程序、设置CI/CD或管理基础设施。涵盖Kubernetes（Helm、ArgoCD）、无服务器（Vercel、Lambda）、边缘（Cloudflare Workers、Deno）、IaC（Pulumi、OpenTofu、SST）和GitOps模式。

部署应用程序

从Kubernetes到无服务器和边缘函数的生产部署模式。弥合从应用程序组装到生产基础设施的差距。

目的

这个技能提供清晰的指导用于：

  • 选择正确的部署策略（Kubernetes、无服务器、容器、边缘）
  • 使用Pulumi或OpenTofu实现基础设施即代码
  • 使用ArgoCD或Flux设置GitOps自动化
  • 选择无服务器数据库（Neon、Turso、PlanetScale）
  • 部署边缘函数（Cloudflare Workers、Deno Deploy）

何时使用此技能

在以下情况下使用此技能：

  • 将应用程序部署到生产基础设施
  • 设置CI/CD管道和GitOps工作流
  • 在Kubernetes、无服务器或边缘部署之间选择
  • 实施基础设施即代码（Pulumi、OpenTofu、SST）
  • 从手动部署迁移到自动化基础设施
  • 与“组装组件”集成以完成部署流程

部署策略决策树

工作负载类型？

├── 复杂微服务（10+服务）
│   └─ Kubernetes + ArgoCD/Flux（GitOps）
│       ├─ Helm 4.0用于打包
│       ├─ 服务网格：Linkerd（5-10%开销）或Istio（25-35%开销）
│       └─ 参见references/kubernetes-patterns.md

├── 可变流量/成本敏感
│   └─ 无服务器
│       ├─ 数据库：Neon/Turso（缩放至零）
│       ├─ 计算：Vercel、AWS Lambda、Cloud Functions
│       ├─ 边缘：Cloudflare Workers（<5ms冷启动）
│       └─ 参见references/serverless-dbs.md和references/edge-functions.md

├── 一致负载/可预测流量
│   └─ 容器（ECS、Cloud Run、Fly.io）
│       ├─ ECS Fargate：AWS原生，无服务器容器
│       ├─ Cloud Run：GCP，缩放至零容器
│       └─ Fly.io：全球边缘，多区域

├── 全局低延迟（<50ms）
│   └─ 边缘函数 + 边缘数据库
│       ├─ Cloudflare Workers + D1（SQLite）
│       ├─ Deno Deploy + Turso（libSQL）
│       └─ 参见references/edge-functions.md

└── 快速原型/初创MVP
    └─ 托管平台即服务
        ├─ Vercel（Next.js，零配置）
        ├─ Railway（任何框架）
        └─ Render（从Git自动部署）

IaC选择？

├─ TypeScript优先 → Pulumi（Apache 2.0，多云支持）
├─ HCL基础 → OpenTofu（CNCF，Terraform兼容）
└─ 无服务器TypeScript → SST v3（基于Pulumi）

核心概念

基础设施即代码（IaC）

使用代码定义基础设施，而非手动配置。

主要：Pulumi（TypeScript）

  • Context7 ID：/pulumi/docs（信任度：94.6/100，9,525片段）
  • TypeScript优先（与React/Next.js相同语言）
  • 多云支持（AWS、GCP、Azure、Cloudflare）
  • 参见references/pulumi-guide.md获取模式和示例

替代：OpenTofu（HCL）

  • CNCF项目，Terraform兼容
  • MPL-2.0许可证（开放治理）
  • 直接替换Terraform
  • 参见references/opentofu-guide.md获取迁移指南

无服务器：SST v3（TypeScript）

  • 基于Pulumi
  • 针对AWS Lambda、API Gateway优化
  • 实时Lambda开发

GitOps部署

以Git为单一真实来源的声明式基础设施。

ArgoCD（推荐给平台团队）：

  • 丰富的Web UI
  • 内置RBAC和多租户
  • 自愈部署
  • 参见references/gitops-argocd.md

Flux（推荐给DevOps自动化）：

  • Kubernetes原生
  • CLI导向
  • 架构更简单
  • 参见references/gitops-argocd.md

服务网格

用于微服务通信、安全和可观测性的可选层。

何时使用服务网格：

  • 多团队微服务（安全边界）
  • 零信任网络（需要mTLS）
  • 高级流量管理（金丝雀、蓝绿部署）

何时不使用：

  • 简单单体或2-3服务（开销不合理）
  • 无服务器架构（不兼容）

Linkerd（性能导向）：

  • 5-10%开销
  • 基于Rust
  • 简单、有主见

Istio（功能丰富）：

  • 25-35%开销
  • C++（Envoy）
  • 高级路由、可观测性

参见references/kubernetes-patterns.md获取服务网格模式。

快速启动工作流

工作流1：将Next.js部署到Vercel（零配置）

# 安装Vercel CLI
npm i -g vercel

# 链接项目
vercel link

# 部署到生产环境
vercel --prod

参见examples/nextjs-vercel/获取完整示例。

工作流2：使用ArgoCD部署到Kubernetes

  1. 创建Helm图表
  2. 将图表推送到Git仓库
  3. 创建ArgoCD应用
  4. ArgoCD自动同步

参见examples/k8s-argocd/获取完整GitOps设置。

工作流3：使用Pulumi部署无服务器应用

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

// 创建Lambda函数
const lambda = new aws.lambda.Function("api", {
    runtime: "nodejs20.x",
    handler: "index.handler",
    role: role.arn,
    code: new pulumi.asset.FileArchive("./dist"),
});

export const apiUrl = lambda.invokeArn;

参见examples/pulumi-aws/和references/pulumi-guide.md获取模式。

工作流4：将边缘函数部署到Cloudflare Workers

import { Hono } from 'hono'

const app = new Hono()

app.get('/api/hello', (c) => {
  return c.json({ message: '从边缘来的你好！' })
})

export default app

使用Wrangler部署：

wrangler deploy

参见examples/cloudflare-workers-hono/和references/edge-functions.md。

与组装组件集成

在使用“组装组件”构建应用程序后，此技能提供部署模式：

前端（Next.js/Vite）→ 部署：

  1. 查看部署决策树
  2. 选择平台：Vercel（Next.js）、Cloudflare Pages（静态）或自定义（Pulumi）
  3. 设置环境变量
  4. 使用选择的方法部署

后端（FastAPI/Axum）→ 部署：

  1. 容器化应用程序（Dockerfile）
  2. 选择平台：ECS Fargate、Cloud Run或Kubernetes
  3. 设置IaC（Pulumi或OpenTofu）
  4. 使用GitOps（ArgoCD/Flux）或CI/CD部署

参见references/pulumi-guide.md获取集成示例。

参考文件

Kubernetes部署

  • references/kubernetes-patterns.md - Helm 4.0、服务网格、自动缩放
  • references/gitops-argocd.md - ArgoCD/Flux GitOps工作流

无服务器与边缘

  • references/serverless-dbs.md - Neon、Turso、PlanetScale（缩放至零）
  • references/edge-functions.md - Cloudflare Workers、Deno Deploy（<5ms冷启动）

基础设施即代码

  • references/pulumi-guide.md - Pulumi TypeScript模式、组件模型
  • references/opentofu-guide.md - OpenTofu/Terraform迁移

实用脚本

scripts/中的脚本在执行时不会加载到上下文（无令牌）。

生成Kubernetes清单：

python scripts/generate_k8s_manifests.py --app-name my-app --replicas 3

验证部署配置：

python scripts/validate_deployment.py --config deployment.yaml

参见脚本文件获取完整使用文档。

示例

examples/中的完整可运行示例：

  • pulumi-aws/ - 使用Pulumi部署ECS Fargate
  • k8s-argocd/ - Kubernetes + ArgoCD GitOps
  • sst-serverless/ - SST v3无服务器TypeScript

每个示例包括：

  • README.md包含设置说明
  • 完整源代码
  • 环境变量配置
  • 部署命令

库推荐

基础设施即代码（2025）

主要：Pulumi

  • Context7：/pulumi/docs（信任度：94.6，9,525片段）
  • TypeScript优先，多云支持
  • Apache 2.0许可证

替代：OpenTofu

  • CNCF项目，MPL-2.0
  • Terraform兼容
  • HCL语法

无服务器：SST v3

  • 基于Pulumi
  • AWS Lambda优化
  • TypeScript原生

无服务器数据库

Neon PostgreSQL：

  • 数据库分支（类似Git）
  • 缩放至零计算
  • 完全PostgreSQL兼容

Turso SQLite：

  • 边缘部署（200+位置）
  • 亚毫秒级读取
  • libSQL（SQLite分支）

PlanetScale MySQL：

  • 非阻塞模式变更
  • Vitess驱动
  • 按行定价

参见references/serverless-dbs.md获取比较和集成。

边缘函数

Cloudflare Workers：

  • <5ms冷启动（V8隔离）
  • 200+边缘位置
  • 每请求128MB内存

Deno Deploy：

  • TypeScript原生
  • Web标准API
  • 全球边缘（<50ms延迟）

Hono框架：

  • 在所有边缘运行时运行
  • 14KB捆绑大小
  • TypeScript优先

参见references/edge-functions.md获取模式。

最佳实践

安全

  • 使用秘密管理（AWS Secrets Manager、Vault）
  • 为服务间通信启用mTLS
  • 实施最小权限IAM角色
  • 扫描容器镜像的漏洞

成本优化

  • 对可变流量使用无服务器数据库（缩放至零）
  • 在Kubernetes中启用水平Pod自动缩放（HPA）
  • 正确调整计算资源（CPU/内存）
  • 对非关键工作负载使用Spot实例

性能

  • 将部署靠近用户（对全球应用使用边缘函数）
  • 对静态资产使用CDN（CloudFront、Cloudflare）
  • 实施缓存策略（Redis、CloudFront）
  • 监控无服务器的冷启动时间

可靠性

  • 实施健康检查（Kubernetes存活/就绪探针）
  • 设置自动缩放（HPA、Lambda并发）
  • 对关键服务使用多区域部署
  • 实施断路器与重试

故障排除

部署失败

Kubernetes Pod启动失败：

  1. 检查Pod日志：kubectl logs <pod-name>
  2. 描述Pod：kubectl describe pod <pod-name>
  3. 验证资源限制与请求
  4. 检查镜像拉取错误（imagePullSecrets）

无服务器冷启动太慢：

  1. 减少捆绑大小（树摇、代码分割）
  2. 使用预配置并发（AWS Lambda）
  3. 考虑边缘函数（Cloudflare Workers）
  4. 优化初始化代码

GitOps同步错误（ArgoCD/Flux）：

  1. 验证Git仓库访问
  2. 检查清单有效性（kubectl apply --dry-run）
  3. 审查同步策略（修剪、自愈）
  4. 检查ArgoCD/Flux日志

性能问题

服务网格开销高：

  1. 考虑切换到Linkerd（5-10% vs Istio 25-35%开销）
  2. 禁用不必要功能
  3. 评估是否需要服务网格

数据库连接池耗尽：

  1. 增加连接池大小
  2. 使用无服务器数据库（Neon缩放至零）
  3. 实施连接池（PgBouncer）

参见references/文件获取详细故障排除指南。

迁移模式

从手动到IaC

  1. 清点现有基础设施
  2. 从非关键环境开始（开发、暂存）
  3. 使用Pulumi/OpenTofu将基础设施代码化
  4. 在生产前在暂存测试
  5. 逐步迁移（一次一个服务）

从Terraform到OpenTofu

# 安装OpenTofu
brew install opentofu

# 迁移状态
terraform state pull > terraform.tfstate.backup
tofu init -migrate-state
tofu plan
tofu apply

参见references/opentofu-guide.md获取完整迁移。

从EC2到容器

  1. 容器化应用程序（创建Dockerfile）
  2. 本地测试（Docker Compose）
  3. 部署到暂存（ECS/Cloud Run/Kubernetes）
  4. 监控性能与成本
  5. 切换生产流量（蓝绿部署）

从容器到无服务器

  1. 识别无状态服务
  2. 重构为无服务器友好模式
  3. 使用无服务器数据库（Neon/Turso）
  4. 部署到Lambda/Cloud Functions
  5. 监控冷启动与成本

后续步骤

部署应用程序后：

  • 设置可观测性（指标、日志、追踪）
  • 实施CI/CD管道（GitHub Actions、GitLab CI）
  • 配置自动缩放与资源限制
  • 设置灾难恢复与备份
  • 为事件响应记录运行手册

附加资源