原来地址: https://akomljen.com/kubernetes-api-resources-which-group-and-version-to-use/

Overview

Kubernetes 使用声明式 API 来使得系统更加的健壮。但是这也意味着如果我们要创建一个对象，我们可以通过 CLI 或者 REST 的方式告诉系统我们需要什么，然后系统就会帮我们创建这些对象了。但是在定义想要什么对象的时候，我们还需要定义 API 的 resource name，group 和 version。

不过这样用户也会感到困惑，原因是用户作为人类是不擅长于去记忆太多规范的。在一个 Deloyment 的定义中，你会看到 apiVersion 是 apps/v1beta2，但是其他的 apiVersion 却是 apps/v1，那么到底哪个才是正确的呢？我们可以用哪一个？如果检查我们的 K8S 集群是否支持这些 apiVersion？kubectl 给出了答案。

API Resources

我们可以通过命令 kubectl api-resources 来获取 K8S 支持的 resource 类型。

输出被我截断了，你仍然可以通过这个命令来获取所有的 resource，结果输出了很多有用的信息，我们来分析一下。

• SHORTNAMES - kubectl 可以使用的缩写，比如 namepace -> ns，当然不是每种 resource 都有缩写的
• APIGROUP - 在 yaml 文件中可以看到其使用 <APIGROUP>/v1
• KIND - resource 的 name，同样也是在 yaml 中常见的字段

你也可以通过输入一些 options 给 kubectl 来获取更多的信息。

另外我们还可以通过 explain 来获取更详细的信息。

需要注意的是 resource 可以有多个 apiVersion，explain 可能会输出旧的 group/version，但是你可以通过显示的添加 --api-version 来控制输出哪个版本的信息。

kubectl explain replicaset --api-version apps/v1

API Versions

我们可以通过下面这个命令，来获取集群支持ID所有的 API version。

有时候，你只是想检查一下某个 group/version 是否可用于某个 resource。可以通过下面这个命令来检查。deployments.v1.apps 分别对应 <API_RESOURCE_NAME>.<API_VERSION>.<API_GROUP>。

kubectl get deployments.v1.apps -n kube-system

当这个 resource 指定的 group/version 不存在的时候，就会报错。

Summary

这篇文章帮我们理解了场景的 yaml 文件里 kind 和 apiVersion 的含义，以及当你不确定集群是否支持对应资源的时候，我们该怎么通过 kubectcl 来探查。