Kubernetes API版本演进策略和API Group介绍

2020-08-16 0 By admin

一、Kubernetes API版本的演进策略

为了在兼容旧版本的同时不断升级新的API,Kubernetes提供了多版本API的支持能力,每个版本的API都通过一个版本号路径前缀进行区分,例如/api/v1beta3。

在通常情况下,新旧几个不同的API版本都能涵盖所有的Kubernetes资源对象,在不同的版本之间,这些API接口存在一些细微差别。

Kubernetes开发团队基于API级别选择版本而不是基于资源和域级别,是为了确保API能够清晰、连续地描述一个系统资源和行为的视图,能够控制访问的整个过程和控制实验性API的访问。

API的版本号通常用于描述API的成熟阶段,例如:

  1. v1表示GA稳定版本;
  2. v1beta3表示Beta版本(预发布版本);
  3. v1alpha1表示Alpha版本(实验性的版本)。

当某个API的实现达到一个新的GA稳定版本时(如v2),旧的GA 版本(如v1)和Beta版本(例如v2beta1)将逐渐被废弃,Kubernetes建议废弃的时间如下。

  1. 对于旧的GA版本(如v1),Kubernetes建议废弃的时间应不少于12个月或3个大版本Release的时间,选择最长的时间。
  2. 对旧的Beta版本(如v2beta1),Kubernetes建议废弃的时间应不少于9个月或3个大版本Release的时间,选择最长的时间。
  3. 对旧的Alpha版本,则无须等待,可以直接废弃。

完整的API更新和废弃策略请参考官方网站 https://kubernetes.io/docs/reference/usingapi/deprecation-policy/的说明。

二、API Groups(API组)

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

  1. Core Groups(核心组),也可以称之为Legacy Groups,作为 Kubernetes最核心的API,其特点是没有“组”的概念,例如“v1”,在资源对象的定义中表示为“apiVersion:v1”。
  2. 具有分组信息的API,以/apis/$GROUP_NAME/$VERSION URL路径进行标识,在资源对象的定义中表示为“apiVersion: $GROUP_NAME/$VERSION”,例如:“apiVersion: batch/v1”“apiVersion: extensions:v1beta1”“apiVersion: apps/v1beta1”等

详细的API列表请参见官网https://kubernetes.io/docs/reference,目前根据 Kubernetes的不同版本有不同的API说明页面。

例如,由于Pod属于核心资源对象,所以不存在某个扩展API Group,其属于Core Groups,在Pod的定义中为“apiVersion: v1”。
StatefulSet则属于名为apps的API组,版本号为v1,在StatefulSet的定义中为“apiVersion: apps/v1”。

2.1、启动或者禁用特定API组

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