我正在尝试为我的应用程序找到一个DB(对象存储)。该应用程序实际上是ISTIO Network Routing API的包装。基本上简化了我的网络的ISTIO配置。 Kubernetes(k8s)定制资源定义(CRD)似乎符合我的要求。也喜欢CRD提供的watch和REST API功能。
数据库要求
为什么使用CRD是个好主意还是一个坏主意?使用CRD是否有任何性能暗示。 This 2016 stackflow answer建议etcd数据不在RAM中。而etcd链接建议etcd可以10k writes/sec做(因此,即使不在内存中,也没有纯粹在磁盘中,谁在乎)。
我看到使用k8s CRD的多个应用程序。
答案 0 :(得分:2)
考虑到这一点(CRD page)
资源是 Kubernetes API 中的终结点,用于存储某种类型的API对象。例如,内置的pods资源包含Pod对象的集合。
自定义资源是 Kubernetes API 的扩展,不一定在每个Kubernetes群集上都可用。换句话说,它代表特定Kubernetes安装的自定义。
A CRD用于扩展Kubernetes本身,而不用于应用程序数据。
helm-crd/examples/mariadb.yaml是关于轻量级元数据的,它将使Kubernetes下载正确的发行版并通过Helm安装它。
不是存储没有Kubernetes的随机应用程序的数据(相对于Helm版本,后者仅在Kubernetes部署方案中有意义)
类似地,Istio CRD仅在Kubernetes上下文中才有意义:
Kubernetes当前在自定义资源定义(CRD)上实现Istio配置。这些CRD对应于名称空间范围CRD和群集范围CRD,并通过Kubernetes RBAC自动继承访问保护。
这种方法(使用etcd存储任何应用程序数据)将无法扩展。