k8s：kube-apiserver RESTful API 实现 - 存储

总结：同学们对提供外部接口用于查询和监控集群资源状态的服务有一个大概的了解，这些服务主要做一件事：添加接口调用我知道这是映射、删除、更改的方式。 查询对后端存储的访问。 在设计过程中，我们考虑到这是一个迭代速度很快的开源项目。 很多接口版本在未来的版本中可能会发生变化，那么如何设计扩展

入门

了解k8s的同学都知道kube-apiserver提供的是RESTful。 API接口，提供查询和监控集群（资源）状态服务。 kube-apiserver 主要做一件事。 它是一种映射 RESTful API（CREATE、DELETE、UPDATE、GET 等）接口调用以访问后端存储（添加、删除、修改、确认）的方法。 等）。 设计时考虑到k8s是一个快速迭代的开源项目，未来很多API接口（版本）可能会发生变化。 随着版本的变化，如何设计一个可扩展性强、耦合度低的架构从Google Groups诞生之初就应该是首要考虑的问题。 这就是为什么 kube-apiserver 最初是与 kube-scheduler 和 kube[. k4]Controller-manager应该有一个简单的代码设计，但它非常复杂（在我看来）〜

kube-apiserver接收RESTful API请求并直到检索数据（.etc更新） ）从后端存储它可能必须经过几个层（非正式命名），每个层都通过“接口”进行交互（隔离）。

RESTful API
||

||
存储
||

||
存储后端（etcd2、etcd3）

存储等和存储后端Kend通过存储后端接口进行交互（参见k8s：kube-apiserver访问etcd后端存储），存储和RESTful API通过REST操作接口（增删改查方法封装）进行交互。

存储

存储是 RESTful 存储服务的通用接口。
导出到 apiserver 的 RESTful API 的资源必须实现此接口（原注释，下同）
>对象应能够实现以下接口之一
所有想要通过 RESTful 公开的资源API必须实现Storage接口。 存储接口是一个最小接口（单一责任）。 资源类可以根据自身情况实现各种其他接口。

// kubernetes/staging/src/k8s.io/apiserver/pkg/registry/rest/rest.gotype 存储接口 { New() 运行时;   Object}

REST操作接口

StandardStorage是一个涵盖常见动词的接口。 用于测试资源是否满足正常存储实践。
使用。传递不透明存储对象时的存储
StandardStorage

type StandardStorage interface { Getter Lister GreaterUpdater GracefulDeleter CollectionDeleter Watcher}

StandardStorage是可以应用的操作（或动词、动作）总计的。 Storage ），RESTful API 根据该（子）接口测试Storage是否支持相关操作，并注册相应的API接口。 例如，如果您的存储支持删除接口，请使用相应的资源路径注册 DELETE HTTP 方法。

存储实现类

kubernetes/pkg/registry/core目录包含各种存储知名的pod、services、endpoints、configmaps、nodes、directory等实现类每个资源的结构。虽然它们非常相似，但我们以 pod 为例。

kubernetes/pkg/registry/core/pod rest storage storage.go <- Storage 实现 doc.go Strategy.go Strategy_test.go

PodStorage

以Pod存储为例分析存储创建。 第一个是 Pod 存储定义。

type PodStorage struct { Pod *REST Binding *BindingREST Eviction *EvictionREST Status *StatusREST Log *podrest.LogREST Proxy *podrest.ProxyREST Exec *podrest.ExecREST Attach *podrest.AttachREST PortForward *podrest.PortForwardREST}

这里出现了一些新的 REST 类型。 BindingREST .etc，这些 XXXREST 是对应于特定 RESTful 端点的“真实”存储。

// REST 为 podstype 实现 RESTStorage REST struct { *genericregistry.Store proxyTransport http.RoundTripper}// 实现 BindingREST 使用 etcd 时将 pod 绑定到节点 REST 端点 for type BindingREST struct {store *genericregistry.Store }

XXXREST 类包含 genericregistry.Store 类型的字段。 这里我们使用k8s：kube-。 apiserver访问etcd后端存储进行分析，用于访问后端存储。

PodStorage是通过NewStorage方法创建的，每个XXXREST共享一个Store。

func NewStorage (optsGetter generic.RESTOptionsGetter, ...) { genericregistry.Store 创建 store := &genericregistry.Store { ... } ... return PodStorage { Pod: &REST{Store, proxyTransport}, Binding: &BindingREST{Store: Store} ... }}

注册存储

存储是如何“绑定”到API接口的呢？这里面还涉及到一些数据结构（类）。 绑定相关代码如下：

// kubernetes/pkg/registry/core/rest/storage_core.gofunc (c LegacyRESTStorageProvider) NewLegacyRESTStorage( ...) { ...restStorageMap := map[string ]rest.Storage { "pods" : podStorage.Pod, "pods/attach": podStorage.Attach ... }}

后续详细分析

总结

在这篇文章中，介绍了 kube-apiserver 中与存储相关的一些概念。 希望阅读k8s源码对大家有用