<p>I'm looking to understand how to recreate my cluster.  There's a cluster-level setting to specify the IP range for nodes created within it, which I want to use so I can set a decent firewall rule.  However, it looks like that can't be changed once the cluster is created.</p>

<p>I have a number of namespaces, deployments, services, secrets, persistent volumes and claims.  If I wanted to transfer them all to a new cluster, should I just <code>kubectl get all --namespace=whatever --format=yaml</code>, <code>kubectl delete -f</code>, and then <code>kubectl apply -f</code> on the new cluster?</p>

<p>Would something so crude work for mapping to the same load balancers / public IPs, persistent volumes, secrets, etc?</p>

<p>As you can see the backup and the migration of whole clusters is quite a discussed matter and still an open issue on Kubernetes github as well:</p>

<ul>
<li><a href="https://github.com/kubernetes/kubernetes/issues/24229" rel="nofollow noreferrer">https://github.com/kubernetes/kubernetes/issues/24229</a></li>
</ul>

<p>Therefore I do not believe that the command that you posted might be considered a solution or work. I think it will fail due to different resources that are cluster dependent and IPs. Moreover since this kind of use is not supported It will lead for to multiple issues.</p>

<p>Lets say that you change zone of the cluster, how could be possible to move the PV if the disk cannot be attached to an instance in a different zone (or possibly if you migrate to a different cloud service)?</p>

<p>More important I would not risk to delete my production to run a command that is not documented or indicated as best practise. You could try it on test namespace, but I would not suggest to go further.</p>

<p>You can check <a href="https://hackernoon.com/introducing-reshifter-for-kubernetes-backup-restore-migration-upgrade-ffaf78da36" rel="nofollow noreferrer">reshifter</a> and <a href="https://github.com/heptio/ark" rel="nofollow noreferrer">ark</a> since they might cover your needs. I have never tested them but they are mentioned in the thread, so they might be of your interest.</p>

<hr>

<p>I tried this approach in one of my test cluster obtaining:</p>

<pre><code>Error from server (Conflict): Operation cannot be fulfilled 
Error from server (Conflict): Operation cannot be fulfilled 
Error from server (Forbidden): [...]
</code></pre>

<p>Honestly I believe that for a limited subset of resources it might be possible (Note that some resources were created correctly) , but it cannot be considered at all a way to migrate.</p>
