问题描述
我正在尝试为我的应用程序找到一个DB(对象存储).该应用程序实际上是ISTIO网络路由API的包装.基本上简化了我的网络的ISTIO配置. Kubernetes(k8s)定制资源定义(CRD)似乎符合我的要求.也喜欢CRD提供的watch和REST API功能.
I am trying to find a DB (object storage) for my application. The application is really a wrapper over ISTIO Network Routing API. Basically simplifying the ISTIO configuratin for my network. Kubernetes (k8s) Custom Resource Definition (CRD) seems to fit my requirements. Also love the watch and REST API capability provided by CRD.
数据库要求
- 几乎没有100 MB的数据-最坏的情况
- 观看对象的能力
- 对象的REST API支持
- 持久性
- 每秒约2k次写入和每秒类似/更多读取.尽管我确实将我的应用程序用作CRD的代理，可以在其中缓存内容.
为什么使用CRD是个好主意还是一个坏主意?使用CRD是否有任何性能暗示. 此2016年Stackflow答案表明etcd数据不在RAM中.而etcd链接建议etcd可以 10k次写入/秒(因此，即使事情不在RAM中)并完全在磁盘上(谁在乎).
Why using CRD will be a good or a bad idea? Are there any performance implication using CRD. This 2016 stackflow answer suggest that etcd data is not in RAM. Whereas etcd link suggest that etcd can do 10k writes/sec (so even things are not in RAM and purely in disk, who cares).
我看到使用k8s CRD的多个应用程序.
I am seeing multiple application using k8s CRDs.
- Helm使用CRD存储版本
- Istio使用CRD存储其网络路由API对象
推荐答案
考虑到这一点( CRD页面)
-
资源是 Kubernetes API 中的端点，该端点存储某种类型的API对象的集合.例如，内置的pods资源包含Pod对象的集合.
A resource is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind. For example, the built-in pods resource contains a collection of Pod objects.
自定义资源是 Kubernetes API 的扩展，不一定在每个Kubernetes群集上都可用.换句话说，它代表特定Kubernetes安装的自定义.
A custom resource is an extension of the Kubernetes API that is not necessarily available on every Kubernetes cluster. In other words, it represents a customization of a particular Kubernetes installation.
CRD 用于扩展Kubernetes本身，而不用于应用程序数据.
A CRD is for extending Kubernetes itself, it is not for application data.
helm-crd/examples/mariadb. yaml 是关于轻量级元数据的，它将使Kubernetes下载正确的发行版并通过Helm安装它.
The helm-crd/examples/mariadb.yaml is about lightweight metadata which will enable Kubernetes to download the right release and through Helm install it.
不是为可能没有
Kubernetes存在的随机应用程序存储数据(与Helm版本相反，Helm版本仅在Kubernetes部署方案中才有意义)
It is not to store data for a random application which could exist without Kubernetes (as opposed to Helm releases, which make sense only in a Kubernetes deployment scenario)
类似地， Istio CRD 仅在Kubernetes上下文中才有意义:
Similarly, Istio CRD makes sense only in a Kubernetes context:
这种方法(使用etcd存储任何应用程序数据)将无法扩展.
That approach (using etcd to store any application data) would not scale.
这篇关于我可以将应用程序数据存储在kubernetes配置资源中吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！