<p>While I can create custom objects just fine, I am wondering how one is supposed to handle large payloads (Gigabytes) for an object.</p>

<p>CRs are mostly used in order to interface with garbage collection/reference counting in Kubernetes.</p>

<p>Adding the payload via YAML does not work, though (out of memory for large payloads):</p>

<pre><code>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_...
</code></pre>

<p>One could perhaps add the payload to a PV and just reference that path in the CR.
Then I have the problem, that it seems like I cannot clean up the payload file, should the CR get finalized (could not find any info about custom Finalizers).</p>

<p>Have no clear idea how to integrate such a concept into Kubernetes lifetimes.</p>

<p>In general the limit on size for any Kube API object is ~1M due to etcd restrictions, but putting more than 20-30k in an object is a bad idea and will be expensive to access (and garbage collection will be expensive as well).</p>

<p>I would recommend storing the data in a object storage bucket and using an RBAC proxy like <a href="https://github.com/brancz/kube-rbac-proxy" rel="nofollow noreferrer">https://github.com/brancz/kube-rbac-proxy</a> to gate access the bucket contents (use a URL to the proxy as a reference from your object).  That gives you all the benefits of tracking the data in the api, but keeps the object size small.  If you want a more complex integration you could implement an aggregated API and reuse the core Kubernetes libraries to handle your API, storing the data in the object store.</p>
