Kubernetes-API-Resources和Versions

概述

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

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

API Resources

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

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

1. SHORTNAMES: kubectl可以使用的缩写，比如Namespace->ns，当然不是每种resource都有缩写的
2. APIGROUP: 在yaml文件中可以看到其使用<APIGROUP>/v1
3. NAMESPACED: 资源的可见范围是否跟Namespace有关
4. KIND: resource的name，同样也是在yaml中常见的字段

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

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

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

1

kubectl explain replicaset --api-version apps/v1

API Versions

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

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

1

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

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

总结

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

参考资料

1. Kubernetes API Resources: Which Group and Version to Use?

💡赞赏支持

微信打赏 支付宝打赏