Option to backup all namespaces

[iTrooz]

Summary

As someone that wants to backup their k8s cluster
I want the ability to backup the full cluster
So that everything is backuped automatically without having to setup k8up for every new namespace in the future

Context

I would love the ability to make a full cluster backup with k8up. I think that currently this tool is only capable of doing a backup of a single namespace

Out of Scope

No response

Further links

No response

Acceptance Criteria

No response

Implementation Ideas

No response

[ImDevinC]

100%. Having to create a backup per namespace is extremely cumbersome and not ideal. One backup schedule that covers all namespaces would be phenomenal

[danielpodwysocki-gini]

I personally do not like this. I'm a big fan of this tool precisely because it tailors to thinking about "what am I bundling and what backup/schedule I want to bundle with it?"

If I'm deploying X into namespace Y, it is largely independent of X in namespace Z.

That makes it real clean to think about components that I make either a part of an application or a self-service platform.

I think the way it would change how the tool models its view of the cluster would either have to be hacky or potentially close doors to ideas such as watching only specific namespaces with a given instance (which could be a really nice enhancement in of its own)

(I'm just a user, but throwing in my 0.02 cents here)

[ImDevinC]

@danielpodwysocki-gini i don't believe the ask is to remove the current functionality, or even change the defaults; just add an option to support all namespaces. I don't believe it would be hacky, as many tools already have similar functionality (ie: cert-manager has Issuer and ClusterIssuer, SealedSecrets supports a cluster-wide annotation, etc).

[danielpodwysocki-gini]

Well, it depends what angle you look at it from.

If you look at the tool and how the code must look at the information, as soon as you introduce cluster-wide resources, it needs to span across namespaces and interact in a lot of ways that lock in certain decisions.

That means that 1) you cannot cleanly separate out per-namespace tenants, 2) any features that'd target per-namespace/per-deployment must also take the cluster-view and do extra work to consider that.

That shapes what it can/cannot do and how easily it can be implemented.
It changes the tool's "mental model" and constraints what&how easily you can implement.

In my view that'd just make it poor man's Velero - it becomes geared towards cluster operators and not the owners/users of individual components.

If I was to wear the hat of a cluster operator, I just want to do a blanket backup of everything, without looking at per application constraints.

When I use k8up, I want to let the owner of a deployment own their data (and perform any extra steps needed to assure consistency/etc.). The backups are bundled with either components I provide or within deployments the app owner does.

Different data owners will have:

• different schedules
• different retentions
• different regulatory constraints to where the data ends up
• at times, even different storage backends!

I like the tool considering each deployment in its own right - it makes it really good at that kind of usage.
I'm worried having to make two distinct decision trees would make it worse for both worlds.

[iTrooz]

Hello !

Regarding your comment on Velero: does this mean that k8up does not aim to become a Velero alternative in long-term, providing the same features (full kubernetes cluster backup) ?

This is personally what I planned to use this project as

[danielpodwysocki-gini]

Regarding your comment

No idea - I do not maintain k8up, I'm an individual user. That can likely be easier gleaned from Slack or the roadmap.

I'm just a sharing why I deployed it for the teams I have run it and what I see it useful in those contexts.

[Kidswiss]

Hi Everyone

K8up maintainer here.

@danielpodwysocki-gini's explanation is pretty much on point. K8up was desinged to delegate backups away from the platform operators. So that each team/app can bundle their own specific backup needs.

Having said that: we do have ideas to modernize K8up at some point and we talked about having the ability to also provide cluster level backups in addition to the namespaced ones. However, these are only ideas at the current stage and I can't really give a timeline or roadmap for this.

On thing you could do is using something like https://github.com/vshn/espejo (or it's successor) to deploy schedules to all namespaces from one single definition.

[ImDevinC]

I appreciate the insight towards the roadmap, I'll look for a tool that better supports my use case, thanks.