本文讲述了使用controller-gen生成CRD在生产环境中的经验教训，翻译自 https://ahmet.im/blog/crd-generation-pitfalls/，

此文为个人翻译，仅供参考，不代表我个人立场。翻译过程中可能有删改或遗漏，如需了解原文，请自行查阅。如有疏漏，欢迎指正。

在sourcegraph中的 代码搜索查询 显示，在开源代码库中至少有 7000 个 Kubernetes 自定义资源定义，其中大多数可能是使用 controller-gen 生成的——这是一种将带有 注释标记 的 Go 结构转换为 Kubernetes CRD 清单的工具，最终成为 Kubernetes API Server提供的自定义 API。

在 LinkedIn，我们开发了许多自定义 Kubernetes API 和控制器，以运行工作负载或管理基础设施。在此过程中，我们高度依赖自定义资源机制和 controller-gen 来生成我们的 CRD。

决定独立生存之后已经一个半月了，成为up主第43天。原有技能、数字游民和up主方向都没有明显的起色，无论如何，每个阶段总是要总结一下。

最近，Cursor 引发广泛关注，一名年仅 8 岁的女孩在短短 45 分钟内开发出一个聊天机器人，这一事件再次引发了对生成式 AI 潜力的热议。与此同时，Kelsey Hightower 在《The New Stack》的采访中，还有在 9 月 11 日与云服务公司 Civo 联合创始人兼首席执行官 Mark Boost 的 “炉边谈话” 里，深入探讨了生成式 AI 如何重塑开发者的未来。

之前文章讲了containerd的镜像存储原理，镜像在containerd中保存了两份，一份是镜像的原始文件（manifest、config、blob），另一部分是layer解压后的快照。而运行容器只使用了解压后layer快照，对于不需要进行镜像推送场景，原始镜像blob部分存在空间的浪费。在较小磁盘空间下，容易出现镜像占用过多磁盘的情况，那么如何节约空间呢？

当我们执行 nerdctl pull、crictl pull 或 nerdctl load 时，镜像是如何保存到系统中的呢？本文将介绍 containerd 如何储存镜像，帮助大家理解镜像在containerd中的存储机制。

决定开启独立生存模式后“路在脚下-不打工独立生存”，我先尝试了钓鱼记录类的视频，发现我不太适合钓鱼这个方向，算是交了个学费。下一阶段我准备回上海，在那边待一段时间，根据独立生存情况，决定是否离开上海。