OpenFeign with Kubernetes: Do You Still Need Spring Cloud LoadBalancer?

Yes. This is one of the biggest changes from the old microservice architecture to Kubernetes.

Short answer

If your microservices are running inside Kubernetes:

• ✅ Use OpenFeign for service-to-service communication.
• ✅ Let Kubernetes Service handle load balancing.
• ❌ You typically do not need Spring Cloud LoadBalancer.

---

Before Kubernetes (Traditional Spring Cloud)

Order Service
      │
      ▼
OpenFeign
      │
      ▼
Spring Cloud LoadBalancer (Earlier Ribbon)
      │
      ▼
Eureka Server
      │
      ▼
Instance 1
Instance 2
Instance 3

How it worked:

1. Feign asked Eureka for all instances.
2. Eureka returned a list of instances.
3. Spring Cloud LoadBalancer chose one.
4. Feign sent the request.

The client decided where to send the request (client-side load balancing).

---

With Kubernetes

Order Pod
    │
    ▼
OpenFeign
    │
    ▼
customer-service
(Kubernetes Service)
    │
    ▼
kube-proxy / networking
    │
 ┌──┴────┬─────┐
 ▼       ▼     ▼
Pod 1   Pod 2  Pod 3

How it works:

1. Feign sends the request to http://customer-service.
2. Kubernetes DNS resolves customer-service to the Service IP.
3. Kubernetes Service automatically forwards the request to one of the healthy pods.

Feign doesn’t know or care which pod receives the request.

---

So does Spring Cloud LoadBalancer disappear?

In most Kubernetes deployments:

Yes, practically.

You don’t configure:

• Eureka
• Ribbon
• Spring Cloud LoadBalancer

because Kubernetes already provides service discovery and load balancing.

---

Example

Your Feign client:

@FeignClient(name = "customer-service")
public interface CustomerClient {

    @GetMapping("/customers/{id}")
    Customer getCustomer(@PathVariable Long id);

}

Application configuration:

customer-service:
  url: http://customer-service

Feign calls:

http://customer-service/customers/1

Kubernetes automatically routes it:

customer-service
      │
      ▼
Pod A

Next request
      ▼
Pod C

Next request
      ▼
Pod B

No extra load-balancing code is required.

---

Why do some projects still include Spring Cloud LoadBalancer?

There are a few reasons:

• The same application runs both locally and in Kubernetes.
• The team hasn’t fully migrated from an older Spring Cloud architecture.
• They use advanced client-side load-balancing features or custom selection policies.

For a Kubernetes-only environment, it’s usually unnecessary.

---

Modern enterprise architecture

                Kubernetes Cluster
------------------------------------------------

API Gateway
      │
      ▼
Order Service
      │
      ▼
OpenFeign
      │
      ▼
customer-service (K8s Service)
      │
      ▼
Pod 1
Pod 2
Pod 3

------------------------------------------------

Responsibilities

Component	Responsibility
OpenFeign	Makes HTTP calls using a Java interface
Kubernetes DNS	Finds the destination service
Kubernetes Service	Load balances requests across healthy pods
Pods	Process the request

So, in a modern Kubernetes-based microservice architecture, OpenFeign is still used, but Kubernetes is responsible for service discovery and load balancing, making Spring Cloud LoadBalancer generally unnecessary.