# Kubernetes 清单生成器创建生产就绪的 Kubernetes 清单的分步指南，包括部署、服务、ConfigMap、Secret 和 PersistentVolumeClaims。 ## 目的该技能提供了全面的指导，帮助您按照云原生最佳实践和 Kubernetes 约定生成结构良好、安全且可用于生产的 Kubernetes 清单。 ## 何时使用此技能当您需要执行以下操作时，请使用此技能： * 创建新的 Kubernetes 部署清单 * 定义网络连接的服务资源 * 生成ConfigMap和Secret资源用于配置管理 * 为有状态工作负载创建 PersistentVolumeClaim 清单 * 遵循 Kubernetes 最佳实践和命名约定 * 实施资源限制、健康检查和安全上下文 * 多环境部署的设计清单 ## 分步工作流程 ### 1\.收集需求 **了解工作量：** * 应用程序类型（无状态/有状态） * 容器镜像和版本 * 环境变量及配置需求 * 存储要求 * 网络暴露要求（内部/外部） * 资源需求（CPU、内存） * 缩放要求 * 健康检查端点 **要问的问题：** * 应用程序名称和用途是什么？ * 将使用什么容器镜像和标签？ * 应用程序是否需要持久存储？ * 应用程序公开哪些端口？ * 是否需要任何秘密或配置文件？ * CPU 和内存要求是多少？ * 应用程序是否需要对外暴露？ ### 2\.创建部署清单 **遵循此结构：** api版本：apps/v1 种类：部署元数据：名称：<应用程序名称> 命名空间：<命名空间> 标签：应用程序：<应用程序名称> 版本：<版本> 规格：副本：3 选择器：匹配标签：应用程序：<应用程序名称> 模板：元数据：标签：应用程序：<应用程序名称> 版本：<版本> 规格：容器： - 名称：<容器名称> 图片：<图片>:<标签> 端口： - 容器端口：<端口> 名称：http 资源：要求：内存：“256Mi” 中央处理器：“250m” 限制：内存：“512Mi” 中央处理器：“500m” 活性探针： http获取：路径：/健康端口：http 初始延迟秒数：30 周期秒：10 准备情况探针： http获取：路径：/准备好端口：http 初始延迟秒数：5 周期秒：5 环境： - 名称：ENV_VAR 值：“值” 环境来自： - 配置映射参考：名称：<应用程序名称>-config - 秘密参考：名称：<应用程序名称>-秘密 **应用的最佳实践：** * 始终设置资源请求和限制 * 实施活性和就绪探针 * 使用特定的图像标签（绝不是`:latest`） * 为非 root 用户应用安全上下文 * 使用标签进行组织和选择 * 根据可用性需求设置适当的副本数量 **参考：** 请参阅 `references/deployment-spec.md` 了解详细的部署选项 ### 3\.创建服务清单 **选择适当的服务类型：** **ClusterIP（仅限内部）：** api版本：v1 种类：服务元数据：名称：<应用程序名称> 命名空间：<命名空间> 标签：应用程序：<应用程序名称> 规格：类型：集群IP 选择器：应用程序：<应用程序名称> 端口： - 名称：http 端口：80 目标端口：8080 协议： TCP **负载均衡器（外部访问）：** api版本：v1 种类：服务元数据：名称：<应用程序名称> 命名空间：<命名空间> 标签：应用程序：<应用程序名称> 注释： service.beta.kubernetes.io/aws-load-balancer-type：nlb 规格：类型：负载均衡器选择器：应用程序：<应用程序名称> 端口： - 名称：http 端口：80 目标端口：8080 协议： TCP **参考：** 请参阅 `references/service-spec.md` 了解服务类型和网络 ### 4\.创建配置映射 **对于应用程序配置：** api版本：v1 种类：ConfigMap 元数据：名称：<应用程序名称>-config 命名空间：<命名空间> 数据： APP_MODE：生产 LOG_LEVEL：信息 DATABASE_HOST：db.example.com # 对于配置文件应用程序属性： | 服务器端口=8080 服务器主机=0.0.0.0 日志记录级别=信息 **最佳实践：** * 仅对非敏感数据使用 ConfigMap * 将相关配置整理在一起 * 为键使用有意义的名称 * 考虑每个组件使用一个 ConfigMap * 进行更改时的版本 ConfigMap **参考：** 有关示例，请参阅“assets/configmap-template.yaml” ### 5\.创造秘密 **对于敏感数据：** api版本：v1 种类：秘密元数据：名称：<应用程序名称>-秘密命名空间：<命名空间> 类型: 不透明字符串数据： DATABASE_PASSWORD：“更改我” API_KEY：“秘密 API 密钥” # 对于证书文件 tls.crt: | -----开始证书----- ... -----证书结束----- tls.key: | -----开始私钥----- ... -----结束私钥----- **安全考虑：** * 切勿以纯文本形式向 Git 提交秘密 * 使用密封秘密、外部秘密操作员或保险库 *定期轮换秘密 * 使用RBAC限制秘密访问 * 考虑使用 Secret 类型：`kubernetes.io/tls` 作为 TLS 密钥 ### 6\.创建 PersistentVolumeClaim（如果需要） **对于有状态应用程序：** api版本：v1 种类：持久卷声明元数据：名称：<应用程序名称>-数据命名空间：<命名空间> 规格：访问模式： - 读写一次存储类名称：gp3 资源：要求：存储：10Gi **安装在部署中：** 规格：模板：规格：容器： - 名称：应用程序体积安装： - 名称：数据挂载路径：/var/lib/app 卷： - 名称：数据持久卷声明：声明名称：<应用程序名称>-数据 **存储注意事项：** * 根据性能需求选择合适的StorageClass * 使用 ReadWriteOnce 进行单 Pod 访问 * 使用ReadWriteMany进行多pod共享存储 * 考虑备份策略 * 设置适当的保留策略 ### 7\.应用安全最佳实践 **将安全上下文添加到部署：** 规格：模板：规格：安全上下文： runAsNonRoot: true 以用户身份运行：1000 FS组：1000 seccomp简介：类型：运行时默认容器： - 名称：应用程序安全上下文：允许权限升级： false 只读根文件系统：true 能力：掉落： - 全部 **安全检查表：** * 以非 root 用户身份运行 * 放弃所有能力 * 使用只读根文件系统 * 禁用权限提升 * 设置seccomp配置文件 * 使用 Pod 安全标准 ### 8\.添加标签和注释 **标准标签（推荐）：** 元数据：标签： app.kubernetes.io/name: <应用程序名称> app.kubernetes.io/instance: <实例名称> app.kubernetes.io/版本：“1.0.0” app.kubernetes.io/component：后端 app.kubernetes.io/part-of: <系统名称> app.kubernetes.io/管理者：kubectl **有用的注释：** 元数据：注释：描述：“应用描述” 联系方式：“team@example.com” prometheus.io/scrape：“真实” prometheus.io/端口：“9090” prometheus.io/路径：“/metrics” ### 9\.组织多资源清单 **文件组织选项：** **选项 1：带有 `---` 分隔符的单个文件** # 应用程序名称.yaml --- api版本：v1 种类：ConfigMap ... --- api版本：v1 种类：秘密 ... --- api版本：apps/v1 种类：部署 ... --- api版本：v1 种类：服务 ... **选项 2：单独的文件** 体现/ ├── configmap.yaml ├── Secret.yaml ├── 部署.yaml ├── service.yaml └── pvc.yaml **选项 3：定制结构** 基地/ ├── kustomization.yaml ├── 部署.yaml ├── service.yaml └── configmap.yaml 覆盖/ ├── 开发/ │ └── kustomization.yaml └── 产品/ └── kustomization.yaml ### 10\.验证和测试 **验证步骤：** # 试运行验证 kubectl apply -f manifest.yaml --dry-run=client # 服务器端验证 kubectl apply -f manifest.yaml --dry-run=server # 使用 kubeval 进行验证 kubeval 清单.yaml # 使用 kube-score 进行验证 kube-score 分数manifest.yaml # 使用 kube-linter 检查 kube-linter lint manifest.yaml **测试清单：** * 清单通过试运行验证 * 所有必填字段均已存在 * 资源限制合理 * 健康检查已配置 * 设置安全上下文 * 标签遵循约定 * 命名空间已存在或已创建 ## 常见模式 ### 模式 1：简单的无状态 Web 应用程序 **用例：** 标准 Web API 或微服务 **所需组件：** * 部署（3 个副本用于 HA） * 集群IP服务 * ConfigMap用于配置 * API密钥的秘密 * HorizontalPodAutoscaler（可选） **参考：**参见`assets/deployment-template.yaml` ### 模式 2：有状态数据库应用程序 **用例：** 数据库或持久存储应用程序 **所需组件：** * StatefulSet（不是部署） * 无头服务 * PersistentVolumeClaim 模板 * ConfigMap用于数据库配置 * 凭证的秘密 ### 模式 3：后台作业或 Cron **用例：** 计划任务或批处理 **所需组件：** * CronJob 或 Job * 作业参数的ConfigMap * 凭证的秘密 * 带有 RBAC 的 ServiceAccount ### 模式 4：多容器 Pod **用例：** 使用 Sidecar 容器的应用程序 **所需组件：** * 多容器部署 * 容器之间共享卷 * 初始化容器进行设置 * 服务（如果需要） ## 模板 `assets/` 目录中提供了以下模板： * `deployment-template.yaml` \ - 具有最佳实践的标准部署 * `service-template.yaml` \- 服务配置（ClusterIP、LoadBalancer、NodePort） * `configmap-template.yaml` \- 具有不同数据类型的 ConfigMap 示例 * `secret-template.yaml` \- 秘密示例（待生成，未提交） * `pvc-template.yaml` \- PersistentVolumeClaim 模板 ## 参考文档 * `references/deployment-spec.md` \- 详细部署规范 * `references/service-spec.md` \- 服务类型和网络详细信息 ## 最佳实践总结 1. **始终设置资源请求和限制** \- 防止资源匮乏 2. **实施健康检查** \- 确保 Kubernetes 可以管理您的应用程序 3. **使用特定的镜像标签** \- 避免不可预测的部署 4. **应用安全上下文** \- 以非 root 身份运行，删除功能 5. **使用 ConfigMaps 和 Secrets** \- 将配置与代码分开 6. **标记一切** \- 启用过滤和组织 7. **遵循命名约定** \- 使用标准 Kubernetes 标签 8. **应用前验证** \- 使用试运行和验证工具 9. **对清单进行版本控制** \- 通过版本控制保留在 Git 中 10. **带注释的文档** \- 为其他开发人员添加上下文 ## 故障排除 **Pod 未启动：** * 检查镜像拉取错误：`kubectl描述pod ` * 验证资源可用性：`kubectl getnodes` * 检查事件：`kubectl get events --sort-by='.lastTimestamp'` **服务无法访问：** * 验证选择器与 pod 标签匹配：`kubectl get endpoints ` * 检查服务类型和端口配置 * 从集群内测试：`kubectl run debug --rm -it --image=busybox -- sh` **ConfigMap/Secret 未加载：** * 验证部署中的名称是否匹配 * 检查命名空间 * 确保资源存在：`kubectl get configmap,secret` ## 后续步骤创建清单后： 1. 存储在Git仓库中 2. 设置 CI/CD 管道进行部署 3.考虑使用 Helm 或 Kustomize 进行模板化 4. 使用 ArgoCD 或 Flux 实施 GitOps 5.添加监控和可观察性 ## 相关技能 * `helm-chart-scaffolding` \- 用于模板和包装 * `gitops-workflow` \- 用于自动化部署 * `k8s-security-policies` \- 用于高级安全配置

K8s 清单生成器

包含技能