Kubernetes Manifest 生成实战指南k8s-manifest-generator 的生产级 YAML 创作工作流【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本文以 GitHub 推荐项目精选 / agents24 / agents 仓库中的plugins/kubernetes-operations/skills/k8s-manifest-generator技能为核心完整讲解从需求收集、Deployment / Service / ConfigMap / Secret / PVC 清单编写到安全加固、多资源组织与上线前校验的十步工作流。读完本文你将掌握一套可复制的生产级 Kubernetes YAML 创作方法包括资源限额、三类探针、安全上下文、标准标签、多环境目录组织与 dry-run 校验命令并能直接使用仓库内随附的模板与规范参考文件投入实战。一、技能定位一个用于生成 K8s 清单的 Agent 技能k8s-manifest-generator是仓库 plugins/kubernetes-operations 下提供的一门 Agent 技能Skill。在 SKILL.md 中它的定位被描述为创建生产就绪的 Kubernetes 清单Deployments、Services、ConfigMaps 和 Secrets遵循最佳实践与安全标准。当需要生成 Kubernetes YAML 清单、创建 K8s 资源或编写生产级 Kubernetes 配置时使用。该技能适用于以下场景创建新的 Kubernetes Deployment 清单定义 Service 资源以实现网络连通生成 ConfigMap 与 Secret 资源用于配置管理为有状态工作负载创建 PersistentVolumeClaim 清单遵循 Kubernetes 最佳实践与命名约定落实资源限制、健康检查与安全上下文设计面向多环境部署的清单。技能正文只保留精简导航详细的模式与完整示例集中存放在references/details.md即本文所围绕的核心文档。整个技能包由四部分构成组成部分相对路径作用技能入口SKILL.md技能声明、最佳实践摘要与排障速查详细指南details.md十步工作流、四大模式与模板索引规范参考deployment-spec.md 与 service-spec.mdDeployment 与 Service 的全字段级参考现成模板assets/ 目录下的 YAML 模板可直接取用的生产级清单骨架与仓库中同目录下的其他技能形成互补helm-chart-scaffolding负责模板化打包、gitops-workflow负责自动化部署、k8s-security-policies负责更高级的安全策略NetworkPolicy、Pod Security Standards、RBAC而k8s-manifest-generator则是清单创作本身的地基。二、十步工作流从需求到可上线的清单第 1 步收集需求任何清单创作都应始于对工作负载的理解而不是直接写 YAML。需求收集需要先明确以下维度应用类型无状态stateless还是有状态stateful直接决定使用 Deployment 还是 StatefulSet容器镜像与版本镜像仓库地址、镜像名、tag环境变量与配置需求哪些配置走 ConfigMap、哪些敏感信息走 Secret存储需求是否需要持久化、需要多少容量、哪种访问模式网络暴露需求仅集群内访问ClusterIP、节点直连NodePort还是对外暴露LoadBalancer / Ingress资源需求CPU 与内存的 requests / limits 估值扩缩容需求固定副本数还是需要 HPA健康检查端点应用提供哪些 HTTP 健康端点用于配置探针。在向需求方确认时核心问题清单如下应用名称与用途是什么将使用哪个容器镜像和 tag应用是否需要持久化存储应用暴露哪些端口是否有 Secret 或配置文件需求CPU 与内存需求是多少应用是否需要对外暴露第 2 步创建 Deployment 清单Deployment 是绝大多数无状态应用的主资源。详细指南给出了如下基础结构apiVersion: apps/v1 kind: Deployment metadata: name: app-name namespace: namespace labels: app: app-name version: version spec: replicas: 3 selector: matchLabels: app: app-name template: metadata: labels: app: app-name version: version spec: containers: - name: container-name image: image:tag ports: - containerPort: port name: http resources: requests: memory: 256Mi cpu: 250m limits: memory: 512Mi cpu: 500m livenessProbe: httpGet: path: /health port: http initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: http initialDelaySeconds: 5 periodSeconds: 5 env: - name: ENV_VAR value: value envFrom: - configMapRef: name: app-name-config - secretRef: name: app-name-secret应用此结构时必须遵守的最佳实践始终设置资源 requests 和 limits——防止资源饥饿与单个容器抢占节点同时实现 liveness 与 readiness 探针——让 Kubernetes 有能力管理应用生命周期使用具体镜像 tag绝不使用:latest——避免不可预测的部署结果为容器应用非 root 安全上下文使用标签进行组织与选择根据可用性需求设置合理副本数。关于 Deployment 的全字段级参考副本管理、更新策略、镜像拉取策略、QoS 等级、三类探针、安全上下文、卷、调度、优雅终止等请参见 deployment-spec.md。仓库还提供了可直接取用的生产级模板 deployment-template.yaml其中已经内置了revisionHistoryLimit: 10、零停机滚动更新策略maxSurge: 1/maxUnavailable: 0、minReadySeconds、progressDeadlineSeconds、标准标签、Prometheus 注解、三种探针、生命周期钩子、podAntiAffinity 与 topologySpreadConstraints 等全部生产要素。更新策略与副本管理要点源自 deployment-specstrategy.type支持RollingUpdate默认逐步替换 Pod与Recreate先删后建会短暂停机rollingUpdate.maxSurge默认 25%表示更新期间允许超出期望副本数的最大 Pod 数量如 3 副本 maxSurge: 1时更新期最多 4 个 PodrollingUpdate.maxUnavailable默认 25%表示更新期间允许低于期望副本数的最大数量设置为0可实现零停机发布注意maxSurge与maxUnavailable不能同时为 0revisionHistoryLimit默认 10控制为回滚保留的旧 ReplicaSet 数量设为 0 将禁用回滚能力资源 requests 与 limits 的取值还会自动决定 Pod 的 QoS 等级requests limits 为 Guaranteed最高优先级、最晚被驱逐、requests limits 为 Burstable、完全不设置为 BestEffort最先被驱逐。生产环境建议始终设置 requests内存 limits 通常取 requests 的 1.52 倍。第 3 步创建 Service 清单Service 为 Pod 提供稳定的网络端点。选择哪种 Service 类型取决于暴露需求ClusterIP仅集群内部apiVersion: v1 kind: Service metadata: name: app-name namespace: namespace labels: app: app-name spec: type: ClusterIP selector: app: app-name ports: - name: http port: 80 targetPort: 8080 protocol: TCPLoadBalancer对外访问apiVersion: v1 kind: Service metadata: name: app-name namespace: namespace labels: app: app-name annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb spec: type: LoadBalancer selector: app: app-name ports: - name: http port: 80 targetPort: 8080 protocol: TCP关于 Service 类型与网络细节的完整参考四种类型、命名端口、会话亲和、流量策略、无头服务、服务发现、负载均衡、网络策略等请参见 service-spec.md。仓库随附的 service-template.yaml 一次提供了 7 个模板ClusterIP、LoadBalancer含 AWS NLB 注解与externalTrafficPolicy: Local、NodePort、Headless配合 StatefulSet、多端口 监控指标、带会话亲和ClientIP / 3 小时超时以及 ExternalName 外部服务映射。Service 网络要点速查源自 service-spec命名端口在 Pod 中为端口命名如name: httpService 的targetPort可以直接引用端口名避免容器端口调整时同步改 Service无头服务clusterIP: NoneDNS 返回各个 Pod IP 而非 Service IP是 StatefulSet 发现与数据库集群的标配服务发现集群内 DNS 格式为service-name.namespace.svc.cluster.local同命名空间可直接用服务名访问Kubernetes 还会向 Pod 注入SERVICE_SERVICE_HOST与SERVICE_SERVICE_PORT环境变量注意 Pod 必须晚于 Service 创建流量策略externalTrafficPolicy: Local保留客户端源 IP 并减少一跳但可能造成负载不均Cluster为默认值会跨节点负载均衡但掩盖源 IP会话亲和sessionAffinity: ClientIP可将同一客户端 IP 的请求固定到同一 Pod适用于有状态应用、基于会话的应用与 WebSocket 长连接。第 4 步创建 ConfigMapConfigMap 承载非敏感的应用配置apiVersion: v1 kind: ConfigMap metadata: name: app-name-config namespace: namespace data: APP_MODE: production LOG_LEVEL: info DATABASE_HOST: db.example.com # For config files app.properties: | server.port8080 server.host0.0.0.0 logging.levelINFO最佳实践ConfigMap 只存放非敏感数据敏感信息一律走 Secret将相关配置组织在一起键名使用有意义的命名考虑每个组件一个 ConfigMap变更时对 ConfigMap 进行版本管理更改 ConfigMap 不会自动触发 Pod 滚动更新需配合版本标签或重启策略。仓库随附的 configmap-template.yaml 提供了 7 个进阶模板简单键值对、YAML 配置文件application.yaml、多配置文件nginx.conf 等、JSON 配置、按环境区分的配置production、脚本配置init.sh/healthcheck.sh以及 Prometheus 抓取配置并在文末给出了 4 种挂载用法示例envFrom批量注入环境变量、整卷挂载为文件、items选择性挂载指定键、configMapKeyRef注入单个环境变量。第 5 步创建 SecretSecret 用于敏感数据apiVersion: v1 kind: Secret metadata: name: app-name-secret namespace: namespace type: Opaque stringData: DATABASE_PASSWORD: changeme API_KEY: secret-api-key # For certificate files tls.crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- tls.key: | -----BEGIN PRIVATE KEY----- ... -----END PRIVATE KEY-----安全注意事项永远不要以明文形式将 Secret 提交到 Git——Secret 只应作为清单模板存在实际值需在部署时注入生产环境应使用 Sealed Secrets、External Secrets Operator 或 Vault 等方案管理机密定期轮换 Secret通过 RBAC 限制对 Secret 的访问TLS 证书类机密应使用type: kubernetes.io/tls类型此例仅为展示stringData的写法实际 TLS Secret 建议声明专用类型。第 6 步按需创建 PersistentVolumeClaim有状态应用需要持久化存储apiVersion: v1 kind: PersistentVolumeClaim metadata: name: app-name-data namespace: namespace spec: accessModes: - ReadWriteOnce storageClassName: gp3 resources: requests: storage: 10Gi在 Deployment 中挂载spec: template: spec: containers: - name: app volumeMounts: - name: data mountPath: /var/lib/app volumes: - name: data persistentVolumeClaim: claimName: app-name-data存储考量根据性能需求选择合适的 StorageClass单 Pod 访问使用ReadWriteOnce多 Pod 共享使用ReadWriteMany制定备份策略设置合适的保留策略。第 7 步应用安全最佳实践给 Deployment 添加安全上下文Pod 级 容器级双层加固spec: template: spec: securityContext: runAsNonRoot: true runAsUser: 1000 fsGroup: 1000 seccompProfile: type: RuntimeDefault containers: - name: app securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: - ALL安全自查清单以非 root 用户运行runAsNonRoot: true丢弃所有 capabilitiesdrop: [ALL]仅按需add如NET_BIND_SERVICE使用只读根文件系统readOnlyRootFilesystem: true将/tmp等目录挂为emptyDir禁用特权提升allowPrivilegeEscalation: false设置 seccomp profileRuntimeDefault遵循 Pod Security Standardsrestricted / baseline / privileged 三级命名空间标签关于 Pod 安全标准的命名空间级落地pod-security.kubernetes.io/enforce/audit/warn标签、NetworkPolicy 与 RBAC 的详细配置可参考同仓库的 k8s-security-policies 技能。第 8 步添加标签与注解标准标签推荐使用 Kubernetes 官方推荐标签体系metadata: labels: app.kubernetes.io/name: app-name app.kubernetes.io/instance: instance-name app.kubernetes.io/version: 1.0.0 app.kubernetes.io/component: backend app.kubernetes.io/part-of: system-name app.kubernetes.io/managed-by: kubectl实用注解注解承载非标识性元数据用于描述与观测集成metadata: annotations: description: Application description contact: teamexample.com prometheus.io/scrape: true prometheus.io/port: 9090 prometheus.io/path: /metrics注意 Deployment 的spec.selector.matchLabels与template.metadata.labels必须匹配标准标签中的app.kubernetes.io/nameapp.kubernetes.io/instance组合同时被仓库内的 Deployment / Service 模板用作 selector 依据保证跨资源一致性。第 9 步组织多资源清单三种常见的文件组织方式方式一单文件 ---分隔符# app-name.yaml --- apiVersion: v1 kind: ConfigMap ... --- apiVersion: v1 kind: Secret ... --- apiVersion: apps/v1 kind: Deployment ... --- apiVersion: v1 kind: Service ...方式二独立文件manifests/ ├── configmap.yaml ├── secret.yaml ├── deployment.yaml ├── service.yaml └── pvc.yaml方式三Kustomize 结构base/ ├── kustomization.yaml ├── deployment.yaml ├── service.yaml └── configmap.yaml overlays/ ├── dev/ │ └── kustomization.yaml └── prod/ └── kustomization.yaml对于多环境部署Kustomize 的 base / overlays 结构是仓库模板推荐的方向base 维护通用定义dev / prod overlay 通过 patch 与 configMapGenerator 注入环境差异。第 10 步校验与测试上屏前的校验命令# Dry-run validation客户端校验 kubectl apply -f manifest.yaml --dry-runclient # Server-side validation服务端 schema 校验 kubectl apply -f manifest.yaml --dry-runserver # Validate with kubeval kubeval manifest.yaml # Validate with kube-score kube-score score manifest.yaml # Check with kube-linter kube-linter lint manifest.yaml测试检查清单清单通过 dry-run 校验所有必填字段齐全apiVersion、kind、metadata.name等资源限额设置合理已配置健康检查已设置安全上下文标签符合约定规范目标 Namespace 已存在或已创建三、四大常见模式模式 1简单无状态 Web 应用适用场景标准 Web API 或微服务。所需组件Deployment3 副本保证 HAClusterIP Service用于配置的 ConfigMap用于 API 密钥的 SecretHorizontalPodAutoscaler可选。可直接基于 deployment-template.yaml 起步。模式 2有状态数据库应用适用场景数据库或需要持久化的应用。所需组件StatefulSet注意不是 Deployment无头 ServiceHeadlessclusterIP: NonePersistentVolumeClaim 模板StatefulSet 的volumeClaimTemplates数据库配置用 ConfigMap凭据用 Secret。模式 3后台任务或定时任务适用场景定时任务或批处理。所需组件CronJob 或 Job任务参数用 ConfigMap凭据用 Secret带 RBAC 的 ServiceAccount最小权限。模式 4多容器 Pod适用场景带 sidecar 容器的应用。所需组件多容器的 Deployment容器间共享卷如emptyDir共享日志目录用于初始化依赖的 Init 容器如等待数据库就绪、执行迁移Service按需。在 deployment-spec.md 中可找到对应的完整可运行示例Sidecar Container Patternfluent-bit 只读挂载共享日志卷与 Init Container for Dependencieswait-for-dbrun-migrations组合。四、随附模板资产详细指南声明以下模板位于assets/目录其中仓库内已落盘并确认存在的有三份模板仓库路径内容deployment-template.yamlassets/deployment-template.yaml内置全部最佳实践的标准 Deploymentservice-template.yamlassets/service-template.yamlClusterIP / LoadBalancer / NodePort 等 7 种 Service 配置configmap-template.yamlassets/configmap-template.yaml不同类型数据的 ConfigMap 示例键值、文件、多文件、JSON、环境差异、脚本、Prometheus 配置secret-template.yaml按文档说明待生成、不提交Secret 示例pvc-template.yaml按文档说明提供PersistentVolumeClaim 模板使用时将模板中的app-name、namespace、image:tag等占位符替换为实际值即可切勿将含真实 Secret 的文件提交到 Git。五、参考文档导航references/deployment-spec.md——Deployment 详细规范副本与回滚、更新策略、镜像拉取策略、QoS 等级、三类探针及全部探针时序参数、Pod / 容器级安全上下文、卷类型、调度nodeSelector / affinity / tolerations、优雅终止与生产检查清单references/service-spec.md——Service 类型与网络细节四种类型、命名端口与多端口、会话亲和、内外流量策略、无头服务、DNS 与环境变量服务发现、负载均衡与服务网格集成、网络策略与排障命令。六、排障速查源自 SKILL.mdPod 无法启动kubectl describe pod pod-name # 查看镜像拉取错误等事件 kubectl get nodes # 确认节点资源充足 kubectl get events --sort-by.lastTimestamp # 查看集群事件Service 无法访问kubectl get endpoints service-name # 确认 selector 匹配到 Pod 标签 kubectl run debug --rm -it --imagebusybox -- sh # 从集群内部测试常见原因selector 与 Pod 标签不匹配、没有运行中的 Podendpoints 为空、端口配置错误、NetworkPolicy 阻断流量。ConfigMap / Secret 未加载核对 Deployment 中引用的名称是否一致检查 Namespace确认资源确实存在kubectl get configmap,secret。七、清单之后的下一步创建完清单只是起点。SKILL.md 给出的后续路线是将清单存入 Git 仓库做版本管理 → 搭建 CI/CD 流水线部署 → 使用 Helm 或 Kustomize 做模板化 → 用 ArgoCD 或 Flux 落地 GitOps → 补充监控与可观测性。这些环节可分别由同仓库的 helm-chart-scaffolding、gitops-workflow 与 k8s-security-policies 技能继续支撑。一句话总结这套方法论需求先行 → 资源递进Deployment → Service → ConfigMap → Secret → PVC→ 安全与标签收尾 → 统一组织 → dry-run 校验后再 apply配合仓库中 deployment-spec、service-spec 两份全字段参考与三份可直接落地的模板即可稳定产出符合生产标准的 Kubernetes 清单。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考