Feature request: Manage Traefik ingress replicas and HA settings from QuickStack UI

[DenisNovikau]

Summary

It would be useful if QuickStack exposed basic Traefik ingress high-availability settings in the UI, especially for multi-node clusters.

QuickStack already manages domains, HTTPS, Traefik ingress, and cluster nodes. However, there does not seem to be a documented UI option to configure the Traefik deployment itself, for example the replica count or scheduling behavior.

Docs references:

• QuickStack architecture mentions Traefik handling ingress and automatic TLS: https://quickstack.dev/docs
• Custom domains rely on Traefik and HTTPS: https://quickstack.dev/docs/how-to/networking/domains
• Cluster nodes support multi-node setups: https://quickstack.dev/docs/how-to/admin/cluster-nodes
• Required ports list 80/443 as Traefik ingress: https://quickstack.dev/docs/reference/ports-and-endpoints

Problem

In a multi-node k3s cluster, Traefik may run as a single replica on one node while the k3s ServiceLB exposes 80/443 on all node IPs.

That means public traffic can enter through a node that is not actually running the Traefik pod and then be forwarded internally. If that node's public 443 path has intermittent connectivity problems, apps behind QuickStack can become unreachable even though:

• the application pod is healthy,
• the Kubernetes service/endpoints are healthy,
• Traefik is healthy on another node,
• another node IP can serve the same domain successfully.

This is especially visible for Git-over-HTTPS workloads such as Gitea, where intermittent TCP connect timeouts on port 443 cause pushes/fetches to fail before the request even reaches the app.

Proposed feature

Add an admin section, for example under:

Settings -> QuickStack Server -> Networking / Traefik

Possible settings:

• Traefik replica count, e.g. 1, 2, 3, or auto
• Optional topology spread / pod anti-affinity so replicas are placed on different nodes
• Optional node selector / preferred ingress nodes
• A clear indication of which public node IPs currently serve 80/443
• A warning when domains point to a node that is not running a Traefik replica
• Optional external traffic policy / ServiceLB guidance if QuickStack can safely manage it

Desired behavior

For a multi-node QuickStack cluster, admins should be able to make ingress highly available without manually editing the k3s Traefik HelmChart/HelmChartConfig.

QuickStack could persist this configuration in the same way it manages other cluster-level settings, so it survives QuickStack updates, k3s upgrades, and Traefik restarts.

Why this matters

QuickStack is marketed as a simple self-hosted PaaS with multi-server support. For production setups, the ingress layer is one of the most critical components. If apps can run across multiple nodes but the ingress controller remains a single replica with no visible HA controls, users may assume the cluster is more redundant than it actually is.

A UI-managed Traefik HA configuration would make production setups safer and reduce the need for manual Kubernetes changes outside QuickStack.