云原生平台运维脚本编写实战版提示词

角色定义与任务定位

请以一名资深云原生平台运维工程师的身份，运用你的系统架构知识、自动化思维和对Kubernetes、Docker、Service Mesh等核心技术的深刻理解，进行内容生成。你的核心目标是：针对给定的具体运维场景，构思并输出可直接运行或稍作修改即可投入使用的、符合最佳实践的脚本代码（如Shell、Python或基于特定CLI工具的脚本），并附上清晰的逻辑注释与关键参数说明，确保脚本的实用性、健壮性和可维护性。

适用场景

• 为Kubernetes集群设计自动化部署与滚动更新脚本。
• 编写用于监控Pod状态、节点资源使用率并触发告警的巡检脚本。
• 构建一键式日志收集、故障诊断与信息汇总的排查工具链脚本。
• 实现跨命名空间或跨集群的资源同步与备份恢复流程脚本。
• 创建用于管理Istio等Service Mesh配置的自动化校验与发布脚本。

核心提示词

以下提示词组合可直接用于生成具体脚本。请将【】内的内容替换为您的实际参数。

• 编写一个Python脚本，使用Kubernetes Python客户端，自动清理【命名空间】中所有状态为Evicted的Pod，并记录清理日志到文件。
• 创建一个Shell脚本，用于监控集群所有节点的CPU和内存使用率，当任一指标超过【阈值百分比】时，通过curl调用Webhook发送告警信息，信息需包含节点名和具体数值。
• 设计一个完整的Bash脚本流程，实现：1. 备份指定【Deployment】的当前配置；2. 使用最新镜像标签更新该Deployment；3. 循环检查滚动更新状态直至完成或超时；4. 若更新失败，自动回滚到备份配置。
• 生成一个使用kubectl和jq工具的脚本，一键获取所有命名空间下Pod的重启次数排名，输出格式为表格，并高亮显示重启次数大于【N】的Pod。

风格方向

• 工程化风格：脚本结构清晰，包含函数定义、错误处理（set -euo pipefail）、日志输出和退出码管理。
• 文档化风格：在脚本开头提供详细的用途、参数、环境依赖说明，关键步骤附有行内注释。
• 防御式风格：包含参数校验、前置条件检查（如工具是否存在、集群连通性）、资源存在性判断。
• 模块化风格：将通用功能（如日志函数、发送告警函数）抽象，便于复用和脚本维护。

构图建议

此处的“构图”指脚本的逻辑结构与信息组织方式。

• 总-分-总结构：脚本开头概述功能，中间主体分步骤实现，结尾进行状态汇总或清理。
• 管道与过滤器构图：串联多个命令行工具（如kubectl, grep, awk, jq），通过管道传递和处理数据流。
• 并行处理构图：对于可独立执行的任务，使用后台进程或xargs -P参数实现并发，提升效率。
• 配置与执行分离：将可配置变量（如阈值、命名空间、URL）集中在脚本头部，使核心逻辑更清晰。

细节强化

• 安全细节：避免在脚本中硬编码敏感信息；使用Secret或环境变量；对输入进行转义防止注入攻击。
• 可观测性细节：在关键决策点输出INFO/WARN/ERROR级别日志；记录脚本开始与结束时间；支持--dry-run试运行模式。
• 兼容性细节：注明所需的kubectl版本、CLI工具版本或Python库版本；考虑不同Linux发行版的命令差异。
• 资源管理细节：在循环中增加sleep避免频繁请求API Server；脚本结束时清理临时文件；考虑资源操作的幂等性。

使用建议

• 在使用核心提示词生成脚本后，务必在测试环境中充分验证，尤其是涉及删除、更新等写操作的功能。
• 将生成的脚本纳入版本控制系统（如Git），并通过CI/CD流水线进行代码扫描和基础测试。
• 复杂脚本建议配套生成一份简明的README，说明使用前提、执行示例和常见问题排查步骤。
• 根据实际平台差异（如EKS, AKS, GKE或自建K8s），可能需要调整认证方式或特定API调用。