We continue with the discussion of the script to export and import Kubernetes resources.
By changing the namespace, the same files can be imported again.
The export order should be resources first followed by definitions while the import order should be definitions followed by resources.
The above script only prints the commands and does not execute them.
There are two modifications that may be required to the commands.
First, the ip addresses for host, cluster and the service endpoints will need to be modified when the resources are exported from one namespace on a cluster to another. These addresses are easy to find as we make incremental progress towards the definitions and resources.
Second, the uid will need to be specified for some resources because they will pertain to existing resources in fields such as ownerReferences. This is a way to indicate that the resource will be cleaned up when the owner gets cleaned up. The ownerReferences is a way of chaining the cleanup and gives us an opportunity to do proper cleanup with a broader scope.
These two changes will help enable the resources and definitions to be recreated in the destination cluster and namespace. The commands also provide a point of reference between this method and the resulting changes provided by the Velero tool. It might be interesting to note that the latter involves specifications that may not be as lightweight and customized as the scripts above. At the same time, the tool works across deployments in general. The scripts above will work for any Kubernetes framework.
By changing the namespace, the same files can be imported again.
The export order should be resources first followed by definitions while the import order should be definitions followed by resources.
The above script only prints the commands and does not execute them.
There are two modifications that may be required to the commands.
First, the ip addresses for host, cluster and the service endpoints will need to be modified when the resources are exported from one namespace on a cluster to another. These addresses are easy to find as we make incremental progress towards the definitions and resources.
Second, the uid will need to be specified for some resources because they will pertain to existing resources in fields such as ownerReferences. This is a way to indicate that the resource will be cleaned up when the owner gets cleaned up. The ownerReferences is a way of chaining the cleanup and gives us an opportunity to do proper cleanup with a broader scope.
These two changes will help enable the resources and definitions to be recreated in the destination cluster and namespace. The commands also provide a point of reference between this method and the resulting changes provided by the Velero tool. It might be interesting to note that the latter involves specifications that may not be as lightweight and customized as the scripts above. At the same time, the tool works across deployments in general. The scripts above will work for any Kubernetes framework.
No comments:
Post a Comment