Kubernetes 的能力都是通过各种 API 对象来提供,API 对象正是我们使用 Kubernetes 的接口,我们正是通过操作这些提供的 API 对象来使用 Kubernetes 能力的。最常见的就是 kubectl apply
命令。
对于我们使用 Kubernetes API 对象的方式,一般会编写对应 API 对象的 YAML 文件交给 Kubernetes(而不是使用一些命令来直接操作 API)。所谓“声明式”,指的就是只需要提交一个定义好的 API 对象来“声明”(这个 YAML 文件其实就是一种“声明”),表示所期望的最终状态是什么样子就可以了。而如果提交的是一个个命令,去指导怎么一步一步达到期望状态,这就是“命令式”了。
这意味着 kube-apiserver
在响应命令式请求(比如,kubectl replace
)的时候,一次只能处理一个写请求,否则会有产生冲突的可能。而对于声明式请求(比如,kubectl apply
),一次能处理多个写操作,并且具备 Merge 能力。
一个 API 对象在 Etcd 里的完整资源路径,是由:Group(API组)、Version(API版本)和 Resource(API资源类型)
三个部分组成的。
具体案例如下图:
可以看出,Kubernetes 里 API 对象的组织方式,其实是层层递进的。
借助之前的yaml文件,参考如下的一个结构:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: demo-statefulset
spec:
serviceName: "demo-service"
replicas: 3
selector:
matchLabels:
app: demo-nginx
template:
........
在这个 YAML 文件中,StatefulSet
就是这个 API 对象的资源类型(Resource),apps
就是它的组(Group),v1
就是它的版本(Version)。
对 Resource、Group 和 Version 进行检索,最终定位到API对象的流程如下:
/api
这个层级进行下一步的匹配过程。StatefulSet
等非核心 API 对象来说,Kubernetes 就必须在 /apis
这个层级里查找它对应的 Group,进而根据“apps”
这个 Group 的名字,找到 /apis/apps
。
这些 API Group
的分类是以对象功能为依据的,比如 Deployment
, StatefulSet
就都属于“apps” 这个 Group。具体可查看如下这张图:
匹配 Version
对于 StatefulSet
这个 API 对象来说,Kubernetes 在 apps
这个 Group 下,匹配到的版本号就是 v1
。在 Kubernetes 中,同一种 API 对象可以有多个版本,这正是 Kubernetes 进行 API 版本化管理的重要手段。这样,比如在 StatefulSet
的开发过程中,对于会影响到用户的变更就可以通过升级新版本来处理,从而保证了向后兼容。
/apis/apps/v1
下的 StatefulSet
对象。CRD 的全称是 Custom Resource Definition
。它指的就是,允许用户在 Kubernetes 中添加一个跟 Pod、Node 类似的、新的 API 资源类型,即:自定义 API 资源。
在 ListAndWatch 机制下,一旦 APIServer 端有新的实例被创建、删除或者更新,Reflector 都会收到“事件通知”。 ListAndWatch 方法的含义是:
综上,Kubernetes“声明式 API”的独特之处:
PATCH
的方式对 API 对象进行修改,而无需关心本地原始 YAML 文件的内容。所以“声明式 API“ 才是 Kubernetes 项目编排能力“赖以生存”的核心所在,PaaS平台与这完全没有可比性。
本文系转载,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文系转载,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。