Kubernetes API Groups (API 组) k8s rabc curl k8s api - 原文含k8s全套知识点-缺点版本较老

作者：半兽人
原文链接：https://www.orchome.com/1358
来源：OrcHome
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

为了更容易对API进行扩展，Kubernetes 使用API Groups (API组)进行标识。APIGroups 以及REST URL中的路径进行定义。当前支持两类API groups。

Core Groups (核心组)，也可以称为Legacy Groups，该组的REST路径位于/api/v1, 作为 Kubernetes 最核心的 API，它是没有“组”的概念，例如 ”vl“，在资源对象的定义中表示为”apiVersion: v1“。

具有分组信息的API，以/apis/$GROUP_NAME/$VERSIONURL路径进行标识，在资源对象的定义中表示为apiVersion: $GROUP_NAME/$VERSION（例如，apiVersion: batch/v1）。已支持的 API 组详细列表请参阅 Kubernetes API reference。

例如 Pod 的 API 说明如图所示，由于 Pod 属于核心资源对象，所以不存在某个扩展 API Group，页面显示为“Core" 在Pod的定义中为“apiVersion:v1”。

如果要启用或禁用特定的 API 组，则需要在 API Server 的启动参数中设置–runtime-config进行声明，例如–runtime-config=batch/v2alphal表示启用API组的 “batch/v2alpha1”，也可以设置–runtime-config=batch/v1=false表示禁用API组“batch/v1”。多个 API组的设置以逗号分隔。在当前的API Server服务中，DaemonSets、Deployments、HorizontalPodAutoscalers、Ingress、Jobs和ReplicaSets所属的 API 组是默认启用的。

在未来的演进中， Kubernetes 将支持用户自定义资源对象和对它们的基本CRUD操作。 伴随着自定义资源对象，Kubernetes 的未来版本还将支持用户自定义API Server，与 Kubernetes Master的 API Server共同工作，完成更复杂的资源对象管理工作。