Spring Boot Microservices mit nativer Kubernetes Service Discovery

Seit wir unsere gesamte Netflix-OSS Cloud-Native- und Spring Cloud-Infrastruktur nach Kubernetes migrieren, wollen wir die meisten Netflix-OSS-Abhängigkeiten loswerden. Features wie Service Discovery über Eureka werden nativ von Kubernetes bereitgestellt und sind nicht mehr nötig, da der Netflix-OSS-Stack zu einer Zeit entstand, als Technologien wie Kubernetes noch nicht existierten.

In den meisten Fällen ersetzen wir auch das Client-Side-Load-Balancing über Ribbon durch Kubernetes (Virtual IPs) Server-Side TCP Load-Balancer (sogenannte Services). Unsere Praxiserfahrung zeigt, dass in 95% der Fälle der Unterschied zwischen beiden Mechanismen so gering ist, dass ein zusätzlicher Hop keinen spürbaren Einfluss hat. Der Vorteil: Wir haben abhängigkeitsfreie Spring Boot Microservices und Services auf anderen Technologien, die alle denselben Kommunikationsweg nutzen. Weniger Konfigurationsaufwand, da Eureka wegfällt, und die Kubernetes-Standard-Load-Balancing-Einstellungen funktionieren hervorragend – Rolling-Upgrades mit Zero-Downtime laufen noch stabiler, unabhängig von der Anzahl der Pods.

Für klassische Spring-Boot-Microservices

Für klassische Spring-Boot-Microservices ist das einfach: Die @EnableServiceDiscovery-Annotation aus der Main-Klasse entfernen und die Eureka-Dependency aus der Build-Datei löschen. Mit Feign kann nun der Hostname oder FQDN des Kubernetes-Services (erstellt via Helm) als URL-Parameter in der @FeignClient-Annotation verwendet werden.

FeignClient Annotation

@FeignClient(url = "http://your-k8s-service-name:port")

Es sollte möglich sein, Port und Protokoll wegzulassen und nur mit Hostnamen zu arbeiten. In diesem Fall braucht man Port 80 in der Kubernetes-Service-Definition, der auf den echten Endpoint/Pod-Port weiterleitet.

FeignClient Annotation nur mit Hostname

@FeignClient(url = "your-k8s-service-name")

Spring-Boot-Admin mit Kubernetes-Service-Discovery und Label-Filter

Zunächst braucht man die Discovery Client-Implementierung, die Servicenamen zu Kubernetes Services auflöst, im Spring-Boot-Admin-Projekt. Einfach als Maven-Dependency hinzufügen:

Maven: Spring Cloud Starter Kubernetes

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-kubernetes</artifactId>
</dependency>

Die gleiche Dependency für Gradle (in die build.gradle einfügen):

Gradle: Spring Cloud Starter Kubernetes

compile group: 'org.springframework.cloud', name: 'spring-cloud-starter-kubernetes', version: '1.0.1.RELEASE'

Wenn die Spring-Boot-Microservices einen separaten Management-Port verwenden (wie wir es aus Sicherheitsgründen tun), muss dem Kubernetes-Service-Discovery-Client in Spring-Boot-Admin mitgeteilt werden, welcher Port aufgelöst werden soll.

application.yml

spring:
  cloud:
    kubernetes:
      discovery:
        primaryPortName: management

Services per Label filtern

Da wir einen gemischten Stack haben und z.B. auch Node.js-Services im Kubernetes-Namespace laufen, wollen wir nicht, dass diese in Spring-Boot-Admin auftauchen – sie haben schließlich keine Actuator- und Management-Endpoints. Dafür können wir Label-basiertes Filtering nutzen.

In diesem Fall werden nur Services abgerufen, die das Label "spring-boot=true" tragen.

application.yml

spring:
  cloud:
    kubernetes:
      discovery:
        serviceLabels:
          spring-boot: true

Endpoints aus mehreren Namespaces abrufen

Da wir sicherheitsrelevante Services in einem eigenen Namespace wie "spring-server" betreiben, brauchen wir die Möglichkeit, Endpoints aus anderen oder allen Namespaces abzurufen. Das war zu diesem Zeitpunkt nicht ohne Workaround möglich. Den Workaround für alle Namespaces findet man hier.