Can Kubernetes Replace a Full‑Stack Microservice Framework? A Detailed Comparison of Gateway, Service Discovery, Load Balancing, Circuit Breaking, and Config Center

Question: Having deployed various microservice components with Kubernetes, can we discard the entire microservice framework, such as circuit breaking and service discovery?

Answer: Yes, but it depends on the situation.

Using Spring Cloud as a mainstream example, we compare its capabilities with Kubernetes, highlighting overlaps and complementarities for each core microservice component.

Microservice Gateway

Gateways are largely independent of business logic and many implementations exist; the choice should match business needs. Spring Cloud Gateway cannot serve as a Kubernetes Ingress Controller, and using a gateway that is not compatible with Ingress may forfeit benefits provided by Kubernetes Ingress.

Service Discovery

Kubernetes’ built‑in service discovery based on Services and DNS is already powerful, storing metadata in etcd (CP) and fitting the dynamic, elastic nature of clusters; it can gracefully drain traffic before a pod exits.

This does not conflict with Spring Cloud, which also offers a Kubernetes integration jar that uses native discovery as a DiscoveryClient.

Consul can be loosely integrated with Kubernetes, but Eureka’s weak consistency makes it unsuitable for the constantly changing pod IPs in Kubernetes.

Load Balancing

Load balancing relies on service discovery; if you adopt Kubernetes Service/DNS for discovery, you can drop the load‑balancing component from the microservice framework because the functionality fully overlaps.

Circuit Breaking, Degradation, Rate Limiting

Kubernetes itself lacks a circuit breaker, so the circuit‑breaking component of a microservice framework remains necessary. Even with a Service Mesh providing circuit breaking, business‑level circuit logic may still be required; the two operate at different granularity.

Hystrix offers limited features, while newer solutions like Alibaba Sentinel support rate limiting, complementing Kubernetes’ native capabilities and overlapping with Service Mesh functions.

Configuration Center

Having tried Spring Cloud Config, Nacos, and Kubernetes ConfigMap/Secret, the author recommends discarding GUI‑based configuration centers in favor of the simplest reliable approach: maintain configuration in Git and deploy it via CI/CD to ConfigMap/Secret.

Summary

Traditional microservice frameworks emerged before the container ecosystem matured; thus, suites like Spring Cloud had to provide a full set of governance capabilities from configuration to service discovery and API gateways.

Now that the container ecosystem is mainstream, many DevOps‑oriented concerns—service discovery, load balancing, configuration center, API gateway—can be better handled by Kubernetes and its ecosystem, allowing developers to focus on business logic and handling circuit‑breaker scenarios.

In short, for newly developed microservices you can forego a complete framework and combine the strengths of each technology, achieving better long‑term benefits and ROI. However, for existing systems, consider team expertise, migration risks, manpower, and cost before removing legacy components.