虽然我可以很好地创建自定义对象,但我想知道如何处理对象的大型有效负载(千兆字节)。
CR主要用于与Kubernetes中的垃圾收集/引用计数接口。
但是,通过YAML添加有效负载不起作用(大型有效负载的内存不足):
apiVersion: "data.foo.bar/v1"
kind: Dump
metadata:
name: my-data
ownerReferences:
- apiVersion: apps/v1
kind: Deploy
name: my-deploy
uid: d9607a69-f88f-11e7-a518-42010a800195
spec:
payload: dfewfawfjr345434hdg4rh4ut34gfgr_and_so_on_...
也许可以将有效载荷添加到PV并且仅引用CR中的该路径。然后我有问题,似乎我无法清理有效负载文件,如果CR最终确定(找不到有关自定义终结器的任何信息)。
不清楚如何将这样的概念整合到Kubernetes生命周期中。
通常,由于etcd限制,任何Kube API对象的大小限制为〜1M,但是在对象中放置超过20-30k是一个坏主意并且访问成本很高(并且垃圾收集也会很昂贵)。
我建议将数据存储在对象存储桶中,并使用像https://github.com/brancz/kube-rbac-proxy这样的RBAC代理来访问存储桶内容(使用代理的URL作为对象的引用)。这为您提供了跟踪api中数据的所有好处,但保持了较小的对象大小。如果您想要更复杂的集成,您可以实现聚合API并重用核心Kubernetes库来处理您的API,将数据存储在对象库中。
我们仍然使用CO。除此之外,我们还创建了一个Kubernetes控制器,它可以处理PV中的使用寿命。对我们来说这很好用,因为Controller可以是PV的单个写入器,而实际的Services只需要对PV的读访问权。结合ownerReference
,这可以很好地融入Kubernetes的生命周期。