Skip to content
Open
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
23 changes: 18 additions & 5 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -95,6 +95,9 @@ The CloudStack Kubernetes Provider supports several annotations on LoadBalancer

**Description:** Enables the [HAProxy Proxy Protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) on a CloudStack load balancer. This annotation only applies to TCP service ports and requires CloudStack 4.6 or later.

Toggling this annotation on an existing service updates the CloudStack load balancer rule in place:
the rule keeps its identity and its public port is not interrupted.

**Use Case:** Use this annotation when you need to preserve the original client IP address through the load balancer. This is commonly required for ingress controllers like Traefik or Nginx that need to know the client's real IP address.

**Example:**
Expand Down Expand Up @@ -389,13 +392,23 @@ account when migrating from the old cloud provider to the standalone controller.

### Load Balancer

Load balancer rule names now include the protocol in addition to the LB name and service port.
This was added to distinguish tcp, udp and tcp-proxy services operating on the same port.
Without this change, it would not be possible to map a service that runs on both TCP and UDP port 8000, for example.
Load balancer rule names now include the protocol in addition to the LB name and service port, so
that a rule identifies the protocol it serves. The controller keeps the name in step with the
protocol, so a rule renamed from `-tcp-` to `-tcp-proxy-` reflects a protocol change rather than a
new rule.
Comment thread
Copilot marked this conversation as resolved.

Note that CloudStack rejects two load balancer rules with overlapping port ranges on the same public
IP regardless of their protocols, so a service cannot expose the same port over both TCP and UDP
through one IP address. Use separate services on separate IPs for that.

A rule created by the old provider carries no protocol in its name. The controller adopts such a
rule on the first reconcile, matching it by public IP, IP protocol and public port, and renames it
to the current scheme. Existing rules therefore do not have to be removed before migrating.

:warning: **If you have existing rules, remove them before the migration, and add them back afterwards.**
:warning: **Rules of a Service that is recreated during the migration are not adopted.**

If you don't do this, you will end up with duplicate rules for the same service, which won't work.
Rule names derive from the Service UID, so a Service recreated with a new UID leaves its old rules
behind. Remove those rules and release their public IPs by hand.

### Metadata

Expand Down
Loading
Loading