Spring Cloud微服务部署K8s：能否替换Eureka、Zuul为原生组件？

Great question! This is a super common pattern when migrating Spring Cloud microservices to Kubernetes—let’s break down your queries one by one:

1. Is replacing Eureka with Kubernetes Service feasible? #

Absolutely. Kubernetes Service is built to handle exactly the two core jobs Eureka does: service discovery and load balancing. Here’s how it stacks up:

• Kubernetes uses label selectors to automatically group pods belonging to the same service, so you don’t need manual registration like with Eureka.
• Each Service gets a stable ClusterIP (or internal DNS name like {service-name}.{namespace}.svc.cluster.local) that stays consistent even when pods are rescheduled, scaled, or replaced.
• The kube-proxy component handles distributing traffic across all healthy pods in the Service, acting as a built-in load balancer.

The key shift is from Eureka’s client-side discovery (your apps query Eureka directly) to Kubernetes’ server-side discovery (your apps only need to know the Service’s DNS/IP, and Kubernetes handles the rest). You’ll just need to adjust your microservices to call the Kubernetes Service address instead of using Eureka service names for lookups.

2. How does Zuul recognize services to forward requests to? #

Since you’re ditching Eureka, Zuul can’t pull service registries from it anymore. Instead, you can configure Zuul’s routing rules directly to point to your Kubernetes Services:

Option 1: Static route configuration #

Update your application.yml to map request paths to Service addresses explicitly:

zuul:
  routes:
    product-service:
      path: /product/**
      url: http://product-service.default.svc.cluster.local:8080
    order-service:
      path: /order/**
      url: http://order-service.default.svc.cluster.local:8080

Replace default with your actual Kubernetes namespace if it’s different.

Option 2: Ribbon without Eureka #

If you’re using Ribbon alongside Zuul, you can disable Eureka integration and specify Service addresses directly for client-side load balancing:

product-service:
  ribbon:
    eureka:
      enabled: false
    listOfServers: product-service.default.svc.cluster.local:8080
order-service:
  ribbon:
    eureka:
      enabled: false
    listOfServers: order-service.default.svc.cluster.local:8080

3. Kubernetes-native alternatives to Zuul #

Yes, Kubernetes has built-in components that can replace Zuul’s API gateway functionality:

• Ingress: The most popular choice. An Ingress resource defines routing rules to forward external HTTP/HTTPS traffic to internal Services. It supports path matching, SSL termination, and works with controllers like NGINX Ingress or Traefik.
• Gateway API: An evolution of Ingress, offering more flexible routing (like TCP/UDP traffic, header-based routing, and cross-namespace routing). It’s the modern, recommended way to handle API gateway needs in Kubernetes.
• Service NodePort/LoadBalancer: These are simpler for exposing individual services, but they don’t offer the full API gateway features (like path-based routing across multiple services) that Zuul or Ingress provide.

4. How to run the app locally or in non-Kubernetes environments? #

You can maintain compatibility across environments with these approaches:

• Profile-based configuration: Use Spring profiles to switch setups:
  • dev profile: Enable Eureka and Zuul, configure services to register with a local Eureka server.
  • prod profile: Disable Eureka, point services to Kubernetes Service addresses, and use Ingress instead of Zuul.
• Docker Compose for local dev: Spin up a local Eureka server, Zuul, and your microservices using Docker Compose. This mimics your original Spring Cloud stack without Kubernetes.
• Local reverse proxy: Use NGINX or Apache as a local proxy to route requests to your running microservices (similar to Ingress), and have services communicate directly via localhost ports if you don’t want to run Eureka.

内容的提问来源于stack exchange，提问作者javafan