Document backing up a container using Kubernetes

[niranjandarshann]

This is a Feature Request

There is the information gap in the kubernetes documentation in which no any supportive information is provided for the backup of Container in stateless or stateful container state.

What would you like to be added

The brief description about taking regular backup of stateless or stateful container is needed if yes then it should be updated with the respective information. To help reader wondering about this information.

Why is this needed
It is needed as it help reader to find the information about the Container backup.
To update the document with missing information.

Page to Update
https://kubernetes.io/docs/concepts/containers/ or which you can find more relevant.

[niranjandarshann]

/language en

[niranjandarshann]

/sig docs

[niranjandarshann]

#43112 (comment) this comments referencing to raise this issue.

[sftim]

/retitle Document backing up a container using Kubernetes

[sftim]

I would:

• explain that you're typically advised to change your app so that its volumes, but not your running Pod, need to be backed up
  • also see https://12factor.net/disposability
• add documentation about how to back up volumes (emphasize that you need 3rd party tooling, or to write your own)

We could make a tutorial about how to do a simple backup of a volume, such as saving a gzip copy of the backing storage, delete the PersistentVolume and its storage, and then restore. If we have capacity.

[tengqm]

container backup is not fully working yet ...
you can backup a container but ... you cannot restore it,
the backup will be left there forever to be a "backup".
We can document that container checkpoint API if needed but I'm not sure if it is what you are looking for.

[niranjandarshann]

I would:

• explain that you're typically advised to change your app so that its volumes, but not your running Pod, need to be backed up

  • also see https://12factor.net/disposability

• add documentation about how to back up volumes (emphasize that you need 3rd party tooling, or to write your own)

We could make a tutorial about how to do a simple backup of a volume, such as saving a gzip copy of the backing storage, delete the PersistentVolume and its storage, and then restore. If we have capacity.

@sftim yes making Tutorial will be useful.

I would:

• explain that you're typically advised to change your app so that its volumes, but not your running Pod, need to be backed up

  • also see https://12factor.net/disposability

• add documentation about how to back up volumes (emphasize that you need 3rd party tooling, or to write your own)

We could make a tutorial about how to do a simple backup of a volume, such as saving a gzip copy of the backing storage, delete the PersistentVolume and its storage, and then restore. If we have capacity.

@sftim I do agree, according to this issue #43112 it will be good.

[niranjandarshann]

Inactive from long time as there is no any conclusion on it .
So closing this issue.

[niranjandarshann]

/close

[k8s-ci-robot]

@niranjandarshann: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[niranjandarshann]

/reopen

[k8s-ci-robot]

@niranjandarshann: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[niranjandarshann]

@sftim @tengqm I had gone through the doc of Kubernetes and yes I hadnot finad anything related to backup. Here I think if we mention something informative for backup in kubernetes through various blogs and docs available on internet will be useful for our readers and the developers. I dont know whether it will be good or not but yes mentioning about backup in kubernetes will be important and new. Here backup means everything like configuration, namespaces, and especially persistent volumes. Whether it will be possible? Can we investigate more for this.
Thats why i reopen it
Your suggestion and guidelines will be useful for us.

[sftim]

/triage accepted
/priority backlog

See #43307 (comment) for guidance

[tengqm]

Do we have a use case for "backup a container"?

[niranjandarshann]

@tengqm Some use case of backing up container in k8s are:

1. We might want to back up the configuration files or environment variables used by a container.
2. If We have custom container images stored in registry, we should want to back up the registry to ensure that we can recover the images in case of data loss.
3. In some cases, containers might have stateful components or data that need to be backed up. etc.
   These use cases focus more on backing up related to containers rather than the containers themselves, they are still important considerations in Kubernetes environments. It's essential to have a backup strategy in place for both application data and any container-related components

[tengqm]

@tengqm Some use case of backing up container in k8s are:

1. We might want to back up the configuration files or environment variables used by a container.

According to the 12-factor app, you wouldn't couple your config data with your app (container here). You store them somewhere else. For example, in kubernetes, you store them in ConfigMaps. You can store them in a PV volume as well. In any cases, you don't backup the container.

2. If We have custom container images stored in  registry, we should  want to back up the registry to ensure that we can recover the images in case of data loss.

That is something related to your image registry, e.g. Harbor or some light-weight alternatives. It has nothing to do with container instances. You can store many things in the registry, for various purposes.

3. In some cases, containers might have stateful components or data that need to be backed up. etc.

A stateful application has its data stored in a PV volume. The data is not persisted in the container. You would not do that. You would not treat a container as a VM. Treating containers like VMs would make things a lot difficult to manage. On the contrary, you may want to forbid writing anything to your container's file system, for security's sake or for availability's sake.

   These use cases focus more on backing up related to containers rather than the containers themselves, they are still important considerations in Kubernetes environments. It's essential to have a backup strategy in place for both application data and any container-related components

Most of the existing solutions, AFAICT, are based on the velero framework. Some vendors create their own extensions, such as backing up static pod manifests or control plane configurations. But I would NOT call that "container backup". Remember that one key design consideration behind Pods (not to mention Containers inside it) is making them dispensable. They don't have a fixed IP address! Imagine that. They are designed to be short lived. Why bother to backup them then?

[sftim]

We can tell people about good practice. However, Kubernetes does aim to help you run your legacy workloads too; containers can be svelte things with a single 27MiB binary based on scratch, or a behemoth lifted and shifted from a legacy build.

We recommend the svelte one but we don't insist. Yes, you should back up your volumes and not your containers, but we should ideally tell you - in outline - how to achieve both ways whilst still firmly recommending a cloud native approach.

[niranjandarshann]

@sftim What i thaught is the general approach for taking backup of configurational file. Please have a look and let me know WDYT about this.

1 Approach is General Approach

How to backup configuration file 
like configmap,secret,pv,deployment etc. in ;local

we can do it by using kubectl command

kubectl get configmap --all-namespaces -o yaml > configmapsbackup.yaml
kubectl get secret --all-namespaces -o yaml > secretsbackup.yaml

we can apply this configmapbackup.yaml and secretbackup.yaml to create configmap and secret of same again.

kubectl apply -f configmapbackup.yaml

2. Approach is making snapshot and restoring the snapshot.
3. Approach is by using cronJob to copyin the things in our local or in cloud.

I investigated and got some information. In these approach there is no any third party involvement is required.

WDYT?

[sftim]

My thinking from #43307 (comment) and #43307 (comment) stands.

Maybe what you're proposing would work better as a blog article rather than documentation?

[niranjandarshann]

Ok got your point.

[niranjandarshann]

My thinking from #43307 (comment) and #43307 (comment) stands.

Maybe what you're proposing would work better as a blog article rather than documentation?

Proposed PR #49452 considering a simple backup of a volume, such as saving a gzip copy of the backing storage, delete the PersistentVolume and its storage, and then restore. by creating a Tutorial. PTAL !