创意电子

标题: kubernetes 源码分析(kube-apiserver 处理流程) [打印本页]

作者: 坑害小朋友的少年    时间: 2021-8-20 23:43
标题: kubernetes 源码分析(kube-apiserver 处理流程)
kube-apiserver简介

kube-apiserver 是 kubernetes 中与 etcd 直接交互的一个组件,其控制着 kubernetes 中焦点资源的变革。它主要提供了以下几个功能:

kube-apiserver 处理流程

kube-apiserver 主要通过对外提供 API 的方式与其他组件举行交互,可以调用 kube-apiserver 的接口 $ curl -k https://:6443大概通过其提供的 swagger-ui 获取到,其主要有以下三种 API:
API 的 URL 大致以 /apis/group/version/namespaces/my-ns/myresource 组成,其中 API 的结构大致如下图所示:


                               
登录/注册后可看大图

相识了 kube-apiserver 的 API 后,下面会介绍 kube-apiserver 如何处理一个 API 请求,一个请求完整的流程如下图所示:


                               
登录/注册后可看大图

此处以一次 POST 请求示例说明,当请求到达 kube-apiserver 时,kube-apiserver 首先会执行在 http filter chain 中注册的过滤器链,该过滤器对其执行一系列过滤操作,主要有认证、鉴权等检查操作。当 filter chain 处理完成后,请求会通过 route 进入到对应的 handler 中,handler 中的操作主要是与 etcd 的交互,在 handler 中的主要的操作如下所示:

                               
登录/注册后可看大图

Decoder
kubernetes 中的多数 resource 都会有一个 internal version,因为在整个开辟过程中一个 resource 可能会对应多个 version,比如 deployment 会有 extensions/v1beta1apps/v1。 为了避免出现问题,kube-apiserver 必须要知道如安在每一对版本之间举行转换(例如,v1v1alpha1,v1v1beta1,v1beta1v1alpha1),因此其使用了一个特殊的internal versioninternal version 作为一个通用的 version 会包罗所有 version 的字段,它具有所有 version 的功能。 Decoder 会首先把 creater object 转换到 internal version,然后将其转换为 storage versionstorage version 是在 etcd 中存储时的另一个 version。

在解码时,首先从 HTTP path 中获取期待的 version,然后使用 scheme 以正确的 version 创建一个与之匹配的空对象,并使用 JSON 或 protobuf 解码器举行转换,在转换的第一步中,如果用户省略了某些字段,Decoder 会把其设置为默认值。

Admission

在解码完成后,须要通过验证集群的全局束缚来检查是否可以创建或更新对象,并根据集群配置设置默认值。在 k8s.io/kubernetes/plugin/pkg/admission 目次下可以看到 kube-apiserver 可以使用的所有全局束缚插件,kube-apiserver 在启动时通过设置 --enable-admission-plugins 参数来开启须要使用的插件,通过 ValidatingAdmissionWebhookMutatingAdmissionWebhook 添加的插件也都会在此处举行工作。

Validation

主要检查 object 中字段的合法性。

在 handler 中执行完以上操作后最后会执行与 etcd 相关的操作,POST 操作会将数据写入到 etcd 中,以上在 handler 中的主要处理流程如下所示:
v1beta1  internal  |  |  v1  json/yaml  etcd
admission validation





欢迎光临 创意电子 (https://wxcydz.cc/) Powered by Discuz! X3.4