Is your feature request related to a problem? Please describe.
Currently, QuickStack supports one master node and multiple worker nodes. This creates a single point of failure for the control plane: if the master node becomes unavailable, cluster management and critical control-plane operations are affected. For production or more resilient setups, this limitation makes it harder to run QuickStack in a highly available configuration.
Describe the solution you'd like
I would like QuickStack to support multiple master nodes / control-plane nodes in addition to multiple worker nodes. Ideally, the setup flow should allow adding additional master nodes after the initial installation, similar to how worker nodes can be added today.
This would make it possible to run QuickStack in a highly available K3s setup, where the control plane is replicated across multiple nodes and the cluster can continue operating even if one master node fails.
Describe alternatives you've considered
The current alternative is to run only one master node with multiple workers and rely on backups or manual recovery if the master fails. Another option would be to manually modify the underlying K3s setup, but this would bypass QuickStack’s intended management flow and may cause issues with future updates or node management.
Is your feature request related to a problem? Please describe.
Currently, QuickStack supports one master node and multiple worker nodes. This creates a single point of failure for the control plane: if the master node becomes unavailable, cluster management and critical control-plane operations are affected. For production or more resilient setups, this limitation makes it harder to run QuickStack in a highly available configuration.
Describe the solution you'd like
I would like QuickStack to support multiple master nodes / control-plane nodes in addition to multiple worker nodes. Ideally, the setup flow should allow adding additional master nodes after the initial installation, similar to how worker nodes can be added today.
This would make it possible to run QuickStack in a highly available K3s setup, where the control plane is replicated across multiple nodes and the cluster can continue operating even if one master node fails.
Describe alternatives you've considered
The current alternative is to run only one master node with multiple workers and rely on backups or manual recovery if the master fails. Another option would be to manually modify the underlying K3s setup, but this would bypass QuickStack’s intended management flow and may cause issues with future updates or node management.