Exporting Kubernetes resources: 

The resources created in Kubernetes on one cluster can be exported to another cluster. While Kubernetes is a platform that allows separation of resources by namespaces, the user objects created through Kubernetes api-services can be assigned to any namespace and belong to any type. These objects include such things as secrets, serviceaccounts, configmaps, persistentvolumes and custom resources. Collecting all the resources for a particular namespace is as easy as: 

“kubectl get --export --all -n <user-namespace>” 

And each resource can be collected in json or yaml format. 

The exported resources have creation timestamp or if they were in the state of being deleted then they have deletion timestamp. These and some other attributes will need to be removed from the declaration before they can be imported into another cluster. 

When the resource is imported in the destination cluster with: 

“kubectl create –f <resource-definition.yaml> -n <user-namespace>” 

the corresponding resources get created just as they were in the origin cluster. This means that the application works essentially the same as before.  

This works for individual Kubernetes resources and their definitions. However, the links between the resources such as the service account to be used with a particular resource needs to be in the exported-imported yaml declarations otherwise they are not re-created. In order to do this, an application must be mindful of all the objects and their dependencies including those that exists in the catalog or have their service-brokers point to resources external to the cluster. 

Some solutions like the Heptio Ark or Velero perform this nicely for some of the applications but the collection of all resources and objects determine a fully functional backup and restore. 

The customizations performed over the backup and restore from the tool above should be minimal and just enough to support the packing and unpacking of user resources in a bundle to be exported from source and imported at destination. 

These include: 

• Registrations in the catalog 
• Custom resources being created: for example, FlinkApplications, FlinkSavepoints and FlinkClusters 
• External logic saved as maven artifacts or other files on disk aside from custom resources 

• Metrics data  
• Events for all the user resources 
• Logs for all the containers 
• User accounts and roles 
• Store connection info and containers 

• Proprietary Data migration for each container in etcd, databases, blobs, files and stream store.