1. Kubernetes 中的对象
Kubernetes 对象是系统中的持久实体,用于表示集群的状态。用户通过操作对象,与 Kubernetes 进行交互,告诉系统自己期望的工作负载情况。对象的操作是通过 Kubernetes API 来实现的。每个 Kubernetes 对象包含两个嵌套的对象字段,Spec 和 Status。Spec 描述了期望的对象状态,Status 描述了实际的对象状态。Kuernetes API 对 Spec 字段进行操作,系统会比较 Spec 与 Status 的差异,采取一定的措施,使得 Spec 与 Status 保持一致。这就是声明式 API,用户只需要告诉系统期望的状态,系统帮你达成状态。在 Kubernetes 中,API 是非常核心的部分。用户对集群的操作,都是通过调用 API 操作对象来实现的。
2. 什么是 Apiserver
apiserver 提供了对各类资源对象,如 Pod、Service、Deployment、CRD 等的增删改查,以及 Watch 的 API 接口,是整个集群的操作入口。下面是 apiserver 提供的具体功能:
- 集群管理的 RESTful API 接口
- 集群通信的枢纽,其他模块之间都通过 apiserver 进行交互,只有 apiserver 才能操作 etcd
- 集群安全管理机制
- 资源配额控制的入口
kube-apiserver 采用的是 HTTP 协议、 Json 数据格式的 API。如下图所示,URL 端点的格式主要由三部分构成:例如,/apis/batch/v1/namespaces/$NAMESPACE/job
。
- Group,逻辑上相关的 Kinds 的集合。
- Version,每个 Group 可以存在多个版本。例如,v1alpha1,然后升为 v1beta1,最后稳定为 v1 版本。
- Resource,HTTP 操作实体的表现形式,可以是单个资源,
../namespaces/default
,也可以是资源集合,../jobs
。
Group、Version、Resource(GVR)可以唯一确定一个 HTTP 资源端点。
3. Apiserver 工作原理
apiserver 提供了 Kubernetes 的 RESTful API,实现了认证、授权、准入控制等安全校验功能,同时也负责集群状态的存储操作。以 /apis/batch/v2alpha1/jobs
为例,GET 请求的处理过程如下图所示:
4. 使用 Kubernetes API
apiserver 同时提供了 https 和 http 协议的 API,其中 http API 是非安全接口,不做任何认证授权机制,不建议生产环境启用,仅允许本地访问。https 和 http 接口提供的 RESTful API 格式相同。kubectl 实际上就是一个 Kubernetes API 客户端。用户将对象信息配置在 yaml 文件中,kubectl 在发起 API 请求时,将这些信息转换成 Json 格式,然后调用 apiserver 的接口。除了直接使用 kubectl 进行操作,下面提供两种 Kubernetes API 的使用和调试方式:
4.1 本地 proxy
执行命令,并保持会话:
|
|
默认为 8001 端口,也可以通过参数指定服务端口,后台运行。如: kubectl proxy --port=8001 &
。proxy 作为反向代理与远程 minikube 连接,对本地提供服务。本地可以直接访问 http://127.0.0.1:8001 ,对集群进行操作。另启一个会话:
|
|
4.2 直接访问
由于 Kubernetes 集群已经对外开放了 https 访问入口,我们可以直接访问 apiserver 。这种方式与 kubectl 的访问方式一样,需要指定一些配置。主机、端口、证书等配置,可以通过 kubectl 命令查看:
|
|
使用 curl 进行访问
|
|
在项目中,可以使用封装好的客户端调用 Kubernetes API。在 https://github.com/kubernetes-client 上已经提供了很多语言的 Client,Go、Python、Javascript、Java、Perl 等。其他 OpenAPI 支持的语言,可以通过 gen 工具生成相应的 Client。
5. 参考
- https://feisky.gitbooks.io/kubernetes/components/apiserver.html
- https://blog.openshift.com/kubernetes-deep-dive-api-server-part-1/