微服务拆分部署
后端团队将单体应用拆成 6 个微服务，每个服务需独立 Deployment 和 Service。手动写 12 个 YAML 文件，字段对齐、端口映射、标签一致性极易出错。使用本工具，输入服务名、镜像、端口和副本数，一次性生成 Deployment 和 Service 模板，标签自动关联，selector 与 service 端口对应无误，避免因手写遗漏导致的 Pod 无法被 Service 发现的问题。
通用metadata
DEPLOYMENTapps/v1
SERVICEv1 · selector 自动关联
INGRESSnetworking.k8s.io/v1
CONFIGMAPv1 · data
后端关联：Service.selector 与 Ingress backend 均自动指向 Deployment 的 app: 应用名 标签，配好 Deployment 即一键配套。
生成 YAMLkubectl apply -f
第一节
关于本工具
About手写 Deployment YAML 时，镜像版本号写错、Service 端口与 Pod 不匹配、Ingress 域名拼错——这类低级错误在线上回滚时才被发现。这个工具把 Deployment、Service、Ingress 三个模板整合到一个页面，填上镜像、端口、域名，直接生成可粘贴的 YAML。所有计算和模板拼接在浏览器本地完成，不经过服务器，填错了随时改，没有网络延迟。
使用场景
Ingress 路径重写
前端团队将 SPA 应用部署在 /app 路径下，后端 API 在 /api 下，需通过同一个域名对外暴露。手动编写 Ingress 规则时，路径前缀与后端服务的映射关系容易写错，导致 404。本工具提供 Ingress 模板，支持路径前缀匹配和重写规则配置，输入域名、路径和后端服务名，自动生成带 rewrite-target 注解的 YAML，确保前端静态资源与 API 请求正确路由到对应 Service。
测试环境快速重建
QA 团队每天需在测试集群上重建 3 套环境，每套环境包含 4 个 Deployment 和 2 个 Service。手动复制旧 YAML 改镜像标签和命名空间，常因漏改导致部署失败。使用本工具，输入环境标识、镜像版本和端口映射，生成完整 YAML 集合，统一替换命名空间和标签，5 分钟内完成一套环境配置，减少因手误导致的重复部署。
灰度发布配置
运维人员需对新版本服务进行灰度发布，创建两个 Deployment（稳定版 v1.0、灰度版 v2.0），通过 Service 的 label selector 分流。手动编写时，两个 Deployment 的标签和 Service 的 selector 必须精确匹配，否则流量全走一个版本。本工具允许用户定义两个 Deployment 的标签差异，自动生成匹配的 Service YAML，确保灰度流量按预期比例分发到不同版本 Pod。
K8s 学习实验
刚接触 K8s 的开发者想理解 Deployment 的 replicas、滚动更新策略与 Service 的端口映射关系。手动写 YAML 常因缩进错误或字段名拼错导致 kubectl apply 报错。本工具提供表单化输入，用户调整副本数、更新策略和容器端口后，实时生成正确 YAML 并预览，通过对比不同参数生成的配置，直观理解字段含义与依赖关系，避免因语法错误浪费调试时间。
第二节
使用指南
Getting Started使用步骤
- 1在「Deployment」区域填写容器名、镜像地址（如 nginx:latest）及副本数，右侧预览区同步生成 Deployment YAML
- 2切换至「Service」标签，选择服务类型（ClusterIP/NodePort/LoadBalancer）并设定端口映射，YAML 预览自动更新
- 3进入「Ingress」标签，输入域名与后端 Service 名称，勾选 TLS 后填入证书密钥名，Ingress 规则即时生成
- 4点击 YAML 预览区右上角「复制」按钮，将完整 YAML 内容粘贴至 kubectl apply 命令使用
输入输出示例
| 输入 | 输出 | 说明 |
|---|---|---|
| Deployment: name=my-app, image=nginx:1.25, replicas=3, port=80, env=DB_HOST=prod-db.example.com | apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-app image: nginx:1.25 ports: - containerPort: 80 env: - name: DB_HOST value: prod-db.example.com | 常规：最典型的 Deployment 配置——指定镜像、副本数、端口、环境变量，验证基本字段完整输出 |
| Service: name=my-svc, selector=app=my-app, port=80, targetPort=8080, type=ClusterIP | apiVersion: v1 kind: Service metadata: name: my-svc spec: selector: app: my-app ports: - port: 80 targetPort: 8080 type: ClusterIP | 常规：Service 基本配置，重点验证 targetPort 与 port 分离、默认 type 为 ClusterIP 的体现 |
| Ingress: name=my-ing, host=api.example.com, path=/v1, serviceName=api-svc, servicePort=80, tlsSecret=my-tls | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ing spec: tls: - hosts: - api.example.com secretName: my-tls rules: - host: api.example.com http: paths: - path: /v1 pathType: Prefix backend: service: name: api-svc port: number: 80 | 常规：Ingress 带 TLS 和路径路由，验证 pathType 默认值（Prefix）和 TLS 配置段是否生成 |
| Deployment: name=zero-replicas, image=busybox, replicas=0, port=80 | apiVersion: apps/v1 kind: Deployment metadata: name: zero-replicas spec: replicas: 0 selector: matchLabels: app: zero-replicas template: metadata: labels: app: zero-replicas spec: containers: - name: zero-replicas image: busybox ports: - containerPort: 80 | 边界：replicas=0 是合法值（用于暂停/缩减），验证工具不会报错或忽略该字段 |
| Service: name=no-selector-svc, port=80, targetPort=80, type=ExternalName, externalName=my-svc.other-ns.svc.cluster.local | apiVersion: v1 kind: Service metadata: name: no-selector-svc spec: type: ExternalName externalName: my-svc.other-ns.svc.cluster.local ports: - port: 80 targetPort: 80 | 边界：ExternalName 类型不需要 selector，验证工具是否正确处理无 selector 场景 |
| Ingress: name=wildcard-host, host=*.example.com, path=/, serviceName=wildcard-svc, servicePort=80 | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: wildcard-host spec: rules: - host: '*.example.com' http: paths: - path: / pathType: Prefix backend: service: name: wildcard-svc port: number: 80 | 边界：通配符域名（*.example.com）在 Ingress 中合法，验证工具是否保留星号且不报错 |
| Deployment: name=multi-port, image=myapp:latest, replicas=2, port=8080, port=8443, env=ENV=prod, env=LOG_LEVEL=debug | apiVersion: apps/v1 kind: Deployment metadata: name: multi-port spec: replicas: 2 selector: matchLabels: app: multi-port template: metadata: labels: app: multi-port spec: containers: - name: multi-port image: myapp:latest ports: - containerPort: 8080 - containerPort: 8443 env: - name: ENV value: prod - name: LOG_LEVEL value: debug | 易错：多端口和多环境变量同时输入，验证工具能否正确处理重复字段（port/env 各两个） |
| Ingress: name=empty-path, host=test.example.com, path=, serviceName=test-svc, servicePort=80 | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: empty-path spec: rules: - host: test.example.com http: paths: - path: / pathType: Prefix backend: service: name: test-svc port: number: 80 | 易错：用户可能不填 path，工具应默认 '/' 而非留空或报错，验证空路径的降级处理 |
常见错误对照
1.Service 的 selector 与 Deployment 的 label 不匹配
✗ 错误
Deployment 的 spec.template.metadata.labels 为 { app: my-app }，Service 的 spec.selector 为 { app: my-app, version: v1 }✓ 修复
Deployment 的 labels 和 Service 的 selector 保持完全一致，如 { app: my-app }Service 通过 selector 精确匹配 Pod 的 label，多一个 key-value 就会导致无端点、流量不通。K8s 官方文档明确要求 selector 必须与 Pod 标签子集一致。
2.Ingress 的 host 字段写成了 IP 地址
✗ 错误
spec.rules[0].host: 192.168.1.100✓ 修复
spec.rules[0].host: example.com 或留空Ingress host 只接受合法域名（RFC 1123），IP 地址会被 K8s 拒绝或忽略。Ingress 控制器依赖 DNS 路由，不是 IP 直连。
3.Deployment 的 replicas 写成了字符串
✗ 错误
spec.replicas: '3'✓ 修复
spec.replicas: 3replicas 是 int 类型，YAML 中加引号变成字符串后，K8s API 校验会报错。严格模式（如 kubectl apply --dry-run=server）直接拒绝。
4.Service 端口名重复导致冲突
✗ 错误
两个端口都写 name: http✓ 修复
每个端口有唯一 name，如 name: http / name: metricsK8s Service 端口名在同一个 Service 内必须唯一，否则创建失败。Istio 等 Service Mesh 还依赖端口名做协议嗅探。
5.Ingress 的 path 没写前缀斜杠
✗ 错误
spec.rules[0].http.paths[0].path: api/v1✓ 修复
spec.rules[0].http.paths[0].path: /api/v1Ingress path 必须以 / 开头，否则 Ingress 控制器（如 nginx-ingress）会报 invalid path 错误。K8s 1.19+ 的 Ingress API 强制校验。
6.Deployment 的 containerPort 与 Service 的 targetPort 类型不一致
✗ 错误
containerPort: 8080（int），targetPort: '8080'（string）✓ 修复
两者都用 int：containerPort: 8080，targetPort: 8080targetPort 支持 int 和 string（命名端口），但混用类型时 K8s 会做隐式转换，容易在端口重命名时引入 bug。最佳实践是保持类型一致。
7.Ingress 的 service.name 拼写错误
✗ 错误
spec.rules[0].http.paths[0].backend.service.name: my-servce✓ 修复
spec.rules[0].http.paths[0].backend.service.name: my-serviceK8s 不会校验 Service 名称是否存在，拼错后 Ingress 创建成功但流量 404。必须与 kubectl get svc 的输出完全一致。
8.Deployment 的 image 标签用了 latest
✗ 错误
spec.template.spec.containers[0].image: nginx:latest✓ 修复
spec.template.spec.containers[0].image: nginx:1.25.3latest 是可变标签，不同节点可能拉取不同版本，导致行为不一致。生产环境必须使用语义化版本标签（如 1.25.3）确保可复现。
第三节
工作原理
How It Works核心公式
replicas = ceil(desired_pods / (1 - max_unavailable_ratio))
变量说明
replicasDeployment 期望副本数desired_pods目标运行 Pod 数量max_unavailable_ratio滚动更新最大不可用比例
示例
目标运行 10 个 Pod，滚动更新策略 maxUnavailable=25%：replicas = ceil(10 / (1 - 0.25)) = ceil(10 / 0.75) = ceil(13.333) = 14。最终 YAML 中 replicas: 14，确保更新期间始终有 ≥10 个 Pod 可用。
用户输入
本地处理
输出结果
第五节
常见问题
Q & A问这个工具生成的 YAML 能直接 kubectl apply 吗？＋
答
可以。生成的 Deployment、Service、Ingress 模板是标准 Kubernetes 资源对象格式，字段命名和结构严格遵循 K8s API v1 规范。填写完参数后复制 YAML 内容，保存为 .yaml 文件，执行 kubectl apply -f 文件名.yaml 即可部署。注意：Ingress 部分需要你的集群已安装 Ingress Controller（如 Nginx Ingress），否则 Ingress 资源虽然创建成功但不会生效。
问为什么生成的 Service 类型是 ClusterIP，我想用 NodePort 怎么改？＋
答
本工具默认生成 ClusterIP 类型，适合集群内部通信。如需对外暴露，在「Service 配置」区域找到「类型」下拉框，目前提供 ClusterIP、NodePort、LoadBalancer 三种选项。NodePort 模式下，K8s 会在每个节点上随机分配 30000-32767 端口，外部通过 节点IP:端口 访问。如果你需要固定端口号，生成后手动修改 YAML 中 spec.ports[].nodePort 字段即可。
问生成的 Ingress 里 pathType 是 Prefix 还是 Exact，有什么区别？＋
答
本工具默认使用 Prefix（前缀匹配）。Prefix 表示路径前缀匹配，例如 /api 会匹配 /api/v1、/api/v2 等所有以 /api 开头的请求；Exact 则必须完全一致，/api 只匹配 /api 本身，不匹配 /api/。如果你后端服务有多个路由（如 /api/v1 和 /api/v2 分别对应不同 Service），建议用 Prefix；如果只有一个精确路径（如 /healthz），用 Exact 更安全。可在 Ingress 配置的「路径类型」字段切换。
问为什么 Deployment 里 replicas 填了 3，生成的 YAML 里却没有？＋
答
replicas 字段默认值为 1（K8s 规范），如果你在界面输入框里没有修改或填了无效值（如非数字、负数），工具会保留默认值 1。检查一下输入框是否显示了 3，如果显示 3 但生成 YAML 里还是 1，可能是页面输入框的「减号按钮」点击后数值未正确同步到内部状态——可以尝试手动输入数字 3，而不是用加减按钮。
问工具生成的 YAML 里没有 resource requests/limits，需要自己加吗？＋
答
是的，本工具目前不自动生成资源配额字段（requests/limits），因为不同场景对资源需求差异很大。生产环境强烈建议手动添加 spec.template.spec.containers[].resources，否则 Pod 可能因节点资源争抢被 OOM Kill 或调度失败。推荐格式：requests: {cpu: 100m, memory: 128Mi}, limits: {cpu: 500m, memory: 512Mi}。如果集群启用了 LimitRange 或 ResourceQuota，不加 limits 可能导致 Pod 创建失败。
问生成的 Service 里 selector 跟 Deployment 的 labels 怎么对应？＋
答
本工具在生成 Deployment 时会自动为其 spec.template.metadata.labels 添加一个 app 标签，值等于你填写的「应用名称」；同时 Service 的 spec.selector 也会自动匹配这个 app 标签。例如应用名称填 my-app，Deployment 的 Pod 模板会有 app: my-app，Service 的 selector 也是 app: my-app。如果你手动修改了 Deployment 的 labels，记得同步修改 Service 的 selector，否则流量不会路由到 Pod。
问为什么生成的 YAML 里 apiVersion 有的是 apps/v1 有的是 v1？＋
答
这是 K8s API 分组和版本决定的。Deployment 属于 apps 组，当前稳定版 apiVersion 是 apps/v1（v1.9+ 集群）；Service 和 Ingress 前者在 core 组（v1），后者在 networking.k8s.io 组（v1.19+ 集群用 networking.k8s.io/v1，老集群用 extensions/v1beta1）。本工具默认使用最新稳定版 apiVersion，如果你的集群版本低于 v1.19，生成的 Ingress 可能无法识别，需要手动将 apiVersion 改为 extensions/v1beta1。
隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。