kubernetes-operator
作者 alirezarezvani使用 kubernetes-operator 设计和审查 Kubernetes Operators、CRDs 与 reconcile loops。该技能包含 CRD 设计参考、controller-runtime reconcile skeleton、生产级 CRD template，以及用于 CRD validation、reconcile linting 和 OperatorHub 风格 capability checks 的 Python audits。
该技能评分为 84/100。对于希望专注构建或审查 Kubernetes Operators 的目录用户来说，它是一个值得收录的候选项。它提供了足够的触发指引、可复用模板、面向领域的检查项和解释性参考，相比通用 Kubernetes prompt 能减少不少摸索成本。不过，如果安装说明和快速上手步骤更清晰，采用门槛会更低。
- 触发意图清晰：frontmatter 明确覆盖构建 Operator 的需求，并包含 CRD design、reconcile loop、controller-runtime、kubebuilder、operator-sdk、KOPF、custom resource 等关键词。
- 实操价值高：随附生产级 CRD template、Go reconcile skeleton，以及用于 CRD validation、reconcile-loop linting 和 capability auditing 的脚本。
- 参考资料层次清楚：四份参考分别覆盖何时需要构建 Operator、CRD 设计、reconcile-loop 结构，以及 framework/tooling 选型。
- 技能目录中未提供安装命令或 README，因此用户可能需要参考整个 repository 的通用安装约定。
- 内置的 validators/linter 标注为仅依赖 stdlib，适合做最佳实践检查；但从摘录看，它们属于启发式检查，并不是完整的 Kubernetes/API 校验。
kubernetes-operator skill 概览
kubernetes-operator skill 适合帮你构建什么
kubernetes-operator skill 用于设计、生成和评审 Kubernetes Operators：也就是将 Custom Resource 的期望状态协调为真实集群资源的自定义控制器。它不是通用的 Kubernetes 辅助工具。它最擅长在问题演变成集群故障之前，提前发现 Operator 特有的设计风险：薄弱的 CRD schema、缺失的 status conditions、finalizer 使用错误、非幂等的 reconcile 逻辑、不合理的 requeue 处理，以及 RBAC 或能力缺口。
最适合的用户与 Cloud Architecture 工作场景
这个 skill 适合平台工程师、SRE、DevOps 团队，以及在 Kubernetes 上构建内部平台的 Cloud Architecture 团队。当你要把运维 runbook 抽象成 Kubernetes API、比较 kubebuilder、operator-sdk、controller-runtime、KOPF 或 metacontroller，或者审查某个 Operator 是否已经具备内部生产使用或接近 OperatorHub 风格预期的成熟度时，可以使用它。
它和普通 prompt 有什么不同
普通 prompt 可以解释 Operator 模式，但这个 skill 会给助手提供更具体的 Operator 设计护栏：CRD 设计参考、reconcile loop 骨架、生产级 CRD 模板，以及用于校验的 stdlib Python 脚本。因此，它更适合做确定性评审任务，例如“这个 CRD 是否正确暴露了 status？”或“这个 reconcile loop 是否安全处理了删除和瞬时错误？”
什么时候不该选这个 skill
如果你只需要 Helm chart、Deployment、CronJob 或一次性迁移 Job，就不要安装 kubernetes-operator。如果工作并不直接关联 Custom Resource 和控制器，它也不是排查广义 Kubernetes 问题、集群网络、storage class 或通用 YAML 清理的首选入口。
如何使用 kubernetes-operator skill
kubernetes-operator 的安装方式与优先查看的文件
在兼容的 agent 环境中安装这个 skill：
npx skills add alirezarezvani/claude-skills --skill kubernetes-operator
安装后，先阅读 SKILL.md，了解触发条件和工作流。然后查看：
references/operator_pattern.md：用于判断是否真的需要构建 Operatorreferences/crd_design.md：在设计 API 表面之前阅读references/reconcile_loop.md：在实现控制器逻辑之前阅读references/tooling_landscape.md：在选择框架之前阅读assets/crd_template.yaml和assets/reconcile_skeleton.go：作为起步结构scripts/crd_validator.py、scripts/reconcile_lint.py和scripts/operator_capability_audit.py：用于评审检查
哪些输入能让 kubernetes-operator 使用效果更好
不要只说“build an operator”。更有效的输入应包含被管理的应用、生命周期操作、故障模式、期望的 CR 字段、status 字段、namespace 模型、云依赖，以及选定的框架。
较弱的 prompt：
Build a Kubernetes operator for PostgreSQL.
更强的 prompt：
Use the kubernetes-operator skill to design a
DatabaseClusterCRD for a namespaced PostgreSQL operator. It must support version upgrades, replica count, backup schedule, restore source, storage size, and maintenance window. We are usingkubebuilderandcontroller-runtime. Include status conditions, printer columns, finalizer behavior, reconcile phases, RBAC notes, and risks that would make this better as Helm instead of an operator.
更强的版本会告诉 skill：哪些运维知识必须被编码进去、哪些框架约束很重要，以及需要检查哪些取舍。
设计新 Operator 的实用工作流
先做适配性检查：确认这个应用确实需要 Helm 之外的生命周期自动化。接着，先设计 CRD，再写控制器代码；一旦用户开始使用，糟糕的 API 形态会变得很难修改。以 assets/crd_template.yaml 作为基线，并有意识地调整字段，尤其是 spec、status.conditions、subresources.status、版本策略和 printer columns。
然后基于 assets/reconcile_skeleton.go 起草 reconcile loop。让助手把每个 CR 字段映射到幂等动作、status 更新、requeue 行为和 finalizer 清理。适用时运行或对照内置脚本检查，再根据发现的问题迭代，而不是把生成的代码当作最终结果。
如何有效使用审计脚本
这些脚本是轻量级检查，不是集群测试的替代品。crd_validator.py 会查找结构化 CRD 设计问题，例如缺失 status subresource、缺失 conditions、版本策略薄弱，以及命名不完整。reconcile_lint.py 适合评审 controller-runtime 风格代码中的常见 reconcile 错误。operator_capability_audit.py 帮助判断成熟度缺口，例如安装、升级、可观测性、备份、恢复和生命周期行为。
把脚本输出当作待办清单：让 skill 解释每条发现、划分严重程度，并提出在保持 API 兼容性的前提下最小化修复方案。
kubernetes-operator skill 常见问题
kubernetes-operator 适合初学者吗？
适合，前提是你已经理解基本的 Kubernetes 对象，并希望按 Operator 专属路径获得指导。它不会从零讲完整的 Kubernetes 基础，但会通过聚焦 CRD 形态、reconcile 流程、status、finalizers 和框架选择，让 Operator 模式更具体、更可落地。
这和直接询问 kubebuilder 帮助有什么不同？
kubebuilder 用来脚手架化一个 Go Operator 项目。kubernetes-operator skill 帮你判断这个 Operator 应该做什么、是否应该存在、CRD 应该长什么样，以及 reconcile 逻辑是否符合安全的控制器模式。实践中两者可以一起用：用 kubebuilder 搭项目结构，用这个 skill 做设计与评审把关。
我能用它做 Python、Java 或非 Go Operator 吗？
可以，用于架构、CRD 设计、生命周期建模和框架比较都适用。内置的 Go reconcile 骨架最直接对应 controller-runtime，但 reconcile 原则同样适用于 KOPF、Java Operator SDK，以及基于 webhook 的方案，例如 metacontroller。
什么时候应该避免使用这个 skill？
当你的目标只是普通 manifest 生成、集群调试、service mesh 搭建，或不需要 Custom Resource 和控制器的应用部署时，应避免使用它。对许多无状态应用来说，带有良好默认值的 Helm chart 比 Operator 更简单、成本更低，也更容易运维。
如何改进 kubernetes-operator skill
用更充分的上下文提升 kubernetes-operator 结果
这个 skill 在你提供架构约束，而不只是代码时效果最好。请包含 Kubernetes 版本假设、目标发行版（例如 vanilla Kubernetes 或 OpenShift）、namespace scope 还是 cluster scope、多租户需求、云厂商依赖、必需的生命周期操作，以及用户在 kubectl get 中应该看到什么。这能帮助助手设计出贴合真实运维场景的 API 和 status 字段。
建议让 kubernetes-operator skill 检查的常见失败模式
请明确要求它检查 Operator 专属评审点：
- Reconcile loop 是否幂等？
- 瞬时错误是否会被返回，从而让请求重新入队？
- Finalizers 是否被安全地添加和移除？
status是否与spec分开更新？- Conditions 是否使用了
observedGeneration？ - CRD 是否具备 structural schema、status subresource 和 printer columns？
- RBAC 是否比 “cluster-admin” 更收敛？
这些检查能让 kubernetes-operator usage 比宽泛的架构 prompt 更具体。
从设计到实现再到审计，分轮迭代
一个好的工作流通常分三轮。第一轮，请求 API 和生命周期设计。第二轮，请求 reconcile 伪代码或特定框架的实现指导。第三轮，使用仓库脚本和参考资料作为标准，对 CRD、控制器或设计进行审计式 prompt 检查。每一轮都应保持聚焦；把 CRD 设计、RBAC、生成代码和生产就绪度混在一个 prompt 里，往往会得到比较浅的输出。
按你的平台标准定制这个 skill
要让 kubernetes-operator skill 更适合 Cloud Architecture 团队，可以加入组织内部约定：已批准的 API groups、命名规则、condition types、备份要求、可观测性标准、安全边界，以及支持的框架。如果你已经有标准化的 golden operators，可以让助手把新设计与它们对比，这样 skill 输出的就会是符合平台一致性的建议，而不是泛泛的 Operator 建议。