把一堆 values 变成 API
一句话总结
CRD不是添加新功能的装置。是将API服务器已经拥有的能力直接借用给我定义的类型的装置。
为什么需要这个？
想象一下分发内部服务的Helm图表吧。起初image，replicas原来是两个的values.yaml这一年后就四十岁了。然后这种事情会重复发生。
- 有人
replicas: "3"加上引号。模板照样渲染，发布成功，但没有出现问题。 - 有人
tier: prd犯了一个错误。没有被发现，安静地贴上了错误的标签。 - 出现了解释“我们图表的values模式”的维基文档，该文档总是比代码更旧。
- 如果想知道现在在群集中以什么值浮动的话
helm get values每个版本都要循环播放。不能一次性用标签选择。
问题的根源只有一个。**values.yaml从API服务器的角度来看，只是一个字符串块。**没有验证的主体，存储位置不在发布秘密中，所以很难查询，谁什么时候更改的记录也没有在感谢日志中以资源单位留下，也不能通过RBAC将只更改一个值的权限分配。
CRD将这个问题颠倒为“那么把它变成真正的API对象吧”。
怎么行动
应用一个CRD的话，API服务器会/apis/<그룹>/<버전>/namespaces/<ns>/<복수형>打开终点，从那一刻开始，下一个就会免费到来。
| 能力 | values.yaml | CR |
|---|---|---|
| 数据结构验证 | 无（只有在渲染后才发现） | 使用OpenAPI v3进行apply时拒绝 |
| 注入基本值 | 模板内default函数 |
结构defaultAPI服务器填充 |
| 不知道的字段 | 静静地忽略 | 通过pruning剪掉或明确保留 |
| 存储 | 释放秘密 | 作为对象在etcd中 |
| 查询 | helm get values |
kubectl get，标签选择器，定制栏 |
| 变更监控 | 无 | watch 流 |
| 权限分离 | 整个图表单位 | 资源·子资源单位 RBAC |
| 审计 | 管道日志 | API审计日志以对象为单位 |
这里再加一个。可以在结构中使用CEL规则。self.tier != 'prod' || self.replicas >= 2在没有Webhook服务器的情况下，在API服务器中检查相同字段之间的约束。以前必须发布验证Webhook的事情，现在已经成为模式的一行。
还有一定要记住。**CRD单单不能发生任何事情。**应用CR后，经过验证的数据只会很好地存储在etcd中，不会出现pad，也不会进行备份。只有加上观察并调整该类型的控制器，才算是一个操作员。
CRD = 새 어휘 (무엇을 원하는지 말하는 언어)
컨트롤러 = 그 어휘를 현실로 만드는 두뇌
오퍼레이터 = CRD + 컨트롤러
在现场相遇的样子
**第一，平台团队的自助服务。**制作内部开发者平台的团队大部分都倾向于使用CRD进行抽象化。开发者WebService写一张，平台将其翻译为Deployment·Service·Ingress·HPA·NetworkPolicy。开发者要学习的表面从40行values减少到5行CR。
**第二，Prometheus Operator的ServiceMonitor。**而不是让一个人编辑巨大的Prometheus设置文件，而是让每个团队创建一个小CR，宣布“去抓我的服务的指标”。多个团队编辑一个设置文件的冲突变成了资源单位所有权。
**第三，有明确的时候不应该使用。**如果符合以下任何一项，CRD都是过度的。
- 这是以Deployment和HPA结尾的无状态应用程序。只有抽象化层次增加，调试就变得困难。
- 安装一次后，之后几乎没有运营行为。那是Helm和GitOps的位置。
- 从长远来看，没有人来维护。CRD是代码，如果容器版本升级，就必须跟上。
- 已经有很好管理的官方操作员了，在自己制作之前，一定要先找找看。
**第四，CRD不是代码，而是API合同。**控制器代码可以随时重新部署，但已经堆积在etcd上的数千个CR和用户在Git上提交的配置文件不能随便更改。如果一个字段做错了，就会跟着从v1alpha1到v1走好几年路。所以API表面要从小开始，提前铺好进化的道路。
在下次确认中看到的东西
在接下来的测验中，CRD不是简单的YAML格式，而是具有长期兼容性的API合同。
确认需要设计的理由。检查了名称、范围、结构图、版本转换的判断标准。
在下一个模块中apps.labhub.io团体的WebService直接定义类型。