Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decision: Managed MachineSets for Cloudscale Provider #367

Merged
merged 3 commits into from
Nov 29, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
= Managed MachineSets for Cloudscale Provider

== Problem

We created a cloudscale Machine-API provider for OpenShift 4 as decided in https://kb.vshn.ch/appuio-cloud/explanation/decisions/machine-api.html[Custom Machine API Provider].
The provider allows to managed MachineSets for all node types in an OpenShift 4 cluster.
The provider runs on the control plane nodes but we've not yet found a feasible way to run it on bootstrap nodes.
Some configuration is still based on Puppet or Terraform.

=== Goals

* Frictionless management of nodes
* Reduce cluster installation time

=== Non-goals

* More general centralized management of OpenShift 4 clusters

== Proposals

=== Option 1: Manage worker nodes

We only manage worker nodes with the Machine-API provider.
After installing the control-plane nodes, the infra nodes and any additional nodes (for example storage nodes), we create a MachineSet for the worker nodes.

This allows us to have the required customer requested AutoScale feature and helps us by being able to easily replace failing worker nodes.
It doesn't help us with replacing other node types, such as infra nodes.

=== Option 2: Manage all nodes except control plane nodes

We manage all nodes except the control plane nodes with the Machine-API provider.
After installing the control-plane nodes, the worker nodes, infra nodes and any additional nodes (for example, storage nodes) are scaled up from a MachineSet.

This allows us to have the required customer requested AutoScale feature and helps us by being able to easily replace failing nodes.

Control plane nodes aren't managed by the Machine-API provider because they aren't expected to be replaced often.
Control plane nodes need some configuration in the VSHN DNS zone and can't be that easily replaced anyways.
There is no easy and intuitive way to bootstrap the control plane nodes with the Machine-API provider since the provider itself is running on the control plane nodes.

Some caution has to be taken to follow correct node replacement procedures such as updating the router back end configuration for infra nodes or rebalancing the storage nodes.
bastjan marked this conversation as resolved.
Show resolved Hide resolved

Router back end configuration will need to be automated, independently of this issue, as soon as we rollout the new cloudscale load balancers.
bastjan marked this conversation as resolved.
Show resolved Hide resolved

=== Option 3: Manage all nodes

We manage all nodes with the Machine-API provider.
The control plane nodes are managed by the Machine-API provider as well.
We find a way to run the provider on the bootstrap nodes or on the engineer's device.

This allows us to have the required customer requested AutoScale feature and helps us by being able to easily replace failing nodes.

Replacing control plane nodes has been tested and just works, thanks to PodDisruptionBudgets in the OpenShift 4 distribution.
Some caution has to be taken to update internal VSHN DNS zone configuration to the new control plane nodes.

We most likely can replace the DNS zone configuration after we introduced the new cloudscale load balancers.

== Decision

We decided to go with option 2: Manage all nodes except control plane nodes.

== Rationale

We decided to go with option 2 because it allows us to have the required customer requested AutoScale feature and helps us by being able to easily replace most types of failing nodes.
Since the provider is fairly new we want to start with a smaller scope and expand it later on.
Setting up control plane nodes with a provider isn't straightforward.
With the introduction of the new cloudscale load balancers we might revisit this decision.
1 change: 1 addition & 0 deletions docs/modules/ROOT/partials/nav.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -245,6 +245,7 @@

* Decisions
** xref:oc4:ROOT:explanations/decisions/machine-api.adoc[]
** xref:oc4:ROOT:explanations/decisions/managed-machine-sets-cloudscale.adoc[]
** xref:oc4:ROOT:explanations/decisions/maintenance-trigger.adoc[]
** xref:oc4:ROOT:explanations/decisions/maintenance-alerts.adoc[]
** xref:oc4:ROOT:explanations/decisions/syn-argocd-sharing.adoc[]
Expand Down