Introduction into Load Balancers on Thalassa Cloud

Load balancers play a critical role in any cloud infrastructure. They ensure that incoming traffic is reliably routed to healthy services, distributing load across multiple backend targets. On Thalassa Cloud, load balancers are designed from the ground up to be fast, flexible, and API-driven. Built on top of Envoy Proxy, our load balancer implementation provides high performance with a strong focus on automation and self-service.

In this post, we introduce the core load balancer features available on Thalassa Cloud, explain the key building blocks like listeners and target groups, and walk through how our integration with Kubernetes makes load balancing seamless for container workloads.

Load Balancer Capabilities

Thalassa Cloud Load Balancers are engineered for high performance and fast configuration. They support both TCP and UDP traffic, making them suitable for a wide range of use cases-from internal services and databases to real-time systems or edge workloads. The provisioning time is typically under one minute, and changes to existing load balancer configurations are applied within seconds.

Each load balancer supports up to 100 listeners, giving you the flexibility to expose multiple services or ports through a single endpoint. Listener settings include connection limits, idle timeouts, and support for Proxy Protocol, which allows passing client IP metadata to the backend service. Configuration changes are non-disruptive and can be automated via our API, SDK, or UI. This fast, reliable behavior is powered by Envoy Proxy as the underlying engine.

Core Concepts: Load Balancer, Listeners, and Target Groups

To use Thalassa Cloud Load Balancers effectively, it’s helpful to understand the three core resources involved: the load balancer itself, listeners, and target groups.

• A Load Balancer is the top-level object you deploy inside a subnet within your VPC. It can be configured as an internal (private) or external (public) resource, depending on your requirements. Each load balancer holds one or more listeners, which determine how traffic is received and forwarded.
• Listeners define the port and protocol (TCP or UDP) for incoming connections. Each listener connects to a specific Target Group, which is a collection of backend servers or services. Listeners are independently configurable, allowing you to define limits such as maximum concurrent connections or idle timeouts. You can also restrict access using source IP CIDRs.
• A Target Group represents the set of endpoints that will receive traffic. Targets can be manually attached or selected dynamically using label selectors. Each group is bound to a protocol and a target port, and supports multiple load balancing strategies including round robin, random, and Maglev. This modular design allows for flexible and reusable configurations across environments.

Health Checks Per Target Group

Health checks are essential for ensuring traffic is only routed to healthy backends. In Thalassa Cloud, each target group can be configured with its own health check policy. This includes defining the protocol (TCP, HTTP), port, interval, timeout, and threshold conditions for declaring a backend healthy or unhealthy.

• Note that unlike the listeners, health checks currently only support TCP and HTTP protocols.
• These health checks run continuously in the background and influence how traffic is distributed.
• If a backend fails to respond or becomes slow, it will be automatically removed from the pool until it recovers. This built-in resilience protects your services from degraded nodes and improves uptime without manual intervention.
• Important: A target group must have at least one healthy backend for health checking to function correctly. If all backends fail, traffic will be forwarded to all backends within a pool.

Kubernetes Integration via cloud-provider-thalassa

For users running workloads on Thalassa Cloud Managed Kubernetes, load balancers are integrated directly into the Kubernetes ecosystem through our custom Cloud Controller Manager, cloud-provider-thalassa. When you define a Kubernetes Service of type LoadBalancer, the platform automatically provisions and configures a load balancer instance for that service.

The integration implements Kubernetes annotations and ensures services are properly exposed according to your network setup. Internal services can be bound to private IPs, while public services are assigned external endpoints. By using Kubernetes-native primitives, DevOps teams can manage networking in a declarative, version-controlled way-just like they do with deployments or ingress rules.

This integration reduces the operational overhead typically associated with setting up and managing load balancers manually. It also ensures consistency between your cloud infrastructure and Kubernetes services.

Designed for Modern Infrastructure

Unlike many traditional platforms where load balancers are an afterthought, Thalassa Cloud treats them as a first-class component of the platform. This approach allows you to build modern, cloud-native networking layers without relying on manual setup, shell scripts, or third-party appliances.

Thalassa Cloud Load Balancers are built with multi-tenancy, automation, and observability in mind. They can support both legacy and containerized applications, allowing you to gradually modernize your stack without making disruptive changes. Combined with our VPC networking and security groups, you get full control over how traffic flows within and between your workloads.

Architecture and High Availability

Thalassa Cloud Load Balancers are designed from the ground up for high availability and fault tolerance. Every load balancer you deploy is automatically configured in HA mode, without requiring any extra configuration or setup on your part.

High Availability

In practice, this means that if the active load balancer instance becomes unavailable-due to hardware failure, software crash, or maintenance-it will be automatically replaced by a healthy instance. This failover happens behind the scenes, and the load balancer’s IP address remains consistent. In nearly all cases, you will not notice this failover happening.

Load balancer upgrades and failovers are designed to be non-disruptive. Configuration changes, such as adding listeners or updating target groups, are applied live and without downtime or connection interuption. During platform-level upgrades (e.g., a new Envoy version), the load balancer service remains available, although existing TCP connections may be reset while components are restarted. In such cases, client applications should be designed to gracefully handle TCP RST events and re-establish connections as needed.

Multi zone aware

Our architecture is multi-zone aware, allowing load balancers to operate across availability zones within a region. This ensures that your services remain reachable even if an entire zone experiences a failure. It also enables us to distribute load balancer instances for better redundancy and performance.

This architecture ensures that your applications stay online and responsive-even during upgrades, failures, or changes-while giving you full control over networking behavior via a modern, API-first platform.

Roadmap: What’s Coming Next

While the current version of Thalassa Cloud Load Balancers focuses on high-performance L4 load balancing (TCP and UDP), we are actively expanding its capabilities to support more advanced use cases.

• Our roadmap includes the introduction of Layer 7 (L7) support, enabling HTTP, HTTPS, and gRPC-based routing. This will allow for smarter traffic control based on headers, paths, and hostnames, making it easier to run complex applications behind a single endpoint.
• We are also working on a built-in Web Application Firewall (WAF) to protect your applications from common web-based threats such as SQL injection, cross-site scripting, and malicious bots. This will integrate directly with your load balancer configuration and can be enabled per listener.
• Additionally, access logging will soon be available. You’ll be able to monitor all incoming traffic, filter logs based on listeners or target groups, and forward logs to your own observability tools or to Thalassa Cloud’s native logging service.
• Our load balancing engine will integrate with our Intrusion Detection System (IDS). This integration will enable real-time traffic inspection and anomaly detection, adding another layer of defense against both external and internal threats.
• Finally, we are investigating possibilities to offer transparent network load balancing as well, so backend applications see the source IP address directly. This eliminates the need for Proxy Protocol, as well as opens up new capabilities for more clear firewalling and integration with Kubernetes based workloads.

These features will be rolled out incrementally and will follow the same principles as the rest of the platform: fast provisioning, clear APIs, and deep integration with your infrastructure.