kops import: Support kops created clusters
kops import is intended for use with clusters created with kube-up. If it could support kops created clusters as well, when paired with Terraform (or other output format someday) it could become a great way to ensure cluster infrastructure can be completely rebuilt from scratch.
austinmoore-
All 5 comments
completely rebuilt from scratch
What do you mean?
chrislovecnm
on 4 Nov 2016
I'm imagining a worst case scenario where all cloud resources are destroyed. While unlikely, it is important to be capable of completely recovering from such a scenario. Describing infrastructure as code is a great way to do this, and the Terraform support in kops can provide this. However, since everything is gone - including the kops state store in S3 - the cluster created with TF cannot be managed by kops. If kops could import that cluster, then the reproducible infrastructure is complete.
I did some testing since posting this yesterday, and recovering from such a scenario in this way would actually prove to be quite difficult. The instances depend on resources in the state store, so if they're not there nodeup can't complete. Plus things like secrets would have to be recreated.
I would much rather have a way to pass config, instancegroups/nodes, etc. to kops on the command line for it to use. Then I could version control those files and rebuild the cluster through Jenkins, or a script. I want to remove the need for humans to edit files to rebuild a cluster. I think @justinsb told me yesterday that this is planned at some point.
Also, @justinsb may have a different use case in mind. He asked me to open this issue when I was discussing this yesterday. I was pretty much only thinking of a way to rebuild the cluster.
austinmoore-
on 4 Nov 2016
Issues go stale after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Prevent issues from auto-closing with an /lifecycle frozen comment.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale
fejta-bot
on 19 Dec 2017
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale
fejta-bot
on 18 Jan 2018
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
fejta-bot
on 17 Feb 2018
Related issues
endejoli
路
4Comments
justinsb
路
4Comments
pluttrell
路
4Comments
minasys
路
3Comments
georgebuckerfield
路
4Comments
Most helpful comment
I'm imagining a worst case scenario where all cloud resources are destroyed. While unlikely, it is important to be capable of completely recovering from such a scenario. Describing infrastructure as code is a great way to do this, and the Terraform support in kops can provide this. However, since everything is gone - including the kops state store in S3 - the cluster created with TF cannot be managed by kops. If kops could import that cluster, then the reproducible infrastructure is complete.
I did some testing since posting this yesterday, and recovering from such a scenario in this way would actually prove to be quite difficult. The instances depend on resources in the state store, so if they're not there nodeup can't complete. Plus things like secrets would have to be recreated.
I would much rather have a way to pass
config,instancegroups/nodes, etc. to kops on the command line for it to use. Then I could version control those files and rebuild the cluster through Jenkins, or a script. I want to remove the need for humans to edit files to rebuild a cluster. I think @justinsb told me yesterday that this is planned at some point.Also, @justinsb may have a different use case in mind. He asked me to open this issue when I was discussing this yesterday. I was pretty much only thinking of a way to rebuild the cluster.