通义灵码可自动生成符合Kubernetes集群版本与业务需求的YAML清单，支持Pod/Deployment基础配置、亲和性、探针、滚动更新策略及项目专属规则约束，避免手写错误。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要快速生成符合当前集群版本和业务需求的Kubernetes资源清单，避免手写yaml时字段遗漏、缩进错误或apiVersion不匹配导致apply失败。
用通义灵码自动生成Pod基础配置
打开任意支持通义灵码的IDE（如VS Code或JetBrains），在新建的空白文件中输入注释：// 生成一个名为nginx-app的Pod，使用nginx:1.25镜像，暴露80端口，添加标签app=nginx。
光标置于注释行末尾，按下快捷键（默认Ctrl+Enter）触发通义灵码补全，它将直接输出完整yaml内容。
生成结果自动包含apiVersion: v1、kind: Pod、metadata.name、spec.containers列表等必需字段，且容器name与image严格对应你描述中的“nginx-app”和“nginx:1.25”。【若未指定namespace，生成的yaml默认不写namespace字段，将部署到default命名空间】
让通义灵码生成带亲和性与探针的Deployment
方法一：自然语言描述增强
在代码文件中写下：// 创建Deployment：名称为api-server，3副本，镜像registry.example.com/backend:v2.1，要求调度到有disktype=ssd标签的节点；添加livenessProbe检测/healthz路径，readinessProbe检测/readyz，两者都用HTTP GET，超时5秒。
通义灵码会识别“disktype=ssd”为nodeAffinity需求，并在spec.affinity.nodeAffinity下生成requiredDuringSchedulingIgnoredDuringExecution结构；同时自动配置livenessProbe和readinessProbe的httpGet、path、port、timeoutSeconds字段。
方法二：基于已有yaml续写
先粘贴一段基础Deployment yaml，把光标放在spec:下方空行处，输入# 添加反亲和性：不允许同个应用的Pod调度到同一节点，再触发补全。通义灵码会在spec下插入affinity.podAntiAffinity配置块，使用topologyKey: kubernetes.io/hostname和labelSelector匹配自身app标签。
结合kubectl explain精准生成字段
第一步：确认目标资源字段是否被支持
终端执行kubectl explain deployment.spec.strategy.rollingUpdate.maxSurge，查看该字段说明和类型（string或int）。
第二步：把explain输出的关键信息喂给通义灵码
在IDE中写注释：// Deployment滚动更新时，maxSurge设为25%，maxUnavailable设为1，触发生成。通义灵码会将maxSurge: "25%"写为字符串格式，而非整数25，【因为kubectl explain明确标注其类型为string，写成25会导致apply报错】。
第三步：校验生成结果
将通义灵码输出的yaml保存为deploy.yaml，运行kubectl apply --dry-run=client -f deploy.yaml -oyaml。如果输出无报错且结构完整，说明字段可用性已通过本地校验。
用项目专属规则约束生成风格
在项目根目录创建.lingma/rules/k8s-convention.md文件，写入以下内容：
所有Deployment必须设置revisionHistoryLimit: 5；容器端口名统一用http、https、metrics；环境变量优先使用configMapRef而非硬编码value。
保存后重启IDE或刷新通义灵码上下文。下次生成Deployment时，即使你没提“保留5个历史版本”，通义灵码也会自动加入revisionHistoryLimit: 5字段。
这个规则只对当前项目生效，不会影响其他工程。如果团队共用Git仓库，.lingma/rules目录会被一同提交，确保多人生成风格一致。
