Kubernetes清单生成器Skill k8s-manifest-generator

这个技能用于生成生产就绪的Kubernetes清单,包括Deployment、Service、ConfigMap、Secret和PersistentVolumeClaim,遵循最佳实践和安全标准,支持DevOps和云原生应用部署。关键词:Kubernetes、清单生成、DevOps、云原生、安全配置、容器编排、YAML模板、配置管理。

Docker/K8s 0 次安装 0 次浏览 更新于 3/16/2026

name: k8s-manifest-generator description: 为Deployment、Service、ConfigMap和Secret创建生产就绪的Kubernetes清单,遵循最佳实践和安全标准。在生成Kubernetes YAML清单、创建K8s资源或实施生产级Kubernetes配置时使用。

Kubernetes清单生成器

逐步指导创建生产就绪的Kubernetes清单,包括Deployment、Service、ConfigMap、Secret和PersistentVolumeClaim。

目的

本技能提供全面指导,用于生成结构良好、安全且生产就绪的Kubernetes清单,遵循云原生最佳实践和Kubernetes惯例。

何时使用此技能

当您需要时使用此技能:

  • 创建新的Kubernetes Deployment清单
  • 定义Service资源以实现网络连接
  • 生成ConfigMap和Secret资源进行配置管理
  • 创建PersistentVolumeClaim清单以支持有状态工作负载
  • 遵循Kubernetes最佳实践和命名约定
  • 实施资源限制、健康检查和安全上下文
  • 设计多环境部署的清单

逐步工作流程

1. 收集需求

了解工作负载:

  • 应用程序类型(无状态/有状态)
  • 容器镜像和版本
  • 环境变量和配置需求
  • 存储需求
  • 网络暴露需求(内部/外部)
  • 资源需求(CPU、内存)
  • 伸缩需求
  • 健康检查端点

需要询问的问题:

  • 应用程序名称和目的是什么?
  • 使用什么容器镜像和标签?
  • 应用程序是否需要持久存储?
  • 应用程序暴露哪些端口?
  • 是否需要任何密钥或配置文件?
  • CPU和内存需求是什么?
  • 应用程序是否需要外部暴露?

2. 创建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

应用的最佳实践:

  • 始终设置资源请求和限制
  • 实现存活和就绪探针
  • 使用特定镜像标签(绝不使用 :latest
  • 为非根用户应用安全上下文
  • 使用标签进行组织和选择
  • 根据可用性需求设置适当的副本数量

参考: 参见 references/deployment-spec.md 获取详细部署选项

3. 创建Service清单

选择适当的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: TCP

LoadBalancer(外部访问):

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

参考: 参见 references/service-spec.md 获取服务类型和网络详细信息

4. 创建ConfigMap

用于应用程序配置:

apiVersion: v1
kind: ConfigMap
metadata:
  name: <app-name>-config
  namespace: <namespace>
data:
  APP_MODE: production
  LOG_LEVEL: info
  DATABASE_HOST: db.example.com
  # 用于配置文件
  app.properties: |
    server.port=8080
    server.host=0.0.0.0
    logging.level=INFO

最佳实践:

  • 仅将ConfigMap用于非敏感数据
  • 组织相关配置在一起
  • 为键使用有意义的名称
  • 考虑每个组件使用一个ConfigMap
  • 在更改时对ConfigMap进行版本控制

参考: 参见 assets/configmap-template.yaml 获取示例

5. 创建Secret

用于敏感数据:

apiVersion: v1
kind: Secret
metadata:
  name: <app-name>-secret
  namespace: <namespace>
type: Opaque
stringData:
  DATABASE_PASSWORD: "changeme"
  API_KEY: "secret-api-key"
  # 用于证书文件
  tls.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  tls.key: |
    -----BEGIN PRIVATE KEY-----
    ...
    -----END PRIVATE KEY-----

安全考虑:

  • 绝不将密钥以明文提交到Git
  • 使用Sealed Secrets、External Secrets Operator或Vault
  • 定期轮换密钥
  • 使用RBAC限制密钥访问
  • 考虑使用Secret类型: kubernetes.io/tls 用于TLS密钥

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:

spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        fsGroup: 1000
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: app
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          capabilities:
            drop:
            - ALL

安全检查清单:

  • [ ] 作为非根用户运行
  • [ ] 丢弃所有能力
  • [ ] 使用只读根文件系统
  • [ ] 禁用权限提升
  • [ ] 设置seccomp配置文件
  • [ ] 使用Pod安全标准

8. 添加标签和注解

标准标签(推荐):

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: "应用程序描述"
    contact: "team@example.com"
    prometheus.io/scrape: "true"
    prometheus.io/port: "9090"
    prometheus.io/path: "/metrics"

9. 组织多资源清单

文件组织选项:

选项1:使用 --- 分隔符的单个文件

# app-name.yaml
---
apiVersion: v1
kind: ConfigMap
...
---
apiVersion: v1
kind: Secret
...
---
apiVersion: apps/v1
kind: Deployment
...
---
apiVersion: v1
kind: Service
...

选项2:单独文件

manifests/
├── configmap.yaml
├── secret.yaml
├── deployment.yaml
├── service.yaml
└── pvc.yaml

选项3:Kustomize结构

base/
├── kustomization.yaml
├── deployment.yaml
├── service.yaml
└── configmap.yaml
overlays/
├── dev/
│   └── kustomization.yaml
└── prod/
    └── kustomization.yaml

10. 验证和测试

验证步骤:

# 客户端干运行验证
kubectl apply -f manifest.yaml --dry-run=client

# 服务器端验证
kubectl apply -f manifest.yaml --dry-run=server

# 使用kubeval验证
kubeval manifest.yaml

# 使用kube-score验证
kube-score score manifest.yaml

# 使用kube-linter检查
kube-linter lint manifest.yaml

测试清单:

  • [ ] 清单通过干运行验证
  • [ ] 所有必填字段存在
  • [ ] 资源限制合理
  • [ ] 健康检查已配置
  • [ ] 安全上下文已设置
  • [ ] 标签遵循约定
  • [ ] 命名空间存在或已创建

常见模式

模式1:简单无状态Web应用程序

用例: 标准Web API或微服务

所需组件:

  • Deployment(3个副本用于高可用性)
  • ClusterIP Service
  • ConfigMap用于配置
  • Secret用于API密钥
  • HorizontalPodAutoscaler(可选)

参考: 参见 assets/deployment-template.yaml

模式2:有状态数据库应用程序

用例: 数据库或持久存储应用程序

所需组件:

  • StatefulSet(非Deployment)
  • Headless Service
  • PersistentVolumeClaim模板
  • ConfigMap用于数据库配置
  • Secret用于凭证

模式3:后台任务或Cron

用例: 计划任务或批处理

所需组件:

  • CronJob或Job
  • ConfigMap用于作业参数
  • Secret用于凭证
  • ServiceAccount和RBAC

模式4:多容器Pod

用例: 带边车容器的应用程序

所需组件:

  • Deployment带多个容器
  • 容器间共享卷
  • Init容器用于设置
  • Service(如果需要)

模板

assets/ 目录中提供以下模板:

  • deployment-template.yaml - 带最佳实践的标准部署
  • service-template.yaml - Service配置(ClusterIP、LoadBalancer、NodePort)
  • configmap-template.yaml - 不同类型数据的ConfigMap示例
  • secret-template.yaml - Secret示例(应生成,不提交)
  • pvc-template.yaml - PersistentVolumeClaim模板

参考文档

  • references/deployment-spec.md - 详细部署规范
  • references/service-spec.md - 服务类型和网络详细信息

最佳实践总结

  1. 始终设置资源请求和限制 - 防止资源饥饿
  2. 实现健康检查 - 确保Kubernetes能管理您的应用程序
  3. 使用特定镜像标签 - 避免不可预测的部署
  4. 应用安全上下文 - 作为非根用户运行,丢弃能力
  5. 使用ConfigMap和Secret - 将配置与代码分离
  6. 标签化一切 - 启用过滤和组织
  7. 遵循命名约定 - 使用标准Kubernetes标签
  8. 应用前验证 - 使用干运行和验证工具
  9. 版本化您的清单 - 在Git中进行版本控制
  10. 用注解记录 - 为其他开发人员添加上下文

故障排除

Pod未启动:

  • 检查镜像拉取错误: kubectl describe pod <pod-name>
  • 验证资源可用性: kubectl get nodes
  • 检查事件: kubectl get events --sort-by='.lastTimestamp'

Service不可访问:

  • 验证选择器匹配Pod标签: kubectl get endpoints <service-name>
  • 检查服务类型和端口配置
  • 在集群内测试: kubectl run debug --rm -it --image=busybox -- sh

ConfigMap/Secret未加载:

  • 验证名称在Deployment中匹配
  • 检查命名空间
  • 确保资源存在: 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 - 用于高级安全配置