<aside> 🧐 本节主要讲解 kuberntes API 接口模型
</aside>
Kubernetes 中最核心的就是 kube-apiserver 组件,其他组件都是和 kube-apiserver 进行通信的,本节主要就来研究下 Kubernetes API 接口的模型。
在 Kubernetes 集群中,Kubernetes 对象是我们持久化的实体,就是最终存入 etcd 中的数据,集群中通过这些实体来表示整个集群的状态。平时我们都是直接编写 YAML 资源清单文件,然后通过 kubectl 来提交创建对应的资源对象,那么它究竟是如何将我们的 YAML 文件转换成集群中的一个 API 对象的呢?
这个就需要去了解下**声明式 API
**的设计,为了可扩展性,Kubernetes 在不同的 API 路径(比如/api/v1
或者 /apis/batch
)下面支持了多个 API 版本,不同的 API 版本意味着不同级别的稳定性和支持:
v1alpha1
默认情况下是被禁用的,可以随时删除对功能的支持,所以要慎用v2beta1
默认情况下是启用的,表示代码已经经过了很好的测试,但是对象的语义可能会在随后的版本中以不兼容的方式更改v1
表示已经是稳定版本了,也会出现在后续的很多版本中。在 Kubernetes 集群中,一个 API 对象在 Etcd 里的完整资源路径,是由:Group(API 组)
、Version(API 版本)
和 Resource(API 资源类型)
三个部分组成的。通过这样的结构,整个 Kubernetes 里的所有 API 对象,实际上就可以用如下的树形结构表示出来:
从上图中我们也可以看出 Kubernetes 的 API 对象的组织方式,在顶层,我们可以看到有一个核心组(由于历史原因,是 /api/v1
下的所有内容而不是在 /apis/core/v1
下面)和命名组(路径 /apis/$NAME/$VERSION
)和系统范围内的实体,比如 /metrics
。我们也可以用下面的命令来查看集群中的 API 组织形式:
$ kubectl get --raw /
{
"paths": [
"/api",
"/api/v1",
"/apis",
"/apis/",
......
"/version"
]
}
比如我们来查看批处理这个操作,在我们当前这个版本中存在两个版本的操作:/apis/batch/v1
和 /apis/batch/v1beta1
,分别暴露了可以查询和操作的不同实体集合,同样我们还是可以通过 kubectl 来查询对应对象下面的数据:
$ kubectl get --raw /apis/batch/v1 | python -m json.tool
{
"apiVersion": "v1",
"groupVersion": "batch/v1",
"kind": "APIResourceList",
"resources": [
{
"categories": [
"all"
],
"kind": "Job",
"name": "jobs",
"namespaced": true,
"singularName": "",
"storageVersionHash": "mudhfqk/qZY=",
"verbs": [
"create",
"delete",
"deletecollection",
"get",
"list",
"patch",
"update",
"watch"
]
},
{
"kind": "Job",
"name": "jobs/status",
"namespaced": true,
"singularName": "",
"verbs": [
"get",
"patch",
"update"
]
}
]
}
但是这个操作和我们平时操作 HTTP 服务的方式不太一样,这里我们可以通过 kubectl proxy
命令来开启对 apiserver 的访问:
$ kubectl proxy
Starting to serve on 127.0.0.1:8001