Kubernetes创建不同名称同Kind的CRD报错原因排查

不可以在同一个Kubernetes API组下创建metadata名称不同但Kind完全相同的CRD，这就是你创建自定义资源报错的直接原因。

问题根因 #

Kubernetes API Server识别资源的核心依据是GVK三元组，即API组(Group) + 版本(Version) + 资源类型(Kind)，CRD的metadata名称、plural复数名不属于GVK匹配的判断维度：

• 你提交的两个CRD同属contoso.com API组，且都声明Kind为MyPlatform，本身就存在Kind注册冲突
• API Server遇到同组下重复的Kind声明时，只会保留最先完成注册的CRD的资源映射规则，也就是集群默认内置的v1beta1版本旧CRD。你后创建的crd2虽然能通过CRD资源校验被存入etcd，但它声明的v1版本MyPlatform资源映射根本不会被API Server的路由层加载，所以创建v1版本CR时会提示找不到对应资源映射。
• 你给crd2设置不同的metadata名、不同的plural复数名，完全绕不开同组下Kind重名的冲突，这两个字段不参与GVK匹配逻辑。

可行解决方法 #

你无权修改原有默认CRD的前提下，只能通过调整新CRD配置避开GVK冲突，二选一即可：

• 调整新CRD的API组：把crd2的spec.group改成其他无冲突的组名，比如v1.contoso.com，新CRD的GVK变为v1.contoso.com/v1/MyPlatform，和旧CRD完全不冲突，创建CR时把apiVersion改成对应新组名即可正常使用。
• 调整新CRD的Kind：保持contoso.com组不变，把crd2的spec.names.kind改成不重复的取值，比如MyPlatformV1，同步调整对应的plural、singular、shortNames字段匹配新Kind名，注册完成后就能正常创建对应资源。

注意：不要用kubectl get crd能查到两个CRD资源就判断配置没问题，只要存在同组同Kind冲突，后注册的CRD的版本映射永远不会生效。

内容的提问来源于stack exchange，提问作者ambikanair