Added a variable to enable live-booting with Typhoon (bare-metal flatcar-linux) #4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sadi-a
force-pushed
the
live_boot
branch
3 times, most recently
from
e33ace4
to
adbef8d
Compare
…car-linux) Until now, Typhoon needed to be installed on a machine. This commit aims to change that through several additions. First, the worker.yaml and controller.yaml files were renamed to *.tftpl in order to use the themplating functionalities found in Terraform and make it obvious they are used. Second, a variable named "enable_live", which defaults to false, has been added. This variable's value has several effects : first, the config url used will have os=installed if enable_live is true. Second, which is the interesting part, if it is enabled, we won't install Flatcar and will instead do several operations : we start by checking if a certain partition, which contains the SSH host keys as well as the kubernetes certificates and other files, exists. If it doesn't, this partition is created on the smallest disk, some SSH host keys are generated and the partition is given a label. After that, we mount the partition in /persist/ and generate some SSH host keys if they don't already exist and give it the required files to run kubernetes. Furthermore, when possible, the services will use /persist instead of /etc to get some files (like for the kubernetes manifests for example). That way, we always have the same host keys and keep access to the kubernetes cluster.
Sadi-a
force-pushed
the
live_boot
branch
6 times, most recently
from
234a952
to
9f3e543
Compare
For some reason, the bootstrapping, which is just a `kubectl apply`, was done on the machines with a service that was launched with SSH on every single controller. This commit aims to change this through the addition of the Kubernetes provider as well as a GKE autopilot cluster to workaround the limitations of the Kubernetes provider when it comes to applying manifests (cf official documentation, application of manifests can only be done at plan time).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Until now, Typhoon needed to be installed on a machine. This commit aims to change that through several additions.
First, the worker.yaml and controller.yaml files were renamed to *.tftpl in order to use the themplating functionalities found in Terraform and make it obvious they are used.
Second, a variable named "enable_live", which defaults to false, has been added. This variable's value has several effects : first, the config url used will have os=installed if enable_live is true. Second, which is the interesting part, if it is enabled, we won't install Flatcar and will instead do several operations : we start by checking if a certain partition, which contains the SSH host keys as well as the kubernetes certificates and other files, exists. If it doesn't, this partition is created on the smallest disk, some SSH host keys are generated and the partition is given a label.
After that, we mount the partition in /persist/ and generate some SSH host keys if they don't already exist and give it the required files to run kubernetes. Furthermore, when possible, the services will use /persist instead of /etc to get some files (like for the kubernetes manifests for example).
That way, we always have the same host keys and keep access to the kubernetes cluster.
Furthermore, the bootstrapping, which is just a
kubectl apply, was done on machines with a service that was launched with SSH on every single controller. This is also changed through this PR with the addition of the Kubernetes provider as well as a GKE autopilot cluster to workaround the limitations of the Kubernetes provider when it comes to applying manifests (cf official documentation, application of manifests can only be done at plan time).